scatter/gather 是结构化数据处理方式而非直接性能优化手段，通过分离 header/body 关注点提升可维护性；需预分配固定缓冲区、精确控制 flip/limit、配合协议状态机处理半包，并复用缓冲区池以避免 gc 和创建开销。
Java NIO 的 Scatter/Gather 机制本身不是“性能优化手段”，而是一种结构化数据处理方式——它通过分离逻辑关注点来简化协议解析，间接提升可维护性与稳定性。真正影响性能的是缓冲区设计、数据边界控制和与业务协议的匹配度。
按协议结构预分配固定大小缓冲区
Scatter 读要求各 Buffer 在填满前不跳转，因此 header/body 等字段必须有确定长度。例如 HTTP/1.1 请求行 + 固定头字段可设为 512 字节，body 则预留 8KB：
- header = ByteBuffer.allocate(512)
- body = ByteBuffer.allocate(8192)
- channel.read(new ByteBuffer[]{header, body})
若实际 header 不足 512 字节，剩余空间会空置；但避免了动态扩容带来的数组拷贝或状态判断开销。
用 flip + limit 精确控制有效数据范围
聚集写时，只有 position 到 limit 之间的内容会被写出。写入前务必调用 flip()，否则可能写入未初始化内存或越界数据：
- header.put("HTTP/1.1 200 OK\r\n".getBytes()); header.flip();
- body.put(responseData); body.flip();
- channel.write(new ByteBuffer[]{header, body});
尤其注意：多个 buffer 写入顺序即数组索引顺序，header 必须在 body 前，否则网络层收到乱序包。
结合协议状态机避免半包误判
Scatter/Gather 不解决黏包或半包问题。例如 TCP 流中一个完整消息被拆成两段到达，第一次 read 可能只填满 header 缓冲区，body 为空；第二次才补全。此时需配合外部状态管理：
- 检查 header.limit() 是否等于预期长度（如 512），否则暂存并等待下次 read
- 从 header 中解析出 body 长度（如 Content-Length），再校验 body.position() 是否达标
- 未满足条件时不执行 gather write，防止发送不完整响应
这要求将 Scatter/Gather 置于协议解析流程中，而非裸用。
慎用 DirectBuffer 但避免频繁分配
高吞吐场景下，反复 allocate()/clear() HeapByteBuffer 会触发 GC；建议复用缓冲区池：
- 使用 ThreadLocal
或轻量对象池管理 header/body 实例 - 优先用 allocateDirect 分配，减少 JVM 堆压力，但注意 DirectBuffer 创建成本略高
- 不要对每个请求 new 一套 buffer，而是从池中取、用完 reset（clear/flip）归还
分散/聚集的价值不在“更快”，而在让 header 解析、body 处理、校验逻辑彼此解耦，降低出错概率。真正快的是后续基于清晰 buffer 边界的零拷贝传输（如 transferTo）或直接内存操作。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
