Netty 堆外内存缓慢爬升 4 小时撞穿 -XX:MaxDirectMemorySize：泄漏检测、jemalloc 与 pmap 的一次组合定位

结论先行

Netty 的堆外内存问题，90% 不是「分配太多」，而是「没释放」——也就是 ByteBuf.refCnt() 泄漏。而排查这件事，jcmd / heap dump / 常规 JVM 工具链都帮不上忙，必须用「泄漏检测 Level + jemalloc heap profiling + pmap 大段 anon」三件套。下面是一次真实的 4 小时爬升事故，带参数、带命令、带踩坑。

一、现象：堆很健康，RSS 却 4 小时爬了 2.6G

一个内部 RPC 网关（JDK 17.0.10 + Netty 4.1.97.Final + gRPC 1.58，4C8G Pod，QPS 峰值约 2400）上线后第 3 天开始出问题：

• container_memory_working_set_bytes 从 3.1G 缓慢爬到 5.7G，斜率约 650MB/h，无周期性；
• Java 堆：-Xmx4g，稳态占用 2.4G，Young GC 平均 4ms，无 Full GC，heap dump 里 Top 10 对象全是常规业务对象，没有任何「可疑大户」；
• jcmd <pid> VM.direct_buffers：allocated=2.81GB / used=2.79GB / totalCapacity=3.05GB —— used 和 allocated 一起涨，这是关键信号：不是「分配了没在用」，而是「分配的对象还活着但没人释放」；
• 4 小时后进程抛出 java.lang.OutOfMemoryError: Direct buffer memory（不是 OOMKilled，是 JVM 自己抛的，exit code 1），Pod 重启后 3 天再犯。

影响面：3 次进程级 OOM，每次恢复 20~40s，网关侧 5xx 峰值 1.4%，P99 从 45ms 抖到 380ms。

二、根因：Netty 4.1 的 Direct Buffer 是「池化 + 泄漏检测采样」，不是「malloc/free」

先把机制讲清楚，否则后面的命令看不懂：

1. PooledByteBufAllocator 按 chunk 分配。Netty 4.1 默认把堆外内存切成 16MB 的 chunk，chunk 内部按 maxOrder（默认 11，即最大 32KB 的 size class）分片。一个 arena（默认 = 2 × CPU 核数，本例 8 个 arena）各自管自己的 chunk。这意味着：只要有一个 chunk 里还有一片没释放，整个 16MB 都回收不掉。所以 used 涨到接近 allocated 是「有泄漏」的典型形态，而不是「正常高水位」。

2. 泄漏检测默认是 SIMPLE（采样 1/128）。io.netty.leakDetectionLevel 缺省 SIMPLE，意思是每 128 次 alloc 才随机选 1 次挂 ResourceLeakDetector，且只在对象被 GC 且 refCnt>0 时才报 LEAK: 日志。所以「线上日志干净」完全不能证明没泄漏——默认配置下，真正的泄漏大概率一条日志都看不到。

3. -XX:MaxDirectMemorySize 的默认值等于 -Xmx。JDK 17 下如果你没显式配，这个上限就是 4G（本例 Xmx=4g）；而 Netty 4.1 里 PlatformDependent.maxDirectMemory() 还受 -Dio.netty.maxDirectMemory 和 io.netty.maxDirectMemory=0（禁用上限）两个开关影响。三者取 min，很多人以为「我 Netty 没设，就是不限」，其实是被 Xmx 卡住的——这也是为什么抛的是 JVM 的 Direct buffer memory 而不是 Netty 自己的 OOM。

4. 本例真正的泄漏点：一处业务代码在 channelRead0 里对 msg.retainedSlice() 做了异步转发，但异步链路的异常分支忘了 refCnt -= 1。QPS 2400 × 650MB/h，反推每小时约 1.1 亿次引用泄漏，量级完全对得上。

三、具体做法：三件套组合拳，可复现

第 1 步：把泄漏检测从 SIMPLE 调到 PARANOID，让每条 ByteBuf 都挂检测器。

# JVM 启动参数，排障窗口开；PARANOID 有 5%~10% 的吞吐损耗，别常开
-Dio.netty.leakDetectionLevel=PARANOID
-Dio.netty.leakDetection.targetRecords=64   # 记录最近 64 次操作栈，够定位

复现窗口内观察日志，会看到类似：

LEAK: ByteBuf.release() was not called before it reached garbage
collector (total=128, pending=3)
#0. allocated at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(...)
#1. retained at com.example.gateway.rpc.UpstreamCodec.encode(UpstreamCodec.java:147)
#2. ...

retained at 那一行就是泄漏点。 PARANOID 模式下 20 分钟内稳定复现，指认到 UpstreamCodec.java:147 的 retainedSlice()。

第 2 步：jemalloc 抓分配热点，交叉验证「是不是 Netty 的 chunk 在涨」。

# 用 jemalloc 替换 glibc malloc 启动（JDK 17 直接 -agentpath 即可）
LD_PRELOAD=/usr/lib/libjemalloc.so.2 \
  MALLOC_CONF="prof:true,prof_prefix:/tmp/jeprof,lg_prof_interval:28" \
  java -jar gateway.jar

# 复现 1 小时后 dump
kill -USR1 <pid>
jeprof --show_briefs --format=google /usr/bin/java /tmp/jeprof.<pid>.0.heap | dot -Tsvg > alloc.svg

