HttpClient 在vivo内销浏览器的高并发实践优化

1. 从某个时间点开始，云监控显示部分Http接口的熔断器被打开，而且从明细列表可以发现问题机器：

   
   

2. 从PAAS平台Hystrix熔断管理界面中可以进一步确认问题机器的所有Http接口调用均出现了熔断：

3. 日志中心有大量从Http连接池获取连接的异常：

org.apache.http.impl.execchain.RequestAbortedException: Request aborted。

综合以上三个现象，大概可以推测出问题机器的TCP连接管理出了问题，可能是虚拟机问题，也可能是物理机问题；与运维与系统侧沟通后，发现虚拟机与物理机均无明显异常，第一时间联系运维重启了问题机器，线上问题得到解决。

2.1 临时解决方案

几天以后，线上部分其他机器也陆续出现了上述现象，此时基本可以确认是服务本身有问题；既然问题与TCP连接相关，于是联系运维在问题机器上建立了一个作业查看TCP连接的状态分布：

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

结果如下：

如上图，问题机器的CLOSE_WAIT状态的连接数已经接近200左右（该服务Http连接池最大连接数设置的250），那问题直接原因基本可以确认是CLOSE_WAIT状态的连接过多导致的；本着第一时间先解决线上问题的原则，先把连接池调整到500，然后让运维重启了机器，线上问题暂时得到解决。

2.2 原因分析

netstat-tulnap|grep CLOSE_WAIT

经过与合作方确认，目标IP均来自该合作方，与我们的推测是相符的。

2.3 TCP抓包

在定位问题的同时，也让运维同事帮忙抓取了TCP的数据包，结果表明确实是客户端（浏览器服务端）没返回ACK结束握手，导致挥手失败，客户端处于了CLOSE_WAIT状态，数据包的大小也与怀疑的问题接口相符。

为了方便大家理解，我从网上找了一张图，大家可以作为参考：

2.4 独立连接池

为了不影响其他业务场景，防止出现系统性风险，我们先把问题接口连接池进行了独立管理。

2.5 深入分析

带着2.3的疑问我们仔细查看一下业务调用代码：

try {        httpResponse = HttpsClientUtil.getHttpClient().execute(request);        HttpEntity httpEntity = httpResponse.getEntity();        is = httpEntity.getContent();     }catch (Exception e){        log.error("");     }finally {        IOUtils.closeQuietly(is);        IOUtils.closeQuietly(httpResponse);     }

2.6 源码分析

2.6.1 连接池初始化 

初始化方法：

进入PoolingHttpClientConnectionManager这个类，有一个重载构造方法里包含连接存活时间参数：

顺着继续向下查看：

接着我们就看到了HttpClient关闭空闲连接的具体实现，里面有我们想要看到的内容：

此时，我们可以得出第一个结论：可以在初始化连接池的时候，通过实现带参的PoolingHttpClientConnectionManager构造方法，修改validityDeadline的值，从而影响HttpClient对长连接的管理策略。

2.6.2 执行方法入口

先找到执行入口方法：

org.apache.http.impl.execchain.MainClientExec.execute,看到了keepalive相关代码实现：

我们来看下默认的策略：

由于中间的调用逻辑比较简单，就不在这里一一把调用的链路贴出来了，这边直接给结论：HttpClient对没有指定连接有效时间的长连接，有效期设置为永久（Long.MAX_VALUE）。

综合以上分析,我们可以得出最终结论：

这样简单修改上线后，处于close_wait状态的连接数没有再持续增长，这个线上问题也算是得到了彻底的解决。

3.1 前言

• 【PoolingHttpClientConnectionManager】：连接池管理器类，主要作用是管理连接和连接池，封装连接的创建、状态流转以及连接池的相关操作，是操作连接和连接池的入口方法；

  
  

• 【CPool】：连接池的具体实现类，连接和连接池的具体实现均在CPool以及抽象类AbstractConnPool中实现，也是分析的重点；

  
  

• 【CPoolEntry】：具体的连接封装类，包含连接的一些基础属性和基础操作，比如连接id，创建时间，有效期等；

  
  

• 【HttpClientBuilder】：HttpClient的构造器，重点关注build方法；

  
  

• 【MainClientExec】：客户端请求的执行类，是执行的入口，重点关注execute方法；

  
  

• 【ConnectionHolder】：主要封装释放连接的方法，是在PoolingHttpClientConnectionManager的基础上进行了封装。

3.2 两个连接

• 最大连接数，顾名思义，就是连接池允许创建的最大连接数量；
  

• 最大单路由连接数可以理解为同一个域名允许的最大连接数，且所有maxPerRoute的总和不能超过maxTotal。

  以浏览器为例，浏览器对接了头条和一点，为了做到业务隔离，不相互影响，可以把maxTotal设置成500，而defaultMaxPerRoute设置成400，主要是因为头条的业务接口量远大于一点，defaultMaxPerRoute需要满足调用量较大的一方。

3.3 三个超时

【connectionRequestTimout】：指从连接池获取连接的超时时间；

【connetionTimeout】：指客户端和服务器建立连接的超时时间，超时后会报

ConnectionTimeOutException异常；

【socketTimeout】：指客户端和服务器建立连接后，数据传输过程中数据包之间间隔的最大时间，超出后会抛出SocketTimeOutException。

3.4 四个容器

maxTotal的组成

3.5 连接的产生与管理

1. 循环从available容器中获取连接，如果该连接未失效（根据上文提到的expiry字段判断），则把该连接从available容器中删除，并添加到leased容器，并返回该连接；

   
   

2. 如果在第一步中没有获取到可用连接，则判断r.available + r.leased是否大于maxPerRoute，其实就是判断是否还有free连接；如果不存在，则需要把多余分配的连接释放掉（r. available + r.leased - maxPerRoute），来保证真实的连接数受maxPerRoute控制（至于为什么会出现r.leased+r.available>maxPerRoute的情况其实也很好理解，虽然在整个状态流转过程都加了锁，但是状态的流转并不是原子操作，存在一些异常的场景都会导致状态短时间不正确）；所以我们可以得出结论，maxPerRoute只是一个理论上的最大数值，其实真实产生的连接数在短时间内是可能大于这个值的；

   
   

3. 在真实的连接数（r .leased+ r .available）小于maxPerRoute且maxTotal>leased的情况下：如果free>0，则重新创建一个连接；如果free=0，则把available容器里的最早创建的一个连接关闭掉，然后再重新创建一个连接；看起来有点绕，其实就是优先使用free容器里的连接，获取不到再释放available容器里的连接；

   
   

4. 如果经过上述过程仍然没有获取到可用连接，那就只能等待一个connectionRequestTimout时间，或者有其他线程的信号通知来结束整个获取连接的过程。

3.6 连接的释放

1. 如果是长连接（reusable），则把该连接从leased容器中删除，然后添加到available容器的头部，设置有效期为expiry；

2. 如果是短连接（non-reusable），则直接关闭该连接，并且从released容器中删除，此时的连接被释放，处于free容器中；

3. 最后，唤醒“连接的产生与管理“第四部中的等待线程。

connHolder.releaseConnection()对应“连接的释放”中提到的步骤1，此时连接只是被放入了available容器，并且有效期是永久；

return new HttpResponseProxy(response, null)返回的ConnectionHolder是null，结合IOUtils.closeQuietly(httpResponse)的具体实现，连接并没有及时关闭，而是永久的放在了available容器里，并且状态为CLOSE_WAIT，无法被复用；

HttpClient作为当前使用最广泛的基于Java语言的Http调用框架，在笔者看来其存在两点明显不足：