Java HttpClient 连接复用怎么观察：请求超时、连接池与响应体关闭边界

线上服务调用第三方接口时，连接复用是否生效，通常不会直接报一个“复用失败”。更常见的信号是：第一次请求还能接受，连续请求的延迟开始抖动，超时设置也像没有起作用。Java 11 引入的标准 HttpClient 能复用连接，但要把连接建立超时、请求整体超时和响应体处理分开观察，才知道问题落在哪一层。

先用同一个 HttpClient 实例发出一组请求，分别记录连接建立边界、响应完成时间和响应体是否读完；不要每次请求都重新创建客户端。

同一个 HttpClient，才有观察连接复用的前提

把 HttpClient.newBuilder().build() 写进每个请求方法，是最容易忽略的边界。每个调用都得到新客户端时，即使目标地址相同，也无法用一组请求观察同一个客户端的复用行为。更稳妥的做法是把客户端作为应用级依赖保存下来，让请求只创建 HttpRequest。

HttpClient client = HttpClient.newBuilder()
        .connectTimeout(Duration.ofSeconds(2))
        .build();

HttpRequest request = HttpRequest.newBuilder(uri)
        .timeout(Duration.ofSeconds(5))
        .GET()
        .build();

HttpResponse response = client.send(
        request, HttpResponse.BodyHandlers.ofString());

这里有两个时间边界：connectTimeout 针对建立连接，HttpRequest.timeout 针对一次请求的完成。后者不是“连接池超时”，也不会替你判断服务端业务是否已经处理完。

把连接建立、响应头和响应体分成三段记录

实测时不要只打印一个总耗时。可以在发送前记录 startedAt，在 send 返回后记录 headersAt，再读取 response.body() 后记录 bodyAt。同步 API 的返回已经带着完整响应体；异步 API 则要把完成阶段定义清楚。

如果连接建立慢，优先看 DNS、代理和目标地址；如果响应头很快但响应体慢，问题更接近服务端输出或网络传输；如果同一客户端的后续请求耗时下降，才有理由把它作为连接复用的观测信号。

sendAsync 不能只看响应头：响应体读完才算一次完整请求

sendAsync 返回的是 CompletableFuture。使用 BodyHandlers.ofString 时，响应体会被收集成字符串，最终的 HttpResponse 才适合作为一次完成请求的记录点。不要在看到响应头后就把请求标成成功，否则耗时和连接压力都会被低估。

CompletableFuture> future =
        client.sendAsync(request, HttpResponse.BodyHandlers.ofString());

future.thenAccept(response -> {
    int status = response.statusCode();
    String body = response.body();
    record(status, body.length());
});

这段链路中，sendAsync 是启动点，BodyHandlers.ofString 决定响应体如何消费，HttpResponse 才携带状态码和已经得到的 body；可以把这一步明确记成“响应体读取”。对大响应体不要盲目使用字符串收集器，应按业务改用流式处理并记录读取完成条件。

三个容易误判的超时和复用问题

把连接超时当成请求总超时

目标主机已经连上，但服务端迟迟不返回完整响应时，connectTimeout 不会替你结束这次请求。用 HttpRequest.timeout 表达单次请求上限，并在异常记录中区分超时发生阶段。

每次请求都创建 HttpClient

这种写法让客户端生命周期和请求生命周期绑死，既不利于复用，也让排查时无法比较同一实例的连续请求。应用关闭时再统一释放相关资源，调用代码只负责构造请求。

只记录 statusCode，不记录 body 完成

状态码到达不等于响应体已经被业务消费。把 response.body() 的读取完成放进成功判定，才能和真实用户等待时间对应起来。

用一组可比较的请求确认变化是否真实

验证时固定目标地址、请求方法和响应体大小，先发送一组冷启动请求，再在同一个 HttpClient 实例上发送连续请求。记录每次的请求总时长、异常类型、状态码和 body 长度；不要只拿一次最快结果下结论。

如果改动前后只有客户端创建位置发生变化，比较两组请求的中位数和高分位耗时更有意义。若高分位仍被服务端处理时间主导，继续调整客户端连接参数通常不会解决根因。

相关问题

HttpClient 应该每次请求创建吗？

通常不应该。对同一应用或同一远程服务，优先复用一个配置明确、生命周期可管理的 HttpClient。

connectTimeout 能限制接口返回时间吗？

不能。它主要约束连接建立；单次请求的总时间应使用 HttpRequest.timeout 并结合响应体完成记录。

为什么响应头到了，业务仍然很慢？

响应体可能仍在传输或读取。使用 BodyHandlers.ofString 时，应把 body 收集完成作为一次完整请求的结束点。

把客户端生命周期、超时边界和响应体完成点分开后，连接复用不再是一个凭感觉的优化项。先用同一实例建立可比较的请求记录，再根据延迟分布判断是连接建立、服务端处理还是响应体传输在拖慢调用。