FileChannel的transferTo方法可在Linux等支持sendfile的系统上实现零拷贝，需满足源为FileChannel、目标为SocketChannel、JDK 11+等条件；Windows下退化为普通拷贝。
FileChannel的transferTo方法可以在支持操作系统的底层实现“零拷贝”（Zero-Copy），即数据不经过JVM堆内存，直接由内核在文件通道和目标通道（如SocketChannel）之间传输。但要注意：它是否真正零拷贝，取决于操作系统、JDK版本以及目标通道类型。
transferTo的基本用法与前提条件
该方法签名如下：
long transferTo(long position, long count, WritableByteChannel target)它从当前FileChannel的指定位置开始，最多传输count字节到target通道中。要触发零拷贝，需满足以下关键条件：
- 源通道必须是
FileChannel（不能是内存或网络通道） - 目标通道推荐为
SocketChannel（Linux下可利用sendfile(2)系统调用） - 运行环境为Linux或支持
sendfile的系统（Windows不支持真正的零拷贝，会退化为普通拷贝） - JDK版本建议11+（旧版本在某些场景下可能绕过零拷贝路径）
典型零拷贝示例：文件→网络发送
下面是一个将大文件通过NIO直接发送给客户端的常见写法：
try (FileChannel fileChannel = FileChannel.open(Paths.get("data.bin"), StandardOpenOption.READ);SocketChannel socketChannel = SocketChannel.open(new InetSocketAddress("127.0.0.1", 8080))) {
socketChannel.configureBlocking(false);
// 确保连接已建立（略去握手逻辑）
long transferred = 0;
long size = fileChannel.size();
while (transferred long n = fileChannel.transferTo(transferred, size - transferred, socketChannel);
if (n == 0) break; // 暂不可写，需配合Selector轮询
transferred += n;
}
}
注意：transferTo在非阻塞模式下可能返回0，表示目标通道暂不可写，此时应注册OP_WRITE事件并等待就绪后再继续。
为什么有时不是零拷贝？常见陷阱
即使代码调用transferTo，实际仍可能走常规拷贝路径，原因包括：
- 目标通道不是
SocketChannel（例如写入FileChannel或PipeSinkChannel） - 传输范围超出文件大小或position越界
- Linux内核限制：若目标socket启用了TCP_CORK或存在TSO/GSO等网卡特性干扰，部分版本JDK会自动降级
- 使用了SSL/TLS加密（
SSLEngine包装的通道无法零拷贝，必须先解密/加密）
验证是否真正零拷贝
可通过以下方式辅助判断：
- 用
strace -e trace=sendfile,write,read运行Java进程，观察是否调用sendfile系统调用 - 监控系统调用次数和上下文切换数（
pidstat -w），零拷贝时线程上下文切换明显减少 - 对比相同数据量下CPU使用率和吞吐差异：零拷贝通常CPU更低、延迟更稳
