HttpClient 4.3连接池参数配置及源码解读

た入场券 2022-05-21 08:14 349阅读 0赞

目前所在公司使用HttpClient 4.3.3版本发送Rest请求，调用接口。最近出现了调用查询接口服务慢的生产问题，在排查整个调用链可能存在的问题时（从客户端发起Http请求->ESB->服务端处理请求，查询数据并返回），发现原本的HttpClient连接池中的一些参数配置可能存在问题，如defaultMaxPerRoute、一些timeout时间的设置等，虽不能确定是由于此连接池导致接口查询慢，但确实存在可优化的地方，故花时间做一些研究。本文主要涉及HttpClient连接池、请求的参数配置，使用及源码解读。

以下是本文的目录大纲：

一、HttpClient连接池、请求参数含义

二、执行原理及源码解读

1、创建HttpClient，执行request

2、连接池管理

2.1、连接池结构

2.2、分配连接 & 建立连接

2.3、回收连接 & 保持连接

2.4、instream.close()、response.close()、httpclient.close()的区别

2.5、过期和空闲连接清理

三、如何设置合理的参数

# 一、HttpClient连接池、请求参数含义 #

1.  import java.io.IOException;
2.  import java.io.InputStream;
3.  import java.io.InterruptedIOException;
4.  import java.net.UnknownHostException;
5.  import java.nio.charset.CodingErrorAction;
6.  import javax.net.ssl.SSLException;
7.  import org.apache.http.Consts;
8.  import org.apache.http.HttpEntity;
9.  import org.apache.http.HttpEntityEnclosingRequest;
10. import org.apache.http.HttpHost;
11. import org.apache.http.HttpRequest;
12. import org.apache.http.client.HttpRequestRetryHandler;
13. import org.apache.http.client.config.RequestConfig;
14. import org.apache.http.client.methods.CloseableHttpResponse;
15. import org.apache.http.client.methods.HttpGet;
16. import org.apache.http.client.protocol.HttpClientContext;
17. import org.apache.http.config.ConnectionConfig;
18. import org.apache.http.config.MessageConstraints;
19. import org.apache.http.config.SocketConfig;
20. import org.apache.http.conn.ConnectTimeoutException;
21. import org.apache.http.conn.routing.HttpRoute;
22. import org.apache.http.impl.client.CloseableHttpClient;
23. import org.apache.http.impl.client.DefaultHttpRequestRetryHandler;
24. import org.apache.http.impl.client.HttpClients;
25. import org.apache.http.impl.conn.PoolingHttpClientConnectionManager;
26. import org.apache.http.protocol.HttpContext;
27. 
28. public class HttpClientParamTest\{
29. public static void main(String\[\] args)\{
30. */\*\**
31.  *\* 创建连接管理器，并设置相关参数*
32.  *\*/*
33. *//连接管理器，使用无惨构造*
34. PoolingHttpClientConnectionManager connManager
35. = new PoolingHttpClientConnectionManager();
36. 
37. */\*\**
38.  *\* 连接数相关设置*
39.  *\*/*
40. *//最大连接数*
41. connManager.setMaxTotal( 200);
42. *//默认的每个路由的最大连接数*
43. connManager.setDefaultMaxPerRoute( 100);
44. *//设置到某个路由的最大连接数，会覆盖defaultMaxPerRoute*
45. connManager.setMaxPerRoute( new HttpRoute( new HttpHost( "somehost", 80)), 150);
46. 
47. */\*\**
48.  *\* socket配置（默认配置 和 某个host的配置）*
49.  *\*/*
50. SocketConfig socketConfig = SocketConfig.custom()
51. .setTcpNoDelay( true) *//是否立即发送数据，设置为true会关闭Socket缓冲，默认为false*
52. .setSoReuseAddress( true) *//是否可以在一个进程关闭Socket后，即使它还没有释放端口，其它进程还可以立即重用端口*
53. .setSoTimeout( 500) *//接收数据的等待超时时间，单位ms*
54. .setSoLinger( 60) *//关闭Socket时，要么发送完所有数据，要么等待60s后，就关闭连接，此时socket.close()是阻塞的*
55. .setSoKeepAlive( true) *//开启监视TCP连接是否有效*
56. .build();
57. connManager.setDefaultSocketConfig(socketConfig);
58. connManager.setSocketConfig( new HttpHost( "somehost", 80), socketConfig);
59. 
60. */\*\**
61.  *\* HTTP connection相关配置（默认配置 和 某个host的配置）*
62.  *\* 一般不修改HTTP connection相关配置，故不设置*
63.  *\*/*
64. *//消息约束*
65. MessageConstraints messageConstraints = MessageConstraints.custom()
66. .setMaxHeaderCount( 200)
67. .setMaxLineLength( 2000)
68. .build();
69. *//Http connection相关配置*
70. ConnectionConfig connectionConfig = ConnectionConfig.custom()
71. .setMalformedInputAction(CodingErrorAction.IGNORE)
72. .setUnmappableInputAction(CodingErrorAction.IGNORE)
73. .setCharset(Consts.UTF\_8)
74. .setMessageConstraints(messageConstraints)
75. .build();
76. *//一般不修改HTTP connection相关配置，故不设置*
77. *//connManager.setDefaultConnectionConfig(connectionConfig);*
78. *//connManager.setConnectionConfig(new HttpHost("somehost", 80), ConnectionConfig.DEFAULT);*
79. 
80. */\*\**
81.  *\* request请求相关配置*
82.  *\*/*
83. RequestConfig defaultRequestConfig = RequestConfig.custom()
84. .setConnectTimeout( 2 \* 1000) *//连接超时时间*
85. .setSocketTimeout( 2 \* 1000) *//读超时时间（等待数据超时时间）*
86. .setConnectionRequestTimeout( 500) *//从池中获取连接超时时间*
87. .setStaleConnectionCheckEnabled( true) *//检查是否为陈旧的连接，默认为true，类似testOnBorrow*
88. .build();
89. 
90. */\*\**
91.  *\* 重试处理*
92.  *\* 默认是重试3次*
93.  *\*/*
94. *//禁用重试(参数：retryCount、requestSentRetryEnabled)*
95. HttpRequestRetryHandler requestRetryHandler = new DefaultHttpRequestRetryHandler( 0, false);
96. *//自定义重试策略*
97. HttpRequestRetryHandler myRetryHandler = new HttpRequestRetryHandler() \{
98. 
99. public boolean retryRequest(IOException exception, int executionCount, HttpContext context)\{
100. *//Do not retry if over max retry count*
101. if (executionCount >= 3) \{
102. return false;
103. \}
104. *//Timeout*
105. if (exception instanceof InterruptedIOException) \{
106. return false;
107. \}
108. *//Unknown host*
109. if (exception instanceof UnknownHostException) \{
110. return false;
111. \}
112. *//Connection refused*
113. if (exception instanceof ConnectTimeoutException) \{
114. return false;
115. \}
116. *//SSL handshake exception*
117. if (exception instanceof SSLException) \{
118. return false;
119. \}
120. 
121. HttpClientContext clientContext = HttpClientContext.adapt(context);
122. HttpRequest request = clientContext.getRequest();
123. boolean idempotent = !(request instanceof HttpEntityEnclosingRequest);
124. *//Retry if the request is considered idempotent*
125. *//如果请求类型不是HttpEntityEnclosingRequest，被认为是幂等的，那么就重试*
126. *//HttpEntityEnclosingRequest指的是有请求体的request，比HttpRequest多一个Entity属性*
127. *//而常用的GET请求是没有请求体的，POST、PUT都是有请求体的*
128. *//Rest一般用GET请求获取数据，故幂等，POST用于新增数据，故不幂等*
129. if (idempotent) \{
130. return true;
131. \}
132. 
133. return false;
134. \}
135. \};
136. 
137. */\*\**
138.  *\* 创建httpClient*
139.  *\*/*
140. CloseableHttpClient httpclient = HttpClients.custom()
141. .setConnectionManager(connManager) *//连接管理器*
142. .setProxy( new HttpHost( "myproxy", 8080)) *//设置代理*
143. .setDefaultRequestConfig(defaultRequestConfig) *//默认请求配置*
144. .setRetryHandler(myRetryHandler) *//重试策略*
145. .build();
146. 
147. *//创建一个Get请求，并重新设置请求参数，覆盖默认*
148. HttpGet httpget = new HttpGet( "http://www.somehost.com/");
149. RequestConfig requestConfig = RequestConfig.copy(defaultRequestConfig)
150. .setSocketTimeout( 5000)
151. .setConnectTimeout( 5000)
152. .setConnectionRequestTimeout( 5000)
153. .setProxy( new HttpHost( "myotherproxy", 8080))
154. .build();
155. httpget.setConfig(requestConfig);
156. 
157. CloseableHttpResponse response = null;
158. try \{
159. *//执行请求*
160. response = httpclient.execute(httpget);
161. 
162. HttpEntity entity = response.getEntity();
163. 
164. *// If the response does not enclose an entity, there is no need*
165. *// to bother about connection release*
166. if (entity != null) \{
167. InputStream instream = entity.getContent();
168. try \{
169. instream.read();
170. *// do something useful with the response*
171. \}
172. catch (IOException ex) \{
173. *// In case of an IOException the connection will be released*
174. *// back to the connection manager automatically*
175. throw ex;
176. \}
177. finally \{
178. *// Closing the input stream will trigger connection release*
179. *// 释放连接回到连接池*
180. instream.close();
181. \}
182. \}
183. \}
184. catch (Exception e) \{
185. e.printStackTrace();
186. \}
187. finally\{
188. if(response != null)\{
189. try \{
190. *//关闭连接(如果已经释放连接回连接池，则什么也不做)*
191. response.close();
192. \} catch (IOException e) \{
193. e.printStackTrace();
194. \}
195. \}
196. 
197. if(httpclient != null)\{
198. try \{
199. *//关闭连接管理器，并会关闭其管理的连接*
200. httpclient.close();
201. \} catch (IOException e) \{
202. e.printStackTrace();
203. \}
204. \}
205. \}
206. \}
207. \}

