transferTo()调用失败或退化为普通拷贝，主要因目标Channel不支持内核转发、源文件超2GB、文件系统不兼容（如NFS/FUSE）、Windows下仅SocketChannel稳定；需用strace验证是否触发sendfile，传错Channel类型会导致静默降级。
transferTo() 调用失败或退化为普通拷贝，怎么回事？
Java 的 transferTo() 方法在底层依赖操作系统原生的 sendfile（Linux/Unix）或 TransmitFile（Windows），但并非总能触发零拷贝。常见失效场景包括：
- 目标
Channel不支持直接内核转发（如写入普通FileOutputStream的FileChannel，在 Linux 上可能 fallback 到用户态循环读写） - 源文件大小超过
Integer.MAX_VALUE（2GB），而某些 JDK 版本对超大 offset 处理不完善，导致分段调用时部分走常规路径 - 源
FileChannel未处于只读模式，或底层文件系统不支持sendfile（如某些 NFS 挂载、FUSE 文件系统） - Windows 上仅当目标是
SocketChannel且启用了SO_SNDBUF优化时才较稳定；写入本地文件基本不走TransmitFile
验证是否真零拷贝：用 strace -e trace=sendfile,read,write（Linux）观察系统调用，若出现大量 read+write，说明已退化。
DirectBuffer 是必须的吗？HeapBuffer 会拖慢 transferTo 吗？
transferTo() 本身不接受 Buffer 参数，它绕过了用户缓冲区，所以 HeapBuffer 或 DirectBuffer 对该方法无直接影响——它不碰你的 Buffer。
但容易混淆的点在于：如果你在调用 transferTo() 前，先用 FileChannel.read(HeapBuffer) 读了一段数据，那这一步就会触发 NIO 的隐式拷贝：JVM 会把 HeapBuffer 数据先复制进临时 DirectBuffer，再交给内核，白白多一次 sun.misc.Unsafe.copyMemory()。
- 真正需要
DirectBuffer的是显式read()/write()场景，尤其是高频小包或需长期持有缓冲区时 - 纯
transferTo()场景下，连Buffer都不用分配，省心又高效 - 若混合使用（比如先
map()再get()修改），则必须用DirectBuffer或MappedByteBuffer，否则修改不会落盘
map() + MappedByteBuffer 比 transferTo() 更快？
不一定。两者适用场景不同：map() 是内存映射（mmap），transferTo() 是内核零拷贝（sendfile）。关键区别在于数据流向和控制粒度：
-
transferTo()：适合“管道式”整块搬运，比如文件 → socket、文件 → 文件（同设备），全程无 Java 层参与，延迟最低 -
map()：适合随机读写、频繁小范围修改（如数据库页缓存），但写操作立即生效，没 flush 控制，force()才保证落盘，且映射过大易触发 OOM（受限于进程虚拟地址空间） - 实测中，5GB 连续复制，
transferTo()通常比map()+put()快 10%~20%，因后者仍需 JVM 拷贝字节到 mapped 区域
注意：MappedByteBuffer 的 cleaner 在 GC 时才释放内存映射，若频繁创建大映射，可能卡住 GC 或耗尽虚拟内存，需配合 System.gc()（不推荐）或显式 Cleaner 调用（JDK 9+）。
为什么大文件传输还是卡在磁盘 I/O，零拷贝没用？
零拷贝解决的是“CPU 和内存带宽瓶颈”，不是“磁盘吞吐瓶颈”。如果源文件在机械硬盘上，而目标也是同一块磁盘，那无论用什么技术，物理寻道和旋转延迟都绕不开。
- 确认瓶颈：用
iostat -x 1看%util和await，若接近 100% 且await> 10ms，说明是磁盘本身慢 - 零拷贝收益明显场景：SSD + 千兆以上网络传输、跨设备文件复制（如 SSD → NVMe）、高并发小文件聚合发送
- 若磁盘是瓶颈，优先考虑异步预读（
FileChannel.map()配合load()）、RAID 或换存储介质，而非纠结零拷贝参数
最常被忽略的一点：transferTo() 的第三个参数是目标 Channel，它必须支持接收内核数据（如 SocketChannel、同文件系统下的 FileChannel），传错类型会导致静默降级——这点没有编译错误，也难 debug。
