分块传输编码（Chunked Transfer Encoding）在HTTP响应里其实是相当常见的，尤其是在服务端没法提前知道响应体总长度的时候。比如流式输出日志、实时推送数据、动态生成报表，服务端就会用Transfer-Encoding: chunked告诉客户端“我接下来会一段一段地把数据发给你，长度不定，你按块收就行”。我之前用HttpAsyncClient处理这类响应时，踩过不少坑，一开始总是拿到空响应或者数据丢一半，后来把异步回调的逻辑理清楚了，才发现关键在于怎么在回调里正确消费缓冲区、怎么判断流结束、以及怎么处理块之间的边界。
这篇内容就围绕HttpAsyncClient解析chunked响应的完整思路展开，从设计层面解释为什么异步模式下分块响应容易“看着像没数据”，再给出一套可以直接落地的实现方案，包括回调封装、缓冲区的选择、逐块解析的技巧，以及几个典型的坑——像是连接被提前释放、回调内阻塞导致请求堆积、还有块大小和实际内容的边界问题。适合正在用HttpAsyncClient做HTTP流式处理，或者在异步请求里遇到“响应为空但明明有数据”这类诡异问题的开发者参考。
1. Chunked响应的底层机制与异步处理的特殊性
先快速过一遍chunked编码本身。HTTP/1.1的chunked传输，服务端在响应头里带Transfer-Encoding: chunked，然后响应体被拆成多个块，每个块前面有一行十六进制数字表示当前块的大小，接着是块数据，再往下是下一个块，直到收到一个大小为0的块，表示整个响应体结束。这个设计解决了Content-Length无法确定的问题，但同时也把“响应体的结束判定”从“读够N个字节”变成了“识别结束块”。
HttpAsyncClient处理这类响应的时候，底层NIO模型决定了它不能像传统同步HttpClient那样，在阻塞IO流里按字节读。AsyncClient的请求结果是通过Future.get()或者回调接口拿到的，而分块响应是流式的，数据是陆续到达的，API一旦等到“响应完成”再取结果，取到的往往只是最后一块或者根本取不到内容——因为所有中间块都在回调阶段被丢弃了。这是新手最容易踩的第一个坑：以为异步请求拿到响应对象后能直接读body，实际上body在异步模式下是“不可直接访问”的，你得在响应到达的每个阶段自己接管处理。
另外要注意，chunked响应和Content-Length响应的核心差异，不仅是“有没有长度字段”，而是处理模型的不同。Content-Length响应是一个“可完整缓冲的有限数据体”，你可以直接累积到字节数组；而chunked响应天然是需要“边收边处理”的流式数据，如果你强行把全量数据先存进内存再处理，服务端开的是长连接流式输出，那你的内存就会无上限增长，连接也可能因为消费不及时被对端拖死。
2. 异步响应处理的整体设计思路
要处理chunked响应，核心是理解AsyncClient的HttpAsyncResponseConsumer机制。这个接口的控制点刚好覆盖了分块响应的全生命周期：接收响应头、接收每个内容块、响应完成、失败、取消。开发者真正要做的，就是在这几个回调节点里，把chunked流“拆、存、转、判”——拆出每个块的数据，存到合适的缓冲区，转成可用的业务对象，判断终止条件。
我最早用的是最简单粗暴的做法：自己维护一个ByteArrayOutputStream，在每个content块到达时往里面写入，响应结束后再从流里拿出完整字节数组。这个方案在面对小响应时确实有效，代码逻辑也直观。但有个很实际的问题——如果对方是个持续输出的流式接口，比如日志推送或者做SSE类长轮询，这种累积式的处理会把内存越撑越大，而且因为你在回调里同步等待完整流结束，你对“每一块数据到达”这个事件完全无感，业务侧没法做实时处理。
后来我改成了基于“块级回调和终止信号”的设计：每个content块到达时先做独立的业务解析，比如提取当前块的JSON片段、计算进度、即时更新缓存等，再决定是不是要累积或落盘。整个处理链路分成了三层——连接层只负责把字节块回调出来，解析层负责把块转换为业务事件，存储层负责按需落内存或落文件。这样chunked就不再是一个“要等完整下载完才能看的内容”，而是一串可以实时消费的数据流。
这里有个需要提前设计的点：消费者回调是跑在异步I/O线程上的，绝对不能在这个线程里做重计算，比如写数据库、加密、序列化大对象，否则会阻塞I/O线程，直接影响后续块的接收速度。正确姿势是把原始字节块拷贝出来后立即返回，然后交给自有线程池去做后续解析。字节块数据在回调返回后是会被HttpAsyncClient复用的，这点特别重要——如果直接把回调里的byte[]引用存下来而不做拷贝，等下一块到达时这块缓冲区的内容可能已经被覆盖了。
3. 实操：基于HttpAsyncResponseConsumer的chunked解析实现
下面给出一份可用的实现。这里以处理一个“服务端实时返回多行JSON数据”的模拟场景为例，每个chunk可能包含一条或多条完整JSON，也可能只包含半个JSON，需要自己做拼接。
先定义消费者。关键点是复写onBodyReceived方法，逐块处理，而不是等到onCompleted才读数据：
import org.apache.http.HttpResponse; import org.apache.http.nio.IOControl; import org.apache.http.nio.client.methods.AsyncByteConsumer; import org.apache.http.nio.protocol.HttpAsyncResponseConsumer; import org.apache.http.protocol.HttpContext; import java.io.IOException; import java.nio.ByteBuffer; import java.nio.charset.StandardCharsets; public class ChunkedJsonConsumer extends AsyncByteConsumer<byte[]> { private final ChunkHandler handler; private final StringBuilder rawBuffer = new StringBuilder(); public ChunkedJsonConsumer(ChunkHandler handler) { this.handler = handler; } @Override protected void onByteReceived(ByteBuffer buf, IOControl ioctrl) throws IOException { // 关键一步：把当前块字节拷贝出来，转成字符串碎片 byte[] bytes = new byte[buf.remaining()]; buf.get(bytes); String fragment = new String(bytes, StandardCharsets.UTF_8); handler.onRawFragment(fragment); } @Override protected byte[] buildResult(HttpContext context) { return rawBuffer.toString().getBytes(StandardCharsets.UTF_8); } @Override public void onResponseReceived(HttpResponse response) throws IOException { super.onResponseReceived(response); // 在这里可以做响应头校验，比如确认Transfer-Encoding是不是chunked handler.onResponseStart(response); } public interface ChunkHandler { void onResponseStart(HttpResponse response); void onRawFragment(String fragment); } }这里有几个细节说明一下：
AsyncByteConsumer是HttpAsyncResponseConsumer的通用实现，它已经封装好了协议层解析，我们只需要覆写块回调即可。onByteReceived收到的ByteBuffer是协议层的缓冲区，它是被复用的。我在里面直接buf.get(bytes)做拷贝，就是为了避免缓冲区复用导致的数据覆盖问题。字符串转换可以放在回调里快速做，但如果量很大，建议只拷贝字节，把解析推迟到业务线程。buildResult在这里返回的其实只是一个“最终兜底”内容，真正的数据消费已经通过handler逐块完成了。
接着是发送异步请求并挂接这个消费者的方法。注意异步客户端的执行方式——直接传消费者对象，而不是像同步那样等HttpResponse返回后读流：
import org.apache.http.HttpHost; import org.apache.http.client.methods.HttpPost; import org.apache.http.entity.StringEntity; import org.apache.http.impl.nio.client.CloseableHttpAsyncClient; import org.apache.http.impl.nio.client.HttpAsyncClients; import org.apache.http.nio.protocol.BasicAsyncResponseConsumer; import org.apache.http.nio.protocol.HttpAsyncRequestExecutor; import org.apache.http.protocol.HttpCoreContext; import java.util.concurrent.Future; public class ChunkedRequestDemo { public static void main(String[] args) throws Exception { CloseableHttpAsyncClient client = HttpAsyncClients.custom() .setMaxConnPerRoute(50) .setMaxConnTotal(100) .build(); client.start(); HttpPost request = new HttpPost("http://your-service.example/stream/json"); request.setEntity(new StringEntity("{\"query\":\"demo\"}", StandardCharsets.UTF_8)); request.setHeader("Content-Type", "application/json"); request.setHeader("Accept", "application/json"); ChunkedJsonConsumer consumer = new ChunkedJsonConsumer(new ChunkedJsonConsumer.ChunkHandler() { @Override public void onResponseStart(HttpResponse response) { System.out.println("响应状态: " + response.getStatusLine().getStatusCode()); } @Override public void onRawFragment(String fragment) { // 这里只把原始碎片交出去，不直接解析业务对象 System.out.println("收到分块: " + fragment); } }); Future<byte[]> future = client.execute(request, consumer, null); byte[] finalResult = future.get(); System.out.println("请求结束, 兜底结果长度: " + finalResult.length); client.close(); } }这段代码可以跑通基本的chunked响应接收。但真实场景里，服务端下发的chunk边界往往和业务数据的边界不一致——可能一个JSON被拆在两个块里，也可能一个块里包含好几个JSON。第4节就讲怎么把这种原始碎片处理成完整业务事件。
4. 核心环节：碎片拼接与逐块解析的完整方案
chunked响应的块边界是TCP/IP层的行为决定的，和业务数据边界没有必然关系。所以如果服务端发的是JSON对象流（每行一个对象），客户端侧必须做一个“按行拼接、按对象切分”的缓冲逻辑。我在做某跨平台系统的时候，服务端对接的中间件返回的是NDJSON格式，每一行是一个完整JSON对象，但传输层实际到达的chunk可能半行、一行、三行不等。
核心做法是在handler层再包一个“行缓冲器”。维护一个ByteBuffer或StringBuilder，每次拿到新fragment时先按\n切分。如果末尾不完整，就保留最后一段塞进缓冲区，等下一块到达时再拼接。实现如下：
public class LineBufferedHandler implements ChunkedJsonConsumer.ChunkHandler { private final StringBuilder lineBuffer = new StringBuilder(); private final JsonLineCallback callback; public LineBufferedHandler(JsonLineCallback callback) { this.callback = callback; } @Override public void onResponseStart(HttpResponse response) { // 响应头校验可放这里 } @Override public void onRawFragment(String fragment) { lineBuffer.append(fragment); int newlineIndex; while ((newlineIndex = lineBuffer.indexOf("\n")) != -1) { String line = lineBuffer.substring(0, newlineIndex).trim(); lineBuffer.delete(0, newlineIndex + 1); if (!line.isEmpty()) { callback.onJsonLine(line); } } } public void finish() { if (lineBuffer.length() > 0) { String last = lineBuffer.toString().trim(); if (!last.isEmpty()) { callback.onJsonLine(last); } lineBuffer.setLength(0); } } public interface JsonLineCallback { void onJsonLine(String json); } }finish()方法很关键——如果服务端最后一行数据末尾没有换行符，这一段会一直留在缓冲区里，直到连接关闭。onCompleted回调触发时表示整个响应体接收完毕，此刻必须调用一次finish()把最后残存的半个业务对象补出来。这个细节很容易漏，漏了就会出现“最后一条数据永远不出现”的现象。
有了这个按行缓冲器，chunked响应的业务处理就通畅了——你把ChunkedJsonConsumer里的handler替换成LineBufferedHandler，然后每个完整JSON行都会回调到业务代码里。解析JSON、入库、打印进度，都可以放在业务侧线程池里做。
再扩展一下：如果服务端返回的不是行分割的文本，而是连续的大块文本，比如实时日志流，那参考思路是“滑动窗口 + 结束标记”或者“按自定义协议切割”，但拼接的本质逻辑和上面是一致的——块边界是随机的，业务边界是确定的，客户端要做的是把随机边界还原成确定边界。
还有一类特殊场景：chunked响应中还嵌着gzip压缩。服务端可能一边chunked一边Content-Encoding: gzip，这时你就不能在fragment层直接按行切分，得先把所有块累积成完整字节流，在流的层面做gzip解压后再按行切分。如果逐块解压，因为压缩数据的边界和压缩帧边界错位，解出来的碎片没法正确拼接。这个我在一次对接第三方流式接口时实测碰到了，一开始收到的fragment全是乱码半截汉字，后来改成“先累积字节再统一解压再按行切分”才恢复正确。
5. 连接管理、超时与回调线程的生命周期陷阱
处理chunked响应时除了数据解析，还有几个和连接生命周期强相关的点很容易踩坑。
第一个是连接被提前释放的问题。当服务端结束chunked流（发来0长度的终止块）时，HttpAsyncClient会认为整个请求已经完成，之后会触发onCompleted并把连接归还连接池。但如果你在onCompleted里才去异步提交业务处理，业务线程可能还在读一个已经被I/O线程标记完成的消费结果。我习惯的做法是在onRawFragment阶段就把数据拷贝出来交给独立线程池，onCompleted只做状态标记和连接清理，不在这个回调里做重活。
第二个是超时参数。长流式响应往往单次传输时间很久，默认的setSocketTimeout如果设置得太短（比如30秒），会出现“明明服务端还在发数据，客户端却因为两次读取间隔超时断开了连接”。这块很多人容易混淆setConnectTimeout、setConnectionRequestTimeout和setSocketTimeout。在分块传输场景里，setSocketTimeout控制的其实是“两个字节块之间允许的最大静默时间”，所以如果服务端的行为是定时批量推送，间隔可能超过默认值，就得调大，不然就会被误判为死连接。
CloseableHttpAsyncClient client = HttpAsyncClients.custom() .setDefaultSocketTimeout(120000) // 两分钟没数据再判超时 .setDefaultRequestConfig(RequestConfig.custom() .setConnectTimeout(10000) .setConnectionRequestTimeout(5000) .build()) .build();第三个坑是强制对端关闭时的取消处理。如果客户端主动取消一个正在进行的chunked请求（比如用户手动停止下载），HttpAsyncClient会调用cancel流程，最终触发onFailed或onCancelled。这时你的LineBufferedHandler里可能还残留着没处理完的半行数据，业务侧如果没有清理逻辑，这些残留数据就丢了。所以cancel回调里也要考虑调用finish()或丢弃缓冲，具体看业务是要尽量处理残余数据还是直接作废。
第四个和第I/O线程相关的坑，是回调里不能做任何阻塞操作。比如在onRawFragment里直接Thread.sleep()模拟处理耗时，马上就会观察到请求吞吐量骤降，因为回调线程被卡住了，后续数据块来不及消费，对端写缓冲会积压。正确做法是回调只拷贝数据、然后放进一个有界队列，由业务线程池消费。队列容量也要设计——如果服务端下发的速度远快于业务消费速度，队列会满，这时候要么丢弃并记录，要么反压阻塞，不能无界堆积。
6. 常见问题与排查技巧实录
把我在实际环境里排查chunked响应遇到的典型问题整理成一个速查表，基本都是可以直接对照定位的：
| 现象 | 根本原因 | 排查与处理方式 |
|---|---|---|
| 响应对象里拿不到body，Future.get()结果为空字节 | 未在onByteReceived阶段消费块，只依赖buildResult兜底返回 | 确认chunk数据在onByteReceived中已被逐块拷贝；buildResult默认不保留中间数据 |
| 收到的fragment全是一段段无意义字节，中文乱码 | chunk边界错位，直接按块内字节转字符串导致跨块字符断裂 | 改为按行缓冲；多个块拼接后再做字符解码 |
| 回调里做耗时处理，请求速度越来越慢 | 在I/O回调线程做了业务逻辑阻塞 | 回调里只做字节拷贝和状态记录，业务处理提交到独立线程池 |
| 响应一直等到超时才结束，明明数据都发完了 | onResponseReceived阶段未正确识别chunked结束标记，连接等待后续数据 | 抓包看终止块是否到达；确认没有将socketTimeout设为过短触发静默误判 |
| 最后一条数据永远不出现 | 流结束前最后一个业务对象未以换行结尾，一直在行缓冲器里等待换行 | 在onCompleted里显式调用缓冲器的finish方法 |
| cancel请求后，再次请求同一连接失败 | cancel未清理连接状态，连接池返回了脏连接 | 在cancel回调里关闭并丢弃对应连接，不要复用到连接池 |
| gzip+chunked同时启用时解析出乱码 | 对压缩数据做了按块解析而非按完整流解析 | 先累积完整字节流再做gzip解压，再进行业务切分 |
还有一个很反直觉的现象值得单独说一下：chunked响应里可能存在“空块”。有些服务端框架为了保活或发送特定信号，会发送size为0但后面还跟着内容的情况，严格来说这是不符合规范的，但事出有因——某些网关会额外追加数据。如果你看到onByteReceived收到长度为0的缓冲区，不要立即认为是流结束，得继续等真正的0-size终止块。直接以0缓冲区分流终止，可能在连接复用后读串数据。
另外排查时建议开启HttpAsyncClient的日志，通过日志可以看到每个块的接收情况。我个人习惯是先做一个小测试服务，只输出固定分块大小的响应，比如把一条长文本分成每个4096字节的chunk发过来，然后看客户端是不是完整收齐。如果分块和行缓冲逻辑没问题，再切换到真实服务端。这个从简到繁的排查顺序，能帮你更快确认问题是出在协议解析还是chunk拼接。
7. 关于缓冲策略与内存控制的补充建议
前面代码里用的是StringBuilder做行拼接，简单直观，但有一个内存上的隐患——StringBuilder内部的字符数组会随着内容增长不断扩容，扩容时会复制旧数据。如果一条业务数据特别长（比如几MB的单行JSON），这个拼接过程会产生大量临时内存和复制开销。
针对大块数据场景，更稳的替代方案是用ByteArrayOutputStream或自增长的ByteBuffer桶。ByteBuffer可以预分配一个合理大小（比如64KB），消费完再按需扩。另一个思路是直接把行缓冲改成“链表分片”——用List<byte[]>累积每一块，等到需要拼成完整一行时再一次性分配大小刚好的数组。这个过程和Netty的CompositeByteBuf思路类似，能极大减少数据复制，但对大多数业务来说有点过度设计。我更推荐的做法是：预估单行数据最大长度，预分配一个足够大的ByteBuffer，不要用StringBuilder做高频append。别小看这一点，处理高频流式数据时GC压力差距非常明显。
内存控制还有一层要注意：回调里new String(bytes, StandardCharsets.UTF_8)这个操作也是创建新对象的，如果分块很多，会产生大量短生命周期字符串，触发频繁Young GC。我自己实测过的项目里，把字符编码延后到“检测到完整业务行”后再统一做，能明显降低内存波动。也就是在onByteReceived阶段只做字节拷贝，按行缓冲器维护的是ByteArrayOutputStream而不是StringBuilder，切分出完整一行后再做new String(lineBytes, charset)。
8. 从同步到异步响应的思维转变
处理chunked响应，最大的阻碍往往不是API不熟，而是思维模型没转过来。传统同步写法里，你从HttpResponse.getEntity().getContent()拿到InputStream，然后按需读取，读到-1就结束。你控制着读的节奏，读多少、什么时候读、要不要停止，都在你的代码里。但异步模式下，数据到达是你无法控制的，你只能通过回调被动接收。这个“控制权反转”是理解一切异步HTTP处理的前提。
同时，分块传输编码的响应天然是事件流式的，每一块数据到达都是一个独立事件。如果你把这个事件模型用好，处理实时数据就会非常顺手——比如统计传输进度、边收边解析边入库、即时推送到监控面板。反之，如果你硬要用“收完整包再处理”的同步思路套异步客户端，就会遇到各种别扭。
落实到代码层面，我的建议是：在项目里抽象一层“HTTP流式响应处理器”，对外暴露onStart、onData、onComplete、onError四个事件，内部根据业务选择不同的分块拼接策略。这样上层业务不用关心协议层到底是chunked还是plain length，也只需要测试这一层的正确性。我目前维护的某跨平台系统里，这一层已经复用了多个接口，从实时数据采集到日志转发都在用，稳定性比较理想。
如果你刚开始接触HttpAsyncClient的chunked处理，可以先从第3节的简化版入手，跑通一个固定文本流，确认你能一块一块收到数据；然后加上行缓冲，连上真实服务端；最后再考虑GZIP解压、连接池调优、内存控制这些进阶点。路径清晰了，踩坑的时候就不会慌。
