一眼看出fd是否在涨：用watch -n 1 'ls /proc/pid/fd/ | wc -l'实时监控，数字持续上升即泄漏；再用lsof -p pid | grep -e "(socket|anon_inode)"统计异常类型，结合strace或perf跟踪open/close是否成对。
怎么一眼看出某个进程 fd 数在涨
直接盯住 /proc/[pid]/fd/ 目录数量变化最有效。泄漏不是静态的，是随时间推移持续增长的。
- 先用
ls /proc/<pid>/fd/ | wc -l</pid>记下当前值 - 再用
watch -n 1 'ls /proc/<pid>/fd/ | wc -l'</pid>每秒刷新一次，如果数字稳定不动，基本可排除泄漏；若持续+1、+2甚至跳变，问题就在这个进程里 - 注意：
watch默认会高亮变化行，比手动敲命令省眼力
别依赖单次 lsof -p <pid></pid> 输出——它只反映快照，而泄漏往往藏在“开得多、关得少”的节奏里。
为什么 lsof -p <pid></pid> 里一堆 socket 或 anon_inode
这两类 fd 占比异常高，基本就是泄漏信号。socket 表示网络连接没关，anon_inode 常见于 epoll、eventfd、timerfd 等内核对象未释放。
-
lsof -p <pid> | grep socket | wc -l</pid>统计 socket 数量，对比业务并发量是否合理（比如只有 10 个请求，却有 200+ socket） -
lsof -p <pid> | grep anon_inode</pid>若输出大量重复路径如anon_inode:[eventpoll]，说明 epoll 实例或定时器没 close - 特别留意
NAME列带(deleted)的条目——文件已被 rm，但进程还握着 fd，典型“删了日志但服务没 reload”场景
如何快速定位到具体哪段代码漏关
靠人肉扫代码效率极低，优先用系统级跟踪确认 open/close 是否成对出现。
- 用
perf trace -e syscalls:sys_enter_openat,syscalls:sys_enter_close -p <pid></pid>实时抓系统调用，观察是否有 open 调用后长期不见对应 close - 若环境不支持 perf，改用
strace -p <pid> -e trace=open,openat,close,closefrom 2>&1 | grep -E "(open|close)"</pid>，注意加-v可看参数（如文件路径、返回 fd） - 对 C/C++ 进程，检查是否用了
FD_CLOEXEC：fork 后子进程继承父进程 fd 是默认行为，若子进程不操作这些 fd 却又不设标志，它们就变成“幽灵句柄”
Java 进程要额外注意：try-with-resources 不是银弹，若底层 native 资源（如 JNI 创建的 socket）没在 finalize 或 Cleaner 中显式 close，照样泄漏。
systemd 服务启动后 fd 限制还是 1024 怎么办
ulimit -n 临时生效，但 systemd 服务默认不读 shell 的 limits 配置，必须显式声明。
- 编辑服务 unit 文件，加入
LimitNOFILE=65536（数值按需调整），然后systemctl daemon-reload && systemctl restart xxx - 验证是否生效：
systemctl show <service-name> | grep LimitNOFILE</service-name>，或查/proc/<pid>/limits</pid>中Max open files行 - 容器环境（Docker/K8s）需同步透传：Docker 加
--ulimit nofile=65536:65536，K8s 在securityContext里配limits.nofile
调高 limit 只是买时间，不是治病。真正难的是在 fd 数刚过 1000 就触发告警，而不是等它涨到 65535 才发现——监控阈值建议设为软限制的 70%。
