JVM 内存区域深度解析——堆外内存泄漏排查的完整方法论

适读人群：有 JVM 基础知识、遇到过内存相关问题的 Java 工程师 | 阅读时长：约18分钟 | 核心价值：彻底理解 JVM 各内存区域的作用，掌握堆外内存泄漏的系统排查方法论

---

一、那次诡异的 OOM

两年前我处理过一个非常棘手的内存问题。某个微服务在生产环境运行，JVM 堆内存 -Xmx 4G，业务高峰期系统 RSS（进程实际内存）一路涨到 8G，然后被 K8s OOM Killer 杀掉。

奇怪的是，GC 日志里 JVM 堆内存一直维持在 2.5G 左右，堆内存完全正常。那多出来的 3.5G 内存是谁占的？

排查了三天，最终发现是 Netty 的 DirectByteBuffer 泄漏：有个地方错误地用了 ByteBuf.retain() 但没有对应的 release()，堆外内存一点一点地积累，直到被系统 OOM Killer 干掉。

这件事让我深刻认识到：Java 不是只有堆内存，JVM 内存区域的全貌比很多人想象的复杂得多。这篇文章我从内存区域的架构开始讲，重点讲堆外内存的排查方法，把方法论给你。

---

二、JVM 内存区域全景图

JVM 内存区域分为两大类：线程私有区域和线程共享区域。

线程私有区域：

• 程序计数器（PC Register）：每个线程独有，记录当前执行的字节码指令地址。执行 native 方法时为 undefined。是 JVM 规范中唯一不规定 OOM 的区域。
• 虚拟机栈（JVM Stack）：每个方法调用对应一个栈帧，存放局部变量表、操作数栈、动态连接、方法返回地址。栈深度超限抛 StackOverflowError；栈无法扩展时抛 OOM。
• 本地方法栈（Native Method Stack）：为 native 方法服务，HotSpot 将虚拟机栈和本地方法栈合二为一。

线程共享区域：

• 堆（Heap）：所有对象实例分配在这里。GC 主要管理的区域，OOM 最常见的地方。分为新生代（Eden + S0 + S1）和老年代。
• 方法区（Metaspace）：存放类信息、常量、静态变量、JIT 编译后的代码。Java 8 之后改为 Metaspace，使用本地内存，不受 -Xmx 限制。
• 运行时常量池：方法区的一部分，存放编译期生成的字面量和符号引用。

堆外内存（Off-Heap Memory）：

• 直接内存（Direct Memory）：通过 ByteBuffer.allocateDirect() 或 Netty DirectByteBuf 分配，走 JNI 调用 malloc，不受 GC 管理。-XX:MaxDirectMemorySize 控制上限。
• Code Cache：JIT 编译器把热点代码编译成机器码，存放在 Code Cache。满了之后 JIT 停止编译，性能下降。

---

三、各区域常见 OOM 及触发原因

堆 OOM（最常见）：

java.lang.OutOfMemoryError: Java heap space

原因：对象持续增长，GC 回收跟不上分配速度。常见场景：内存泄漏（集合无限增长）、大对象（大 List、大文件读入内存）、并发量过高。

Metaspace OOM：

java.lang.OutOfMemoryError: Metaspace

原因：类不断被加载但无法卸载，通常是动态代理、脚本引擎、CGLib 生成的代理类数量失控。

直接内存 OOM：

java.lang.OutOfMemoryError: Direct buffer memory

原因：DirectByteBuffer 分配后未释放，超过 -XX:MaxDirectMemorySize 限制。

栈溢出：

java.lang.StackOverflowError

原因：递归调用太深，或局部变量过多导致单个栈帧太大。

---

四、堆外内存泄漏排查方法论

回到开头的案例。进程内存（RSS）持续增长，但 JVM 堆正常，说明内存增长发生在堆外。排查流程如下：

4.1 第一步：确认不是堆泄漏

用 jstat -gcutil <pid> 5000 每 5 秒打印一次 GC 情况：

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
  0.00  98.23  56.89  64.12  95.68  92.34    512    8.234    12    2.456   10.690

如果老年代（O 列）没有持续增长、GC 后能回收到正常水位，说明堆内存健康，问题在堆外。

4.2 第二步：查直接内存使用量

package com.example.diagnostic;

import java.lang.management.ManagementFactory;
import java.lang.reflect.Field;

/**
 * 读取 JVM 直接内存使用量。
 * 通过反射访问 java.nio.Bits 的 reservedMemory 字段，获取当前直接内存占用。
 */
public class DirectMemoryChecker {

    public static long getDirectMemoryUsed() {
        try {
            Class<?> bitsClass = Class.forName("java.nio.Bits");
            Field reservedMemoryField = bitsClass.getDeclaredField("reservedMemory");
            reservedMemoryField.setAccessible(true);
            // Java 11+ 返回 AtomicLong，需要特殊处理
            Object value = reservedMemoryField.get(null);
            if (value instanceof java.util.concurrent.atomic.AtomicLong) {
                return ((java.util.concurrent.atomic.AtomicLong) value).get();
            }
            return (Long) value;
        } catch (Exception e) {
            return -1L;
        }
    }

