FileChannel.transferTo()实现零拷贝需同时满足：目标为SocketChannel（非阻塞）、源为本地文件FileChannel（如RandomAccessFile获取）、Linux内核≥2.4且JDK≥11、文件系统支持mmap（如ext4/xfs）；否则静默降级为用户态拷贝。
FileChannel.transferTo() 能实现文件到 Socket 的零拷贝，但不是调用就自动生效——它只在满足一系列硬性条件时，才真正触发内核的 sendfile 系统调用。否则会静默降级为用户态缓冲区中转，性能反而更差。
必须满足的三个核心条件
缺一不可，任意一项不满足都会 fallback：
- 目标通道必须是 SocketChannel：不能是 FileChannel、PipeChannel、加密包装后的 Channel（如 SSLEngine 包装的），也不能是阻塞模式下的 SocketChannel（需设为非阻塞）
-
源必须是本地文件的 FileChannel：通过
RandomAccessFile.getChannel()或Files.newByteChannel(path, READ)获取；不能来自FileInputStream.getChannel()（部分 JDK 版本不支持写语义），也不能是管道、stdin、NFS、FUSE 或 /proc 下的伪文件 -
文件系统与运行环境支持：Linux 内核 ≥2.4（现代发行版基本满足）、JDK ≥11、文件系统需支持 mmap（如 ext4/xfs；NFS、overlayfs、带
noac或sync挂载选项的卷会静默失败）
正确调用的关键细节
光满足条件还不够，代码写法直接影响是否走零拷贝路径：
-
必须分段传输超长文件：单次
count最大为Integer.MAX_VALUE（2GB），超过会抛IOException: Requested array size exceeds VM limit；建议每段 ≤1GB 更稳妥 -
必须显式处理返回值：
long n = channel.transferTo(pos, count, socketChannel)返回实际传输字节数，可能为 0（非阻塞下目标不可写）或小于count（磁盘满、中断、跨文件系统 fallback）；需循环更新pos += n和剩余量 -
不能依赖
channel.size()一次性判断：文件可能被其他进程截断或追加，应边传边查剩余量
典型错误写法（会绕过零拷贝）
这些操作看似合理，实则让 transferTo 失效：
- 先用
fileChannel.map()或fileChannel.lock()—— mmap 与 sendfile 互斥，内核会拒绝 - 在 transferTo 前/后对同一文件做
read()或write()操作，干扰内核页缓存状态 - SocketChannel 启用了
TCP_CORK或未建立连接（如 connect() 未完成），JDK 8–10 会强制回退 - 在容器中运行且
/proc/sys/net/core/somaxconn被限制，或 socket 开启了某些非常规 TCP 选项
验证是否真零拷贝
别靠猜测，用系统工具确认：
- Linux 下用
strace -e trace=sendfile,read,write -p <pid></pid>观察是否出现sendfile系统调用；若大量read+write，说明已降级 - 检查挂载类型：
df -T /your/file/path，确保 Type 是ext4或xfs - 确认内核版本：
uname -r≥ 2.4，且未禁用sendfile（极少见，但某些容器安全策略会限制）
