transferto()通过内核page cache与dma协同实现零拷贝，数据全程不进用户空间：磁盘→page cache→socket缓冲区→网卡，仅2次拷贝+2次上下文切换，依赖sendfile等系统调用及目标为socketchannel等硬性条件。
FileChannel 的 transferTo() 方法不是“把数据搬进搬出用户空间”，而是让数据始终留在内核空间里流转——它靠的是操作系统内核对缓冲区的统一管理和硬件 DMA 的配合，根本绕开了用户态。
transferTo 的执行路径：数据不进用户内存
调用 transferTo(sourceChannel, position, count, targetChannel) 时，JVM 不分配 byte[]，也不触发 read() 或 write() 系统调用。整个过程由内核调度完成：
- 源文件数据通过 DMA 直接加载到内核 Page Cache（磁盘 → 内核缓冲区）
- 内核判断目标通道类型（如 SocketChannel），若支持 sendfile，则直接将 Page Cache 中的数据地址和长度信息写入 Socket 缓冲区
- 网卡 DMA 控制器根据 Socket 缓冲区中的描述符，从 Page Cache 所在物理内存中直接读取并发出数据
- 全程无 CPU 搬运、无用户缓冲区参与、无用户态/内核态反复切换
为什么能避开用户态？关键在三重支撑
transferTo 能规避用户态，并非 Java 单方面实现，而是依赖底层协同：
- 内核缓冲区共享机制：Page Cache 同时服务于文件 I/O 和网络发送，避免重复缓存
- DMA 散列读取能力：现代网卡支持 Scatter-Gather I/O，可按多个不连续内存块地址直接组装报文
- 系统调用语义封装：Java 的 transferTo 最终映射为 Linux 的 sendfile() 或 splice()，这些系统调用定义本身就不涉及用户空间数据指针
与传统 read+write 的对比差异
同样完成“磁盘文件发到网络”，两种方式的数据路径截然不同：
- 传统方式：磁盘 → Page Cache → 用户 buffer（CPU copy）→ Socket buffer（CPU copy）→ 网卡（DMA）→ 共 4 次拷贝 + 4 次上下文切换
- transferTo 方式：磁盘 → Page Cache → Socket buffer（内核内传递或仅传描述符）→ 网卡（DMA）→ 共 2 次拷贝（或 1 次，取决于硬件）+ 2 次上下文切换
- 真正省下的不是“一次复制”，而是 CPU 参与的搬运动作和用户态栈帧切换开销
实际使用中的边界条件
transferTo 并非万能，它的零拷贝效果受运行环境制约：
- 目标通道必须是 SocketChannel 或支持 sendfile 的 FileChannel（如 Linux 下的本地文件间传输）
- 源通道需基于文件（FileChannel），且文件需驻留于 Page Cache（热数据效果最佳）
- 若目标是普通 OutputStream 或加密通道（如 SSLEngine），JVM 会自动降级为常规 copy
- 某些 JVM 实现或旧版内核不支持 sendfile64，大文件传输可能被拆分或回退
