JVM底层能力体现在能5分钟内定位Metaspace OOM根源，如类加载器泄漏、动态代理暴增或DevTools未关闭，并联动内存区域职责、类卸载条件与元空间扩容逻辑；需关注Metaspace、DirectBuffer、CodeCache等堆外内存，其不受GC控制，须显式配置-XX:MaxMetaspaceSize和-XX:MaxDirectMemorySize。
能从 JVM 底层解决复杂问题，不是靠背参数或看几篇 GC 日志截图，而是你能在 OutOfMemoryError: Metaspace 报错后 5 分钟内判断是类加载器泄漏、动态代理暴增，还是 Spring Boot DevTools 未关闭导致的——这背后是内存区域职责、类卸载条件、元空间扩容逻辑三者的实时联动。
为什么堆外内存问题总在上线后爆发
很多团队把 -Xmx 调大就以为“内存够了”，却忽略 Metaspace、DirectByteBuffer、CodeCache 这些堆外区域不受 GC 控制。比如用 Netty 时频繁创建 PooledByteBufAllocator 实例但没调用 .close()，Direct Memory 会持续增长直到触发 OutOfMemoryError: Direct buffer memory；又或者大量使用 CGLIB 动态代理（Spring AOP 默认模式），导致 Metaspace 不断扩容直至耗尽。
- 排查优先级：先用
jstat -gc <pid>看MU（Metaspace used）和CCSU（Compressed Class Space used）是否持续上涨 - 确认泄漏点：用
jcmd <pid> VM.native_memory summary scale=MB查 Direct Memory 使用量 - 关键限制项：
-XX:MaxMetaspaceSize必须显式设置，否则默认无上限；-XX:MaxDirectMemorySize在 JDK 8+ 默认等于-Xmx，但 Netty 等框架常绕过该限制
GC 日志里真正该盯住的三行指标
不是所有 GC pause 都值得优化。重点看 G1 Evacuation Pause 或 Pause Young (Normal) 后面的三组数字：回收前堆大小 → 回收后堆大小（已用）→ 总堆大小，例如 [1234M->456M(2048M)]。如果长期出现 456M 越来越接近 2048M，说明对象存活率高、老年代正在缓慢填充——这时调小 -XX:G1MixedGCCountTarget 或增大 -XX:G1HeapWastePercent 可能比换收集器更有效。
- 别被“平均停顿 50ms”骗：用
-Xlog:gc*:file=gc.log:time,uptime,level,tags（JDK 11+）开启带时间戳的原始日志，再 grepto-space-exhausted查是否发生疏散失败 - Old Gen 增长慢 ≠ 安全：观察
jstat -gccause <pid>中LGCC（Last GC Cause）是否频繁出现G1 Humongous Allocation，这代表大对象直接进老年代，后续可能引发碎片化 - JDK 8 用
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，但注意日志格式不统一，解析脚本需适配不同 GC 类型
线程 dump 里藏着最真实的瓶颈线索
当 jstack <pid> 输出中出现大量 java.lang.Thread.State: BLOCKED (on object monitor)，不要急着加锁粒度——先看 blocked on 后面的地址，再搜这个地址上一次被哪个线程 locked。如果那个线程状态是 WAITING (parking) 且堆栈含 Unsafe.park，大概率是线程池满 + 拒绝策略为 AbortPolicy 导致任务直接抛异常，上游重试又加剧阻塞。
立即学习“Java免费学习笔记（深入）”；
- 快速定位锁竞争：用
grep -A 10 "BLOCKED" thread.log | grep -E "(locked|waiting to lock)"提取锁地址链 - 区分真死锁与假等待：
jstack -l <pid>的Found one Java-level deadlock是明确信号；若无此提示但线程卡在Object.wait()，检查CountDownLatch.await()是否漏掉countDown() - 注意线程名误导：Spring Boot 默认线程池名是
task-1，但实际可能是 Dubbo 的DubboClientHandler线程在等 ZooKeeper 连接，得结合top -H -p <pid>和printf "%x\n" <tid>对齐 native 线程 ID
真正的底层能力不是记住所有 JVM 参数，而是当 Full GC 频繁发生时，你能从 jmap -histo <pid> 排出的前 10 类中一眼识别出 char[] 占比异常高——然后立刻想到是不是 JSON 解析用了 String.substring() 导致共享底层数组无法回收，而不是盲目调大堆内存。
