FileChannel.transferTo 实现零拷贝需满足：源与目标通道均支持内核级直接传输，Linux 2.6.33+ 本地文件间用 copy_file_range、SocketChannel 用 sendfile；Windows 不支持文件到文件零拷贝；超 2GB 需分段（≤1GB），避免 Invalid argument；须用 RandomAccessFile 获取通道，手动维护 position。
FileChannel.transferTo 确实能实现 GB 级文件的高效磁盘传输，但它不是万能的“一键加速键”——是否真正走零拷贝、性能能否拉满，取决于操作系统支持、目标通道类型、文件大小和 JVM 配置。直接用错参数或忽略限制，反而可能退化成普通拷贝。
transferTo 在什么条件下才真正零拷贝？
核心前提是：源 FileChannel 和目标通道（如另一个 FileChannel 或 SocketChannel）都必须支持内核级直接传输。Java 层调用 transferTo 只是发起请求，最终由底层 OS 决定是否启用 sendfile、copy_file_range 或 fallback 到用户态循环读写。
- Linux 2.6.33+ 支持
copy_file_range，对两个本地文件间传输可真正零拷贝；旧内核或非 Linux 系统（如 macOS）会 fallback 到read/write循环 - 向
SocketChannel传输时，Linux 下通常走sendfile，但若目标 socket 启用了 TCP_NODELAY 或连接未建立，也会降级 - 向另一个
FileChannel（比如RandomAccessFile.getChannel()）传输时，JVM 无法保证零拷贝——因为 Java 没有暴露copy_file_range的完整语义，实际行为依赖transferTo的实现细节和 OS 支持 - Windows 上基本不支持文件到文件的零拷贝
transferTo，全程 fallback
GB 文件传输必须绕开的三个坑
大文件场景下，transferTo 的常见误用会导致阻塞、OOM 或静默降级：
-
transferTo的count参数不能无脑传channel.size()：某些 Linux 内核对单次copy_file_range有长度上限（如 2GB），超长会抛IOException: Invalid argument；应分段调用，每段 ≤ 1GB 安全 - 目标
FileChannel必须已打开且处于可写状态，并且 position 正确；若目标文件未预分配空间，transferTo可能因 ext4/xfs 的延迟分配机制导致写入变慢甚至失败 - 源
FileChannel若来自FileInputStream（而非RandomAccessFile），在部分 JDK 版本中可能不支持transferTo到另一文件——因为FileInputStream.getChannel()返回的 channel 不一定支持写操作语义
安全高效的 GB 文件复制代码模板
以下代码针对 Linux + JDK 17+ 优化，兼顾正确性与性能：
try (RandomAccessFile source = new RandomAccessFile("src.dat", "r");
RandomAccessFile target = new RandomAccessFile("dst.dat", "rw")) {
FileChannel srcCh = source.getChannel();
FileChannel dstCh = target.getChannel();
<pre class="brush:php;toolbar:false;">long position = 0;
long count = srcCh.size();
final long MAX_TRANSFER = 1L << 30; // 1GB
while (position < count) {
long transferred = srcCh.transferTo(position, Math.min(MAX_TRANSFER, count - position), dstCh);
if (transferred == 0) break; // EOF or transient stall
position += transferred;
}}
- 用
RandomAccessFile而非FileInputStream获取源 channel，确保transferTo行为可预期 - 显式控制每次 transfer 大小，避免内核拒绝超长请求
- 不依赖
dstCh.position()自动推进：某些文件系统（如 NFS）下该值不可靠，应手动维护position - 省略
dstCh.force(true)—— 强制刷盘会极大拖慢速度；如需数据持久化，应在传输完成后统一调用一次
比 transferTo 更稳的替代方案：MappedByteBuffer + DirectBuffer
当 transferTo 在你的环境无法稳定触发零拷贝（例如跨文件系统、macOS、容器内 kernel 版本低），MappedByteBuffer 是更可控的选择：
-
fc.map(FileChannel.MapMode.READ_ONLY, 0, size)将源文件 mmap 到内存，再用dstCh.write(mappedBuf)写出——虽然多一次用户态 buffer 引用，但避免了transferTo的黑盒 fallback - 注意：
MappedByteBuffer占用的是 native memory，不受堆内存限制，但需防内存泄漏；建议配合System.gc()提示（非强制）或使用Cleaner显式清理 - 对 GB 文件，映射整块可能失败（如 32 位地址空间不足），应分块映射，每块 ≤ 512MB
真正决定 GB 文件传输效率的，从来不是某一行 API 调用，而是你是否清楚当前 OS/JVM 组合下，那一行 transferTo 最终执行的是哪条内核路径。测不准就 fallback，别迷信“零拷贝”三个字。
