服务器TIME_WAIT和CLOSE_WAIT详解和解决办法

昨天解决了一个HttpClient调用错误导致的服务器异常，具体过程如下：

HttpClient连接池抛出大量ConnectionPoolTimeoutException: Timeout waiting for connection异常排查

今天解决了一个HttpClient的异常，汗啊，一个HttpClient使用稍有不慎都会是毁灭级别的啊。

这里有之前因为route配置不当导致服务器异常的一个处理：

HttpClient4.X 升级 入门 + http连接池使用

在一次服务器异常的排查过程当中（服务器异常排查的过程我会另起文章），我们决定使用HttpClient4.X替代HttpClient3.X或者HttpConnection。

为什么使用HttpClient4？主要是HttpConnection没有连接池的概念，多少次请求就会建立多少个IO，在访问量巨大的情况下服务器的IO可能会耗尽。

HttpClient3也有连接池的东西在里头，使用MultiThreadedHttpConnectionManager，大致过程如下：

 MultiThreadedHttpConnectionManager connectionManager = new MultiThreadedHttpConnectionManager();
 HttpClient client = new HttpClient(connectionManager);...// 在某个线程中。
 GetMethod get = new GetMethod("http://jakarta.apache.org/");
 try {
 client.executeMethod(get);// print response to stdout
 System.out.println(get.getResponseBodyAsStream());
 } finally {
 // be sure the connection is released back to the connection
 managerget.releaseConnection();
 }

可以看出来，它的方式与jdbc连接池的使用方式相近，我觉得比较不爽的就是需要手动调用releaseConnection去释放连接。对每一个HttpClient.executeMethod须有一个method.releaseConnection()与之匹配。

 

HttpClient4在这点上做了改进，使用我们常用的InputStream.close()来确认连接关闭（4.1版本之前使用entity.consumeContent()来确认内容已经被消耗关闭连接）。具体方式如下：

 ...HttpClient client = null;InputStream in = null;
 try{
 client = HttpConnectionManager.getHttpClient();
 HttpGet get = new HttpGet();
 get.setURI(new URI(urlPath));
 HttpResponse response = client.execute(get);
 HttpEntity entity =response.getEntity();
 if( entity != null ){
  in = entity.getContent();
  ....
 }catch (Exception e){
 ....
 }finally{
 if (in != null){
 try{in.close ();}catch (IOException e){
 e.printStackTrace ();
 }
 }
 }

2012-03-06更新：

有网友提出调用in.close()是否会关闭底层socket，事情是这样的：

 回复kangkang203：感谢你提出的这个问题。
 首先我文中提出的方法in.close()它会触发一个连接的释放这个连接将重新被连接管理器收回，官网的原文是这么说的：“Closing the input stream will trigger connection release...the underlying connection gets released back to the connection manager”。但是底层的socket是否会被关闭是不一定的，我看了部分源码（EofSensorInputStream）发现，大多数情况socket并不会关闭，而是否关闭socket貌似是由一个Watcher去决定的。所以in.close的调用不会引起socket的关闭。
 另外，由于http本身我们把它当做“短连接”，所以在一次请求交互完成后仍然打开socket的意义不是很大，毕竟它不像长连接那样在一个连接建立之后会有很多次数据交互。我们试用连接管理器的更多意义在于它对连接的管理。

 

好说完了连接池的使用流程，现在来说一说连接池在使用时最重要的几个参数。我用4.1的版本实现了一个简单的HttpConnectionManager，代码如下：

 public class HttpConnectionManager {

     private static HttpParams httpParams;
     private static ClientConnectionManager connectionManager;

     /**
      * 最大连接数
      */
     public final static int MAX_TOTAL_CONNECTIONS = 800;
     /**
      * 获取连接的最大等待时间
      */
     public final static int WAIT_TIMEOUT = 60000;
     /**
      * 每个路由最大连接数
      */
     public final static int MAX_ROUTE_CONNECTIONS = 400;
     /**
      * 连接超时时间
      */
     public final static int CONNECT_TIMEOUT = 10000;
     /**
      * 读取超时时间
      */
     public final static int READ_TIMEOUT = 10000;

     static {
         httpParams = new BasicHttpParams();
         // 设置最大连接数
         ConnManagerParams.setMaxTotalConnections(httpParams, MAX_TOTAL_CONNECTIONS);
         // 设置获取连接的最大等待时间
         ConnManagerParams.setTimeout(httpParams, WAIT_TIMEOUT);
         // 设置每个路由最大连接数
         ConnPerRouteBean connPerRoute = new ConnPerRouteBean(MAX_ROUTE_CONNECTIONS);
         ConnManagerParams.setMaxConnectionsPerRoute(httpParams,connPerRoute);
         // 设置连接超时时间
         HttpConnectionParams.setConnectionTimeout(httpParams, CONNECT_TIMEOUT);
         // 设置读取超时时间
         HttpConnectionParams.setSoTimeout(httpParams, READ_TIMEOUT);

         SchemeRegistry registry = new SchemeRegistry();
         registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
         registry.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));

         connectionManager = new ThreadSafeClientConnManager(httpParams, registry);
     }

     public static HttpClient getHttpClient() {
         return new DefaultHttpClient(connectionManager, httpParams);
     }

 }