上面的代码参考httpClient 4.3.x的官方样例，其实官方样例中可配置的更多，我只将一些觉得平时常用的摘了出来，其实我们在实际使用中也是使用默认的 socketConfig 和 connectionConfig。具体参数含义请看注释。

个人感觉在实际应用中连接数相关配置（如maxTotal、maxPerRoute），还有请求相关的超时时间设置（如connectionTimeout、socketTimeout、connectionRequestTimeout）是比较重要的。

连接数配置有问题就可能产生总的 连接数不够 或者 到某个路由的连接数太小 的问题，我们公司一些项目总连接数800，而defaultMaxPerRoute仅为20，这样导致真正需要比较多连接数，访问量比较大的路由也仅能从连接池中获取最大20个连接，应该在默认的基础上，针对访问量大的路由单独设置。

连接超时时间，读超时时间，从池中获取连接的超时时间如果不设置或者设置的太大，可能导致当业务高峰时，服务端响应较慢 或 连接池中确实没有空闲连接时，不能够及时将timeout异常抛出来，导致等待读取数据的，或者等待从池中获取连接的越积越多，像滚雪球一样，导致相关业务都开始变得缓慢，而如果配置合理的超时时间就可以及时抛出异常，发现问题。

后面会尽量去阐述这些重要参数的原理以及如何配置一个合适的值。

