inotify与dnotify的区别

说到 Linux 系统下的文件系统监控，inotify 和 dnotify 这两个名字一定不陌生。它们都能盯着文件或目录的一举一动，但背后的实现逻辑和实际表现，差别可不止一星半点。

inotify

1. 内核级支持，天生高效
   inotify 是 Linux 内核的原生机制，直接在内核空间干活，实时性、灵活性都没得说。它能监测文件或目录的创建、删除、修改等各种变动，精度很高。

2. 事件类型丰富，覆盖全面
   支持的事件种类相当多——打开、关闭、读取、写入、移动、重命名……基本你能想到的文件操作，它都能感知到。而且可以通过 API 按需定制感兴趣的事件，不浪费资源。

3. 性能优化出色
   采用事件驱动模型，不是轮询那种“傻等”的方式，所以系统调用少、资源消耗低。可以灵活设置监控文件数量上限以及事件队列长度，应对高并发场景也不慌。

4. 跨平台趋势明显
   虽然最初只为 Linux 而生，但如今 macOS、Windows 等系统也出现了类似机制，算是业界标杆级的设计思路。

5. API 接口丰富，开发友好
   提供了一整套 API 函数，开发者拿来就能用，集成成本低，扩展也方便。

6. 生态主流，成为标准
   高效又灵活，inotify 早已成为众多 Linux 应用的首选监控方案，几乎无处不在。

dnotify

1. 用户级守护进程，轮询低效
   dnotify 运行在用户空间，靠轮询文件系统来发现变化。说白了就是“每隔一会儿看一眼”，不仅响应慢，而且 CPU 和 I/O 开销都比较大。

2. 事件类型有限，灵敏度不足
   主要能捕捉到文件的创建、删除和修改三类基础事件。一旦涉及文件内容的局部改动，它可能根本反应不过来。

3. 配置极其简单
   好处是上手快——只需要指定要监控的目录，不用关心内核那些细节，适合快速搭个简易方案。

4. 兼容老旧系统
   在早期的 Linux 发行版中比较常见，所以如果你还在维护一些老古董机器，dnotify 可能还存在。

5. API 少，灵活性差
   和 inotify 没法比，API 数量少且功能单一，遇到复杂监控场景基本束手无策。

6. 逐步被淘汰
   随着 inotify 的成熟和普及，dnotify 的使用量已经急剧下滑，很多现代 Linux 发行版甚至不再默认安装它。

如何选择？

如果你的需求是高效、实时地监控文件系统的各种变化，且愿意花一点时间熟悉 API，那 inotify 毫无疑问是首选。反过来，如果只想要最基础的监控功能，又希望配置尽可能简单，那 dnotify 或许还能凑合用——但必须提醒一句：性能和功能上的短板决定了它扛不住大规模或复杂的监控任务。

所以，一句话总结：当下大多数场景，直接上 inotify 就够了。