前阵子联调一个数据同步接口对方服务端是边算边返回响应头里没有 Content-Length只有Transfer-Encoding: chunked。用 HttpAsyncClient 发异步请求第一眼看上去返回的 HttpEntity 很普通但真要正确地把数据读完、把连接还给连接池里面还是有不少门道。我前前后后踩了几个坑排查过程也绕了几圈干脆把关于分块传输编码Chunked Transfer Encoding响应处理的经验完整写下来给同样被这类响应教育过的同学一个参考。这篇文章适合两类人一个是刚接触 Apache HttpAsyncClient、听说过 chunked 但不知道怎么处理流式响应的新手另一个是已经在用异步 HTTP 客户端但遇到连接池耗尽、响应读不全、回调线程卡死等诡异问题的开发者。我会从协议本身讲起把 HttpAsyncClient 内部做了什么、我们还需要做什么、以及最容易出问题的几个环节全部拆开说清楚。1. 分块传输编码到底在解决什么问题从一条不知道多长的响应说起1.1 响应体长度不明时HTTP/1.1 给出的答案先回到最基础的问题HTTP 响应里数据到哪里算结束最常见的方式是Content-Length告诉客户端这具响应体有多少字节客户端读够这个数就停。但有一种情况服务器很尴尬——它根本不知道整体要发多少字节。典型场景就是服务端动态生成内容比如查询结果要边查数据库边拼 JSON拼到一半已经可以开始发了视频转码服务的进度通知每出几条进度就要推送一次代理网关收到上游慢响应时自己手里只有流没有总长度。这种时候如果死等Content-Length客户端得等到服务端把整个响应体全部生成完才能拿到第一个字节体验极差。于是 HTTP/1.1 规定了第二种长度声明方式Transfer-Encoding: chunked也就是分块传输编码。它和Content-Length是互斥的RFC 7230 里写得很明白响应里如果带了Transfer-Encoding: chunked就不能再带Content-Length。这也是很多排查场景里最直接的判断信号——没有 Content-Length 但有 Transfer-Encoding那 body 就是 chunked。1.2 分块编码在 TCP 报文层面长什么样很多人对 chunked 的理解停留在听说过的层面实际抓包看一眼就全明白了。一个 chunked 响应体是这样的HTTP/1.1 200 OK Content-Type: application/json Transfer-Encoding: chunked 1f {orderId:1001,items:[ {sku:A001,count:2} ] 0注意那几个看似奇怪的换行里面每一块格式是十六进制数字 CRLF表示这一块数据的字节长度紧接着是这么多个字节的原始数据 CRLF最后是长度0 CRLF CRLF表示整个 body 结束。我习惯用一个类比来记这就好比快递公司不知道这一箱货总共有多重但可以一箱一箱先发走每个箱子上贴一个标签写清楚这箱有多重最后一箱贴个 0 告诉收货人发货结束。HTTP 报文的接收方只要按标签逐个拆箱就行不需要预先知道总重量。对应用层来说chunked 并不改变业务数据本身它只是 HTTP/1.1 在传输层玩的一个包装手法。真正的难点是作为客户端我们怎么把这一箱一箱的数据高效地取出来并且别把连接搞坏。2. HttpAsyncClient 把拆块的脏活提前干完了解码机制与无感知数据通路2.1 你以为要手写 chunk 解析其实大可不必和很多人第一反应不同HttpAsyncClient 处理 chunked 响应基本是透明的。也就是说你拿到HttpResponse.getEntity()之后用entity.getContent()得到的输入流已经是把 chunk 边界和长度前缀全部剥掉之后的纯业务数据流。这是因为 Apache HttpClient 系列包括异步版在协议层内置了 chunked 解码器。响应数据从 TCP 缓冲区被读出来之后会经过一层 ChunkedInputStream 的解码包装这层解码把十六进制长度行、CRLF 分隔符、结束块全部消费掉。你的读取代码根本不需要关心哪几个字节属于哪个 chunk只需要像读普通流一样一直读到-1就算读完了。我见过有人拿原始 socket 自己收 HTTP 响应然后盯着 chunk 长度行写状态机最后累得半死。用 HttpAsyncClient 的话这个状态机是现成的不需要重复造轮子。2.2 数据通路从网络事件到业务输入流要理解后面几个坑最好先对 HttpAsyncClient 的内部数据通路有个大致印象。它底层是 NIO 事件驱动的默认使用 IOReactor 线程组处理连接上的读写事件。当服务端把一块 chunk 数据发过来时IOReactor 线程从 Channel 读数据经过协议解析器识别出当前是 chunk 数据段再通过解码逻辑还原成连续的字节流。然后这些字节被交给当前请求关联的 consumer。HttpAsyncClient 默认的 consumer 会把这些字节累积到一个缓冲里最后在响应完成后包装成可读取的HttpEntity。这就带来一个重要推论**IOReactor 线程一直在参与数据的搬运。**如果你在业务线程里慢慢读输入流只要连接还开着reactor 线程就会持续关注这个连接。如果你处理得太慢缓冲区可能会被动扩大如果你在 reactor 线程里做耗时操作那整个事件循环都会被堵住其他请求全部陪跑。这个点后面踩坑章节我还会详细说。2.3 怎么确认当前响应确实是 chunked写代码时不要凭感觉判断直接打日志最靠谱。常用的判断方式有三个boolean chunked entity.isChunked(); System.out.println(isChunked chunked); // 更直接一点看原始响应头 Header transferHeader response.getFirstHeader(Transfer-Encoding); System.out.println(Transfer-Encoding transferHeader);需要提醒的是entity.isChunked()的返回值和你读取流时实际遇到的行为可能不完全一致。原因是这个值来自响应头但经过代理或中间网络设备时头部可能被改写。比如源站返回 chunked中间经过一个网关被缓存成完整响应带上了 Content-Length这时候isChunked()就是 false。反过来源站给出 Content-Length但传输过程被某些异常情况打断连接关闭时 body 并没有读满这种就不是 chunked 但读起来也读不到 -1。所以判断响应类型只是第一步真正可靠的还是读数据时根据流的实际行为做错误处理。2.4 一个容易搞混的概念不是所有持续输出的响应都是 chunked有些同学把 chunked 和长连接、流式响应混为一谈。其实 chunked 解决的是长度未知的问题而长连接解决的是连接复用的问题。一个连接可以持续复用、同时每个响应都有明确的长度声明这两件事是独立的。还有 SSEServer-Sent Events这类场景服务端通过text/event-stream持续输出事件。SSE 响应通常也会用 chunked 传输因为服务端同样不知道总共要输出多少事件。但反过来说chunked 并不等于 SSE它也可能就是一份普通的 JSON只是服务端懒得算长度或者没法提前知道长度。搞清楚这点调接口时才不会看到 chunked 就以为对方是个流式接口。3. 实战三种方式把分块响应一块一块读出来理论说完直接上代码。我用的是 Apache HttpAsyncClientHttpClient 4.x 异步包连接池和请求配置一次性配好然后分三种姿势读取分块响应。3.1 基础版Future getContent() 流式消费最推荐的方式用FutureHttpResponse拿响应然后像读普通文件一样读取流RequestConfig config RequestConfig.custom() .setConnectTimeout(5000) .setConnectionRequestTimeout(5000) .setSocketTimeout(30000) .build(); PoolingAsyncClientConnectionManager manager new PoolingAsyncClientConnectionManager(); manager.setMaxTotal(200); manager.setDefaultMaxPerRoute(100); CloseableHttpAsyncClient client HttpAsyncClients.custom() .setDefaultRequestConfig(config) .setConnectionManager(manager) .build(); client.start(); try { HttpGet request new HttpGet(http://example.com/api/stream); FutureHttpResponse future client.execute(request, null); // 注意get 超时之后别直接放弃后面我会讲怎么收尾 HttpResponse response future.get(30, TimeUnit.SECONDS); HttpEntity entity response.getEntity(); System.out.println(chunked? entity.isChunked()); System.out.println(Content-Length? entity.getContentLength()); try (InputStream in entity.getContent()) { byte[] buf new byte[8192]; int n; long total 0; while ((n in.read(buf)) ! -1) { total n; // 这里拿到的就是解码后的业务数据没有 chunk 长度前缀 // 按自己的格式解析比如写入文件、逐行解析 JSON 片段等 } System.out.println(read finished, total total); } } finally { client.close(); }这段代码有几个细节值得说。第一entity.getContent()返回的 InputStream 实现类在 HttpClient 4.x 里通常是ContentInputStream内部封装了 chunked 解码。你读出来的字节流已经是干净的业务数据不需要自己拼 chunk。第二try-with-resources一定要用。分块响应如果不读到-1就关闭流底层会把这个连接标记为响应体未完整消费连接池就无法把这个连接归还复用。很多连接池耗尽的问题就是从这里来的。第三流的读取要放在业务线程不要放在future.get()之后的调用点上就掉以轻心——如果这个调用点本身就在某个共享线程里还是会影响别人。3.2 回调版FutureCallback 与线程模型的注意事项有的场景需要异步回调比如发完请求不等结果后续逻辑在回调里触发。HttpAsyncClient 支持FutureCallbackHttpResponseHttpGet request new HttpGet(http://example.com/api/stream); client.execute(request, new FutureCallbackHttpResponse() { Override public void completed(HttpResponse response) { HttpEntity entity response.getEntity(); if (entity null) { return; } // 注意completed 跑在 IOReactor 线程上 // 不能在这里直接读完整条流或做耗时操作 asyncReadHandler.submit(() - { try (InputStream in entity.getContent()) { byte[] buf new byte[4096]; int n; while ((n in.read(buf)) ! -1) { // 业务处理 } } catch (IOException e) { // 异常处理 } }); } Override public void failed(Exception e) { // 连接失败、超时、读取中断等都会走这里 } Override public void cancelled() { // 主动取消时会触发 } });这里最容易被忽略的是线程问题。completed方法的执行线程就是 NIO reactor 线程它是所有异步连接的公共调度线程。如果你在completed里直接EntityUtils.toString(entity)一旦这个响应体有几个 MBIOReactor 线程就被你占住了整个客户端其他请求的读写全都会受影响。正确的做法是在completed里只做把流交给业务线程池这件事然后业务线程池去消费流。我习惯用一个专门的 reader 线程池来读流避免把 reactor 线程堵住。3.3 进阶版直接用 AsyncByteBufferConsumer 逐块消费还有一种更贴近底层的方式自己实现 consumer在每一块数据到达时做处理。这样甚至都不需要等到整个响应完成再读流可以做到来一块处理一块。client.execute(request, new AsyncByteBufferConsumer() { Override protected void onByteReceived(ByteBuffer buf, IOControl ioctrl) { // 这一块数据已经到达buf 里是解码后的部分数据 // 注意同样跑在 reactor 线程不能做复杂逻辑 // 常见做法拷贝进队列交给其他线程 byte[] bytes new byte[buf.remaining()]; buf.get(bytes); queue.offer(bytes); } Override protected void onResponseReceived(HttpResponse response) { // 响应头到达时就可以拿到状态码和头信息 } }, new FutureCallbackHttpResponse() { Override public void completed(HttpResponse response) { // 响应完成的回调 } Override public void failed(Exception e) { } Override public void cancelled() { } });AsyncByteBufferConsumer的好处是内存更可控。默认消费方式把整个响应体累积到一块遇到超大分块响应容易把内存撑爆自己实现 consumer 则可以在每一块字节到达时立刻转发出去不需要在客户端这边攒完整份数据。代价是代码变复杂而且边界条件很多比如连接中断时怎么通知下游、队列积压时要不要背压。我的建议是默认场景用 3.1 的流式读取就够了追求极致的流式处理再上 consumer。4. 我把分块响应读坏过的几个姿势踩坑复盘与根因排查这部分是重点我把真实复现过的几个问题按排查链路完整写下来照着这个思路可以少走弯路。4.1 问题一连接池打满日志出现 Connection pool is exhausted先说现象某个调第三方数据接口的服务平时流量不大但每次一触发批量任务连接池很快就耗尽日志不断出现Connection pool is exhausted。我一开始怀疑是连接池配置太小调大了 MaxTotal 和 MaxPerRoute结果只是把报错推迟了几分钟。后来发现一个规律连接耗尽总是发生在读某个分块大响应之后。于是我去查那些请求到底有没有把响应体读完。排查链路是这样的第一步在读取结束后打日志对比entity.getContentLength()和实际读到的字节数。如果getContentLength()返回 -1说明就是 chunked这时判断依据只能是是否读到了 -1。第二步加钩子看连接释放情况。Apache HttpClient 的连接池在响应体完整消费后才会把连接标记为可复用如果流没有读完就 close连接会被丢弃而不是归还。第三步在读取代码里找到了元凶——异常分支里只 catch 了业务异常但忘记关闭 InputStream。一旦处理过程中抛了业务异常流就永远没人读了连接也就从池子里消失了。修复方案并不复杂确保无论正常还是异常都把流读到底或者至少正确关闭。最好用try-with-resources然后只在确认读到-1的情况下才认为连接可以归还如果业务不需要剩余数据也要显式EntityUtils.consume(entity)让客户端把残余字节读完并归还连接。这条排查链路最大的启发是连接池耗尽不一定就是池子太小很多时候是连接根本没回来。4.2 问题二读取分块响应时 UI 假死排查发现是 reactor 线程被堵另一个典型案例一个桌面工具程序点按钮后去请求大数据接口界面卡死。最初怀疑是网络慢后来发现只要响应是 chunked 且体积稍大界面必卡。排查时我先抓了线程栈发现卡死的线程并不是 UI 线程而是某个名为 IOReactor 的线程。栈顶正好停在FutureCallback.completed方法里再往下是EntityUtils.toString。这下真相大白我在回调里直接做了完整读取把整个 reactor 线程占住了。Apache HttpAsyncClient 底层是 NIO 事件循环所有连接的事件都由少数几个 reactor 线程处理。你在回调里读流的时间越长其他连接的事件处理就被推迟得越久。如果数据量大或者网络慢整个连接池内的请求都会排队等待表现就是客户端整体卡死。修复方式就是 3.2 里写的回调只负责把entity.getContent()的结果提交给业务线程池真正读流和解析全在业务线程里做。修完这根线程就松快了UI 不再卡其他异步请求也恢复顺畅。4.3 问题三服务端在 chunk 之间断开到底算成功还是失败还有一个让人纠结的场景服务端返回了部分数据然后在下一个 chunk 还没发完时 TCP 连接断了。我的读取循环读到一半抛了IOException前面的数据已经交给业务逻辑处理了。这里有个经验性的判断原则流式接口必须以流结束标记为成功标准不能以收到响应头为标准。对 chunked 来说正常的成功结束一定是读到那个长度为 0 的结束块也就是你的read()返回-1。如果中途抛异常不管之前已经处理了多少块整个事务都应该按失败处理。已经处理过的部分数据如果是有业务语义的要做幂等补偿不能因为前面读得很顺利就认为成功。我们后来在业务层约定每条数据本身带一个 end 标记客户端读到 end 标记才算成功如果抛异常但没读到 end就把已积累的数据丢弃并标记任务失败重跑。这样网络抖动、服务端崩溃都能被正确识别。5. 超时、连接池与资源回收分块场景下的配套设置才是真正的胜负手5.1 SocketTimeout 与两个 chunk 之间等太久很多人把 SocketTimeout 理解成整条响应必须在 N 秒内读完其实不对。SocketTimeout 在 TCP 层面表示的是两个数据包到达之间的最大空闲时间也就是读操作阻塞的最大时长。这在分块响应里非常关键。服务端如果边算边发块与块之间可能停顿很久。比如一个查询要跑 40 秒中间每 5 秒发一个进度块但最后一块还在算那么 socket 超时时间如果小于 40 秒客户端会在等下一块数据时超时哪怕整个响应其实还在正常生成中。我踩过这个坑把 SocketTimeout 配成 10 秒调一个慢查询接口结果每 11 秒稳定超时一次。后来把 SocketTimeout 调到 60 秒才稳定。所以分块场景下的超时时间要按服务端最大块间隔来配而不是按整体响应时长。配置代码RequestConfig config RequestConfig.custom() .setConnectTimeout(3000) .setConnectionRequestTimeout(5000) .setSocketTimeout(60000) // 重点按块间隔算 .build();5.2 连接复用与 EntityUtils.consume 的正确姿势分块响应处理完以后连接能不能还给连接池复用完全取决于流是否被完整消费。如果你只关心响应前 1KB 数据后面的一堆 chunk 不想读直接关流虽然不会报错但连接无法复用等于白白浪费一个连接。这种情况下最标准的做法是显式消费掉剩余内容HttpEntity entity response.getEntity(); // 读了一部分后面不重要了 if (entity ! null) { EntityUtils.consume(entity); // 内部会把剩余数据读完并释放连接 }EntityUtils.consume会一直读到流的末尾确保底层连接状态是干净的。要注意的是这方法会真实地把剩余字节从网络上读完如果剩余部分特别大它会花时间但这是保证连接可复用的必要代价。5.3 连接池参数对分块长连接的影响分块响应天然适合连接复用因为服务端和客户端都没有长度约束读完一个响应后连接立刻可以发下一个请求。但如果连接池太小多个慢流式请求会把连接全占住后续请求只能排队等ConnectionRequestTimeout超了就报错。我建议分块场景下至少关注三个参数参数建议理由MaxTotal100~300留足余量给慢流式响应占用的连接DefaultMaxPerRoute50~150按实际并发峰值配置ConnectionRequestTimeout5~10s等待空闲连接的最大时间别配太长配完连接池再配合 4.1 的连接归还检查基本就不会出现连接池被分块响应拖垮的情况。5.4 重试策略分块响应中断后别盲目重试分块响应读到一半断了能不能重试要看请求是否幂等。如果前面读到的数据已经对业务产生了影响重试可能导致重复处理。如果只是拉取数据、解析失败重试没问题。HttpAsyncClient 的重试机制HttpRequestRetryHandler默认对幂等请求GET、HEAD 等生效但重试发生在连接异常时如果响应已经开始传输且断在中间重试一般会重新发起请求。这种时候要注意接口那边会不会重复计算、重复推送。我通常的做法是给请求加一个全链路 trace id服务端根据 trace id 做幂等客户端这边记录已经处理到的偏移量重试时从偏移量往后继续。6. 再往前一步SSE、HTTP/2 与分块响应之外的选择6.1 SSE 和 chunked近亲关系SSEServer-Sent Events是服务端主动推送技术响应类型是text/event-stream。实际抓包你会发现SSE 响应几乎都会带Transfer-Encoding: chunked因为服务端也是不知道总长度、边生成边发。用 HttpAsyncClient 拉 SSE 数据流的做法和普通 chunked 完全一样只要把entity.getContent()拿到的输入流交给一个按行解析的 reader 就行因为 SSE 的协议格式是data: ...分行每行一个事件。但 SSE 有一个额外要求客户端要长时间保持连接期间可能一直有数据流动。这时候连接池的占用时间会更长建议给 SSE 请求单独开一个连接池避免和普通短请求互相抢连接。6.2 HTTP/2 下没有 chunked 了但流式响应依然存在如果服务端和客户端都支持 HTTP/2chunked 这个头就不需要了。HTTP/2 用 DATA 帧天然支持流式传输一个流可以分多个帧慢慢发接收方按帧读取不需要在应用层再套一层长度前缀。Apache HttpClient 5.x 的异步版本已经支持 HTTP/2但需要额外的 h2 依赖和配置。要不要为了支持流式从 HTTP/1.1 切到 HTTP/2我的建议是如果现有服务用 chunked 已经跑得挺好切换价值不大如果追求多路复用、低延迟HTTP/2 确实能把多个请求在一个连接上并行处理减少连接数。但切换意味着服务端、网关、负载均衡都要支持迁移成本要整体评估。6.3 什么时候该考虑 WebSocket还有一种常见持续性通信场景是 WebSocket。注意 WebSocket 不是 HTTP 响应的一种形式它是通过 HTTP 升级握手切换到另一个二进制协议。如果只是想单向接收服务端推送SSE/分块响应就够用如果要做双向实时交互才需要 WebSocket。HttpAsyncClient 本身不处理 WebSocket需要引入专门的客户端库协议处理也是另一套体系别把它和 chunked 混为一谈。我在实际项目中判断标准很简单服务端单方向发数据给我我用分块响应/SSE需要我主动发消息且要求低延迟才上 WebSocket。大多数数据同步、进度通知场景分块响应都比 WebSocket 轻量得多。最后再分享一个小经验处理分块响应时别只盯着业务代码一定要把连接归还、线程模型、超时配置三个维度一起检查。我见过太多人把问题归结为HttpAsyncClient 的 bug最后发现是流没读完导致连接泄漏、或者在 reactor 线程上做了阻塞操作。先看entity.isChunked()再确认流的读取方式和线程归属最后用抓包确认服务端到底是怎么发的这套组合拳打下来分块响应基本不会再有意外。