FileChannel.transferTo 实现零拷贝需同时满足四前提：源为合法 FileChannel、目标支持内核直传（Linux SocketChannel/FileChannel✅，Windows❌）、系统调用可用（Linux sendfile/copy_file_range✅）、传输范围合法且目标就绪；否则退化为普通拷贝。
Java NIO 中用 FileChannel.transferTo 实现高效零拷贝，关键不在“调用”，而在“满足条件后让内核接管搬运”。它不是 Java 自己复制数据，而是告诉操作系统：“把这段文件直接送到目标通道去”，从而跳过 JVM 堆内存、避免 CPU 搬运、减少上下文切换。
必须同时满足的四个硬性前提
缺一不可，否则自动退化为普通 read/write 拷贝：
-
源通道必须是 FileChannel，且由
RandomAccessFile或FileChannel.open(..., READ)打开（FileInputStream.getChannel()在部分 JDK 版本中不保证兼容） -
目标通道必须是 WritableByteChannel 的子类，且实际支持内核直传：Linux 下
SocketChannel✅、本地FileChannel（需内核 ≥2.6.33 +copy_file_range）✅；Windows 下对任意目标都 ❌（全程 fallback） -
操作系统要支持对应系统调用：Linux 使用
sendfile（网络传输）或copy_file_range（文件到文件）；macOS 支持有限；Windows 完全不支持零拷贝路径 -
传输范围合法且目标就绪：position + count 不越界；目标
SocketChannel必须已连接且处于阻塞模式（非阻塞下可能返回 0，需自行重试）
GB 级大文件安全传输的写法
单次 transferTo 最多传 Integer.MAX_VALUE 字节（约 2GB − 1），但部分 Linux 内核对 copy_file_range 有更严限制（如 1GB）。稳妥做法是分段、校验、推进：
long pos = 0;
long size = srcChannel.size();
while (pos < size) {
long toTransfer = Math.min(size - pos, 1_073_741_823L); // ≤1GB
long transferred = srcChannel.transferTo(pos, toTransfer, dstChannel);
if (transferred == 0) {
// 阻塞模式下极少发生；若出现，可 Thread.yield() 后重试
continue;
}
pos += transferred;
}
常见误用与静默降级风险
这些情况不会报错，但零拷贝失效，性能回归传统路径：
立即学习“Java免费学习笔记（深入）”；
- 在 Windows 上对
FileChannel调用transferTo→ 全程走用户态循环读写 - 目标
FileChannel没有预分配空间（如 ext4 延迟分配），导致写入时频繁触发元数据更新，变慢甚至卡住 - 用
FileInputStream获取 channel 后传给另一个FileChannel→ 某些 JDK 版本不识别写语义，强制 fallback - 向未完成 TCP 握手或设置了
TCP_NODELAY的 socket 写入 → 内核可能拒绝 sendfile，退为普通发送
对比传统流式复制的优势在哪
以 1GB 文件发往网络为例：
-
传统方式（
FileInputStream → byte[] → SocketOutputStream）：磁盘 → 内核缓冲区 → JVM 堆 → Socket 内核缓冲区 → 网卡，共 4 次内存拷贝 + 4 次上下文切换 - transferTo 零拷贝路径（Linux + SocketChannel）：磁盘 → 内核缓冲区 → Socket 内核缓冲区 → 网卡，仅 2 次 DMA 搬运 + 2 次上下文切换，CPU 几乎不碰数据