# 二、执行原理及源码解读 #

1、创建HttpClient，执行request

1.  */\*\**
2.   *\* 创建httpClient*
3.   *\*/*
4.  CloseableHttpClient httpclient = HttpClients.custom()
5.  .setConnectionManager(connManager) *//连接管理器*
6.  .setDefaultRequestConfig(defaultRequestConfig) *//默认请求配置*
7.  .setRetryHandler(myRetryHandler) *//重试策略*
8.  .build();

创建HttpClient的过程就是在设置了“连接管理器”、“请求相关配置”、“重试策略”后，调用 HttpClientBuilder.build()。

build()方法会根据设置的属性不同，创建不同的Executor执行器，如设置了retryHandler就会 new RetryExec(execChain, retryHandler)，相当于retry Executor。当然有些Executor是必须创建的，如MainClientExec、ProtocolExec。最后new InternalHttpClient(execChain, connManager, routePlanner …)并返回。

CloseableHttpResponse httpResponse = httpClient.execute(httpUriRequest);

HttpClient使用了责任链模式，所有Executor都实现了ClientExecChain接口的execute()方法，每个Executor都持有下一个要执行的Executor的引用，这样就会形成一个Executor的执行链条，请求在这个链条上传递。按照上面的方式构造的httpClient形成的执行链条为：