最大连接数、获取连接的最大等待时间、读取超时时间 这些配置应该比较容易理解，一般的连接池都会有这些配置，比较特别的是 每个路由(route)最大连接数 。

 

什么是一个route？

 

这里route的概念可以理解为 运行环境机器 到 目标机器的一条线路。举例来说，我们使用HttpClient的实现来分别请求 www.baidu.com 的资源和 www.bing.com 的资源那么他就会产生两个route。

 

这里为什么要特别提到route最大连接数这个参数呢，因为这个参数的默认值为2，如果不设置这个参数值默认情况下对于同一个目标机器的最大并发连接只有2个！这意味着如果你正在执行一个针对某一台目标机器的抓取任务的时候，哪怕你设置连接池的最大连接数为200，但是实际上还是只有2个连接在工作，其他剩余的198个连接都在等待，都是为别的目标机器服务的。

 

怎么样蛋疼吧，我是已经有过血的教训了，在切换到HttpClient4.1的起初没有注意到这个配置，最后使得服务承受的压力反而不如从前了，所以在这里特别提醒大家注意。

 

HttpClient4.X 教程下载：

http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient-contrib/docs/translated-tutorial/httpclient-tutorial-simplified-chinese.pdf

关于版本的补充：

网友w2449008821提醒之后我才发现在HttpClient4.1+的版本ConnManagerParams已经被Deprecated了。

我在写这篇日志的时候时候的httpclient 版本是4.0.3，从4.0版本之后ConnManagerParams被Deprecated，没想到一个小版本升级会有这么大变化。

官网教程举例了新的连接池设置：

 SchemeRegistry schemeRegistry = new SchemeRegistry();
 schemeRegistry.register(
          new Scheme("http", 80, PlainSocketFactory.getSocketFactory()));
 schemeRegistry.register(
          new Scheme("https", 443, SSLSocketFactory.getSocketFactory()));

 ThreadSafeClientConnManager cm = new ThreadSafeClientConnManager(schemeRegistry);
 // Increase max total connection to 200
 cm.setMaxTotalConnections(200);
 // Increase default max connection per route to 20
 cm.setDefaultMaxPerRoute(20);
 // Increase max connections for localhost:80 to 50
 HttpHost localhost = new HttpHost("locahost", 80);
 cm.setMaxForRoute(new HttpRoute(localhost), 50);

 HttpClient httpClient = new DefaultHttpClient(cm);

ConnManagerParams的功能被挪到了 ThreadSafeClientConnManager 和 HttpConnectionParams两个类：

static ConnPerRoute	getMaxConnectionsPerRoute(HttpParams params)            Deprecated. use ThreadSafeClientConnManager.getMaxForRoute(org.apache.http.conn.routing.HttpRoute)
static int	getMaxTotalConnections(HttpParams params)            Deprecated. use ThreadSafeClientConnManager.getMaxTotal()
static long	getTimeout(HttpParams params)            Deprecated. use HttpConnectionParams.getConnectionTimeout(HttpParams)
static void	setMaxConnectionsPerRoute(HttpParams params, ConnPerRoute connPerRoute)            Deprecated. use ThreadSafeClientConnManager.setMaxForRoute(org.apache.http.conn.routing.HttpRoute, int)
static void	setMaxTotalConnections(HttpParams params, int maxTotalConnections)            Deprecated. use ThreadSafeClientConnManager.setMaxTotal(int)
static void	setTimeout(HttpParams params, long timeout)            Deprecated. use HttpConnectionParams.setConnectionTimeout(HttpParams, int)

