Direct buffer OOM：一次 Netty 网关 72 小时内存爬升 4.2GB 的排查与根治

结论先行：堆 OOM 与 Direct buffer OOM 是两套独立的内存池，很多「堆内看着正常、RSS 却悄悄涨到 8G」的事故，根因都在 Netty / Unsafe 那 4GB 堆外池里。下面是一次真实排查记录。

一、现象与背景

去年 8 月，我们一个基于 Netty 4.1.97.Final 的 API 网关（JDK 17.0.8，-Xms6g -Xmx6g -XX:MaxDirectMemorySize=4g，4 实例 × 16C32G），上线稳定跑了 72 小时后开始陆续报警：

• RSS 从 6.8G 缓慢爬到 7.9G，速率约 18MB/h；
• jstat -gcutil 看 Old Gen 稳定在 42%，Young Gen 正常回收，堆内完全干净；
• 第 96 小时，其中一台直接抛 java.lang.OutOfMemoryError: Direct buffer memory，堆栈停在 io.netty.buffer.PooledByteBufAllocator.newDirectBuffer；
• 网关 QPS 当时 1.4w，P99 从 35ms 抖到 800ms；
• 诡异的是：把 -XX:MaxDirectMemorySize 调到 8g 后，只是延后了爆炸时间，4 台机器 6 天后全灭。

二、原理 / 根因分析

先把机制讲清楚，为什么堆看着没事，却会 OOM：

1. Netty 的 ByteBuf 默认走堆外：PooledByteBufAllocator 在启动时会向 PlatformDependent.allocateMemory（底层 Unsafe.allocateMemory / malloc）申请一大块 arena，Arena 内部再用 chunk（默认 16MB）切 page（8KB）和 subpage 做小对象池化。这块内存不占 JVM 堆，受 -XX:MaxDirectMemorySize 限，而不是 -Xmx。
2. 池化带来的「静默泄漏」：非池化 ByteBuf 用完 release 后立刻 freeMemory，泄漏会立刻 OOM，很好发现；但池化 buf 引用计数不归零时，池不会把这块 page 还给 OS，只会记在 arena 的 used 里，表现为 RSS 缓慢上涨、堆内纹丝不动——这就是「72 小时才爆」的原因。
3. 根因定位：网关里有一个 HttpContentCompressor 前置的自定义 ChannelDuplexHandler，在 write 里对 ByteBuf 做了 retain() 用于异步日志落盘，但异常分支（日志线程池满、拒绝策略为 CallerRuns 抛错）没有走 finally release，导致每次拒绝就泄漏一次。生产上日志线程池 queue=1024，高峰期每天被拒约 26 万次，单次泄漏 256B–8KB，72h 累计约 3.8GB，正好对上 RSS 曲线。

三、具体做法（可复现）

1. 打开 Netty 泄漏检测（排查期用 paranoid，日常用 simple/advanced）

# 排查期：CPU 开销约 6–8%，只跑 30 分钟
-Dio.netty.leakDetection.level=paranoid
-Dio.netty.leakDetection.targetRecords=50

日志里直接给出泄漏点：

LEAK: ByteBuf.release() was not called before it reached GC
io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:387)
com.gateway.handler.AccessLogHandler.write(AccessLogHandler.java:92)   # ← 就这一行

2. 用 NMT 佐证堆外，而不是拍脑袋

# 启动参数
-XX:NativeMemoryTracking=summary

# 运行中
jcmd <pid> VM.native_memory baseline
# 1h 后
jcmd <pid> VM.native_memory summary.diff
# 关注 [Direct] 段，正常应 <10MB/h，我们当时是 17.9MB/h

3. 用 pmap 交叉验证

pmap -x <pid> | sort -k3 -nr | head -20
# 找 anon 段，看是否有 16MB 对齐的 arena 块持续增长

4. 修复代码（核心是异常分支也要 release）

@Override
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise p) {
    ByteBuf buf = (ByteBuf) msg;
    ByteBuf copy = buf.retainedSlice();   // retain
    try {
        logExecutor.execute(() -> {
            try { flush(copy); }
            finally { copy.release(); }   // ← 原来这里漏了
        });
    } catch (RejectedExecutionException e) {
        copy.release();                   // ← 原来这里也漏了
    }
    ctx.write(msg, p);
}

5. 参数最终态

-Xms6g -Xmx6g
-XX:MaxDirectMemorySize=4g            # 保持 4g，别治标
-Dio.netty.maxDirectMemory=4294967296
-Dio.netty.leakDetection.level=advanced   # 长期开
-XX:NativeMemoryTracking=summary          # 长期开，开销 <2%

四、踩过的坑 / 反直觉之处

1. 一开始以为是堆 OOM，把 -Xmx 从 6g 调到 10g，没用还更慢——Full GC 次数反而增加，Young 区被压缩变小，STW 从 20ms 涨到 90ms。教训：先分清堆内/堆外，别一上来就调 -Xmx。
2. 调大 MaxDirectMemorySize 是「麻醉剂」：它只是把爆炸时间从 72h 延后到 180h，泄漏速率不变，最终 RSS 还是会顶到容器 32G 上限被 OOMKilled。
3. paranoid 模式不能长期开：CPU 涨 8%、Young GC 频率上升，只适合压测/灰度环境跑 30 分钟。
4. NMT 本身有 ~2% 开销，但 summary 级别可以长期开，比「出事再开」强太多——NMT 是常驻体检，不是事后验尸。
5. -Dio.netty.leakDetection.level=paranoid 的 targetRecords 别设太大，默认 100 就够，设 1000 会显著增加 GC 压力（每个 record 都要跟 GC 关联）。

五、结论与可复用清单

核心结论：Netty 网关类服务，堆外直接内存是默认盲区，堆内指标再干净也不能代表进程内存健康。

可复用清单（可直接抄到运维 checklist）：

• [ ] 启动参数固定带 -XX:NativeMemoryTracking=summary，Prometheus 采集 jcmd VM.native_memory；
• [ ] 监控项增加 RSS - Heap - Metaspace - CodeCache，作为「堆外占用」代理指标，阈值告警；
• [ ] 所有 ByteBuf 操作遵循「谁 retain 谁 release」，异常分支必须 finally；
• [ ] 灰度 / 压测环境跑 30 分钟 paranoid 模式，日志 grep LEAK: 作为上线门禁；
• [ ] 禁止用调大 -XX:MaxDirectMemorySize 掩盖泄漏，只允许在确认「是正常增长」后调整；
• [ ] 容器内存 limit 至少 Xmx + MaxDirectMemorySize + 2G（NMT/栈/线程头），我们最终 32G 容器 = 6G 堆 + 4G 堆外 + 22G 余量，余量偏大，可收敛到 24G。

一句话：堆 OOM 是「当场摔」，Direct buffer OOM 是「慢性中毒」，后者更危险，因为它给你 72 小时的错觉。