bytebuffer.allocatedirect() 可快速触发堆外oom，抛outofmemoryerror: direct buffer memory，用于验证堆外内存配置；堆oom需分配大数组直入老年代；需配置heapdumponoutofmemoryerror并指定可写路径以生成有效hprof文件。
用 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<bytebuffer> 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 触发成功");
}
}</bytebuffer>
用 -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 <pid></pid> 看似简单，但在生产环境极易失败：JVM 进程开了 -XX:+DisableAttachMechanism、容器没装 jdk（只有 jre）、或目标进程运行在不同用户下。
更隐蔽的问题是：手动 dump 时应用还在跑，对象状态持续变化，dump 出来的堆可能不包含刚发生的 OOM 根因（比如某个缓存 Map 正在被清理）。
- 提前确认
tools.jar是否在 classpath（JDK 9+ 已模块化，需用jhsdb替代） - Docker 中优先用
docker exec -it <container> jhsdb jmap --pid 1 --binaryheap --dumpfile /tmp/heap.hprof</container>（JDK 11+） - 如果已 OOM 且进程卡住（比如 CMS 失败后陷入 STW），
jmap可能无限等待，改用gcore+jstack组合更稳
真正难的不是生成 dump，而是从几百 MB 的 hprof 里快速定位到谁持有最多对象、谁阻止了 GC——这得靠 mat 或 VisualVM 配合支配树分析，不是加几个 JVM 参数就能解决的。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