——————————————————————————————

分割线

——————————————————————————————

里面的HttpConnectionManager实现就是我在这里使用的实现。

问题表现：

tomcat后台日志发现大量异常

 org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection

时间一长tomcat就无法继续处理其他请求，从假死变成真死了。

linux运行：

 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

发现CLOSE_WAIT的数量始终在400以上，一直没降过。

问题分析：

一开始我对我的HttpClient使用过程深信不疑，我不认为异常是来自这里。

所以我开始从TCP的连接状态入手，猜测可能导致异常的原因。以前经常遇到TIME_WAIT数过大导致的服务器异常，很容易解决，修改下sysctl就ok了。但是这次是CLOSE_WAIT，是完全不同的概念了。

关于TIME_WAIT和CLOSE_WAIT的区别和异常处理我会单独起一篇文章详细说说我的理解。

简单来说CLOSE_WAIT数目过大是由于被动关闭连接处理不当导致的。

我说一个场景，服务器A会去请求服务器B上面的apache获取文件资源，正常情况下，如果请求成功，那么在抓取完资源后服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢？假设请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后自己并没有释放连接，那就会造成CLOSE_WAIT的状态了。

所以很明显，问题还是处在程序里头。

先看看我的HttpConnectionManager实现：

 public class HttpConnectionManager {

     private static HttpParams httpParams;
     private static ClientConnectionManager connectionManager;

     /**
      * 最大连接数
      */
     public final static int MAX_TOTAL_CONNECTIONS = 800;
     /**
      * 获取连接的最大等待时间
      */
     public final static int WAIT_TIMEOUT = 60000;
     /**
      * 每个路由最大连接数
      */
     public final static int MAX_ROUTE_CONNECTIONS = 400;
     /**
      * 连接超时时间
      */
     public final static int CONNECT_TIMEOUT = 10000;
     /**
      * 读取超时时间
      */
     public final static int READ_TIMEOUT = 10000;

     static {
         httpParams = new BasicHttpParams();
         // 设置最大连接数
         ConnManagerParams.setMaxTotalConnections(httpParams, MAX_TOTAL_CONNECTIONS);
         // 设置获取连接的最大等待时间
         ConnManagerParams.setTimeout(httpParams, WAIT_TIMEOUT);
         // 设置每个路由最大连接数
         ConnPerRouteBean connPerRoute = new ConnPerRouteBean(MAX_ROUTE_CONNECTIONS);
         ConnManagerParams.setMaxConnectionsPerRoute(httpParams,connPerRoute);
         // 设置连接超时时间
         HttpConnectionParams.setConnectionTimeout(httpParams, CONNECT_TIMEOUT);
         // 设置读取超时时间
         HttpConnectionParams.setSoTimeout(httpParams, READ_TIMEOUT);

         SchemeRegistry registry = new SchemeRegistry();
         registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
         registry.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));

         connectionManager = new ThreadSafeClientConnManager(httpParams, registry);
     }

     public static HttpClient getHttpClient() {
         return new DefaultHttpClient(connectionManager, httpParams);
     }

 }

看到没MAX_ROUTE_CONNECTIONS 正好是400，跟CLOSE_WAIT非常接近啊，难道是巧合？继续往下看。

然后看看调用它的代码是什么样的：

 public static String readNet (String urlPath)
     {
         StringBuffer sb = new StringBuffer ();
         HttpClient client = null;
         InputStream in = null;
         InputStreamReader isr = null;
         try
         {
             client = HttpConnectionManager.getHttpClient();
             HttpGet get = new HttpGet();
             get.setURI(new URI(urlPath));
             HttpResponse response = client.execute(get);
             if (response.getStatusLine ().getStatusCode () != 200) {
                 return null;
             }
             HttpEntity entity =response.getEntity();

             if( entity != null ){
                 in = entity.getContent();
                 .....
             }
             return sb.toString ();

         }
         catch (Exception e)
         {
             e.printStackTrace ();
             return null;
         }
         finally
         {
             if (isr != null){
                 try
                 {
                     isr.close ();
                 }
                 catch (IOException e)
                 {
                     e.printStackTrace ();
                 }
             }
             if (in != null){
                 try
                 {
                     <span style="color:#ff0000;">in.close ();</span>
                 }
                 catch (IOException e)
                 {
                     e.printStackTrace ();
                 }
             }
         }
     }

