java channel高效传输核心在于绕开jvm堆内存中转，依赖零拷贝（transferto/transferfrom）、内存映射（mappedbytebuffer）或堆外缓冲区（directbuffer），并严格管理buffer的position/limit状态。
Java 中 Channel 通道的数据传输，核心是围绕 缓冲区（Buffer） 进行的双向读写，不是直接操作字节流，而是通过“通道 ↔ 缓冲区”协作完成。真正高效的关键不在于“用了 Channel”，而在于是否绕开了 JVM 堆内存中转——也就是能否用上零拷贝、内存映射或堆外缓冲区。
用 transferTo/transferFrom 实现零拷贝传输
这是大文件复制或服务端静态资源分发最高效的方式：数据全程在内核空间搬运，不进用户内存。
- 必须有一个 FileChannel 参与：transferTo() 的源是 FileChannel，目标可以是 SocketChannel（如 HTTP 下载）或同文件系统的另一个 FileChannel；transferFrom() 则相反
- Linux 下底层调用 sendfile()，性能极佳；macOS 不支持，会自动降级为普通 read/write，速度明显下降
- 调用前务必检查 sourceChannel.size()，避免 position 或 count 超限导致静默降级
- 示例：复制文件时无需分配 Buffer，一行 transferTo 就能完成
用 MappedByteBuffer 做内存映射随机访问
适合超大文件需频繁跳转读写特定位置的场景，比如日志检索、数据库索引操作。
- 调用 channel.map(READ_ONLY, offset, size) 把文件某段直接映射为 JVM 可访问的直接内存
- 后续可像操作数组一样 get()/put()，OS 按需分页加载，延迟低、无显式 read()
- 写入后若需强持久化，必须调用 force() 确保落盘
- 注意风险：外部程序修改原文件可能触发 IOException；长期映射超大文件易引发 OOM
手动 read/write + DirectBuffer 控制传输逻辑
当需要加压缩、加密、校验或监控进度时，零拷贝不可用，但依然可以保持高性能。
- 用 ByteBuffer.allocateDirect(65536) 分配堆外缓冲区，避免每次 write() 隐式复制到临时 direct 内存
- 循环中 read() 后必须 flip()（设 limit = position，position = 0），否则 get() 或 write() 读不到/写不出数据
- 一次读写完成后用 clear() 重置状态；compact() 仅在需保留未读完内容时才用
- 小数据或单次 header 写入可用 heap buffer；高频复用、长连接缓冲池必须用 direct buffer
别忽略 Buffer 状态管理这个高频坑点
Buffer 不是智能容器，position 和 limit 错位会导致静默失败，是丢数、卡死、数据错乱的常见根源。
- 典型错误：channel.read(buf) 返回 1024 字节后，忘记 flip() 就直接传给解析逻辑 → 实际读取长度为 0
- 调试技巧：打印 buf.toString() 查看当前 position/limit/cap；heap buffer 可用 Arrays.toString(buf.array()) 看真实内容
- 每次 read() 后记得 flip()，每次 write() 后记得 clear()，这是硬性操作节奏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
