FileChannel.transferTo在Linux上仅当源为FileChannel、目标为SocketChannel、文件系统支持mmap（如ext4/xfs）、内核≥2.4且JDK≥11时才真正零拷贝；Windows下始终为普通读写封装，无零拷贝能力。
FileChannel.transferTo 在 Linux 上能真正零拷贝导出数据，但必须满足源是 FileChannel、目标是 SocketChannel、文件系统支持 mmap（如 ext4/xfs）、内核 ≥2.4 且 JDK ≥11；Windows 下永远不是零拷贝，只是普通读写封装。
transferTo 真正零拷贝的硬性前提
调用 transferTo 不等于零拷贝——它只是一层 Java 接口，底层是否走 sendfile(2) 或 copy_file_range(2)，取决于运行时环境：
- 目标通道必须是
SocketChannel（不能是FileChannel、PipeSinkChannel或任何包装过的加密通道，比如SSLEngine包装的） - 源文件必须在支持 mmap 的本地文件系统上（
df -T /path查看 Type，NFS、FAT32、overlayfs、/proc/mounts 中带noac或sync的挂载都会静默 fallback） - Linux 内核 ≥2.4（现代发行版基本都满足），且未禁用
sendfile（极少见，但某些容器安全策略会限制） - JDK 版本 ≥11：JDK 8–10 在部分场景下会绕过零拷贝路径（例如目标 socket 启用了
TCP_CORK）
导出大文件时必须分段调用 transferTo
transferTo 单次最多传 Integer.MAX_VALUE（2GB）字节，超长文件不拆分会触发截断或抛 IOException: Requested array size exceeds VM limit：
- 永远用
Math.min(remaining, Integer.MAX_VALUE)控制单次传输量 - 必须显式检查返回值：
long n = channel.transferTo(pos, count, target)，n可能为 0（非阻塞模式下目标不可写）或小于count（磁盘满、信号中断、跨文件系统 fallback） - 循环中更新
pos += n和remaining -= n，不能依赖channel.size()一次性判断——文件可能被其他进程 truncate 或追加
long pos = 0;
long remaining = fileChannel.size();
while (remaining > 0) {
long toTransfer = Math.min(remaining, Integer.MAX_VALUE);
long n = fileChannel.transferTo(pos, toTransfer, socketChannel);
if (n == 0) {
// 非阻塞模式下需注册 OP_WRITE 并等待就绪
break;
}
pos += n;
remaining -= n;
}
为什么导出到本地文件 ≠ 零拷贝
用 transferTo 把一个文件复制到另一个本地文件，在绝大多数场景下**不是零拷贝**：
- Linux 内核 ≥5.3 + ext4/xfs 才可能走
copy_file_range；老内核或 NFS 挂载点直接 fallback 到用户态缓冲区拷贝 - Windows 完全不支持文件到文件的零拷贝，
transferTo底层就是ReadFile+WriteFile，全程走 JVM 堆外内存 - 即使同 NTFS 分区，Windows 也没有内核 bypass 能力，
transferTo性能通常不如Files.copy() - 如果目标是
FileChannel，OpenJDK 的Files.copy()其实更稳——它内部也先试transferTo，失败后自动切到 8KB 缓冲流，你不用操心 fallback 逻辑
如何验证导出过程是否真零拷贝
别信文档，用系统调用跟踪确认：
- 启动 Java 进程时加
-Djdk.nio.maxCachedBufferSize=0，并在日志中搜索fallback to transferTo with buffer - 更直接：用
strace -e trace=sendfile,copy_file_range,read,write -p观察是否出现sendfile系统调用；若只有read+write，说明已降级 - 注意：
sendfile成功调用 ≠ 数据已发出——它只表示内核接受了传输请求，实际发送仍受 socket 缓冲区和网络状况影响
最容易被忽略的是文件系统类型和挂载参数，同一段代码在 ext4 上零拷贝，在 NFS 上可能慢三倍还报错，而错误日志里往往只字不提 fallback 原因。