很简单，就是个远程读取中文页面的方法。值得注意的是这一段代码是后来某某同学加上去的，看上去没啥问题，是用于非200状态的异常处理：

 if (response.getStatusLine ().getStatusCode () != 200) {
                 return null;
             }

代码本身没有问题，但是问题是放错了位置。如果这么写的话就没问题：

 client = HttpConnectionManager.getHttpClient();
             HttpGet get = new HttpGet();
             get.setURI(new URI(urlPath));
             HttpResponse response = client.execute(get);

             HttpEntity entity =response.getEntity();

             if( entity != null ){
                 in = entity.getContent();
             ..........
             }

             if (response.getStatusLine ().getStatusCode () != 200) {
                 return null;
             }
             return sb.toString ();

看出毛病了吧。在这篇入门（ HttpClient4.X 升级 入门 + http连接池使用 ）里头我提到了HttpClient4使用我们常用的InputStream.close()来确认连接关闭，前面那种写法InputStream in 根本就不会被赋值，意味着一旦出现非200的连接，这个连接将永远僵死在连接池里头，太恐怖了。。。所以我们看到CLOST_WAIT数目为400，因为对一个路由的连接已经完全被僵死连接占满了。。。

其实上面那段代码还有一个没处理好的地方，异常处理不够严谨，所以最后我把代码改成了这样：

 public static String readNet (String urlPath)
     {
         StringBuffer sb = new StringBuffer ();
         HttpClient client = null;
         InputStream in = null;
         InputStreamReader isr = null;
         HttpGet get = new HttpGet();
         try
         {
             client = HttpConnectionManager.getHttpClient();
             get.setURI(new URI(urlPath));
             HttpResponse response = client.execute(get);
             if (response.getStatusLine ().getStatusCode () != 200) {
                 get.abort();
                 return null;
             }
             HttpEntity entity =response.getEntity();

             if( entity != null ){
                 in = entity.getContent();
                 ......
             }
             return sb.toString ();

         }
         catch (Exception e)
         {
             get.abort();
             e.printStackTrace ();
             return null;
         }
         finally
         {
             if (isr != null){
                 try
                 {
                     isr.close ();
                 }
                 catch (IOException e)
                 {
                     e.printStackTrace ();
                 }
             }
             if (in != null){
                 try
                 {
                     in.close ();
                 }
                 catch (IOException e)
                 {
                     e.printStackTrace ();
                 }
             }
         }
     }

显示调用HttpGet的abort，这样就会直接中止这次连接，我们在遇到异常的时候应该显示调用，因为谁能保证异常是在InputStream in赋值之后才抛出的呢。

好了 ，分析完毕，明天准备总结下CLOSE_WAIT和TIME_WAIT的区别。

————————————————————————————————————————

分割线

————————————————————————————————————————

里头的分析过程有提到，通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。

在服务器的日常维护过程中，会经常用到下面的命令：

 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

它会显示例如下面的信息：

TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。

具体每种状态什么意思，其实无需多说，看看下面这种图就明白了，注意这里提到的服务器应该是业务请求接受处理的一方：

这么多状态不用都记住，只要了解到我上面提到的最常见的三种状态的意义就可以了。一般不到万不得已的情况也不会去查看网络状态，如果服务器出了异常，百分之八九十都是下面两种情况：

1.服务器保持了大量TIME_WAIT状态

2.服务器保持了大量CLOSE_WAIT状态

因为linux分配给一个用户的文件句柄是有限的（可以参考：http://blog.csdn.net/shootyou/article/details/6579139），而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的请求就无法被处理了，接着就是大量Too Many Open Files异常，tomcat崩溃。。。

下面来讨论下这两种情况的处理方法，网上有很多资料把这两种情况的处理方法混为一谈，以为优化系统内核参数就可以解决问题，其实是不恰当的，优化系统内核参数解决TIME_WAIT可能很容易，但是应对CLOSE_WAIT的情况还是需要从程序本身出发。现在来分别说说这两种情况的处理方法：

