Kafka零拷贝是Broker端通过FileChannel.transferTo()调用Linux sendfile()实现的内核态直传，避免CPU拷贝和用户态参与；客户端因需序列化/反序列化，仍走标准Socket I/O，无法使用零拷贝。
Kafka 在 Java 客户端层面本身不直接实现零拷贝，零拷贝（zero-copy）是 Kafka 服务端（Broker）基于 Linux sendfile() 或 transferTo() 系统调用，在 JVM 与内核之间绕过用户态内存拷贝的关键优化，而 Java 客户端（Producer/Consumer）仍走标准 Socket I/O 路径，存在用户态缓冲区参与。真正省去用户态–内核态多次拷贝的环节，发生在 Broker 处理 Fetch 请求时的数据传输阶段。
Broker 端如何用 transferTo() 实现零拷贝
Kafka Broker 在响应 Consumer 的 fetch 请求时，若日志段（LogSegment）数据已在页缓存（page cache）中，会调用 Java NIO 的 FileChannel.transferTo() 方法。该方法在底层映射为 Linux 的 sendfile() 系统调用（或 copy_file_range），允许数据直接从文件描述符（磁盘文件）经由内核空间，发送到 socket 描述符，全程不经过 JVM 堆内存，也不触发用户态的 read()+write() 拷贝。
- 前提：目标文件需是普通文件（如 .log 文件），且 socket 需支持 zero-copy（Linux TCP socket 支持）
- 效果：避免了传统方式中的 4 次上下文切换 + 2 次内存拷贝（read: 磁盘→内核→用户；write: 用户→内核→网卡）
- 注意：
transferTo()在 JDK 中对某些文件系统（如 ext4）和 socket 类型有兼容性要求；若不满足，JVM 会自动退化为常规 copy
Java 客户端为何无法使用零拷贝
Producer 和 Consumer 运行在用户态 JVM 中，所有消息序列化、压缩、网络发送/接收都依赖 java.nio.channels.SocketChannel 或 Netty 封装：
- Producer 发送前必须将 RecordBatch 序列化为 byte[] 或 ByteBuffer，这是用户态操作
- Consumer 接收后需反序列化字节流，也必须落回用户态内存解析
- SocketChannel.write() 仍需把用户态 buffer 复制进内核 socket 发送缓冲区（一次拷贝不可避免）
- 目前 JVM 不提供 API 让应用直接把磁盘文件句柄 + offset 交给内核发往远端 socket（即无原生 sendfile 对接能力）
能做的性能优化（贴近零拷贝思想）
虽然客户端不能零拷贝，但可通过减少拷贝次数和提升缓冲效率来逼近效果：
立即学习“Java免费学习笔记（深入）”；
- 使用
ByteBuffer.allocateDirect()分配堆外内存，避免部分 GC 压力，并让 Netty 可更高效地执行writev()向内核提交多个 buffer - 启用
linger.ms和batch.size，攒批发送，摊薄每次 write 系统调用开销 - Consumer 端设置
fetch.min.bytes和fetch.max.wait.ms，提高单次 fetch 数据量，降低往返频率 - 服务端开启
compression.type（如 lz4/snappy），在页缓存中压缩后 transfer，减少网络传输量（虽不减拷贝次数，但减总带宽压力）
验证是否生效的小技巧
可在 Kafka Broker 机器上用 perf record -e syscalls:sys_enter_sendfile 抓取系统调用，观察 fetch 流量高峰期是否有大量 sendfile 调用；同时对比关闭页缓存（echo 1 > /proc/sys/vm/drop_caches）后延迟上升幅度——若显著升高，说明原先确实在走零拷贝路径。
