Java HttpClient BodyHandlers.ofLines 怎么避免响应流未关闭：行读取与资源生命周期

用 Java HttpClient 读取一个逐行返回的接口时，最容易被忽略的不是字符集，而是 BodyHandlers.ofLines() 给你的并非已经装满内存的列表，而是一个仍连接着响应体的 Stream。行读完后要让它正常结束；中途找到目标行就退出，也要显式关闭，否则连接资源的释放会被拖到不可控的时间。

ofLines() 适合边收边处理，但它的返回值必须按流资源管理：完整消费让流自然读尽，提前停止则用 try-with-resources 调用 Stream.close()。

响应头到了，不等于响应体已经结束

HttpClient.send() 返回 HttpResponse 时，响应头已经可用，但流式 body 可能仍在网络中。下面这条链路里，真正持有响应体读取能力的是 HttpResponse.body() 返回的流：

HttpRequest
  -> HttpClient.send(request, BodyHandlers.ofLines())
  -> HttpResponse>
  -> response.body()
  -> Stream
  -> 每一行的消费
  -> close 或读尽

这也是它和 BodyHandlers.ofString() 的关键差异。字符串处理通常在返回前已经完成聚合；ofLines() 则把响应体交给一个可继续读取的行流。Oracle API 文档也明确说明，响应体未必在 HttpResponse 返回时完全接收，流最终要关闭、取消，或读取到耗尽，交换所需资源才有明确的释放路径。

先看状态码，再把行流交给业务处理

一个实用的边界是：不要一拿到 Stream 就开始解析 JSON 行或业务记录。先检查 response.statusCode()，否则 404 或 500 的错误正文也可能被当成正常数据吞进去。

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.util.stream.Stream;

HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://example.com/events"))
    .GET()
    .build();

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

if (response.statusCode() != 200) {
    throw new IllegalStateException("HTTP status: " + response.statusCode());
}

try (Stream lines = response.body()) {
    lines.filter(line -> line.contains("event="))
         .forEach(System.out::println);
}

这里有两个容易漏掉的点。第一，try 包住的是 response.body() 返回的流，不是 HttpResponse；第二，forEach 返回后，try-with-resources 会调用 Stream.close()，让读取链路有一个确定的收尾动作。

只找一行时，提前结束更需要 close

业务代码经常不是要完整遍历，而是找到第一条匹配记录就返回。findFirst() 会让终端操作停止消费，但停止消费和关闭资源是两件事，不能把前者当成后者。

static String findEvent(HttpResponse> response,
                        String eventName) {
    if (response.statusCode() != 200) {
        throw new IllegalStateException("HTTP status: " + response.statusCode());
    }

    try (Stream lines = response.body()) {
        return lines.filter(line -> line.startsWith("event=" + eventName))
                    .findFirst()
                    .orElse(null);
    }
}

findFirst() 找到结果后，流不会为了满足你的业务目标继续把所有字节读完；但 try-with-resources 仍会在返回前关闭它。这个写法尤其适合响应体很长、目标记录靠前的场景。

异常、空响应和重复读取的三个边界

• 发送异常：client.send() 可能在拿到响应前抛出异常，此时没有 response body 需要关闭，调用方应按网络异常处理。
• 空响应：流可以正常没有元素，forEach 不会执行，但 try-with-resources 仍然负责关闭。
• 重复读取：Stream 不能重复消费。第一次终端操作结束后，不要再次调用 response.body() 期待得到新流；把需要的结果在同一个 try 块里提取出来。

还要注意，BodyHandlers 默认不会替你根据状态码拒绝响应体。状态判断属于业务层责任；如果错误响应很大，先采用合适的策略限制读取或改用更适合错误体的 handler，不要无条件把它全部塞入内存。

把资源生命周期写进代码评审清单

相关问题

ofLines() 和 ofString() 应该怎么选？

响应体较小且需要多次按字符串处理时可用 ofString()；需要边读边处理、过滤长响应或减少一次性聚合时选择 ofLines()，但要承担流关闭责任。

只调用 findFirst() 会自动释放 HTTP 连接吗？

它只表示终端操作提前结束，不应替代资源关闭。把 body 流放进 try-with-resources，才能明确执行 Stream.close()。

为什么状态码检查要放在流消费前？

BodyHandlers 本身通常不会按状态码拒绝响应体。先检查状态码，能避免把错误页面或错误 JSON 当成业务记录处理。

读取完成后还需要手动调用 close() 吗？

推荐统一使用 try-with-resources。它同时覆盖正常读尽、提前结束和解析异常三条路径，代码审查时也更容易确认生命周期闭合。

小结

BodyHandlers.ofLines() 的价值是把响应体变成可逐行消费的流，而不是把 HTTP 资源管理隐藏起来。记住“先状态码、再消费；完整读尽或提前停止，都放进 try-with-resources”这条边界，HttpClient 的长响应和快速查找场景就能用同一套清晰的收尾方式。