服务器出现大量 CLOSE_WAIT 怎么排查？和 TIME_WAIT 堆积有什么区别？

知识点详解：收到关闭，应用为什么还没结束？

FIN 只表示一个发送方向结束

假设本地调用外部接口，对端先发 FIN。它表示对端不再发送新数据，不等于两个方向瞬间被强制关闭。

本地确认后可以进入 CLOSE_WAIT。应用读到 EOF 等结束信息，按协议处理剩余工作，再关闭。

TCP 可以半关闭，因此在允许状态与业务约定下，本地仍可能发送数据。这也是短暂 CLOSE_WAIT 不必代表错误的原因。状态含义见 RFC 9293。

持续增长，为什么指向本地生命周期？

读完忘关闭，或异常跳过释放，就可能长期保留连接。

假设只有下载接口的连接不断增加。先按 PID 找持有进程，再按远端统计，缩小到相应客户端。

检查正常完成、读超时、解析失败和提前返回时，响应有没有释放。连接池中，释放响应体通常是归还入口，但是否复用或关闭底层连接，要看库。

不能看到代码有一个 close，就认为所有路径覆盖。要明确资源从创建到结束归谁管理。

怎样排查，而不是先改参数？

Linux 可用 ss 筛选 close-wait，并在相应权限下查看进程，定义见 ss 手册。

记录数量、连接年龄、远端分布与增长速度，再关联超时、失败和文件描述符数量。

流量稳定但未释放连接持续增加，更支持泄漏线索；短暂出现又消失，可能是正常关闭窗口。在授权测试环境让对端提前关闭，覆盖正常、异常、超时，确认资源数量恢复。

图：追到持有资源的具体请求路径。

TIME_WAIT 为什么不能同样处理？

TIME_WAIT 常在主动关闭完成后保留协议状态。大量短连接可能形成大量 TIME_WAIT，即使应用正确关闭。

前者结合连接复用、建立速率和端口资源评估；CLOSE_WAIT 首先检查应用释放。

复杂关闭情形还要按状态机分析，例如同时关闭。不能把常见单方主动关闭的简化模型说成无条件规则。

面试官继续追问

重启后消失，证明什么？

证明进程资源被释放，提供生命周期线索。但没定位遗漏代码，可能重新出现。

服务端一定被动关闭吗？

不是。主动关闭由谁先发起决定，不由客户端/服务端身份固定。

增大描述符上限能解决吗？

只能延后耗尽。合理上限和泄漏修复分开处理。

面试速记卡

• CLOSE_WAIT：收到对端 FIN，等待本地关闭。
• 排查：进程、远端、趋势和异常释放路径。
• 客户端：响应体、池归还和 socket 生命周期分清。
• TIME_WAIT：协议等待，不等于同类泄漏。
• 修复：资源所有权清楚，正常异常都释放。