你好！我是miniluo，今天和你分享使用HttpClient过程中，未考虑释放连接和并发导致的坑。
HttpClient在项目中还是比较常见的，主要都是通过GET或POST请求第三方以获取响应结果。前段时间还了解到也有企业用它来做爬虫。下面我们就从两方面来一起学习HttpClient。
强占着不放
我们先来看一张因未释放连接导致的异常图。
我们再来看代码，代码很简单，用一个static修饰HttpClient的一个对象，也是用static的方式实例化(并发下，static实例化的对象是线程不安全的)。
1@Slf4j
2public class MyHttpClientTest{
3 private static HttpClient client;
4 static {
5 RequestConfig requestConfig = RequestConfig.custom()
6 .setConnectTimeout(5000)
7 .setConnectionRequestTimeout(3000)
8 .setSocketTimeout(5000).build();
9 client = HttpClientBuilder.create().setDefaultRequestConfig(requestConfig)
10 .build();
11 }
12
13 @Test
14 public void testHttpClient(){
15 for (int i = 0; i
16 String url = "http://127.0.0.1:9092/learn/product/get/12";
17 HttpGet httpGet = new HttpGet(url);
18 try {
19 HttpResponse res = client.execute(httpGet);
20 } catch (IOException e) {
21 log.error("异常： ",e);
22 return;
23 }
24 }
25 }
26}
我们看回异常图，图中有2个红框，我们先来看第一个红框的“[total kept alive: 0; route allocated: 2 of2; total allocated: 2 of 20]”，这个DEBUG级别日志描述的什么意思呢？也就是说这个route下共有2个连接，已用2个；pool共有20个，已用2个。再来看第二个红框“Timeout waiting for connection from pool”，从连接池获取连接等待超时。奇怪吧，这顺序执行也会出现？这其实是前两个连接响应结果回来后，并没有释放连接资源，导致后面的请求等待超时。
我们看看PoolingHttpClientConnectionManager类的构造函数，其给Pool初始化时给maxConnPerRoute和maxConnTotal设置了默认值。
1 public PoolingHttpClientConnectionManager(
2 final HttpClientConnectionOperator httpClientConnectionOperator,
3 final HttpConnectionFactory connFactory,
4 final long timeToLive, final TimeUnit tunit){
5 super();
6 this.configData = new ConfigData();
7 //defaultMaxPerRoute默认为2，maxTotal默认为20
8 this.pool = new CPool(new InternalConnectionFactory(
9 this.configData, connFactory), 2, 20, timeToLive, tunit);
10 this.pool.setValidateAfterInactivity(2000);
11 this.connectionOperator = Args.notNull(httpClientConnectionOperator, "HttpClientConnectionOperator");
12 this.isShutDown = new AtomicBoolean(false);
13 }
所以当请求连接被占用2个后，后面的请求并不会获取到连接，这么说，我们需要释放连接资源。这里我们需要介绍EntityUtils这个类，里面包含了两个释放连接资源的方法consumeQuietly(HttpEntity entity)和consume(HttpEntity entity)，前者内部也是请求后者完成关闭InputStream。调整后的代码如下：
1@Test
2 public void testHttpClient(){
3 for (int i = 0; i
4 String url = "http://127.0.0.1:9092/learn/product/get/12";
5 HttpGet httpGet = new HttpGet(url);
6 HttpResponse res = null;
7 try {
8 res = client.execute(httpGet);
9 } catch (IOException e) {
10 log.error("异常： ", e);
11 return;
12 } finally {
13 if (null != res) {
14 EntityUtils.consumeQuietly(res.getEntity());
15 }
16 }
17 }
18 }
调整完代码后，我们执行后发现5个请求都能正确请求并得到响应结果。或许有同学会问到如果我调整maxConnPerRoute和maxConnTotal不也行吗？可以，但是你的连接还是没有释放，当超过你设置值后也会出现无法获得连接池的问题。
被CloseableHttpClient名字所坑
最近项目中就是使用到CloseableHttpClient实现请求第三方，踩完上面的坑后，我们在项目中写了一个工厂类内部用枚举方式实现单例。经过并发测试后，的确没有出现上述坑，看了CloseableHttpClient有一个execute方法，最后也有释放资源，所以没有在意。直到今天写文章对应的测试案例我才发现我被这个方法欺骗了。
CloseableHttpClient的execute()重载了多个方法，而实际调用能释放资源的execute必须是包含ResponseHandler extends T>这个属性，否则和原有HttpClient方式是一样的。为何，模拟高并发下并没有发生问题呢？这是因为项目中请求响应结果后是用下面的代码完成数据获取的。
1 HttpResponse response = client.execute(get);
2 String res = EntityUtils.toString(response.getEntity());
跟进EntityUtils.toString()方法的最底层调用，会执行InputStream关闭流，和上文说的consume方法一样。但是这里坑就坑在，如果请求第三方超时或其他异常，则直接跳过，并没有执行上面的toString()方法，那就不会释放连接资源。
知道坑所在，要解决也就好办。可以有下述两个方案：
1、外层调用增加finally释放连接，上文所述。
2、实例化一个ResponseHandler对象，调用实现了释放连接资源的方法。
总结
今天我们一起学习了HttpClient和CloseableHttpClient没有正确释放连接，以及并发受限的问题。实际项目中如果没有考虑到这两个情况，则会带来生产问题，后面的请求一直无法获取到连接资源，以及并发量起不来。很多项目并不会有这个问题是因为HttpClient和CloseableHttpClient并不是单例的，每次使用都会是新的实例。希望通过今天的学习对你日后使用HttpClient更加得心应手。由于篇幅问题，没有把CloseableHttpClient案例放上来，有兴趣的同学可以到GitHub上下载(https://github.com/littleluo/bj-share-java.git)。
思考和讨论
1、案例中，我们使用了static和枚举的方式解决单例问题，除了这两种方法外，还有哪些方式呢？他们各自的优缺点是什么？
2、说回前面关于分布式锁的文章中，我们用到了redis，也提到client.close()方式归还连接，为何是归还连接，而不是关闭连接呢？
欢迎留言与我分享和指正！也欢迎你把这篇文章分享给你的朋友或同事，一起交流。
感谢您的阅读，我们下节再见！
扫码关注我们，与君共进
![[xsd学习]xsd介绍](https://images.cnblogs.com/OutliningIndicators/ExpandedBlockStart.gif)
