根本原因在于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实例会创建一个inotifyfd - Node.js 的
fs.watch()每调用一次就新增一个inotifyfd；若递归监听目录且未复用 watcher，极易泄漏 - Java NIO 的
Selector.open()每次调用都新建一个epollfd（即使未注册 channel），Spring Boot DevTools 默认启用文件监听，常导致多个inotifyfd - Python 的
watchdog库若未显式调用observer.stop()，其inotifyfd 不会释放
快速定位泄漏源头的实操步骤
别急着改代码，先用系统工具交叉验证：
- 对比
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，检查是否挂载了过多目录（
inotifyfd 数 = 监听目录数 × 子目录深度），特别是/proc或/sys下的动态路径
真正难排查的从来不是 “有多少 fd”，而是 “谁在持有着一个 inotify 实例却不释放它”——这类 fd 没路径、没名字、生命周期脱离业务逻辑，只能靠 fdinfo + strace + 代码审计三路印证。
