Java NIO Gather本质是GatheringByteChannel按序写出多个flip后ByteBuffer的position到limit间数据，不拼接不拷贝；需全用allocateDirect、正确flip、数组索引定序、write后检查返回值并可重试。
Java NIO 的 Gather 技术本质是让一个通道（Channel）一次性从多个已准备好的 ByteBuffer 中按序取出有效数据并发送，不拼接、不拷贝、不重排——它只忠实写出每个 Buffer 从 position 到 limit 之间的字节。
准备多个已写入且 flip() 的 Buffer
每个 Buffer 必须独立完成写入和翻转，确保状态正确：
- 用
put()写入内容，例如statusBuf.put("200".getBytes()) - 调用
flip()切换为读模式：此时position = 0，limit固定为写入长度 - 所有 Buffer 类型需一致：推荐全部使用
ByteBuffer.allocateDirect()，避免 heap buffer 触发 JVM 堆内拷贝
按逻辑顺序组织 Buffer 数组
数组索引决定发送顺序，不能靠后续逻辑调整：
- 比如 HTTP 响应：
[statusBuf, headersBuf, bodyBuf, crlfBuf] - 第一个 Buffer 的内容一定最先发出，最后一个一定最后发出
- 每个 Buffer 只贡献自己的
remaining()字节数（即limit - position），不会补零或截断
调用 write 并处理返回值
write() 不保证一次发完，必须检查实际写出字节数：
立即学习“Java免费学习笔记（深入）”；
- 执行
long written = channel.write(bufs) - 若
written < 总 remaining()，说明网络缓冲区已满，未写完的 Buffer 保持当前position和limit - 下次可直接复用原数组再次调用
write()，无需clear()或重新flip()
仅限支持的通道类型
Gather 不是通用批量工具，有明确运行边界：
- 只支持
GatheringByteChannel子类：即FileChannel和非阻塞SocketChannel - 阻塞式
SocketChannel、DatagramChannel不支持 - 混用 heap 与 direct buffer 会抛异常，必须统一
