CLOSE_WAIT 表示本机 TCP 收到对端 FIN,确认对端已经关闭其发送方向,但本机应用尚未关闭本地发送方向。TCP 是全双工的:对端停止发送后,本机仍可以发送剩余数据,应用完成后调用关闭操作,本机才会发 FIN 并进入后续关闭状态。
因此少量、短暂的 CLOSE_WAIT 是连接关闭中的正常状态;大量连接长期停留通常提示应用没有及时关闭 Socket,可能是代码路径遗漏、异常未清理、连接池生命周期不当或线程阻塞。排查时先找进程、远端地址、持续时间和增长趋势,再关联应用日志、线程栈、连接池指标及异常路径。确认资源释放逻辑覆盖成功、超时和异常分支。
单看 netstat/系统连接数不能证明具体代码错误。也要排除对端行为、代理和采样时机的影响。TIME_WAIT 通常是主动关闭一方最后等待 ACK/旧报文消退;CLOSE_WAIT 是本机等待应用关闭,处理方向完全不同。
定位时把连接状态和应用请求关联起来:检查是否有未关闭的响应体、数据库/HTTP 客户端连接、读写超时缺失或阻塞线程。连接池配置也要确认借出后是否归还、失效连接能否回收。若 CLOSE_WAIT 数量只在流量峰值短暂上升,需观察是否随后下降;持续增长且进程文件描述符逼近上限,才更支持资源释放缺陷。
常见追问
谁发起 FIN 后,本机进入 CLOSE_WAIT?
本机收到对端 FIN 并确认后进入 CLOSE_WAIT。对端进入 FIN_WAIT_2 等状态,本机应用仍可继续发送数据。
CLOSE_WAIT 为什么会越来越多?
常见原因是应用收到 EOF 后未关闭 Socket,或关闭逻辑被阻塞/遗漏,导致内核连接状态长期保留。需以进程和代码证据确认。
怎么解决 CLOSE_WAIT?
修复应用关闭连接的生命周期管理,使用可靠的 finally/资源管理结构,检查异常、超时和连接池回收逻辑;重启只能清理现存连接,不能解决根因。
CLOSE_WAIT 和 TIME_WAIT 可以一起出现吗?
可以,服务端与客户端的不同连接可能处于不同状态,也可能同一连接不同阶段先后经历相应状态。应按连接四元组逐条分析。