最有效方式是多线程+NIO的transferTo/transferFrom，它通过内核零拷贝绕过JVM堆内存，在源目标FileChannel间直接搬运数据；实测SSD/NAS上吞吐量提升3～5倍，但需控制并发线程数（NVMe SSD推荐8～16个）、分段调用防2GB溢出，并避免ByteBuffer堆内存中转。
直接用多线程 + NIO 的 transferTo 或 transferFrom 是提升批量文件复制吞吐量最有效的方式——它绕过 JVM 堆内存，让内核直接在文件通道间搬运数据，避免了传统 IO 的多次拷贝和上下文切换。
选对 NIO 复制方式：优先用 transferTo/transferFrom
普通 ByteBuffer + read/write 仍需用户态参与，而 transferTo（Linux 下对应 sendfile 系统调用）能实现真正的零拷贝：数据从源文件通道经内核页缓存，直接送入目标通道，不经过 JVM 内存。实测在 SSD 或高速 NAS 上，吞吐量可比传统 IO 提升 3～5 倍。
- 源通道必须是
FileChannel，且支持transferTo（普通 socket channel 不适用） - 目标通道也需是
FileChannel，且处于写模式 - 注意：Windows 下
transferTo对非 socket 目标有兼容性限制，建议 fallback 到transferFrom或使用DirectByteBuffer配合read/write
合理控制并发线程数：别盲目堆线程
磁盘 IO 吞吐不随线程数线性增长。过多线程反而引发磁盘寻道竞争、内核调度开销上升，尤其在机械硬盘或共享存储上表现明显。推荐按物理设备维度划分并发度：
- 单块 NVMe SSD：8～16 个并发复制任务较优
- 单块 SATA SSD：4～8 个
- 机械硬盘或网络存储（如 NFS/CIFS）：2～4 个为宜
- 若复制目标分散在多个挂载点（如 /mnt/disk1、/mnt/disk2），可按挂载点分配线程，实现物理并行
配合线程池与异步任务编排
用 ThreadPoolExecutor 管理固定大小的 worker 线程池，每个 task 封装一次 transferTo 调用，并捕获异常、记录进度、支持中断。关键细节：
- 每个线程独占一对
FileChannel（源 + 目标），避免 channel 共享带来的同步开销 - 关闭通道前确保
force(false)或force(true)按需刷盘，防止断电丢数据 - 大文件复制时，分段调用
transferTo(position, count, target)，避免单次传输超 2GB（某些内核版本存在整型溢出风险） - 可搭配
CompletableFuture编排任务依赖，例如先校验源文件完整性，再触发复制
规避常见性能陷阱
很多看似“优化”的操作反而拖慢整体吞吐：
- 不用
ByteBuffer.allocate()做中转缓冲——它走堆内存，GC 压力大；真要缓冲，用ByteBuffer.allocateDirect()，但多数场景下transferTo更优 - 避免在复制线程里做耗时逻辑（如路径拼接、MD5 计算、日志格式化），这些应前置或后置处理
- 不要为每个文件新建
FileChannel实例后再 close——频繁 open/close 触发系统调用，改用 try-with-resources 保证及时释放，或复用 channel（仅适用于只读源文件） - 监控
IOException: Too many open files，及时调整系统 ulimit 和 JVM 的-XX:MaxFDLimit
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