1.  HttpRequestExecutor *//发送请求报文，并接收响应信息*
2.  MainClientExec(requestExec, connManager, ...) *//main Executor，负责连接管理相关*
3.  ProtocolExec(execChain, httpprocessor) *//HTTP协议封装*
4.  RetryExec(execChain, retryHandler) *//重试策略*
5.  RedirectExec(execChain, routePlanner, redirectStrategy) *//重定向*

请求执行是按照从下到上的顺序（即每个下面的Executor都持有上面一个Executor的引用），每一个执行器都会负责请求过程中的一部分工作，最终返回response。

2、连接池管理

2.1、连接池结构

连接池结构图如下:

![6f3717d34737\_thumb2][6f3717d34737_thumb2]

PoolEntry<HttpRoute, ManagedHttpClientConnection>  --  连接池中的实体

包含ManagedHttpClientConnection连接；

连接的route路由信息；

以及连接存活时间相隔信息，如created（创建时间），updated（更新时间，释放连接回连接池时会更新），validUnit（用于初始化expiry过期时间，规则是如果timeToLive>0，则为created+timeToLive，否则为Long.MAX\_VALUE），expiry（过期时间，人为规定的连接池可以保有连接的时间，除了初始化时等于validUnit，每次释放连接时也会更新，但是从newExpiry和validUnit取最小值）。timeToLive是在构造连接池时指定的连接存活时间，默认构造的timeToLive=-1。

ManagedHttpClientConnection是httpClient连接，真正建立连接后，其会bind绑定一个socket，用于传输HTTP报文。

LinkedList<PoolEntry>  available  --  存放可用连接

使用完后所有可重用的连接回被放到available链表头部，之后再获取连接时优先从available链表头部迭代可用的连接。

之所以使用LinkedList是利用了其队列的特性，即可以在队首和队尾分别插入、删除。入available链表时都是addFirst()放入头部，获取时都是从头部依次迭代可用的连接，这样可以获取到最新放入链表的连接，其离过期时间更远（这种策略可以尽量保证获取到的连接没有过期，而从队尾获取连接是可以做到在连接过期前尽量使用，但获取到过期连接的风险就大了），删除available链表中连接时是从队尾开始，即先删除最可能快要过期的连接。

HashSet<PoolEntry>  leased  --  存放被租用的连接

所有正在被使用的连接存放的集合，只涉及 add() 和 remove() 操作。

maxTotal限制的是外层httpConnPool中leased集合和available队列的总和的大小，leased和available的大小没有单独限制。

LinkedList<PoolEntryFuture>  pending  --  存放等待获取连接的线程的Future

当从池中获取连接时，如果available链表没有现成可用的连接，且当前路由或连接池已经达到了最大数量的限制，也不能创建连接了，此时不会阻塞整个连接池，而是将当前线程用于获取连接的Future放入pending链表的末尾，之后当前线程调用await()，释放持有的锁，并等待被唤醒。

当有连接被release()释放回连接池时，会从pending链表头获取future，并唤醒其线程继续获取连接，做到了先进先出。

routeToPool  --  每个路由对应的pool

也有针对当前路由的available、leased、pending集合，与整个池的隔离。

maxPerRoute限制的是routeToPool中leased集合和available队列的总和的大小。

2.2、分配连接 & 建立连接

分配连接

分配连接指的是从连接池获取可用的PoolEntry，大致过程为：

1、获取route对应连接池routeToPool中可用的连接，有则返回该连接，若没有则转入下一步；

2、若routeToPool和外层HttpConnPool连接池均还有可用的空间，则新建连接，并将该连接作为可用连接返回，否则进行下一步；

3、挂起当前线程，将当前线程的Future放入pending队列，等待后续唤醒执行；

整个分配连接的过程采用了异步操作，只在前两步时锁住连接池，一旦发现无法获取连接则释放锁，等待后续继续获取连接。

建立连接

当分配到PoolEntry连接实体后，会调用establishRoute()，建立socket连接并与conn绑定。

2.3、回收连接 & 保持连接

回收连接

连接用完之后连接池需要进行回收（AbstractConnPool\#release()），具体流程如下：  
1、若当前连接标记为重用，则将该连接从routeToPool中的leased集合删除，并添加至available队首，同样的将该请求从外层httpConnPool的leased集合删除，并添加至其available队首。同时唤醒该routeToPool的pending队列的第一个PoolEntryFuture，将其从pending队列删除，并将其从外层httpConnPool的pending队列中删除。  
2、若连接没有标记为重用，则分别从routeToPool和外层httpConnPool中删除该连接，并关闭该连接。

