Java内置HttpClient订阅者移除过慢问题咨询

问题背景 #

我基于OpenJDK 17/19开发了一款监听IDF民防司令部红警预警的应用，通过Java内置HttpClient循环请求目标JSON接口，使用HttpResponse.BodyHandlers.ofInputStream处理响应体，并将响应体InputStream置于try-with-resources块中管理。经IntelliJ Profiler检测发现，HttpBodySubscriberWrapper实例持续堆积，HttpClient通过registerSubscriber添加订阅者的速度远快于subscriberCompleted移除的速度。但使用HttpResponse.BodyHandlers.ofString时无此问题。

疑问解答 #

1. 现象成因

ofInputStream与ofString的核心差异在于响应体处理逻辑：

• ofString会一次性将响应体全部读取到内存，处理完成后立即触发订阅者的完成逻辑，subscriberCompleted被及时调用，订阅者实例正常清理。
• ofInputStream是流式处理，它仅创建绑定到订阅者的InputStream，实际响应体数据的读取是在你操作InputStream时才逐步进行。HttpClient内部的HttpBodySubscriberWrapper会一直存在，直到InputStream被完全读取并关闭，或显式关闭后底层响应流处理完成。若循环请求频率过高，或InputStream的读取/关闭操作未彻底完成（比如仅关闭流但仍有未处理的响应数据残留），就会导致订阅者堆积。

2. try-with-resources仍无法及时移除订阅者的原因

try-with-resources确实会保证调用InputStream的close()方法，但close()不一定能立即触发订阅者的完成逻辑：

• 关闭InputStream时，HttpClient需要先完成底层响应流的收尾工作（如清空剩余响应数据、释放连接资源），这个过程存在异步延迟，高频率循环请求场景下，JVM线程调度可能导致subscriberCompleted的执行滞后于新订阅者的添加。
• 如果代码在try块中未完全读取InputStream内容就关闭流，HttpClient内部需要额外时间处理未读取的响应体，也会拖慢订阅者的清理速度。

3. 控制订阅者集合大小的方法

• 确保完全读取InputStream内容：关闭流之前，主动读取InputStream的全部数据（比如用工具类将流读完），让订阅者更快进入完成状态。
• 调整HttpClient连接池参数：通过HttpClient.newBuilder().connectTimeout()设置连接超时，或用HttpClient.newBuilder().executor()自定义线程池，控制并发请求数量，避免短时间内创建过多订阅者。
• 添加请求间隔：在循环请求之间加入适当延迟，给前一个请求的订阅者清理留出足够时间，避免请求频率超过订阅者清理速度。

4. 强制仅保留1个未完成订阅者的实现

通过串行化请求即可实现：不要并发发起请求，而是在上一个请求完全处理完成（InputStream读取并关闭、订阅者已被清理）后，再发起下一个请求。比如用CompletableFuture链式调用，或直接在单线程中同步执行请求逻辑，确保同一时间只有一个请求在处理，自然只会有一个未完成的订阅者。

是否属于JDK Bug？ #

大概率不是JDK Bug。HttpResponse.BodySubscribers#ofInputStream的文档仅保证关闭InputStream会释放相关资源，并未承诺立即触发订阅者清理。这种堆积更多是使用方式导致的：流式处理本身需要更严谨的资源生命周期管理，高频率循环请求下的异步清理延迟属于预期行为。若怀疑是JDK问题，可构造极简复现案例验证，但常规场景下更可能是代码层面处理不彻底。

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