高性能httpClient

最近工做中遇到了一个rpc高频调用出现

java.net.BindException: 地址已在使用

问题，因为线下测试的时候并无庞大的数据量来支撑，这个问题并无在测试阶段被发现。研究发现，出现改问题的主要是由于短期内OS的socket被迅速烧光，程序初启动前20秒内一切正常，后面开始狂抛此类异常。以前的http调用主要使用httpclient框架实现，代码以下：

HttpClient httpClient = HttpClient();
GetMethod method = GetMethod();
httpClient.getHttpConnectionManager().getParams().setConnectionTimeout();
httpClient.getHttpConnectionManager().getParams().setSoTimeout();
{
    httpClient.executeMethod(method);
} (Throwable t) {
    System..println();
}
String responseBodyAsString = ;
{
    responseBodyAsString = method.getResponseBodyAsString();
    System..println();
} (Throwable t) {
    System..println();
}

该段代码被封装在一个普通的发放内 每次调用传入相应的URL和参数便可。正常状况下并不会出现什么问题。深刻分析代码后发现httpclient 对象内部会默认建立一个HttpClientParams对象和SimpleHttpConnectionManager对象 manager 对象内部会持有一个connection 这里能够类比与jdbc 中的connection。很是蛋疼的一点是这个链接在执行完请求后并不会被当即关闭。SimpleHttpConnectionManager对象中有这样一句

alwaysClose = ;

这意味着该链接默认不会被关闭。固然随着方法被执行完，这些对象就成了垃圾数据会被gc掉。可是底层资源的释放速度可就很差说了。偏偏在于上面的那一大段代码处于方法里，在高频调用这个方法时，会建立超多的底层tcp链接。下面的故事就不用多说了。

可能有人会想到既然没关掉这个链接那就想办法关掉就是了 。本人初期也是这么想的 关掉不就好了吗。网上荡了一份代码

HttpClient httpClient = HttpClient(HttpClientParams(),SimpleHttpConnectionManager());

听说这样就能够保证链接会断开（客户端断开），然并卵～～～

继续坑，既然断掉也不行那就复用好吧，翻看源码发现

HttpConnectionManager

这个接口的实现有三个（包含SimpleHttpConnectionManager），其中一个叫作

MultiThreadedHttpConnectionManager

发现了曙光，为多线程准备的ConnectionManager .搞来玩玩。  因而乎就出现了如下的代码

MultiThreadedHttpConnectionManager =MultiThreadedHttpConnectionManager();

{
    .getParams().setMaxTotalConnections();
    .getParams().setDefaultMaxConnectionsPerHost();
}

须要指出的是，这个管理器能够管理多个链接池，底层是一个Map key为host Value 则是connectionPool

setDefaultMaxConnectionsPerHost  就是指每一个host容许创建的最多链接数。不须要太多！

结合

new HttpClient(new HttpClientParams(),new SimpleHttpConnectionManager(true));

想到了什么 ？

是的 ：

new HttpClient(new HttpClientParams(),cm);

下面的代码原封不动，可是要主要的是获取完数据后记得调用 

method.releaseConnection();

正所谓好借好还，再借不难嘛

这些链接会被管理器揣在兜里须要的时候问他申请，有就给你，没有嘛一边呆着等

我的猜想是借助了http链接的keepAlive 特性。实现多个请求复用一个通道。

注：本文借鉴了多篇该领域的文章，同时结合自身的一些实践心得整理而成