Scatter/Gather特指channel.read(ByteBuffer[])和channel.write(ByteBuffer[])操作：Scatter按序填满多个Buffer（如header+body），需检查返回值并逐个flip；Gather按序写出多个已flip Buffer的有效内容，支持动态响应拼接；仅适用于FileChannel和非阻塞SocketChannel等，且Buffer类型须一致、顺序即数据布局。
Java NIO 的 Scatter 和 Gather 不是“批量读写”的泛称，而是特指 channel.read(ByteBuffer[]) 和 channel.write(ByteBuffer[]) 这两个具体操作——它们用数组替代单个 Buffer，让底层按序填充或拼接数据，避免手动拷贝和大字节数组拼接。
Scatter：一次 read 填满多个 Buffer（适合固定头+可变体）
Scatter 要求数据严格按 Buffer 数组顺序依次填满：前一个 Buffer 必须写满，才进入下一个。这决定了它天然适配“头部长度固定”的协议结构。
- 分配 header（如 4 字节 int 长度字段）和 body（预留足够容量，比如 8192）两个 Buffer
- 调用
channel.read(new ByteBuffer[]{header, body})，NIO 先填满 header，再把剩余字节写入 body - 必须检查返回值：若只返回 2，说明 header 没填满，两个 Buffer 都未就绪，需等待 OP_READ 就绪后重试
- 读完后要对每个 Buffer 单独
flip()：header.flip() 后读出 length，再用body.limit(length).flip()截取有效负载
Gather：一次 write 写出多个已就绪 Buffer（适合动态响应拼接）
Gather 不要求填满每个 Buffer，只写出 position 到 limit 之间的有效内容，因此非常适合构造含状态码、Header、JSON、换行符等多段组成的响应。
- 准备多个 Buffer：statusBuf（写入 "200 OK\r\n" 并 flip）、headersBuf（写入动态 header 后 flip）、bodyBuf（写入实际数据并 flip）
- 调用
channel.write(new ByteBuffer[]{statusBuf, headersBuf, bodyBuf})，NIO 按顺序写出每段的 remaining() 字节 - 返回值是本次实际写出总字节数；若网络缓冲区满，未写完的 Buffer 会保持当前 position/limit，下次可继续 write，无需重新 flip
- 无需手动合并、无额外 byte[] 创建，减少 GC 压力，尤其适合高频小响应
关键限制必须遵守
忽略这些约束会导致行为异常或性能下降：
立即学习“Java免费学习笔记（深入）”；
- 仅支持
FileChannel、非阻塞SocketChannel和ServerSocketChannel；DatagramChannel不支持 - 所有 Buffer 类型必须一致——建议统一使用
allocateDirect()，避免堆内拷贝 - 数组顺序即数据布局顺序：Scatter 从左到右填，Gather 从左到右发
- 每次 read/write 都可能部分完成，尤其在非阻塞模式下，必须检查返回值，不能假设全部完成
不复杂但容易忽略
Scatter/Gather 的价值不在“炫技”，而在用结构化方式规避内存复制。它不自动识别变长字段，但配合固定头设计 + 显式 length 解析 + Buffer limit 控制，就能安全高效处理真实协议。核心是：用 Buffer 数组表达数据逻辑分段，让 NIO 帮你做物理拼接。
