需同步监控进程fd占用率、tcp连接状态分布、连接池空闲连接老化程度三指标：fd占用长期＞85%且每分钟增≥50、close_wait/established异常堆积、connection_pool_max_idle_time未生效或心跳未启用，三者并发异常方可确认长连接未释放导致句柄锁死。
不能只看“连接数”或“句柄数”单个数字，要抓三个联动指标：进程级 fd 实时占用率、TCP 连接状态分布、以及连接池空闲连接老化程度。这三者同步异常，才能确认是长连接未释放引发的系统级句柄锁死，而非临时抖动或配置不足。
看进程 fd 占用率是否持续高位且不可回收
这是最直接的判断依据：
- 执行 ls /proc/$(pgrep -f 'your-service')/fd | wc -l 获取当前打开句柄数
- 对比该进程生效的上限：cat /proc/$(pgrep -f 'your-service')/limits | grep "Max open files"（注意看 soft:hard 两列）
- 若占用长期 >85% 且每分钟增长 ≥50，同时 lsof -p PID | grep socket | wc -l 占比超 70%，基本可锁定为长连接堆积
查 TCP 连接状态是否大量滞留 CLOSE_WAIT 或 ESTABLISHED
长连接未释放会反映在 TCP 状态上，不是所有 ESTABLISHED 都健康：
- 运行 ss -tanop | grep ':
' | awk '{print $1}' | sort | uniq -c ，重点观察 CLOSE_WAIT 和 ESTABLISHED 的数量级 - CLOSE_WAIT 大量存在（如 >500），说明对端已关闭，本端应用未调用 close()，是典型的资源泄漏信号
- ESTABLISHED 持续不降且无实际数据交互（可用 tcpdump -i any port
-c 100 抽样验证），说明连接僵死未被心跳或空闲策略清理
核验连接池空闲连接是否真正归还
很多系统声称“连接自动回收”，但实际未生效：
- 检查客户端配置中 connection_pool_max_idle_time 是否设置合理（建议 ≤180 秒），并确认是否启用 heart_beat_interval
- 在日志中搜索 “connection pool is full”、“get connection timeout”、“failed to return connection” 等关键词
- 若使用 FastDFS v6.0+，可通过 client.getPoolStats()（如有暴露接口）或 JMX 查看 active/idle 连接数；旧版本只能靠 lsof + 状态分布反推
这三个指标必须同时满足异常特征，才能排除误判——比如 ulimit 被人为调低、内核参数 fs.file-max 不足、或只是瞬时流量峰值。真正的句柄锁死，是“占着不放、关不掉、收不回”的三重失效。
