jvm内存结构核心是堆、栈、方法区（元空间）三区域分工：栈管线程运行，堆管对象存储并触发gc，元空间存类元数据；结合gc触发逻辑与实操观察，可贯通抽象模型与真实现象。

直接学 JVM 内存结构，别绕弯——它不是“背概念”，而是理解“代码跑起来时，内存里到底发生了什么”。重点在堆、栈、方法区（元空间）三块核心区域的分工与互动，再配合 GC 的实际触发逻辑，就能把抽象模型和真实现象串起来。

先搞清三块核心区域各管什么

不用记太多术语，抓住一句话定位：

• 栈（Stack）：每个线程独有，管“运行”——方法调用、局部变量、操作数栈都在这儿。方法一执行完，对应栈帧立刻弹出，不等 GC。
• 堆（Heap）：整个 JVM 共享，管“存储”——所有 new 出来的对象、数组都放这里。它是 GC 主战场，也是 OOM 最常发生的地方。
• 方法区（JDK 8+ 叫元空间 Metaspace）：存类的元数据（类名、字段、方法签名、常量池等），不是存对象实例。JDK 8 后从永久代移到本地内存，OOM 不再是 PermGen，而是 Metaspace space。

堆内存划分要动手看，不能只看图

新生代（Eden + Survivor0/1）→ 老年代（Old Gen）这个流程，光读文字容易迷糊。建议做两件事：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 写一段循环创建对象的代码（比如 new byte[1024*1024]），加上 JVM 参数 -XX:+PrintGCDetails -Xms20m -Xmx20m，跑几次就看到 Eden 满了触发 Minor GC，存活对象进 Survivor；反复几次后进入老年代。
• 用 jvisualvm 或 JConsole 连上正在运行的程序，实时观察堆内存各区域使用率变化，比看示意图直观十倍。

GC 机制学法：按回收范围分层理解

不用一上来啃 G1 或 ZGC 的论文，先建立判断逻辑：

• Minor GC：发生在新生代，频率高、停顿短。触发条件就是 Eden 区快满了。
• Major GC / Full GC：清理整个堆 + 方法区。常见诱因包括老年代空间不足、System.gc() 显式调用（不推荐）、元空间不足、CMS 失败后兜底等。
• 真正需要调优时，才深入对比 Parallel（吞吐优先）、CMS（低延迟但已废弃）、G1（平衡型，JDK 9+ 默认）、ZGC（超低延迟，适合大堆）各自适用场景和关键参数（如 -XX:MaxGCPauseMillis、-XX:G1HeapRegionSize）。

遇到问题时，倒着查比正着学更有效

比如报 java.lang.OutOfMemoryError: Java heap space，就顺着线索走：

• 是不是堆设太小？看 -Xms/-Xmx 是否合理；
• 是不是代码里缓存了大量对象没释放？用 jmap -histo 或 MAT 分析堆转储（heap dump）；
• 是不是频繁创建临时大对象（如大数组、大字符串拼接）？检查 StringBuilder 使用是否得当；
• 是不是存在内存泄漏？重点关注静态集合、未关闭的连接、监听器未注销等典型模式。