httpclient4.3 线程池超时问题解决

最新推荐文章于 2025-07-01 17:50:54 发布

原创最新推荐文章于 2025-07-01 17:50:54 发布 · 3.1k 阅读

1 ·

CC 4.0 BY-SA版权

java 同时被 2 个专栏收录

16 篇文章

订阅专栏

HTTP

4 篇文章

订阅专栏

博客讲述了在使用HttpClient4.3时遇到的线程池超时问题及其解决方法。首先检查并确保连接在请求完成后被正确关闭；其次，异常时主动调用HttpUriRequest的abort方法中断请求；最后，调整连接池参数，特别是每个路由的最大连接数，以避免因默认值限制导致的超时问题。通过这些措施，成功解决了线程池超时的问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

之前采用Httpclient4.3写了一个抓取服务，突然有一天线上出现了很多这样的报警

Read time out 和 ConnectionPoolTimeoutException: Timeout waiting for connection

使用连接池的原因是：没有连接池的话，多少次请求就会建立多少个IO，在访问量巨大的情况下服务器的IO可能会耗尽。

1 检查连接是否关闭

EntityUtils.consume(response.getEntity());

经检查所有的地方都采用这种方式在请求完进行关闭了。
以上关闭的原理是取出response的文件流InputStream（in），再执行in.close()关闭。

2 遇到异常时，关闭请求

已确认都关闭，但是线上的报警仍然存在。于是在遇到异常时显示调用HttpUriRequest的abort，这样就会直接中止这次连接，我们在遇到异常的时候应该显示调用，因为谁能保证异常是在InputStream in赋值之后才抛出的呢。

public CloseableHttpResponse request(HttpUriRequest request, List<Cookie> cookies, HttpHost host) {

        if (this.autoReferrer && !StringUtils.isEmpty(this.referrer) && !request.containsHeader(HttpHeaders.REFERER)) {

            request.setHeader(HttpHeaders.REFERER, this.referrer);
        }

        addCookies(this.cookieStore, cookies);

        CloseableHttpResponse response;
        try {
            if (host == null) {
                host = URIUtils.extractHost(request.getURI());
            }

            response = HTTP.execute(host, request, this.httpContext);

        } catch (IOException e) {
            request.abort();
            throw new RuntimeException(e);
        }

        if (this.autoReferrer) {
            this.referrer = request.getURI().toString();
        }

        return response;
    }

3 调整连接池参数

我将最大连接数从30调整为200，按道理讲已经足够承受200个连接请求了，但还是存在报警。经查询因为我发现了少配了每个路由(route)最大连接数。
【来自 http://blog.youkuaiyun.com/shootyou/article/details/6415248】
什么是一个route？

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

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

刚好符合我的应用情景，我不断地请求同一个域名。而每次最多只能有2个请求在工作，这两个请求刚好在这一时间段超时了，导致整个线程池超时，一直处于等待之中。由于我的大量请求集中在同一个域名，因此为每个路由设置了最多100个请求。上线验证，没有连接池超时错误了。

ConnectionPoolTimeoutException: Timeout waiting for connection

但仍然存在Read time out，可以确认是请求地址超时了，反馈给请求服务。