掌握Java内存调试的关键是建立“问题→现象→指标→工具→根因”闭环思维，而非死记区域名称；需理解JVM总内存=堆+元空间+线程栈×线程数+直接内存+JIT缓存，善用jstat、jmap、jcmd等命令快速分类问题，并通过HeapDumpOnOutOfMemoryError自动捕获证据，结合MAT聚焦GC Roots强引用链、静态集合泄漏和ThreadLocal未清理三大根因。
掌握 Java 内存结构调试技巧，关键不是死记区域名称，而是建立“问题→现象→指标→工具→根因”的闭环思维。你不需要一开始就搞懂所有参数，而是从一次真实的内存异常出发，在复现、观察、验证中把抽象结构变成可感知的线索。
看懂 JVM 进程到底占了多少内存
很多人调优只盯着 -Xmx，却忽略了 JVM 是一个完整进程，总内存 = 堆 + 元空间 + 线程栈 × 线程数 + 直接内存 + JIT 编译缓存。线上 OOM 不一定是堆满了，也可能是：
- 线程数暴涨（比如连接池未限制），-Xss 默认 1MB，1000 个线程就吃掉 1GB 栈内存
- 大量动态代理或字节码生成（Spring AOP、MyBatis Mapper），导致 Metaspace 持续增长
- NIO 使用 DirectByteBuffer 但没显式调用 cleaner 或 free()，堆外内存泄漏
学会用最少命令快速定位问题类型
不用等服务崩了再分析，日常巡检或压测中用这几条命令就能初步分类：
- jstat -gc <pid>：看 GC 频率、各代使用率、GC 耗时。如果 Eden 区刚满就 Minor GC，且 Survivor 区对象升老快 → 可能是对象生命周期设计不合理
- jmap -histo <pid>：按实例数排序，一眼发现是否某类对象（如 HashMap$Node、String、ByteBuf）异常堆积
- jcmd <pid> VM.native_memory summary：JDK8+ 支持查看堆外内存分布，确认 Metaspace、Internal、Direct 是否超预期
让 OOM 自己“说话”
别等人工发现内存告警。在启动参数里加这两项，让 JVM 在崩溃前留下关键证据：
立即学习“Java免费学习笔记（深入）”；
- -XX:+HeapDumpOnOutOfMemoryError：触发堆溢出时自动生成 .hprof 文件
- -XX:HeapDumpPath=/path/to/dumps/：指定 dump 存放路径，建议挂载独立磁盘避免写满根分区
- 配合 -XX:+PrintGCDetails -Xloggc:/path/gc.log，把 GC 行为和堆快照时间对齐，排查时能精准定位“哪个 GC 后对象没回收”
用 MAT 或 JProfiler 看懂 dump 文件
拿到 .hprof 后，重点不是看“谁占内存最多”，而是问三个问题：
- 这个大对象是谁在引用它？打开 Path to GC Roots，过滤“exclude weak/soft references”，找到强引用链
- 是不是静态集合（HashMap、ConcurrentHashMap、static List）在不断 put 却不 remove？这是最常见泄漏模式
- 有没有 ThreadLocal 没清理？尤其在线程池场景下，线程复用导致 value 持有业务对象长期不释放
