JavaOOM模拟与垃圾回收测试详解

本文深入讲解了如何精准模拟Java堆内与堆外两种OOM异常，重点剖析了通过ByteBuffer.allocateDirect()快速触发堆外内存溢出以验证JVM堆外监控配置的实用技巧，以及通过大数组直入老年代可靠复现堆OOM的方法；同时强调了生成有效HeapDump的关键细节——必须显式指定可写路径的-XX:HeapDumpPath、规避容器环境权限与空间陷阱，并结合GC日志准确定位问题时间点；文章还指出，比触发OOM更关键的是后续分析：手动jmap易失败且时机不准，而真正挑战在于利用MAT等工具从海量hprof中高效定位内存泄漏根因，帮助开发者跳出只盯堆内存的误区，全面掌控Netty、NIO等场景下的真实内存风险。

用 ByteBuffer.allocateDirect() 快速触发堆外 OOM

直接内存不走 GC，但超限会抛 OutOfMemoryError: Direct buffer memory，比填满堆更快、更可控。适合验证 JVM 是否启用了堆外内存监控或是否配置了 -XX:MaxDirectMemorySize。

常见错误是只关注堆内存，却忽略堆外——比如 Netty、NIO 服务压测时突然挂掉，日志里没见堆溢出，其实是这个错。

• 默认 MaxDirectMemorySize 等于 -Xmx 值（JDK 8+），但未显式设置时可能受系统限制影响
• 写测试时别用循环反复 allocateDirect(1024 * 1024 * 1024)，容易被 JIT 优化掉；加个 list.add(buf) 持有引用
• 要捕获的是 OutOfMemoryError，不是 Exception，Java 中它继承自 Throwable 而非 Exception

List buffers = new ArrayList<>();
try {
    while (true) {
        buffers.add(ByteBuffer.allocateDirect(512 * 1024 * 1024)); // 512MB/次
    }
} catch (OutOfMemoryError e) {
    if (e.getMessage().contains("Direct buffer memory")) {
        System.err.println("堆外 OOM 触发成功");
    }
}

用 -Xmx 限制堆 + new byte[...] 填满老年代

想看 GC 行为或触发 Full GC 后仍 OOM？得绕过年轻代快速晋升。直接分配大数组（比如 > 2MB）大概率进老年代（取决于 JVM 默认的 -XX:PretenureSizeThreshold，HotSpot 默认 0，但实际由阈值和 GC 算法共同决定）。

注意：CMS 和 G1 对大对象处理逻辑不同，G1 的 -XX:G1HeapRegionSize 会影响“大对象”定义（≥ ½ region size 才算 Humongous Object）。

• 启动参数必须设小堆，例如 -Xms128m -Xmx128m，否则填不满
• 单次分配太小（如 1MB）可能被放入 Eden，经历几次 Minor GC 才晋升，干扰观察
• 不要用字符串拼接或 ArrayList 动态扩容来“慢慢耗尽”，那会触发多次 GC，掩盖真实 OOM 场景

byte[] payload = null;
try {
    payload = new byte[100 * 1024 * 1024]; // 100MB，直接冲击老年代
} catch (OutOfMemoryError e) {
    System.err.println("堆 OOM：" + e.getMessage());
}

让 JVM 自动 dump 堆并确保文件可读

光抛异常没用，关键是要拿到 hprof 文件。靠 -XX:+HeapDumpOnOutOfMemoryError 是基础，但默认 dump 到启动目录，容器环境常因权限或路径不存在而静默失败。

典型现象：OOM 发生了，但没生成 dump 文件，查 hs_err_pid*.log 会看到 Unable to create core dump 或 Could not generate heap dump file。

• 必须指定 -XX:HeapDumpPath=/path/to/writable/dir，且该路径对 JVM 进程用户可写
• Linux 容器中避免写根目录或 /tmp（有些镜像挂载为 tmpfs，空间小且重启丢失）
• 加 -XX:+PrintGCDetails -Xlog:gc*:file=gc.log:time（JDK 11+）或 -XX:+PrintGCTimeStamps（JDK 8）对齐 dump 时间点

java -Xms128m -Xmx128m \
     -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/var/log/myapp/heap.hprof \
     -Xlog:gc*:file=/var/log/myapp/gc.log:time \
     -jar app.jar

用 jmap 手动 dump 时权限与时机陷阱

jmap -dump:format=b,file=heap.hprof 看似简单，但在生产环境极易失败：JVM 进程开了 -XX:+DisableAttachMechanism、容器没装 jdk（只有 jre）、或目标进程运行在不同用户下。

更隐蔽的问题是：手动 dump 时应用还在跑，对象状态持续变化，dump 出来的堆可能不包含刚发生的 OOM 根因（比如某个缓存 Map 正在被清理）。

• 提前确认 tools.jar 是否在 classpath（JDK 9+ 已模块化，需用 jhsdb 替代）
• Docker 中优先用 docker exec -it jhsdb jmap --pid 1 --binaryheap --dumpfile /tmp/heap.hprof（JDK 11+）
• 如果已 OOM 且进程卡住（比如 CMS 失败后陷入 STW），jmap 可能无限等待，改用 gcore + jstack 组合更稳

真正难的不是生成 dump，而是从几百 MB 的 hprof 里快速定位到谁持有最多对象、谁阻止了 GC——这得靠 mat 或 VisualVM 配合支配树分析，不是加几个 JVM 参数就能解决的。

今天关于《JavaOOM模拟与垃圾回收测试详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！