transferTo 仅在特定条件下触发零拷贝：Linux 下目标须为 SocketChannel 或同文件系统的 FileChannel，Windows 仅支持 SocketChannel；跨文件系统或目标为内存通道时退化为普通拷贝。

FileChannel.transferTo 不能跨文件系统实现零拷贝，且在 Linux 上实际依赖 sendfile 系统调用——这意味着目标 WritableByteChannel 必须是 socket channel 或同属一个文件系统的另一个 file channel。

transferTo 在什么条件下真正触发零拷贝

零拷贝生效的前提不是调用 transferTo 就自动成立，而是取决于底层 OS 支持 + 目标 channel 类型 + 文件系统一致性：

• Linux 下仅当目标为 SocketChannel 或同一 ext4/xfs 文件系统内的 FileChannel（且源 channel 是 FileChannel）时，JVM 才可能调用 sendfile(2) 或 copy_file_range(2)
• Windows 使用 TransmitFile，仅支持写入 socket；跨卷（drive）的 file-to-file 不走零拷贝路径
• 如果目标是 ByteArrayChannel 或内存映射的 ByteBuffer，JVM 会退化为普通用户态拷贝，transferTo 只是语法糖
• OpenJDK 17+ 对 copy_file_range 的封装更完善，但需内核 ≥ 4.5 且挂载选项未禁用 copy_file_range

常见误用：把 transferTo 当作通用高效 copy 工具

很多代码直接用 transferTo 替代 Files.copy()，却忽略了它对参数组合的敏感性：

• 传入非 socket / 非同文件系统的 FileChannel → 返回值可能小于请求长度，需循环调用；此时已无零拷贝，反而因多次 syscall 开销更大
• 忽略 position 和 count 的边界：若 position + count 超出源文件大小，transferTo 静默截断，不抛异常
• 未关闭源 channel：某些 Linux 内核版本下，transferTo 期间若源文件被 truncate，行为未定义；务必确保源 FileChannel 在传输前已通过 FileInputStream.getChannel() 获取并保持打开
• 示例错误写法：outChannel.transferTo(0, fileSize, inChannel) —— 这里 inChannel 是源，outChannel 是目标，参数顺序反了，编译不报错但逻辑全错

正确用法与 fallback 处理

真要用 transferTo 发挥价值，得按场景选策略：

• 服务端响应静态文件：目标一定是 SocketChannel，源是 FileChannel，用 channel.transferTo(position, count, socketChannel)，并检查返回值是否等于 count；不等则需重试或切到 ByteBuffer 分段读写
• 同磁盘大文件备份：确认两个文件在同一 mount point（df -P file1 file2 输出相同 Filesystem），再用 transferTo；否则老实用 Files.copy() + StandardCopyOption.REPLACE_EXISTING
• 必须兼容跨文件系统？别硬扛——transferTo 返回值 0 时，说明底层拒绝零拷贝，立刻 fallback 到 Channels.newInputStream(inChannel).transferTo(outStream)（基于 read/write 循环）
• 注意 transferTo 不保证原子性：若传输中连接断开或磁盘满，目标文件可能只写入部分字节，应用层需自行校验或清理

真正难的不是写对那行 transferTo 调用，而是判断此刻它到底有没有走内核态直通路径。查 /proc/sys/fs/epoll/max_user_watches 没用，看 strace -e trace=sendfile,copy_file_range 才算数。