close_wait大量堆积本质是应用未调用close()关闭socket，导致连接卡在被动关闭阶段；需用ss -tnop state close-wait定位进程，再查代码中http客户端、数据库连接、i/o超时及异常路径的资源释放逻辑。
端口上 CLOSE_WAIT 大量堆积，本质不是端口问题，而是应用没关连接——对端（比如数据库、下游服务）已经发 FIN 关闭了，你的进程收到并回了 ACK，却迟迟不调 close()，socket 描述符就卡在 CLOSE_WAIT，持续占用文件句柄和端口资源。
快速定位哪个进程在“卡连接”
用 ss 查当前所有 CLOSE_WAIT 连接，并关联到进程：
-
ss -tnop state close-wait—— 显示带 PID 和 fd 编号的 CLOSE_WAIT 连接（需 root 权限） - 若输出类似
users:(("java",pid=12345,fd=102))，说明 PID 12345 的 Java 进程正持有该 socket - 再用
lsof -p 12345 | grep TCP确认它到底有多少 socket 停在 CLOSE_WAIT
确认是不是真泄漏：看句柄数是否逼近上限
CLOSE_WAIT 不释放，最终会拖垮整个进程：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 查当前进程打开的文件数：
ls /proc/12345/fd | wc -l - 对比系统限制：
cat /proc/12345/limits | grep "Max open files" - 如果接近或达到上限（如 1024 或 65535），就会出现
Too many open files，新连接直接失败
聚焦代码层：常见没关连接的场景
不是内核参数能解决的，必须改代码或配置：
- HTTP 客户端未复用连接：Python requests 每次都新建 session，Java OkHttp 未配 connection pool
- 数据库连接未归还：JDBC 使用完没 close() Statement/ResultSet，或连接池配置过小+超时不合理
- 网络读写阻塞未设超时：Socket
read()卡住，后续close()永远不执行；务必设置setSoTimeout() - 异常路径遗漏关闭：try-catch 中只在 try 块里 close()，catch 后没兜底关闭
辅助验证：有没有其他状态一起异常
有时 CLOSE_WAIT 堆积会连带暴露更深层问题：
- 同时看到大量
FIN_WAIT2？可能是本端发了 FIN，但对端不回 ACK，说明对方进程僵死或网络中断 - 大量
TIME_WAIT+ CLOSE_WAIT 并存？说明既有短连接风暴，又有服务端不关连接，要分头治理 - 用
netstat -s | grep -i "embryonic"看半连接队列是否溢出，排除 SYN 攻击干扰判断