保持连接

MainClientExec\#execute()是负责连接管理的，在执行完后续调用链，并得到response后，会调用保持连接的逻辑，如下：

1.  *// The connection is in or can be brought to a re-usable state.*
2.  *// 根据response头中的信息判断是否保持连接*
3.  if (reuseStrategy.keepAlive(response, context)) \{
4.  *// Set the idle duration of this connection*
5.  *// 根据response头中的keep-alive中的timeout属性，得到连接可以保持的时间（ms）*
6.  final long duration = keepAliveStrategy.getKeepAliveDuration(response, context);
7.  if ( this.log.isDebugEnabled()) \{
8.  final String s;
9.  if (duration > 0) \{
10. s = "for " \+ duration + " " \+ TimeUnit.MILLISECONDS;
11. \} else \{
12. s = "indefinitely";
13. \}
14. this.log.debug( "Connection can be kept alive " \+ s);
15. \}
16. *//设置连接保持时间，最终是调用 PoolEntry\#updateExpiry*
17. connHolder.setValidFor(duration, TimeUnit.MILLISECONDS);
18. connHolder.markReusable(); *//设置连接reuse=true*
19. \}
20. else \{
21. connHolder.markNonReusable();
22. \}

连接是否保持

客户端如果希望保持长连接，应该在发起请求时告诉服务器希望服务器保持长连接（http 1.0设置connection字段为keep-alive，http 1.1字段默认保持）。根据服务器的响应来确定是否保持长连接，判断原则如下：

1、检查返回response报文头的Transfer-Encoding字段，若该字段值存在且不为chunked，则连接不保持，直接关闭。其他情况进入下一步；  
2、检查返回的response报文头的Content-Length字段，若该字段值为空或者格式不正确（多个长度，值不是整数）或者小于0，则连接不保持，直接关闭。其他情况进入下一步  
3、检查返回的response报文头的connection字段（若该字段不存在，则为Proxy-Connection字段）值，如果字段存在，若字段值为close 则连接不保持，直接关闭，若字段值为keep-alive则连接标记为保持。如果这俩字段都不存在，则http 1.1版本默认为保持，将连接标记为保持， 1.0版本默认为连接不保持，直接关闭。

连接保持时间

连接交还至连接池时，若连接标记为保持reuse=true，则将由连接管理器保持一段时间；若连接没有标记为保持，则直接从连接池中删除并关闭entry。  
连接保持时，会更新PoolEntry的expiry到期时间，计算逻辑为：  
1、如果response头中的keep-alive字段中timeout属性值存在且为正值：newExpiry = 连接归还至连接池时间System.currentTimeMillis() + timeout；  
2、如timeout属性值不存在或为负值：newExpiry = Long.MAX\_VALUE（无穷）  
3、最后会和PoolEntry原本的expiry到期时间比较，选出一个最小值作为新的到期时间。

2.4、instream.close()、response.close()、httpclient.close()的区别

1.  */\*\**
2.   *\* This example demonstrates the recommended way of using API to make sure*
3.   *\* the underlying connection gets released back to the connection manager.*
4.   *\*/*
5.  public class ClientConnectionRelease\{
6.  
7.  public final static void main(String\[\] args) throws Exception \{
8.  CloseableHttpClient httpclient = HttpClients.createDefault();
9.  try \{
10. HttpGet httpget = new HttpGet( "http://localhost/");
11. 
12. System.out.println( "Executing request " \+ httpget.getRequestLine());
13. CloseableHttpResponse response = httpclient.execute(httpget);
14. try \{
15. System.out.println( "----------------------------------------");
16. System.out.println(response.getStatusLine());
17. 
18. *// Get hold of the response entity*
19. HttpEntity entity = response.getEntity();
20. 
21. *// If the response does not enclose an entity, there is no need*
22. *// to bother about connection release*
23. if (entity != null) \{
24. InputStream instream = entity.getContent();
25. try \{
26. instream.read();
27. *// do something useful with the response*
28. \} catch (IOException ex) \{
29. *// In case of an IOException the connection will be released*
30. *// back to the connection manager automatically*
31. throw ex;
32. \} finally \{
33. *// Closing the input stream will trigger connection release*
34. instream.close();
35. \}
36. \}
37. \} finally \{
38. response.close();
39. \}
40. \} finally \{
41. httpclient.close();
42. \}
43. \}
44. \}

