记录一次 “服务器 CLOSE_WAIT”堆积的解决过程

一 前提与背景

1 前提

只要出现CLOSE_WAIT累积一定是自己服务写的有问题

2 背景

给自己服务访问第三方服务加了连接池后，压测时候发现请求结束后有很多连接处于close_wait状态，且一直不结束

用连接池的原因是为了连接复用与连接控制

二 解决过程

1 知识点回顾

在正式解决该问题前，先回顾下“TCP四次挥手”过程

理解四次挥手时候不要用 服务端-客户端这样去理解每次挥手过程， 而是要以谁是主动断开连接的(即主动发送 FIN)为标准

2 服务是如何解决

如【背景】图所示，处于 CLOSE_WAIT的是【访问 8501接口】 和 【访问 80端口】的第三方服务连接。

• 问题1： 所以这里疑问来了，是我的服务主动访问第三方服务的，为什么会出现CLOSE_WAIT？

• 答案1： 如【知识点回顾】所说， 要以谁是主动断开连接的来判断； 这里我的服务连接状态是CLOSE_WAIT，那么一定是我访问的第三方服务发送的FIN断开请求， 我是被动关闭了连接请求

• 问题2: 为啥CLOSE_WAIT 不释放 ？

• 答案2: 一直处于CLOSE_WAIT 意味着 四次挥手过程中 第三次挥手一直没有挥手，也就是说我的服务一直没有给第三方服务发送FIN包

基于这个思路，那么第三方服务主动发送断开连接的情况可能是：第三方服务报错了(可能是超时，服务错误，连接问题等)。

看了下log 确实存在第三方服务报错。

证明了第一个问题后，第二问题“为什么我的服务不给第三方服务发送FIN包？”， 首先看下我的服务是如何写的

很简单的代码， POST访问第三方服务 + 异常判断与获取

可以理解是访问了第三方服务出错了，但是处于CLOSE_WAIT状态不变了， 也就是说一定需要我的服务主动给第三方服务发送FIN

了解到我的连接池中的连接，在访问第三方服务报错后，并不会主动断开连接，需要自己处理： 主动关闭出错的访问连接 。 简单的方案在执行完全部并发线程后关闭整个session

重启服务后测试发现服务CLOSE_WAIT状态的连接已经全部不在，当然不用担心新的连接问题，因为这次请求已经结束了，下次请求连接池会自动帮我们重新建立连接。

当然这里有更好的解决方案，例如只关闭出问题的连接，实际上都一样(对于我的调用逻辑)

三 总结

在使用长链接时候是经常会出现这样的情况，记住一点： 捕获异常，主动关闭出问题的连接

以上是自己个人的片面理解，主要为了记录。如果有误或者不全欢迎指正，非常感谢🙏