WatchService 是怎么监听文件变化的?延迟有多大?事件长什么样?这篇在 macOS 上实测(Linux 上是另一种实现,本篇没有验证),并给出使用时必须注意的 reset 与不递归(文件系统相关的 NIO 篇目在附近)。
WatchService 的实现类:sun.nio.fs.PollingWatchService 默认灵敏度:创建文件 → 收到事件的延迟(秒)= [1.71, 1.99, 2.00] SensitivityWatchEventModifier.HIGH:创建文件 → 收到事件的延迟(秒)= [1.70, 2.00, 2.00]
创建 a.txt 并写入 → [CREATE(a.txt)] 覆盖写 a.txt → [MODIFY(a.txt)] 连续追加 3 次 → [MODIFY(a.txt)] 重命名 a.txt → b.txt → [CREATE(b.txt), DELETE(a.txt)] 删除 b.txt → [DELETE(b.txt)] 创建子目录 sub → [CREATE(sub)] 在子目录 sub 里创建文件(没有注册 sub) → [MODIFY(sub)]
第一次创建:收到 key = true,事件 [CREATE(one)],key.isValid() = true 没有调用 key.reset() 就再创建一个文件:6 秒内收到事件吗?false(不 reset,这个 key 不会再入队) key.reset() 之后:收到 [CREATE(two)] 删除被监视的目录之后:key.isValid() = false