在HttpClient Manual connection release的例子中可以看到，从内层依次调用的是instream.close()、response.close()、httpClient.close()，那么它们有什么区别呢？

instream.close()

在主动操作输入流，或者调用EntityUtils.toString(httpResponse.getEntity())时会调用instream.read()、instream.close()等方法。instream的实现类为org.apache.http.conn.EofSensorInputStream。

在每次通过instream.read()读取数据流后，都会判断流是否读取结束

1.  @Override
2.  public int read(final byte\[\] b, final int off, final int len) throws IOException \{
3.  int l = - 1;
4.  if (isReadAllowed()) \{
5.  try \{
6.  l = wrappedStream.read(b, off, len);
7.  checkEOF(l);
8.  \} catch ( final IOException ex) \{
9.  checkAbort();
10. throw ex;
11. \}
12. \}
13. return l;
14. \}

在EofSensorInputStream\#checkEOF()方法中如果eof=-1，流已经读完，如果连接可重用，就会尝试释放连接，否则关闭连接。

1.  protected void checkEOF(final int eof) throws IOException \{
2.  if ((wrappedStream != null) && (eof < 0)) \{
3.  try \{
4.  boolean scws = true; *// should close wrapped stream?*
5.  if (eofWatcher != null) \{
6.  scws = eofWatcher.eofDetected(wrappedStream);
7.  \}
8.  if (scws) \{
9.  wrappedStream.close();
10. \}
11. \} finally \{
12. wrappedStream = null;
13. \}
14. \}
15. \}

ResponseEntityWrapper\#eofDetected

1.  public boolean eofDetected(final InputStream wrapped) throws IOException \{
2.  try \{
3.  *// there may be some cleanup required, such as*
4.  *// reading trailers after the response body:*
5.  wrapped.close();
6.  releaseConnection(); *//释放连接 或 关闭连接*
7.  \} finally \{
8.  cleanup();
9.  \}
10. return false;
11. \}

ConnectionHolder\#releaseConnection

1.  public void releaseConnection()\{
2.  synchronized ( this.managedConn) \{
3.  *//如果连接已经释放，直接返回*
4.  if ( this.released) \{
5.  return;
6.  \}
7.  
8.  this.released = true;
9.  *//连接可重用，释放回连接池*
10. if ( this.reusable) \{
11. this.manager.releaseConnection( this.managedConn,
12. this.state, this.validDuration, this.tunit);
13. \}
14. *//不可重用，关闭连接*
15. else \{
16. try \{
17. this.managedConn.close();
18. log.debug( "Connection discarded");
19. \} catch ( final IOException ex) \{
20. if ( this.log.isDebugEnabled()) \{
21. this.log.debug(ex.getMessage(), ex);
22. \}
23. \} finally \{
24. this.manager.releaseConnection(
25. this.managedConn, null, 0, TimeUnit.MILLISECONDS);
26. \}
27. \}
28. \}
29. \}

如果没有instream.read()读取数据，在instream.close()时会调用EofSensorInputStream\#checkClose()，也会有类似上面的逻辑。

所以就如官方例子注释的一样，在正常操作输入流后，会释放连接。

response.close()

最终是调用ConnectionHolder\#abortConnection()

1.  public void abortConnection()\{
2.  synchronized ( this.managedConn) \{
3.  *//如果连接已经释放，直接返回*
4.  if ( this.released) \{
5.  return;
6.  \}
7.  this.released = true;
8.  try \{
9.  *//关闭连接*
10. this.managedConn.shutdown();
11. log.debug( "Connection discarded");
12. \} catch ( final IOException ex) \{
13. if ( this.log.isDebugEnabled()) \{
14. this.log.debug(ex.getMessage(), ex);
15. \}
16. \} finally \{
17. this.manager.releaseConnection(
18. this.managedConn, null, 0, TimeUnit.MILLISECONDS);
19. \}
20. \}
21. \}

所以，如果在调用response.close()之前，没有读取过输入流，也没有关闭输入流，那么连接没有被释放，released=false，就会关闭连接。

httpClient.close()

最终调用的是InternalHttpClient\#close()，会关闭整个连接管理器，并关闭连接池中所有连接。