1.服务器保持了大量TIME_WAIT状态

这种情况比较常见，一些爬虫服务器或者WEB服务器（如果网管在安装的时候没有做内核参数优化的话）上经常会遇到这个问题，这个问题是怎么产生的呢？

从上面的示意图可以看得出来，TIME_WAIT是主动关闭连接的一方保持的状态，对于爬虫服务器来说他本身就是“客户端”，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL（max segment lifetime）时间之后，彻底关闭回收资源。为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定的，主要出于以下两个方面的考虑：

1.防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
2.可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。

关于MSL引用下面一段话：

 MSL 為一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間)，由於 RFC 793 TCP 傳輸協定是在 1981 年定義的，當時的網路速度不像現在的網際網路那樣發達，你可以想像你從瀏覽器輸入網址等到第一個 byte 出現要等 4 分鐘嗎？在現在的網路環境下幾乎不可能有這種事情發生，因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低，好讓 連線埠 (Ports) 能更快空出來給其他連線使用。

再引用网络资源的一段话：

 值得一说的是，对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，可 想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态，假如server一秒钟接收1000个请求，那么就会积压240*1000=240，000个 TIME_WAIT的记录，维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT，所以对于新的 TCP连接请求，判断是否hit中一个TIME_WAIT不会太费时间，但是有这么多状态要维护总是不好。
 HTTP协议1.1版规定default行为是Keep-Alive，也就是会重用TCP连接传输多个 request/response，一个主要原因就是发现了这个问题。

也就是说HTTP的交互跟上面画的那个图是不一样的，关闭连接的不是客户端，而是服务器，所以web服务器也是会出现大量的TIME_WAIT的情况的。

现在来说如何来解决这个问题。

解决思路很简单，就是让服务器能够快速回收和重用那些TIME_WAIT的资源。

下面来看一下我们网管对/etc/sysctl.conf文件的修改：

 #对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255，默认值是5，对应于180秒左右时间
 net.ipv4.tcp_syn_retries=2
 #net.ipv4.tcp_synack_retries=2
 #表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒
 net.ipv4.tcp_keepalive_time=1200
 net.ipv4.tcp_orphan_retries=3
 #表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间
 net.ipv4.tcp_fin_timeout=30
 #表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
 net.ipv4.tcp_max_syn_backlog = 4096
 #表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭
 net.ipv4.tcp_syncookies = 1

 #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭
 net.ipv4.tcp_tw_reuse = 1
 #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭
 net.ipv4.tcp_tw_recycle = 1

 ##减少超时前的探测次数
 net.ipv4.tcp_keepalive_probes=5
 ##优化网络设备接收队列
 net.core.netdev_max_backlog=3000

修改完之后执行/sbin/sysctl -p让参数生效。

这里头主要注意到的是 net.ipv4.tcp_tw_reuse

net.ipv4.tcp_tw_recycle
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*

这几个参数。

net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。

net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。

net.ipv4.tcp_keepalive_*一系列参数，是用来设置服务器检测连接存活的相关配置。

关于keepalive的用途可以参考：http://hi.baidu.com/tantea/blog/item/580b9d0218f981793812bb7b.html

[2015.01.13更新]

注意tcp_tw_recycle开启的风险：http://blog.csdn.net/wireless_tech/article/details/6405755

2.服务器保持了大量CLOSE_WAIT状态

休息一下，喘口气，一开始只是打算说说TIME_WAIT和CLOSE_WAIT的区别，没想到越挖越深，这也是写博客总结的好处，总可以有意外的收获。

TIME_WAIT状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。

但是CLOSE_WAIT就不一样了，从上面的图可以看出来，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。个人觉得这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行。

如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情况，那么这篇日志也许对你有用：http://blog.csdn.net/shootyou/article/details/6615051

在那边日志里头我举了个场景，来说明CLOSE_WAIT和TIME_WAIT的区别，这里重新描述一下：

服务器A是一台爬虫服务器，它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源，正常情况下，如果请求成功，那么在抓取完资源后，服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢？假设请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后程序员忘了让HttpClient释放连接，那就会造成CLOSE_WAIT的状态了。

所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是：查代码。因为问题出在服务器程序里头啊。