火焰图里 je_malloc → PlatformDependent.allocateDirectNoCleaner → PooledByteBufAllocator.newChunk 这条链路的宽度，就是 Netty 池化 chunk 的净增量。如果这条链路宽度 ≈ RSS 增量，基本坐实是池化 ByteBuf 泄漏；如果宽度很小，那要怀疑的是 glibc arena 碎片或别的 native 库。

第 3 步：pmap 看大段 anon，量化「chunk 是不是没还回去」。

# 按大小排序，找 16MB 级别的 anon 段
pmap -x <pid> | sort -k3 -n -r | head -30

# 或更精确：统计 16MB 附近的 anon 段数量
pmap -x <pid> | awk '$4 ~ /1638[0-9]/ && $5 == "anon" {n++; s+=$3} END {print n, s/1024/1024 " GB"}'

本例修复前：16MB 级 anon 段 172 段 ≈ 2.69GB；修复后（补上 finally { msg.release(); }）：17 段 ≈ 268MB，稳态不再爬升。段数直接对应「还活着的 chunk 数」，这是比 RSS 更干净的指标。

第 4 步：把上限和告警一起配上，别再让「4 小时后 1」裸奔。

# 显式给 Direct 一个上限，别依赖 Xmx 隐式兜底
-XX:MaxDirectMemorySize=1536m
# Netty 侧对齐（可选，双保险）
-Dio.netty.maxDirectMemory=1610612736
# Prometheus 告警：direct used 的斜率
rate(jvm_buffer_memory_used_bytes{area="direct"}[15m]) > 50*1024*1024  # >50MB/s 持续 15min

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

• 坑 1：io.netty.leakDetectionLevel=PARANOID 不是「常开保险」。 全量挂检测器，每条 ByteBuf 都带一个 ResourceLeakDetector 对象 + 栈记录，QPS 2400 下实测吞吐掉了 7.8%，P99 涨了 12ms。正确姿势：线上开 SIMPLE（默认）或 ADVANCED，排障窗口切 PARANOID，定位完立刻切回。
• 坑 2：-Dio.netty.maxDirectMemory=0 是「禁用上限」，不是「设成 0」。 见过一次事故排查时有人手滑加了这行，结果 Netty 的池化分配完全不受 Xmx 约束，堆外直接吃穿容器被内核 137。0 在这里语义是 OFF。
• 坑 3：jcmd VM.direct_buffers 的 allocated 不等于「泄漏量」。 Netty 池化回收是把整块 chunk 还给池，chunk 内部碎片是常态。看斜率（allocated 的 15min 增量）比看绝对值有用得多，稳态下 200MB 的池化水位很正常，持续单调上涨才是异常。
• 坑 4：PARANOID 报的 LEAK: 日志，retained at 才是泄漏点，allocated at 只是分配点。 我们第一版定位错在 allocated at，去改了一个正确的分配路径，改完泄漏还在。栈帧里第一帧「retained / dereferenced / accessed」才是引用计数变动的现场。
• 反直觉：JDK 17 的 MaxDirectMemorySize 默认 = Xmx，不是「不限」。 很多人写 -Dio.netty.maxDirectMemory 时以为不写就是无上限，其实被 Xmx 兜底了；反过来，如果你把 Xmx 调大，Direct 上限也悄悄跟着涨——改 Xmx 之前，先确认 Direct 上限是不是你预期的值。

五、结论与可复用清单

Netty 堆外内存问题，「分配」几乎永远不是瓶颈，「释放」才是；而 JVM 的工具链（heap dump、jstat、jcmd 大部分子命令）对堆外基本是盲区，必须上「泄漏检测 + native profiler + pmap」这条 native 侧的路。

可复用清单（贴到 runbook 里）：

1. 告警看斜率不看绝对值：rate(jvm_buffer_memory_used_bytes{area="direct"}[15m]) > 50MB/s 持续 15min 就该告警，别等 OOM。
2. 线上 leakDetectionLevel 保持 SIMPLE 或 ADVANCED，排障窗口切 PARANOID，定位完立刻切回；PARANOID 有 5%~10% 吞吐损耗。
3. 显式配 -XX:MaxDirectMemorySize，别依赖 Xmx 隐式兜底；改 Xmx 前先确认 Direct 上限。
4. -Dio.netty.maxDirectMemory=0 语义是 OFF，不是 0 字节，别写错。
5. pmap 数 16MB anon 段是判断「Netty chunk 是否被持有」最快的指标，比 RSS 干净。
6. jemalloc heap profiling 是交叉验证「是不是 Netty 池化在涨」的最硬证据，火焰图里找 PooledByteBufAllocator.newChunk 链路。
7. PARANOID 日志里 retained at 才是泄漏现场，allocated at 只是分配点，别改错地方。
8. 修泄漏时补 finally { msg.release(); } 是底线，异步链路的异常分支是重灾区；能不用 retainedSlice() 就不用，能 copy() 就 copy()（小消息场景下 copy 的开销远小于泄漏排查成本）。

一句话收尾：Netty 的 ByteBuf 是「借来的内存」，refCnt 是借条；SIMPLE 检测是「抽查」，PARANOID 是「全查」——别指望抽查能抓到你，也别让全查一直开着。