too many open files 但 lsof 显示很少的隐藏 fd 类型汇总

根本原因在于lsof默认不显示无文件路径或inode的匿名fd（如eventpoll、inotify等），而它们仍计入ulimit限制；真实fd数应通过ls /proc/$PID/fd/ | wc -l获取。

为什么 lsof 看不到大量打开的文件描述符？

根本原因在于 lsof 默认不显示某些内核维护的、无对应文件路径或 inode 的“隐藏” fd。这些 fd 不在常规文件系统命名空间中，lsof -p $PID 会跳过它们，但它们仍计入进程的 ulimit -n 限制，触发 Too many open files 错误。

常见被 lsof 忽略的 fd 类型包括：

• eventpoll（epoll 实例，类型为 anon_inode，lsof 显示为 anon_inode:[eventpoll]，但默认过滤掉）
• inotify、signalfd、timerfd、eventfd 等匿名 inode fd
• 已 unlink 但仍有引用的文件（lsof 可能显示为 DEL，但数量少且易被忽略）
• socket fd 中处于 CLOSE_WaiT 或 TIME_WAIT 但未被正确 close 的连接（尤其在高并发短连接场景下堆积）

如何查到真正的隐藏 fd 数量？

直接读取 /proc/$PID/fd/ 目录是最可靠的方式——它列出所有 fd 句柄，不论类型。配合 ls 和 wc 即可获得真实总数：

ls -1 /proc/$PID/fd/ | wc -l

若要分类统计隐藏 fd，可用：

ls -la /proc/$PID/fd/ | awk '{print $11}' | sort | uniq -c | sort -nr | head -20

重点关注输出中类似以下的路径（它们代表匿名 inode）：

• anon_inode:[eventpoll]
• anon_inode:[inotify]
• socket:[12345678]（数字为 inode 号，非端口）
• pipe:[98765432]

注意：不要依赖 lsof -p $PID | wc -l 做容量判断，它通常比真实 fd 数少 30%–80%，尤其在使用 epoll 的 go/Node.js/java nio 服务中。

哪些编程模型最容易积累 eventpoll/inotify fd？

不是文件操作多才开得多 fd，而是事件驱动模型中「每个事件源」都可能独占一个 fd。典型场景：

• Go 的 net/http.Server 在 linux 上默认用 epoll，每个活跃连接不额外占 fd，但每个 fsnotify.Watcher 实例会创建一个 inotify fd
• Node.js 的 fs.watch() 每调用一次就新增一个 inotify fd；若递归监听目录且未复用 watcher，极易泄漏
• Java NIO 的 Selector.open() 每次调用都新建一个 epoll fd（即使未注册 channel），spring Boot DevTools 默认启用文件监听，常导致多个 inotify fd
• python 的 watchdog 库若未显式调用 observer.stop()，其 inotify fd 不会释放

快速定位泄漏源头的实操步骤

别急着改代码，先用系统工具交叉验证：

• 对比 ls /proc/$PID/fd/ | wc -l 和 cat /proc/$PID/status | grep 'FDSize|FDMax'，确认是否真逼近上限
• 用 cat /proc/$PID/fdinfo/* 2>/dev/NULL | grep -E '^(flags|ino|path):' | head -50 查看任意几个 fd 的详细信息，识别类型
• 对疑似泄漏进程，执行 strace -p $PID -e trace=epoll_ctl,inotify_add_watch,open,close -f 2>&1 | grep -E '(epoll_ctl|IN_ADD)'，观察是否持续新增
• 若用 docker，检查是否挂载了过多目录（inotify fd 数 = 监听目录数 × 子目录深度），特别是 /proc 或 /sys 下的动态路径

真正难排查的从来不是 “有多少 fd”，而是 “谁在持有着一个 inotify 实例却不释放它”——这类 fd 没路径、没名字、生命周期脱离业务逻辑，只能靠 fdinfo + strace + 代码审计三路印证。