核心是利用Buffer和FileChannel的块状读写实现零拷贝：用DirectBuffer避免JVM堆内存拷贝，合理设置64KB–1MB缓冲区，优先采用transferTo/transferFrom进行channel间零拷贝，辅以MappedByteBuffer处理只读大文件。
核心在于用好 Buffer 和 FileChannel 的块状读写能力，避开传统流式逐字节拷贝的低效路径。关键不是“加缓冲”，而是让操作系统直接参与数据搬运，减少 JVM 堆内存拷贝和上下文切换。
用 DirectBuffer 减少内存拷贝
普通堆内 ByteBuffer 会经历“内核缓冲区 → JVM 堆 → 应用逻辑 → JVM 堆 → 内核缓冲区”两段拷贝。换成直接内存（DirectBuffer），数据可直通内核，省掉一次复制：
- 创建方式：用
ByteBuffer.allocateDirect(8192)替代allocate() - 适合场景：单次传输量大（如 >64KB）、频繁读写、对延迟敏感
- 注意点：DirectBuffer 不受 GC 管理，需手动调用
cleaner或依赖 finalize（不推荐），更稳妥的是复用 Buffer 池
合理设置 Buffer 容量，平衡吞吐与内存占用
Buffer 太小，系统调用频繁；太大，浪费内存且可能触发 GC 压力。实测经验表明：
- 上传下载常规文件：64KB–1MB 是较优区间（如
8192 * 8） - SSD 环境下，128KB–512KB 往往达到 I/O 吞吐峰值
- 不要盲目设到 10MB+，除非明确知道磁盘/网络带宽瓶颈不在内存分配侧
优先使用 channel-to-channel 零拷贝传输
当源和目标都是 FileChannel（比如文件到文件、文件到 SocketChannel），跳过应用层 Buffer，用 transferTo() 或 transferFrom() 让内核直接搬数据：
立即学习“Java免费学习笔记（深入）”；
-
destChannel.transferFrom(srcChannel, position, count)—— 适用于已知长度的文件复制 - 对超大文件，分段调用（如每 2GB 一段），避免 long 超限或系统限制
- 该方式不经过 JVM 内存，真正实现“零拷贝”，性能提升显著（实测比 Buffer 循环快 3–5 倍）
配合 MappedByteBuffer 处理只读大文件场景
如果只是读取分析（如日志解析、内容校验），且文件大小可控（
-
channel.map(MapMode.READ_ONLY, 0, fileSize)将文件片段映射为虚拟内存 - 后续访问像操作数组一样，由 OS 按需加载页，无显式 read() 调用
- 注意：映射过大文件易引发 OOM 或 swap，生产环境慎用于 >1.5GB 文件
