要确认是不是发生了 FD 泄漏，不能只看某一个瞬间，得用 watch -n 1 'ls /proc/PID/fd/ | wc -l' 持续盯着变化。要是这个数字一直比较稳定地往上走，比如 30 秒内增加了 20 个，那基本就该提高警惕了；再减去 3，才是实际打开的数量。接着配合 lsof -n -P -p PID 一起看：如果 FD 列还在持续递增，或者出现 TYPE=REG 且带有 (deleted)，又或者 TYPE=sock 找不到对应业务连接这类异常模式，到了这一步，才能判断是泄漏。
怎么确认 FD 真在泄漏，而不是瞬时高峰
单次 lsof -p PID 或 ls -l /proc/PID/fd/ | wc -l 只是快照，毫无判断力。泄漏的本质是“开得多、关得少”的持续累积。
- 用
watch -n 1 'ls /proc/PID/fd/ | wc -l'每秒刷新，盯住数字是否稳定——跳变或缓慢爬升（比如 30 秒内 +20）就是铁证 - 同时跑
lsof -n -P -p PID 2>/dev/null | grep -E "^(ja va|python|node)" | head -15，看新增句柄是否集中于某类资源（如全是socket:[...]或/tmp/xxx.log） - 注意：
ls -l /proc/PID/fd/ | wc -l结果要减 3（0/1/2 是标准流），才是实际打开数；lsof -p PID | wc -l要减 1（首行是表头）
哪些 FD 行一出现就该立刻怀疑泄漏
lsof -p PID 输出里，FD 列和 TYPE+NAME 组合才是关键线索，不是所有数字都危险。
FD列持续出现递增数字（如1024r、1025w、1026u…），且NAME都指向同一路径（如/var/log/app.log或/tmp/upload_abc）→ 文件反复open却没closeTYPE=REG且NAME含(deleted)→ 文件已被unlink，但句柄未释放，磁盘空间卡死不回收TYPE=sock+STATE=ESTABLISHED但无对应业务连接（比如 HTTP 客户端只发请求不close()）TYPE=anon_inode或pipe数量与线程数强相关（每多一个线程就多 2 个pipe+ 1 个eventpoll）→ epoll 或异步 I/O 初始化后没清理NAME为空 或 显示socket:[1234567]→ 必须进/proc/PID/fd/用ls -l反查真实目标，这类抽象句柄最容易被忽略
如何快速定位到代码级泄漏源头
靠扫代码效率极低，优先用系统调用跟踪确认 open/close 是否成对。
- 用
strace -p PID -e trace=open,openat,close,closefrom -v 2>&1 | grep -E "(open|close)at?"，观察是否有openat成功返回 fd（如3）但后续不见close(3) - 对 C/C++ 进程，检查是否漏设
FD_CLOEXEC：子进程继承父进程 fd 后若不操作也不关闭，就会变成“幽灵句柄” - Ja va 进程别迷信
try-with-resources：JNI 创建的 socket、native 文件句柄若没在Cleaner或finalize中显式close，照样泄漏 - 日志轮转场景下，重点比对
lsof -p PID | grep "access.log"和ls -la /var/log/nginx/access.log*，看进程是否还在写已轮转的旧文件
为什么 lsof 看不到泄漏，但 still get “Too many open files”
这是最常踩的坑：lsof 默认只显示当前存活的句柄，而某些泄漏是“瞬时创建 + 长期持有”，或根本不在 lsof 的识别范围内。
lsof不显示被dup2覆盖但未close的旧 fd（它们仍有效，但lsof可能只列新 fd）- 容器环境（如 rootless Podman）或某些内核模块下，
lsof权限受限，无法读取全部/proc/PID/fd/符号链接 - 短连接高频场景（如每秒数百次 REST 调用），
lsof快照抓不到瞬态 fd，但ulimit -n限制很快耗尽 - 真正可靠的底层数值永远是
ls -l /proc/PID/fd/—— 它直接读内核数据，不依赖用户态解析逻辑
