使用 inotify 踩过的坑

Inotify 用于监听文件系统的变更，我们有个场景需要监听一个根目录下的所有文件，包括不同深度子目录下的文件，如果文件发生变化，增量读取新增的内容。

之前我们使用轮询的模式，周期性递归遍历根目录，对比文件属性信息选择要读取的文件，这种方式有一个问题就是周期很难选择：

所以我们考虑用系统级别的 inotify 替换掉轮询的逻辑，结果踩了不少坑。。。

1. JDK 封装的问题 —— poller

jdk 将 inotify 的功能封装为 WatchService，使用起来非常简单，sample 中还提供了一个递归注册目录的例子 WatchDir.java。

由于 inotify 只支持 1.监听文件，2.监听目录，以及目录下的目录和文件，不能监听子目录下的变更，所以需要递归注册目录。

基于官方的 sample 我们很快就用上了 inotify，效果很不错，不仅 CPU 占用下降了，而且文件读取特别均匀。

直到有一天 CPU 使用率开始飚高了，通过 top 和 jstack 发现占用 CPU 最多的线程不是读文件的线程，而是 LinuxWatchService 中的 poller 线程。

poller 线程的作用如上图所示：

poll requestList，处理业务代码中的目录注册、取消和关闭等请求；
poll inotify 文件描述符获取 inoitfy_event, 然后按照 WatchKey （也就是 watch descriptor）放到不同的队列，队列的长度默认为 512，如果队列满了，那么清空队列并且放入 overflow 事件。

由于我们监听的目录比较多，当大量文件频繁修改的时候是会产生大量的事件，而 poller 线程会尽最大能力读取这些事件，所以造成了很高的 CPU 占用。

然后这是一种无用功，因为 1.事件数量超出 WatchEvent 队列长度，上层业务逻辑也就取不到事件；2. inotify 的文件队列也有简单的事件去重逻辑，没必要特别快地读取事件然后再去重。

实际上 poller 的速度应该受制于下游的处理能力，如果下游已经不能处理，那么暂时放在中转队列也是意义不大的，我们只需要依赖 inotify 的文件队列即可。

顺便提一下 inotify 相关的几个系统参数：

所以我们通过 JNI 调用重新实现了 WatchService 的逻辑，去掉了 poller 线程，由业务线程控制 poll 的频率。

然后一切又变正常了，只是偶尔有几条莫名其妙的 MODIFY 事件。

读到 MODIFY 事件，首先需要读取文件属性，然后走不同的逻辑，但是此刻却抛出 NoSuchFileException。

这个问题一开始也毫无头绪，甚至怀疑是不是文件瞬间被删除了。。。

直到有一天想起了 lsof 这个命令，验证了一下：

REG                8,6        16    6161077 /xxx/xxx/xxx/xxx (deleted)

果然是文件被删除了，但是打开的文件描述符没有关闭，而且还偶尔在写数据。

然后一切又变正常了，文件不存在的 MODIFY 事件归咎于业务方程序的问题。

但是又遇到了新的问题，偶尔发现存在没有读取的文件，而且是整个子目录下的所有文件都没有读。

由于我们监听的目录比较多，有些机器上有约五千个监听目录，所以偶尔会发生事件 overflow，我们猜测是目录创建的事件被 overflow 了，所以没有监听到这个目录。

针对这个问题，我们添加了一个周期性重新递归注册的机制。

由于 inotify 是基于 inode 的，所以重复注册目录获得的 wd (watch descriptor) 是一样的，但是如果目录被移除然后重建了，那么就是一个新的 wd。

此处由于一个 bug 使得问题更严重，由于需要构建文件的绝对路径，我们采用 guava 的 BiMap 存储 wd 与 path 之间的映射，完成 inotify_add_watch 之后需要更新 wdToPath

调用 BiMap 的 put 方法，如果存在遗留的 path，那么是会抛出 IllegalArgumentException 的，所以首先需要处理这种情况，然后调用 forcePut 覆盖旧的映射。

移动监听目录这个场景，由于写代码的时候没有考虑，第一次发现这个问题着实被吓了一下。

有些业务方的重启脚本有保存历史日志的逻辑，也就是 mv 旧的日志根目录，然后创建一个新的日志根目录。

由于 inotify 是基于 inode 的，所以 mv 后的目录还在监听中，并且 wd 没有变化，所以目录下文件的改动还是会触发事件。触发事件不可怕，关键是通过 wdToPath 映射还原的绝对路径已经不对了。

在我们的使用场景中，将 mv 作为删除处理即可，所以注册目录时默认加上 IN_MOVE_SELF 事件监听，如果收到该事件，那么 forceUnregister 这个 wd，如果事件 overflow 了，那么还是依赖周期性重新注册的机制。

本文只是粗略记一下遇过的问题，inotify 的详细介绍可以参考下述文章。

如果觉得我的文章对您有用，请随意打赏。