JVM 堆外内存泄漏排查——从 Native Memory Tracking 到火焰图定位
一、背景与问题
JVM 的内存管理不仅限于堆（Heap），还包括元空间（Metaspace）、线程栈（Thread Stack）、直接内存（Direct Memory）、JNI 分配的 Native 内存等多个区域。当监控平台显示容器内存持续增长、最终被 OOM Killer 终止，但 Heap/Metaspace 指标正常时，问题大概率出在堆外内存。
我们在一个基于 Netty 的网关服务中遇到此类问题：容器 4GB 内存限额，堆配置 2GB，但 RSS（Resident Set Size）在运行 72 小时后逼近 4GB，触发 Kubernetes OOM Killer。Heap 使用率稳定在 55%，Metaspace 仅 80MB——多出的 1.9GB 堆外内存从何而来？
二、方案设计
堆外内存排查的核心思路是：先用 NMT（Native Memory Tracking）确认 JVM 自身分配的各区域用量，再对比进程 RSS，差值即为非 JVM 分配的 Native 内存（通常来自 JNI、第三方库的 malloc）。确认分配来源后，通过火焰图或 GDB 定位具体调用路径。
flowchart TD A[容器 RSS 持续增长] --> B{jstat/gc 日志正常?} B -->|是| C[启用 NMT 追踪] C --> D[jcmd VM.native_memory summary] D --> E{NMT Total ≈ RSS?} E -->|是| F[定位 JVM 内部分配] E -->|否| G[NMT 差值 = 外部 Native 分配] F --> H[NMT detail.diff 定位增长区域] G --> I[火焰图 / GDB 追踪 malloc] H --> J[确认泄漏源并修复] I --> J关键工具链：
- NMT：JVM 内置的 Native 内存追踪器，通过
-XX:NativeMemoryTracking=detail启动，可输出各区域分配详情。 - pmap：查看进程完整内存映射，定位匿名大页。
- perf + FlameGraph：采样调用栈，通过
malloc/calloc的调用热度定位分配源头。
三、实战演示
3.1 启用 NMT 并收集数据
# 启动参数启用 NMT（detail 级别，额外开销约 5%） java -XX:NativeMemoryTracking=detail \ -Xmx2g -Xms2g \ -jar gateway-service.jar # 查看当前 Native 内存摘要 jcmd <pid> VM.native_memory summary # 建立基准后，间隔一段时间对比增长 jcmd <pid> VM.native_memory baseline # ... 运行 24 小时后 ... jcmd <pid> VM.native_memory detail.diffNMT 输出示例（摘要）：
Total: reserved=5768MB, committed=2148MB - Java Heap: reserved=2048MB, committed=2048MB - Class: reserved=1084MB, committed=80MB - Thread: reserved=256MB, committed=256MB (线程数 128) - Internal: reserved=32MB, committed=32MB - Other: reserved=28MB, committed=28MB3.2 对比 RSS 与 NMT
# 获取进程 RSS（单位 KB） ps -o pid,rss -p <pid> # 示例输出：RSS = 3800MB # NMT committed = 2148MB # 差值 = 1652MB → 非 JVM 分配的 Native 内存差值 1652MB 是关键线索。NMT 无法追踪 JVM 外部的 malloc 调用，这部分来自 JNI 库或 Netty 的 Direct Buffer。
3.3 定位 Netty Direct Buffer 泄漏
/** * Netty Direct Buffer 泄漏检测配置 * 生产环境使用 DISABLED（无开销），排查时切换到 ADVANCED */ @Configuration public class NettyLeakDetectionConfig { /** * 设置泄漏检测级别 * 级别：DISABLED / SIMPLE / ADVANCED / PARANOID * ADVANCED 会在每个 Buffer 分配时记录调用栈，开销约 10% */ @PostConstruct public void configureLeakDetection() { String level = System.getProperty("io.netty.leakDetection.level", "ADVANCED"); try { LeakDetectionLevel detectionLevel = LeakDetectionLevel.valueOf(level.toUpperCase()); ResourceLeakDetector.setLevel(detectionLevel); log.info("Netty 泄漏检测级别设置为: {}", detectionLevel); } catch (IllegalArgumentException e) { log.warn("非法泄漏检测级别: {}, 使用默认 SIMPLE", level); ResourceLeakDetector.setLevel(LeakDetectionLevel.SIMPLE); } } }启用 ADVANCED 后，Netty 在日志中输出泄漏报告：
LEAK: ByteBuf.release() was not called before it's garbage-collected. Recent access records: #1: io.netty.handler.codec.http.HttpObjectDecoder.channelRead() at com.example.gateway.HttpProxyHandler.channelRead(HttpProxyHandler.java:45)3.4 修复：确保 ByteBuf 释放
/** * HTTP 代理处理器——修复 Direct Buffer 泄漏 * 关键：在 channelRead 完成后必须释放 ByteBuf */ @Component @Sharable public class HttpProxyHandler extends ChannelInboundHandlerAdapter { @Override public void channelRead(ChannelHandlerContext ctx, Object msg) { try { if (msg instanceof ByteBuf buf) { // 业务处理逻辑 processProxyRequest(ctx, buf); // 必须释放：Direct Buffer 不受 GC 控制 buf.release(); } else if (msg instanceof FullHttpRequest request) { processProxyRequest(ctx, request.content()); request.release(); } } catch (Exception e) { log.error("代理处理异常", e); // 异常时也要释放，避免泄漏 ReferenceCountUtil.release(msg); ctx.fireExceptionCaught(e); } } @Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { log.error("Channel 异常: channelId={}", ctx.channel().id(), cause); ctx.close(); } }3.5 火焰图辅助定位
当 NMT 差值确认是外部 Native 分配但无法确定来源时，用 perf 采样：
# 采样 60 秒，追踪 malloc 调用栈 perf record -g -p <pid> -- sleep 60 # 生成火焰图 perf script | stackcollapse-perf.pl | flamegraph.pl > native-flame.svg # 在火焰图中搜索 malloc，查看最热的调用路径 # 本例中发现 libzstd.so 的 ZSTD_compress 连续调用 malloc # 定位到压缩过滤器未释放临时缓冲区四、深度解析
4.1 JVM 堆外内存的五大区域
| 区域 | 追踪方式 | 典型泄漏场景 |
|---|---|---|
| Direct Buffer | NMT Internal + Netty LeakDetector | 未调用 release() |
| Metaspace | NMT Class | 动态类加载未卸载 |
| Thread Stack | NMT Thread | 线程数持续增长未销毁 |
| JNI Native | 无法由 NMT 追踪 | C 库内存管理错误 |
| Code Cache | NMT Code | JIT 编译巨型方法 |
4.2 NMT 的局限与补充
NMT 有两个盲区：无法追踪 JNI 库的 malloc（如 libzstd、libopenssl）；无法追踪子进程的内存（如 fork 的压缩进程）。对于前者，依赖火焰图或jemalloc的 profiling 功能；对于后者，需在容器层面通过cgroup内存统计监控子进程贡献。
4.3 生产环境的 NMT 开销
detail级别 NMT 的额外开销约 5% CPU 和 3% 内存（用于维护追踪数据结构）。我们建议仅在排查阶段启用，日常运行使用summary级别（开销约 1%）或不启用。
4.4 Direct Buffer 泄漏的根因分类
从 12 个网关服务的生产数据看，Direct Buffer 泄漏可分为三类：
未调用 release()（占 65%）：多出现在异常路径或条件分支中。典型场景：channelRead 中抛出未捕获异常时直接 return、条件判断if (shouldSkip)提前退出而未释放。修复策略是统一使用 try-finally + ReferenceCountUtil.release() 兜底。
引用计数管理错误（占 25%）：当同一个 ByteBuf 被多个 Handler 链式处理时，每个 Handler 需调用retain()增加引用计数、release()减少。遗漏 retain() 会导致下游读到已释放的 ByteBuf（触发 IllegalReferenceCountException），遗漏 release() 则产生泄漏。排查此类问题需在 Netty 的 ResourceLeakDetector 日志中跟踪引用计数变更记录。
第三方库隐式分配（占 10%）：gRPC-Netty、Reactor-Netty 等框架内部使用 PooledByteBufAllocator，但它们的 DefaultLeakDetectionLevel 通常设置为 DISABLED，泄漏检测无法覆盖。对于这类泄漏，NMT 和 Netty LeakDetector 均无效，只能通过 perf 火焰图在 malloc/calloc 热路径中定位，或使用 jemalloc 的prof:true参数追踪分配调用栈。
4.5 RSS 与 NMT 差值的告警阈值设计
生产环境建议对 RSS 与 NMT committed 的差值设置分级告警：差值 < heap 的 20% 为正常；>20% 且 <50% 为警告（排查中）；>50% 为严重告警（立即介入，高概率存在泄漏）。该阈值基于我们 6 个月的观察数据——正常运行的 Java 服务，堆外内存（含 JNI 库的临时分配）通常在 heap 的 15%~20% 之间，超过 50% 意味着存在数 GB 的泄漏。
五、总结与展望
堆外内存泄漏排查的完整路径：RSS 异常 → NMT 确认区域 → 差值定位外部分配 → Netty LeakDetector / 火焰图 / jemalloc profiling 找到调用源 → 修复释放逻辑。关键经验：
- NMT 是第一道防线：启动时加
-XX:NativeMemoryTracking=summary，日常开销可控，排查时可升级到detail。 - Direct Buffer 是最常见的泄漏源：Netty / NIO 的 ByteBuf 必须在所有退出路径上释放，包括异常路径。
- 火焰图是终极手段：当 NMT 无法覆盖时，perf + FlameGraph 能直接定位 malloc 的热路径。
后续我们将把 NMT baseline 采集纳入自动化巡检脚本，结合容器内存趋势告警，在泄漏萌芽阶段即可预警，避免等到 OOM Killer 触发才被动响应。
