解读

面试官想验证三件事：

1. 对“零拷贝”在 Netty 上下文里的具体实现是否清楚，而不是背概念。
2. 能否把内核 bypass、内存复用、减少 GC 压力与最终 QPS 指标做因果量化。
3. 是否具备“性能测试工程师”视角：知道如何设计对照实验、采集哪些指标、怎么排除噪声，最终证明“30%”不是拍脑袋。

国内面试节奏快，回答必须“先结论、后展开、再给数据”，否则会被打断。

知识点

1. Netty 零拷贝三板斧

   1. DirectBuffer + 池化：避免 HeapBuffer→DirectBuffer 的二次复制，减少 GC 停顿。
   2. FileRegion（transferTo/transferFrom）：发送静态文件时直接 DMA 到网卡，内核 bypass 用户空间。
   3. CompositeByteBuf：把多个业务层 Buffer 组装成逻辑连续帧，无需内存拷贝。

2. 自研客户端额外可做

   1. 对象池化（Recycler）+ 轻量级序列化（Protobuf/FlatBuffer 零拷贝模式），减少 new 对象。
   2. 使用 Epoll 边缘触发 + TCP_NODELAY + SO_SNDBUF 调优，降低 syscall 次数。
   3. 批量 flush：单连接每 200 μs 聚合 64 条消息再触发 writeAndFlush，降低系统调用 70%。

3. 性能测试验证方法

   1. 基准版本：HeapBuffer + 同步 flush，采集 QPS、P99 延迟、CPU 利用率、GC 次数。
   2. 零拷贝版本：仅替换上述三项，其余不变，同样 8C16G 物理机、万兆网卡、同网段压测。
   3. 指标对比：QPS 从 18w→23.4w（+30%），P99 从 4.1 ms→2.3 ms，CPU sys 从 38%→22%，Young GC 间隔从 2 s→10 s。

答案

“我们线上网关单机 QPS 卡在 18 万，CPU sys 高、GC 频繁。我在自研 Netty 客户端做了三步零拷贝改造，最终 QPS 提到 23.4 万，涨幅正好 30%。
第一步，把以前 HeapBuffer 换成池化 DirectBuffer，并开启 -XX:MaxDirectMemorySize，去掉 Heap→Direct 的临时拷贝，Young GC 次数降 5 倍。
第二步，业务报文原来是 JSON+gzip，先序列化成 byte[] 再 write；我改成 Protobuf 直接写入 CompositeByteBuf，避免中间 byte[]，每条消息省 1 次内存复制。
第三步，批量 flush：原来每写一条就 flush，导致大量 write syscall；我引入写队列，64 条或 200 μs 超时再 flush，syscall 降 70%，内核上下文切换减少。
最后用 Gatling 发压，同版本、同机型、同网络，重复 5 次取均值，QPS 从 18w 提升到 23.4w，P99 延迟下降 44%，CPU sys 下降 16 个百分点，证明 30% 收益可重复。”

拓展思考

1. 如果后端是 TLS，零拷贝收益会被 SSL 引擎的拷贝抵消一半，需要把 FileRegion 换成 SslHandler+DirectBuffer 批量封装，再测一次看 ROI。
2. 当消息体大于 64 KB 时，CompositeByteBuf 的索引查找会成为新热点，可退化为单一直接内存块；性能测试时需做体积分段压测，找到拐点。
3. 30% 提升后，瓶颈会从 CPU sys 转到网卡 PPS，下一步可引入 RSS 多队列+绑定 IRQ 到固定核，继续深挖。