Java WatchService基于系统原生事件机制（如inotify）高效监听文件变化，需按获取FileSystem、创建服务、注册路径、循环处理WatchKey流程使用；注册路径须存在且仅监听直接子项，多级需递归注册；须调用key.reset()并用try-with-resources确保关闭，避免资源泄漏与事件丢失。
Java中通过WatchService监听文件变化，核心是利用操作系统底层的文件系统事件通知机制（如Linux的inotify、Windows的ReadDirectoryChangesW），而非轮询，因此高效且低开销。
WatchService基本使用流程
监听需按固定步骤：获取FileSystem → 创建WatchService → 注册路径并指定监听事件类型 → 启动循环等待并处理WatchKey。
- 注册路径必须是
Path对象，且该路径需存在（不能监听不存在的目录） - 支持的事件类型包括：
ENTRY_CREATE、ENTRY_MODIFY、ENTRY_DELETE；注意ENTRY_MODIFY在不同系统行为有差异（例如文本文件保存可能触发多次） - 每个
WatchKey被消费后需调用key.reset()，否则后续事件不会再次入队
监听多级目录的注意事项
WatchService默认只监听注册路径的**直接子项**，不递归。若需监听整个目录树，需手动遍历子目录并逐个注册，或借助第三方库（如Apache Commons IO的FileAlterationObserver）。
- 注册子目录时，建议使用
Files.walkFileTree()配合SimpleFileVisitor递归注册 - 注意避免重复注册同一路径，也需考虑软链接和权限问题导致的注册失败
- 注册过多路径可能耗尽系统资源（尤其inotify句柄数有限制，Linux默认通常为8192）
线程安全与资源释放
WatchService本身不是线程安全的，且其内部依赖本地资源，必须显式关闭。
立即学习“Java免费学习笔记（深入）”；
- 推荐用try-with-resources方式创建和关闭（JDK7+），确保
close()被调用 - 监听线程应单独管理，避免阻塞主线程；可结合
ExecutorService做事件分发 - 收到
OVERFLOW事件说明事件丢失，需结合业务做补偿（如全量比对或日志告警）
常见坑与替代方案
原生WatchService功能基础，实际项目中易遇兼容性或稳定性问题：
- macOS上对某些操作（如Finder移动文件）响应不及时或漏事件
- 无法监听文件内容修改细节（比如改了哪一行），仅能感知“被修改”动作
- 部分IDE或编辑器（如VS Code、IntelliJ）保存时先写临时文件再原子替换，此时触发的是
CREATE+DELETE而非MODIFY - 如需更高可靠性，可考虑jnotify（JNI封装）、watchservice-plus（增强版封装）或Spring的FileSystemWatcher（基于WatchService但做了异常重试和路径管理）
基本上就这些。WatchService不复杂但容易忽略重置key和资源释放，上线前务必在目标环境实测事件覆盖度。