1.  public void close()\{
2.  this.connManager.shutdown();
3.  if ( this.closeables != null) \{
4.  for ( final Closeable closeable: this.closeables) \{
5.  try \{
6.  closeable.close();
7.  \} catch ( final IOException ex) \{
8.  this.log.error(ex.getMessage(), ex);
9.  \}
10. \}
11. \}
12. \}

总结：

1、使用连接池时，要正确释放连接需要通过读取输入流 或者 instream.close()方式；

2、如果已经释放连接，response.close()直接返回，否则会关闭连接；

3、httpClient.close()会关闭连接管理器，并关闭其中所有连接，谨慎使用。

2.5、过期和空闲连接清理

在连接池保持连接的这段时间，可能出现两种导致连接过期或失效的情况：

1、连接保持时间到期

每个连接对象PoolEntry都有expiry到期时间，在创建和释放归还连接是都会为expiry到期时间赋值，在连接池保持连接的这段时间，连接已经到了过期时间（注意，这个过期时间是为了管理连接所设定的，并不是指的TCP连接真的不能使用了）。

对于这种情况，在每次从连接池获取连接时，都会从routeToPool的available队列获取Entry并检测此时Entry是否已关闭或者已过期，若是则关闭并分别从routeToPool、httpConnPool的available队列移除该Entry，之后再次尝试获取连接。代码如下

1.  */\*\*AbstractConnPool\#getPoolEntryBlocking()\*/*
2.  for (;;) \{
3.  *//从availabe链表头迭代查找符合state的entry*
4.  entry = pool.getFree(state);
5.  *//找不到entry，跳出*
6.  if (entry == null) \{
7.  break;
8.  \}
9.  *//如果entry已关闭或已过期，关闭entry，并从routeToPool、httpConnPool的available队列移除*
10. if (entry.isClosed() || entry.isExpired(System.currentTimeMillis())) \{
11. entry.close();
12. this.available.remove(entry);
13. pool.free(entry, false);
14. \}
15. else \{ *//找到可用连接*
16. break;
17. \}
18. \}

2、底层连接已被关闭

在连接池保持连接的时候，可能会出现连接已经被服务端关闭的情况，而此时连接的客户端并没有阻塞着去接收服务端的数据，所以客户端不知道连接已关闭，无法关闭自身的socket。

对于这种情况，在从连接池获取可用连接时无法知晓，在获取到可用连接后，如果连接是打开的，会有判断连接是否陈旧的逻辑，如下

1.  */\*\*MainClientExec\#execute()\*/*
2.  if (config.isStaleConnectionCheckEnabled()) \{
3.  *// validate connection*
4.  if (managedConn.isOpen()) \{
5.  this.log.debug( "Stale connection check");
6.  if (managedConn.isStale()) \{
7.  this.log.debug( "Stale connection detected");
8.  managedConn.close();
9.  \}
10. \}
11. \}

isOpen()会通过连接的状态判断连接是否是open状态；

isStale()会通过socket输入流尝试读取数据，在读取前暂时将soTimeout设置为1ms，如果读取到的字节数小于0，即已经读到了输入流的末尾，或者发生了IOException，可能连接已经关闭，那么isStale()返回true，需要关闭连接；如果读到的字节数大于0，或者发生了SocketTimeoutException，可能是读超时，isStale()返回false，连接还可用。

1.  */\*\*BHttpConnectionBase\#isStale()\*/*
2.  public boolean isStale()\{
3.  if (!isOpen()) \{
4.  return true;
5.  \}
6.  try \{
7.  final int bytesRead = fillInputBuffer( 1);
8.  return bytesRead < 0;
9.  \} catch ( final SocketTimeoutException ex) \{
10. return false;
11. \} catch ( final IOException ex) \{
12. return true;
13. \}
14. \}

如果在整个判断过程中发现连接是陈旧的，就会关闭连接，那么这个从连接池获取的连接就是不可用的，后面的代码逻辑里会重建当前PoolEntry的socket连接，继续后续请求逻辑。

后台监控线程检查连接

上述过程是在从连接池获取连接后，检查连接是否可用，如不可用需重新建立socket连接，建立连接的过程是比较耗时的，可能导致性能问题，也失去了连接池的意义，针对这种情况，HttpClient采取一个策略，通过一个后台的监控线程定时的去检查连接池中连接是否还“新鲜”，如果过期了，或者空闲了一定时间则就将其从连接池里删除掉。