    public static void printDirectMemoryInfo() {
        long usedBytes = getDirectMemoryUsed();
        System.out.printf("Direct Memory Used: %.2f MB%n", usedBytes / 1024.0 / 1024.0);

        // 同时获取 JVM 启动参数里配置的 MaxDirectMemorySize
        ManagementFactory.getRuntimeMXBean().getInputArguments()
                .stream()
                .filter(arg -> arg.startsWith("-XX:MaxDirectMemorySize"))
                .forEach(arg -> System.out.println("MaxDirectMemorySize config: " + arg));
    }
}

也可以通过 JMX 监控 java.nio:type=BufferPool,name=direct 的 MemoryUsed 属性，集成到 Micrometer 后在 Grafana 里实时观察。

4.3 第三步：用 NMT 定位堆外内存来源

JVM 提供了 Native Memory Tracking（NMT）功能，可以追踪本地内存的分配情况。

启动 JVM 时加参数：

-XX:NativeMemoryTracking=detail

运行一段时间后，用 jcmd 获取报告：

jcmd <pid> VM.native_memory detail

输出示例：

Native Memory Tracking:

Total: reserved=8.2GB, committed=6.1GB

-                 Java Heap (reserved=4096MB, committed=2560MB)
-                     Class (reserved=1056MB, committed=55MB)
-                    Thread (reserved=128MB, committed=128MB)
-                      Code (reserved=240MB, committed=50MB)
-                       GC (reserved=350MB, committed=350MB)
-                 Compiler (reserved=1MB, committed=1MB)
-                 Internal (reserved=512MB, committed=512MB)  <- 重点关注
-                    Other (reserved=2GB, committed=2GB)      <- 重点关注

如果 Internal 或 Other 持续增长，说明有 native 内存泄漏。

4.4 第四步：用 jemalloc 做 native malloc 分析

如果 NMT 无法定位，说明泄漏发生在 JVM 之外（比如 JNI 库、系统调用）。此时需要用 jemalloc 的内存分析功能：

# Linux 环境
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so \
MALLOC_CONF=prof:true,prof_prefix:/tmp/jeprof.out \
java -jar your-app.jar

# 一段时间后生成分析报告
jeprof --show_bytes --pdf /usr/bin/java /tmp/jeprof.out.* > analysis.pdf

这个工具能精确到 C/C++ 函数级别，告诉你内存在哪里被分配了但没有释放。

---

五、踩坑实录

坑1：Netty DirectByteBuf 泄漏

现象：进程内存持续增长，NMT 显示 Internal 区域持续扩大，JVM 堆正常。

原因：业务代码里调用了 Netty 的 ChannelHandlerContext.alloc().buffer()，用完后忘记调 ReferenceCountUtil.release()。Netty 使用引用计数管理 DirectByteBuf 的生命周期，只有引用计数降为 0 才会释放内存。这个坑我也踩过，当时排查了整整三天。

解法：

// 正确写法：使用 try-finally 确保释放
ByteBuf buf = ctx.alloc().buffer(1024);
try {
    buf.writeBytes(data);
    ctx.writeAndFlush(buf.retain()); // retain() 之后 writeAndFlush 会负责释放
} finally {
    buf.release(); // 释放本地引用
}

// 或者开启 Netty 的泄漏检测（开发/测试环境）
// -Dio.netty.leakDetection.level=PARANOID

坑2：Metaspace OOM 因 CGLib 代理类泄漏

现象：服务运行几天后 Metaspace OOM，重启后恢复，但会复发。

原因：某处每次请求都调用 Enhancer.create() 生成新的 CGLib 代理类，且类加载器的引用被持有，代理类无法被 GC。一天产生几万个 Class，撑满 Metaspace。

解法：CGLib 代理要缓存复用，不能每次动态创建。或者改用接口代理（JDK 动态代理），JDK 代理是基于接口的，Class 数量有限。

坑3：-XX:MaxDirectMemorySize 没设置导致直接内存无上限

现象：服务内存一路涨，没有 OOM，直到被系统 kill。

原因：没有设置 -XX:MaxDirectMemorySize，默认值等于 -Xmx，但实际上 JVM 不会主动触发 Full GC 去回收直接内存（只在内存分配失败时才会触发），所以直接内存可以超过 -Xmx 继续增长，直到系统内存耗尽。

解法：明确设置 -XX:MaxDirectMemorySize=512m（根据业务调整），让 JVM 在超过上限时主动 OOM 并记录，而不是静默地把系统内存耗光。

---

六、排查工具速查

工具	用途	使用场景
jstat -gcutil	查看 GC 统计和堆内存使用率	确认是否是堆泄漏
jcmd VM.native_memory	NMT 报告，查本地内存分配	定位堆外内存来源
jmap -histo:live	打印堆对象统计	分析堆内对象分布
jmap -dump	生成堆转储文件	配合 MAT 深度分析
jemalloc + jeprof	native malloc 分析	JNI 或系统级内存泄漏
Netty -leakDetection	Netty 堆外内存泄漏检测	Netty DirectByteBuf 泄漏

我的建议是：排查内存问题按照"堆 → 直接内存 → NMT → jemalloc"的顺序，先排查最常见的，再深入。不要上来就 dump 堆、用 MAT 分析，那是最重的手段，留到最后用。