transferto在linux上退化为普通拷贝，因其仅在源为filechannel、目标为socketchannel或linux 4.5+的filechannel、文件系统支持sendfile（如ext4/xfs）、长度≤2gb且offset对齐等条件下才触发零拷贝；否则fallback至read/write。
transferTo 方法在 Linux 上为什么有时退化成普通拷贝
Java 的 FileChannel.transferTo 声称支持零拷贝，但实际运行中常发现 strace 显示大量 read + write 系统调用——说明压根没走 sendfile 或 copy_file_range。根本原因是：它只在特定条件下触发底层零拷贝系统调用。
关键限制有三个：
-
transferTo要求源通道是FileChannel，目标通道必须是SocketChannel或另一个FileChannel（仅限 Linux 4.5+ 的copy_file_range） - 源文件必须位于支持
sendfile的文件系统上（ext4、xfs 可以，tmpfs、overlayfs、NFS 大概率不行） - 传输长度不能超过
Integer.MAX_VALUE（2GB），且起始位置需对齐（某些内核版本要求 offset 是 4KB 对齐）
例如：从 /proc/sys/net/core/somaxconn 这类 procfs 文件调用 transferTo 到 socket，会直接 fallback 到用户态拷贝——因为 procfs 不支持 sendfile。
Windows 下 transferTo 根本不零拷贝
Windows 没有等价于 sendfile 的原生系统调用，JDK 在 Windows 上的 transferTo 实现就是纯模拟：开个固定大小的堆外缓冲区（默认 8KB），循环 read + write。它甚至不会尝试 TransmitFile API——除非你用的是 SocketChannel 且显式调用 SocketChannel.write(ByteBuffer) 配合 DirectByteBuffer。
立即学习“Java免费学习笔记（深入）”；
这意味着：跨平台代码里若依赖 transferTo 性能优势，在 Windows 上会突然变慢，且毫无提示。可验证方式是用 VisualVM 看堆外内存分配频率，或用 Process Explorer 观察线程 I/O wait 时间。
如何判断当前 transferTo 是否真走了零拷贝
不能靠文档或日志，得看系统行为。最直接的方法是用 strace -e trace=sendfile,copy_file_range,read,write（Linux）或 Process Monitor（Windows）抓系统调用。
真正零拷贝的痕迹是：
- 出现单次
sendfile(3, 4, ...)或copy_file_range(3, ..., 4, ..., len) - 没有成对的
read(3, ...)和write(4, ...) - 返回值等于请求长度（说明未被截断）
如果看到反复的 read/write，哪怕只有一对，也代表 fallback 已发生。注意：JDK 会自动分片（如传 100MB，可能拆成多个 2GB 以下的 transferTo 调用），每片都需单独验证。
替代方案：MappedByteBuffer + SocketChannel.write()
当 transferTo 不可靠时，更可控的方式是手动 mmap + write：
- 用
FileChannel.map(READ_ONLY, offset, size)得到MappedByteBuffer - 确保 socket 是非阻塞的，然后循环调用
socketChannel.write(mappedBuf)
这本质上是用户态地址空间与内核页缓存共享，绕过 copy，且 Linux/Windows 均有效。但要注意：MappedByteBuffer 不受 GC 控制，需显式调用 Cleaner（JDK 14+ 推荐用 FileChannel.unmap()）；另外 mmap 大文件可能触发 OOM（尤其是 32 位 JVM）。
零拷贝不是银弹——它省的是 CPU 和内存带宽，但换来了对文件系统、内核版本、JVM 实现的强依赖。真正稳定的做法，是把 transferTo 当作性能优化项而非功能保障，始终备好基于 ByteBuffer 的 fallback 路径。