ClientConnectionManager提供了 closeExpiredConnections()和closeIdleConnections()两个方法，关闭过期或空闲了一段时间的连接，并从连接池删除。

closeExpiredConnections()  
该方法关闭超过连接保持时间的连接，并从池中移除。

closeIdleConnections(timeout,tunit)

该方法关闭空闲时间超过timeout的连接，空闲时间从交还给连接池时开始，不管是否已过期，超过空闲时间则关闭。

下面是httpClient官方给出的清理过期、空闲连接的例子

1.  public static class IdleConnectionMonitorThread extends Thread\{
2.  
3.  private final ClientConnectionManager connMgr;
4.  private volatile boolean shutdown;
5.  
6.  public IdleConnectionMonitorThread(ClientConnectionManager connMgr)\{
7.  super();
8.  this.connMgr = connMgr;
9.  \}
10. 
11. @Override
12. public void run()\{
13. try \{
14. while (!shutdown) \{
15. synchronized ( this) \{
16. wait( 5000);
17. *// Close expired connections*
18. connMgr.closeExpiredConnections();
19. *// Optionally, close connections*
20. *// that have been idle longer than 30 sec*
21. connMgr.closeIdleConnections( 30, TimeUnit.SECONDS);
22. \}
23. \}
24. \} catch (InterruptedException ex) \{
25. *// terminate*
26. \}
27. \}
28. 
29. public void shutdown()\{
30. shutdown = true;
31. synchronized ( this) \{
32. notifyAll();
33. \}
34. \}
35. \}

# 三、如何设置合理的参数 #

关于设置合理的参数，这个说起来真的不是一个简单的话题，需要考虑的方面也听到，是需要一定经验的，这里先简单的说一下自己的理解，欢迎各位批评指教。

这里主要涉及两部分参数：连接数相关参数、超时时间相关参数

1、连接数相关参数

根据“利尔特法则”可以得到简单的公式：

![bb1dddfc6ee63][]

简单地说，利特尔法则解释了这三种变量的关系：L—系统里的请求数量、λ—请求到达的速率、W—每个请求的处理时间。例如，如果每秒10个请求到达，处理一个请求需要1秒，那么系统在每个时刻都有10个请求在处理。如果处理每个请求的时间翻倍，那么系统每时刻需要处理的请求数也翻倍为20，因此需要20个线程。连接池的大小可以参考 L。

qps指标可以作为“λ—请求到达的速率”，由于httpClient是作为http客户端，故需要通过一些监控手段得到服务端集群访问量较高时的qps，如客户端集群为4台，服务端集群为2台，监控到每台服务端机器的qps为100，如果每个请求处理时间为1秒，那么2台服务端每个时刻总共有 100 \* 2 \* 1s = 200 个请求访问，平均到4台客户端机器，每台要负责50，即每台客户端的连接池大小可以设置为50。

当然实际的情况是更复杂的，上面的请求平均处理时间1秒只是一种业务的，实际情况的业务情况更多，评估请求平均处理时间更复杂。所以在设置连接数后，最好通过比较充分性能测试验证是否可以满足要求。

还有一些Linux系统级的配置需要考虑，如单个进程能够打开的最大文件描述符数量open files默认为1024，每个与服务端建立的连接都需要占用一个文件描述符，如果open files值太小会影响建立连接。

还要注意，连接数主要包含maxTotal-连接总数、maxPerRoute-路由最大连接数，尤其是maxPerRoute默认值为2，很小，设置不好的话即使maxTotal再大也无法充分利用连接池。

2、超时时间相关参数

connectTimeout  --  连接超时时间

根据网络情况，内网、外网等，可设置连接超时时间为2秒，具体根据业务调整

socketTimeout  --  读超时时间（等待数据超时时间）

需要根据具体请求的业务而定，如请求的API接口从接到请求到返回数据的平均处理时间为1秒，那么读超时时间可以设置为2秒，考虑并发量较大的情况，也可以通过性能测试得到一个相对靠谱的值。

socketTimeout有默认值，也可以针对每个请求单独设置。

connectionRequestTimeout  --  从池中获取连接超时时间

建议设置500ms即可，不要设置太大，这样可以使连接池连接不够时不用等待太久去获取连接，不要让大量请求堆积在获取连接处，尽快抛出异常，发现问题。

参考资料：