Scatter（分散读）和Gather（聚集写）特指channel.read(ByteBuffer[])与channel.write(ByteBuffer[])，通过ByteBuffer数组实现零拷贝结构化读写：Scatter按序填满buffer（如4字节头+体），Gather按序写出已flip的buffer片段，均需检查返回值、仅支持特定channel、要求buffer类型一致且不可中途修改。

Java NIO 的 Scatter（分散读）和 Gather（聚集写）不是“批量读写”的泛称，而是特指 channel.read(ByteBuffer[]) 和 channel.write(ByteBuffer[]) 这两个接口行为。它们通过数组协调多个 Buffer，由底层自动按序填充或拼接数据，避免手动拷贝和临时字节数组分配。

Scatter：固定头+可变体的解析方式

Scatter 适用于接收端解析结构化报文，比如 4 字节长度字段 + 后续不定长内容。它要求数据严格按 Buffer 数组顺序填满——前一个 Buffer 必须写满，才向后一个写。

• 分配两个 direct ByteBuffer：header = ByteBuffer.allocateDirect(4)、body = ByteBuffer.allocateDirect(8192)
• 调用 channel.read(new ByteBuffer[]{header, body})，NIO 先填满 header 的 4 字节，再把剩余字节写入 body
• 必须检查返回值：若只收到 2 字节，read() 返回 2，两个 Buffer 都未 flip，不能直接读取；需等待就绪后重试
• 仅当返回值 ≥ 4 时，才对 header 调用 flip() 并读出长度；再根据该长度判断 body 是否收全（body.position() == length）

Gather：多段响应的零拷贝拼装

Gather 适合发送端构造逻辑上一体、物理上分离的响应消息，例如状态行 + JSON 内容 + 换行符。它不要求每个 Buffer 填满，只写出 position 到 limit 之间的有效数据。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 预先准备多个已写入并 flip 的 Buffer：statusBuf.put("200 OK\r\n".getBytes()).flip()、jsonBuf.put("{\"code\":0}".getBytes()).flip()、crlfBuf.put((byte)'\r').put((byte)'\n').flip()
• 调用 channel.write(new ByteBuffer[]{statusBuf, jsonBuf, crlfBuf})，NIO 按顺序写出各 Buffer 的 remaining() 字节
• 返回值是实际写出总字节数；若网络缓冲区满，未写完的 Buffer 保持当前 position/limit，下次可继续 write，无需 clear 或重新 flip
• 天然减少内存复制和 GC 压力，特别适合高频小响应场景

关键限制与避坑要点

Scatter/Gather 不是通用语法糖，有明确约束，忽略会导致数据错位或行为未定义。

立即学习“Java免费学习笔记（深入）”；

• 仅支持 FileChannel、非阻塞 SocketChannel 和 ServerSocketChannel；DatagramChannel 不支持
• 所有 Buffer 必须类型一致：建议全部使用 allocateDirect()，避免 heap 与 direct 混用引发隐式拷贝
• 数组顺序即数据布局顺序：Scatter 从左到右填，Gather 从左到右发，不可随意调换索引
• 单次操作不保证完成，尤其在非阻塞模式下，必须检查返回值，并配合 Selector 处理 OP_READ/OP_WRITE
• 禁止在 scatter/gather 过程中修改 Buffer 容量或重新分配 backing array

不复杂但容易忽略：Scatter 依赖协议头长度固定，Gather 依赖各 Buffer 提前写好并 flip，两者都绕不开对 position/limit 状态和返回值的手动管理。