应检查 /proc/$PID/fd/ 下真实 fd 数量，因 lsof 可能漏掉 eventfd、timerfd 等匿名 inode 类型 fd；直接统计 ls -1 /proc/$PID/fd/ | wc -l 并对比 limits 中 soft limit，确认是否耗尽，并排查未 close 的系统调用。
当 Linux 进程打开的文件句柄数达到 ulimit -n 限制，却用 lsof -p $PID 查不到多少打开的 fd，说明存在“不可见”或“难以枚举”的文件描述符。这些 fd 通常不对应常规文件、socket 或设备，而是内核内部对象，lsof 默认不显示或无法识别。
检查 /proc/$PID/fd/ 下真实 fd 数量
lsof 可能漏掉某些 fd（如 eventfd、timerfd、signalfd、userfaultfd、io_uring 相关 fd），但 /proc/$PID/fd/ 是内核提供的权威视图——每个数字子目录即一个打开的 fd。直接统计更可靠：
- 运行
ls -1 /proc/$PID/fd/ | wc -l，得到实际 fd 总数 - 对比
cat /proc/$PID/limits | grep "Max open files"中的 soft limit - 若前者接近或等于后者，确认是 fd 耗尽；再用
ls -la /proc/$PID/fd/观察是否有大量类似anon_inode:[eventfd]、anon_inode:[timerfd]的条目
关注匿名 inode 类型 fd
这类 fd 由内核动态创建，不绑定路径，lsof 默认不解析其类型（除非加 -v 或特定编译选项）。常见隐藏来源包括：
- eventfd/timerfd/signalfd：常用于线程间通知、超时控制，尤其在高并发 I/O 框架（如 epoll + timerfd 实现定时器）中易累积
- inotify 实例：每个
inotify_init()创建一个 fd，lsof显示为inotify，但若未显式关闭且监听大量路径，可能被忽略 - io_uring ring fd：现代异步 I/O 框架（如 liburing）会持有一个或多个 io_uring 实例 fd，长期存活
- memfd_create() 创建的内存文件：显示为
memfd:xxx，但某些旧版lsof不识别
排查程序逻辑与资源释放缺陷
隐藏 fd 并非“自动产生”，而是程序调用相应系统调用后未正确 close。重点检查：
- 是否在循环中反复
eventfd(2)或timerfd_create(2)却未配对close() - 是否 fork 后子进程继承了父进程的 fd，但未在子进程中关闭无关 fd（尤其守护进程化时遗漏）
- 异常路径（如错误处理分支、信号中断）中跳过了
close()调用 - C++ RAII 或 Go defer 等机制是否覆盖所有路径，或存在 panic/panic recovery 导致 defer 未执行
辅助诊断 工具 与方法
单靠 lsof 不足，需组合使用：
-
cat /proc/$PID/status | grep -i fdsize：查看当前已分配 fd 位图大小（近似上限） -
strace -e trace=clone,open,openat,socket,eventfd,timerfd_create,close -p $PID -f 2>&1 | grep -E "(eventfd|timerfd|close.*[0-9]+)"：实时抓取 fd 创建 / 关闭行为（注意性能影响） - 若程序支持，启用内部 fd 统计（如 Nginx 的
ngx_http_limit_conn_module日志、Redis 的INFO clients中connected_clients与client_recent_max_input_buffer等间接指标） - 使用
bpftrace或perf跟踪内核中sys_close、sys_eventfd等事件，定位泄漏源头
