Apache HttpAsyncClient部署后遇Connection reset by peer问题求助

结合你给出的错误堆栈、依赖配置和服务器日志，我们可以一步步拆解问题并给出针对性的解决方案：

首先明确两个关键错误的关联：

• java.io.IOException: Connection reset by peer：这是TCP层的错误，意味着服务器或中间代理在连接未完成交互时主动关闭了连接
• 服务器日志里的499状态码（Nginx专属状态码）：表示客户端在服务器准备返回响应前就主动断开了连接，这和Connection reset by peer的出现高度对应，说明请求在处理过程中连接被提前终止了。

1. 升级依赖版本，修复已知连接管理bug #

你当前使用的httpasyncclient 4.1.3是2016年的老版本，httpclient和httpcore的版本也较旧，这些版本存在不少连接池、超时处理的已知问题。建议直接升级到稳定的新版本：

<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpasyncclient</artifactId>
    <version>4.1.5</version> <!-- 该版本修复了多个并发连接相关的bug -->
</dependency>
<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpclient</artifactId>
    <version>4.5.14</version>
</dependency>
<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpcore</artifactId>
    <version>4.4.16</version>
</dependency>

2. 配置合理的超时参数，避免连接意外中断 #

你的代码完全没有设置超时时间，这会导致两种问题：要么客户端等待过久被服务器主动踢掉，要么服务器响应慢时客户端无超时控制引发连接异常。必须添加三类超时配置：

CloseableHttpAsyncClient httpclient = HttpAsyncClients.custom()
        .setConnectionTimeToLive(60, TimeUnit.SECONDS) // 设置连接最大存活时间，避免长期占用
        .setDefaultRequestConfig(RequestConfig.custom()
                .setConnectTimeout(5000) // 连接建立超时（5秒）
                .setSocketTimeout(10000) // 数据传输超时（10秒）
                .setConnectionRequestTimeout(5000) // 从连接池获取连接超时（5秒）
                .build())
        .build();

3. 显式配置连接池，应对并行请求压力 #

默认连接池配置非常保守，并行请求多时容易出现连接耗尽，进而引发连接重置。根据业务需求调整连接池参数：

// 配置IO反应器，线程数建议和CPU核心数匹配
IOReactorConfig ioReactorConfig = IOReactorConfig.custom()
        .setIoThreadCount(Runtime.getRuntime().availableProcessors())
        .build();

// 配置连接池
PoolingNHttpClientConnectionManager connManager = new PoolingNHttpClientConnectionManager(ioReactorConfig);
connManager.setMaxTotal(20); // 全局最大连接数，根据服务器承受能力调整
connManager.setDefaultMaxPerRoute(10); // 单个域名的最大连接数

// 构建客户端时指定连接池
CloseableHttpAsyncClient httpclient = HttpAsyncClients.custom()
        .setConnectionManager(connManager)
        .setDefaultRequestConfig(/* 之前的超时配置 */)
        .build();

4. 修复代码中的资源泄漏问题 #

你的completed回调里没有正确关闭输入流和HttpEntity资源，这会导致连接无法被连接池回收，长期运行会耗尽所有连接，最终引发连接重置。用try-with-resources自动管理资源：

@Override
public void completed(final HttpResponse response) {
    latch.countDown();
    // 使用try-with-resources自动关闭流，避免资源泄漏
    try (BufferedReader in = new BufferedReader(
            new InputStreamReader(response.getEntity().getContent(), StandardCharsets.UTF_8))) {
        String data;
        while ((data = in.readLine()) != null) {
            // 处理数据的逻辑
        }
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        // 确保HttpEntity的资源被彻底释放，即使处理过程中出现异常
        EntityUtils.consumeQuietly(response.getEntity());
    }
}

5. 检查服务器端的超时配置 #

服务器（比如Nginx）如果设置了较短的keepalive_timeout、client_header_timeout或者client_body_timeout，当请求处理稍慢时，服务器会主动关闭连接。可以联系运维同学检查服务器的超时配置，适当延长相关参数，避免提前断开连接。

6. 添加重试机制，提升请求容错性 #

对于偶发的连接重置，可以添加重试策略，让客户端自动重试失败的请求：

CloseableHttpAsyncClient httpclient = HttpAsyncClients.custom()
        // 最多重试3次，允许重试非幂等请求（根据你的API是否幂等调整第二个参数）
        .setRetryHandler(new DefaultHttpRequestRetryHandler(3, true))
        // 其他配置
        .build();

按照上面的步骤逐一调整后，再测试并行请求，应该就能解决Connection reset by peer和499状态码的问题了。

内容的提问来源于stack exchange，提问作者DeathMate