我们在客户端所在服务器执行如下命令

netstat -natp|grep CLOSE

会发现如下现象

为什么呢？

是因为我们连接开启了keepalive,那么此时服务端不会马上关闭连接，服务器经过一段时间，认为该连接空闲，因此主动关闭，收到对方响应后进入 FIN_WAIT_2 状态(等待对方也发起关闭)，而客户端进入 CLOSE_WAIT 状态后却不再发起自己这一方的关闭请求，这时双方处于半关闭,所以可以看到客户端有CLOSE_WAIT状态。

至于原因，官方解释为：One of the major shortcomings of the classic blocking I/O model is that the network socket can react to I/O events only when blocked in an I/O operation. When a connection is released back to the manager, it can be kept alive however it is unable to monitor the status of the socket and react to any I/O events. If the connection gets closed on the server side, the client side connection is unable to detect the change in the connection state (and react appropriately by closing the socket on its end).

我这里网上翻一下：经典阻塞I/O模型的一个主要缺点是，只有在I/O操作中阻塞时，网络套接字才能对I/O事件作出反应。当连接被释放回管理器时，它可以保持活动状态，但是它无法监视套接字的状态并对任何I/O事件作出反应。如果连接在服务器端关闭，客户端连接将无法检测到连接状态的变化（并通过关闭其端的套接字做出适当的反应）。

所以，httpclient是把连接放回连接池里的，当连接在服务器端关闭客户端连接将无法检测到连接状态的变化，所以就只能维持在CLOSW_WAIT状态。
TCP握手和释放参考：https://www.suibibk.com/topic/661576836316135424

解决办法：这需要有定期主动做一些检测和关闭动作。比如用httpclient连接池，连接池的实现应该会自动关闭过期连接：参考PoolingHttpClientConnectionManager