企业官网建设流程全解析

一提到JVM，很多刚学Java的同学第一反应就是头疼。语法还没写利索，就要面对运行时数据区、垃圾回收、类加载机制这些名词，又多又绕。但以我这些年带新人和自己啃源码的经验看，JVM并没有那么可怕，关键是找对切入点——内存结构就是最好的第一站。这次选的「程序计数器」和「虚拟机栈」，正好是六大内存区域里最直观、最容易用代码验证、面试还经常问的两个。把这两个区域吃透，你后面理解堆、方法区、垃圾回收都会轻松很多。这篇文章不搞长篇大论的理论背诵，而是把每个概念背后“为什么要这样设计”讲清楚，再带你亲手复现栈溢出、用工具看线程栈，保证看完你能真正用起来。

1. 学内存结构之前，先把“六个区”的全局图装进脑子

1.1 别把“内存结构”和“JMM”搞混：这是两件完全不同的事

很多人搜索“jvm内存模型”找到的文章，打开发现一会儿讲堆、栈、方法区，一会儿讲volatile、happens-before，好像都对，但总感觉拧着。原因很简单：中文互联网里“JVM内存模型”这个词被说烂了，它其实同时指向两个完全不同的概念。

一个是内存结构，官方叫Runtime Data Area，就是JVM运行时把内存划分成的几个区域，包括程序计数器、虚拟机栈、本地方法栈、堆、方法区。这是JVM的“物理规划”，跟你写的Java代码怎么在内存里存放有关。

另一个是JMM（Java Memory Model），它研究的是多线程场景下共享变量的可见性、有序性、原子性，里面讲主内存、工作内存、volatile、synchronized的底层语义。这是并发编程层面的抽象模型，不是真正的内存区域划分。

看下面的对比就清楚了：

也就是说，碰到“程序计数器、虚拟机栈”这类问题，要答的是内存结构；碰到“两个线程同时改一个变量为什么可能不可见”这类问题，才需要搬出JMM。这两件事在学习路线上的位置也不同：先搞懂内存结构，再去学并发，秩序就顺了。

1.2 六个区域按线程划分，一句话总结各自的职责

HotSpot虚拟机把运行时内存分为六大区域，第一眼要记住的不是每个区有多少细节，而是哪几个是线程私有的，哪几个是线程共享的。

线程私有的有三个：

• 程序计数器：记录当前线程下一条要执行的字节码指令地址。
• 虚拟机栈：每个方法执行时创建一个栈帧，保存局部变量、中间计算过程等。
• 本地方法栈：为虚拟机执行Native方法服务，HotSpot里和虚拟机栈合并在一起实现。

线程共享的也有三个：

• 堆：几乎所有对象实例和数组都在这里分配，也是垃圾回收的主战场。
• 方法区：存类型信息、常量、静态变量、即时编译器编译后的代码等。
• 运行时常量池：它是方法区的一部分，装类和接口的常量池表，包括各种字面量和符号引用。

Java 8之后，方法区的具体实现从永久代换成了元空间，但它依然是逻辑上的方法区。类元信息搬到了本地内存，不再受老年代永久代的堆大小限制。这一点后面讲方法区的时候会单独展开，现在只需要知道区域划分不随JDK版本乱变就行。

1.3 为什么先学程序计数器和虚拟机栈

后面的堆和方法区内容多、牵扯GC、涉及各种调优参数，新人一口气吃下去容易消化不良。程序计数器和虚拟机栈有几个天然优势，适合当先头部队：

第一，概念独立性强。它们基本不牵扯垃圾回收，你可以先把“一个方法从调用到返回发生了什么”这个模型建好，而不需要同时理解对象晋升、GC Roots那一堆事。

第二，特别容易用代码复现。栈溢出一条递归就爆出来了，程序计数器虽然不能在Java代码里直接访问，但通过javap看字节码指令就能感知它的存在。这种即时反馈对建立信心很重要。

第三，面试频率高但答案相对固定。面试官问“JVM内存结构”时，通常先从这两个私有区问起，答得好能让面试官觉得你基础扎实。

2. 程序计数器：唯一不会OOM的“线程私房小本本”

2.1 它存的不是“已经执行的行号”，而是“下一条要执行的指令”

官方文档里程序计数器叫Program Counter Register，有些中文资料叫“PC寄存器”。注意别看带“寄存器”三个字就以为它和CPU寄存器一样，在JVM里它就是一块很小的内存空间。

它的作用是记录当前线程正在执行的字节码指令的地址。更准确地说，解释器工作时，就是通过读取程序计数器来获取下一条需要执行的字节码指令；分支、循环、跳转、异常处理、线程恢复等功能，全部依赖这个计数器才能完成。

我见过不少人以为程序计数器存的是“当前执行到源码第几行”，这个理解不准确。字节码一行行指令和源码行号有关联，但程序计数器记的是字节码层面的执行位置。javap -c看到的字节码里，会有line和pc之类的对应关系，比如源码第10行对应字节码偏移量2，源码第11行对应偏移量5。程序计数器内部对这些偏移量非常敏感，因为它要靠这个偏移量去找到下一条指令。

2.2 线程切换靠它恢复现场，这正是线程私有设计的原因

为什么程序计数器必须是线程私有的？答案是：线程切换时要“恢复现场”。

举个生活中的例子：你正在看书，看到第80页时被人叫走处理事情，处理完再回来看书。如果不在书页夹个书签，你根本想不起自己看到哪了。程序计数器就是每个线程的“书签”。

多线程环境下，CPU会以时间片轮转的方式给线程分配执行机会。线程A执行到字节码偏移量50时，时间片用完了，操作系统把它挂起，调度线程B去执行。等线程A再次获得CPU时间片，它必须知道自己刚才执行到哪了，否则整个方法就乱套了。

这个“刚才执行到哪”的信息不可能共享。如果多个线程共用一个程序计数器，线程A切走又切回来时，计数器可能已经被线程B改得面目全非。所以JVM规定：每个线程都有自己独立的一份程序计数器，互不干扰，这就是“线程私有”的根本原因。

2.3 native方法为什么让程序计数器“失效”，以及没有OOM的底层含义

程序计数器有一个很反直觉的规定：如果线程正在执行的是Native方法，那么程序计数器的值是Undefined（未定义）。

原因不难理解。Native方法走的是JNI调用，通常由C/C++等外部代码实现，执行过程不经过JVM的字节码解释器。既然字节码解释器不参与，自然也就不需要记录“下一条字节码指令的地址”。这时候程序计数器的值是空的，相当于书签暂时没用了。

另一个容易被面试官抓住的点是：程序计数器是唯一不会出现OutOfMemoryError的内存区域。

《Java虚拟机规范》里明确说了，程序计数器没有规定任何OutOfMemoryError情况。因为它的空间需求是极小的，只需要能存下一个返回地址或分支偏移量，不管多极端的场景都不会因为内存不足而抛OOM。虚拟机规范里没有给这块区域定义OOM，HotSpot实现里也确实没有针对PC的内存分配失败检查。

于是面试里那句经典结论就是：Java内存区域中，唯一不会抛出OutOfMemoryError的是程序计数器。

2.4 面试的时候，程序计数器通常怎么出题

程序计数器本身内容不多，面试题一般不是一个大题，而是作为“JVM内存模型（结构）”整体题的切入点出现。常见问法：

• 哪些内存区域是线程私有的？答：程序计数器、虚拟机栈、本地方法栈。
• 程序计数器的作用是什么？答：记录当前线程正在执行的字节码指令地址，用于分支、循环、跳转、异常处理、线程恢复等。
• 为什么程序计数器是线程私有的？答：线程切换后需要恢复到正确的执行位置，各线程互不干扰。
• 程序计数器会OutOfMemoryError吗？答：不会，虚拟机规范没给这块区域定义OOM。
• 执行Native方法时程序计数器存什么？答：值为Undefined，因为Native方法不经字节码解释器执行。

把这五个问答串起来，程序计数器这一块就算过关了。

3. 虚拟机栈：一次方法调用就是一个栈帧的一生

3.1 线程栈与栈帧的关系：调用链就是入栈出栈的过程

虚拟机栈和程序计数器一样，也是线程私有的，生命周期与线程相同。线程在创建时就会分配一个虚拟机栈，用来存放这个线程执行方法时的各种数据。

这里要区分两个层级的概念：虚拟机栈是整个线程的后进先出结构；栈帧是方法调用时压入栈里的一个单元。一个线程可能连续调用多个方法，每调用一个方法就压入一个栈帧，方法返回则栈帧出栈。栈帧永远只属于当前正在执行的那个方法吗？不是，压在最顶上的栈帧才是当前正在执行的方法，下面的栈帧是等待外层方法继续执行的。

举个例子：main()方法调用methodA()，methodA()再调用methodB()。在methodB()正在执行时，栈从底到顶是：main方法栈帧、methodA方法栈帧、methodB方法栈帧。methodB()执行完返回后，它的栈帧被弹出，栈顶变成methodA的栈帧。

一个栈帧里装的东西不少，主要包括四部分：

• 局部变量表
• 操作数栈
• 动态链接
• 方法返回地址

HotSpot规范里还有附加信息，但初学阶段把这四部分理解透就够了。下面一个个拆开看。

3.2 局部变量表：Slot复用、this引用与16GB大对象的坑

局部变量表在编译期就已经确定大小了，存放的是方法里的局部变量。它以“变量槽（Slot）”为最小单位，一个Slot可以存下boolean、byte、char、short、int、float、引用类型和returnAddress。64位长度的long和double占两个连续的Slot。

补充三个容易踩坑的细节：

第一，实例方法的第0个Slot一定是this。静态方法没有this，所以索引从0开始就是第一个参数；实例方法里，this占slot 0，形参从slot 1开始，之后才是方法内部的局部变量。所以在实例方法里使用this，其实本质上是读取局部变量表里的第一个变量。

第二，Slot是可以复用的。只要局部变量的作用域结束了，它占用的Slot就可以被后面的局部变量复用。这个机制本身是为了节省栈帧空间，但它和垃圾回收有微妙关系。看下面这段代码：

public static void test() { byte[] data = new byte[10 * 1024 * 1024]; System.gc(); // 假设这里触发GC }

data的引用在局部变量表里，作用域覆盖到方法结束。如果后面没有新变量复用data的Slot，那么GC时依然会认为这个引用是可达的，那10MB数组就不会被回收，哪怕你后面根本不再用data了。这也是为什么很多性能敏感代码里写data = null来主动切断引用。

但是注意，如果代码改成这样：

public static void test() { { byte[] data = new byte[10 * 1024 * 1024]; } int a = 1; // a复用了data的Slot System.gc(); }

变量a声明时可能复用data原来的Slot，于是data引用被覆盖，数组就可以被回收。实际操作中JIT的优化行为会让情况更复杂，但理解Slot复用对阅读别人的优化代码很有帮助。

第三，栈里的引用和堆里的对象是两回事。很多人一看到“栈”就以为对象全放栈上跑得快，其实局部变量表里放的只是引用，真正的对象实体还是分配到堆里的。比如byte[] data = new byte[16 * 1024 * 1024]，data这个引用只占局部变量表一个Slot，16MB的数组在堆里。想用逃逸分析之类的技术把对象放栈上，是另一套复杂度，不属于入门阶段需要掌握的内容。

3.3 操作数栈：一条加法指令是怎么一步步算出来的

操作数栈又叫表达式栈，是栈帧里的另一个核心区域。说人话，它就是JVM做计算时的“草稿纸”。所有的算术运算、方法调用参数传递、返回值传递，都要在操作数栈上临时倒腾。

例如有如下代码：

int x = 8; int y = 3; int z = x + y;

编译成字节码大致是这样：

bipush 8 istore_1 iconst_3 istore_2 iload_1 iload_2 iadd istore_3

执行过程如下：

1. bipush 8：把常量8压入操作数栈。
2. istore_1：从栈顶弹出8，存入局部变量表槽位1，也就是x。
3. iconst_3：把常量3压入操作数栈。
4. istore_2：弹出3，存入槽位2，也就是y。
5. iload_1：把x的值8压入操作数栈。
6. iload_2：把y的值3压入操作数栈。此时栈里从下到上是8、3。
7. iadd：弹出栈顶两个int值3和8，相加后把结果11压回栈顶。
8. istore_3：弹出11，存入槽位3，也就是z。

注意iadd执行时，不是把x和y从局部变量表里直接取出来，而是要先把值压到操作数栈顶，才能执行加法。这就是“栈式指令集”的特点。JVM大部分指令都是基于操作数栈工作的，字节码里也预先把操作数栈最大深度算好了，存放在方法Code属性的max_stack字段里。

我在初学的时候总觉得这很绕，因为实际写Java不需要关心这么细。但用javap反编译过一次之后我明白了：理解操作数栈，其实是理解字节码执行的一条必经之路。后面学ASM字节码插桩、学动态代理的底层原理，都会遇到类似指令。

3.4 动态链接和返回地址：栈帧里的“幕后管理员”

栈帧里的另外两部分，很多新手容易忽略，但它们负责的是方法之间如何配合。

动态链接（指向运行时常量池中该类的符号引用）。Java里的方法调用，字节码中存的是指向运行时常量池的符号引用，而不是直接的内存地址。每个栈帧里都有一个指向运行时常量池的引用，用来支持调用方法时把符号引用解析为直接引用。

比如methodA()里调用了methodB()，编译出来的字节码里可能是一个invokevirtual指令，指令的操作数指向常量池第20项，这一项是“methodB”的符号引用。真正执行时，JVM要通过这个栈帧里的动态链接找到运行时常量池，再把符号引用解析成实际方法入口地址。这种延迟解析是Java支持多态、动态绑定的底层基础。

方法返回地址。方法正常返回时，需要回到调用者的下一条指令继续执行，这个位置由程序计数器记录；如果方法中途抛出异常且未被捕获，也会导致方法退出，这叫异常返回。不管是正常返回还是异常返回，当前栈帧都要出栈，控制权交还调用者。

这里不要搞混两个概念：方法返回地址在栈帧里保存的是调用者的“返回线索”，而当前线程下一条具体执行哪条指令，最终由程序计数器决定。栈帧弹出后，程序计数器会恢复到调用方法当时的状态。

3.5 StackOverflowError与OutOfMemoryError：两种故障的边界在哪

虚拟机栈有大小限制，可以通过-Xss参数来设置。HotSpot 64位JDK的默认值通常是1MB左右，但这个值在不同平台有差异。栈相关的异常有两种，面试经常放在一起问：

• StackOverflowError：线程请求的栈深度大于虚拟机允许的最大深度。最常见的触发方式就是无限递归。每次方法调用都压入一个新栈帧，栈空间耗尽后就会抛出StackOverflowError。
• OutOfMemoryError：虚拟机栈在动态扩展时无法申请到足够的内存。常见场景是一个进程疯狂创建线程，每个线程默认分配1MB栈，很快耗尽整个进程的内存空间。

两种异常本质区别是：SOF是单个线程的栈已经满到不能再压帧；OOM是整个JVM都申请不到内存来给新线程扩展栈。形象一点说，SOF像一个杯子已经倒满水再倒就溢出来；OOM是整个桶都没水了，新杯子都装不满。

4. 多动手：把栈压爆、看字节码、用jstack查线程

4.1 用一段递归代码复现StackOverflowError，并测出默认栈深度

常见问题与排查技巧实录

4.1.2 用递归复现StackOverflowError并测量深度

写一段最朴素的递归代码：

public class StackOverflowDemo { private static int depth; public static void main(String[] args) { try { recursion(); } catch (StackOverflowError e) { System.out.println("栈溢出时递归深度: " + depth); } } private static void recursion() { depth++; recursion(); } }

运行后，控制台会输出类似：

栈溢出时递归深度: 9472

我测试的机器默认栈大小大约是1MB，跑到接近一万层的递归就触顶了。注意catch位置要放在最外层调用处，如果放在递归方法内部catch，栈已经满了之后你还想在catch块里继续执行代码，反而可能再次触发栈溢出。

这种实验对初学非常有价值：它让你直观感受到每一个方法调用都会占用真实的栈内存，而不是无限扩展的虚拟空间。很多人第一次运行看到顶到1万层就报错，会惊讶于栈的容量如此“有限”——这个印象会帮助你以后写递归时多想想深度问题。

4.2 调整-Xss参数，观察栈深度变化

Java启动参数-Xss可以控制每个线程栈的大小，单位是字节，也支持k、m后缀。在IDEA的VM options里加上：

-Xss256k

再次运行上面的代码，输出会明显变小，我这边大约只有两千多层的递归深度。把参数调大：

-Xss2m

递归深度又明显增加，大约能跑到一万九千多层。

这说明两件事：

• 栈深度和栈大小是正相关的，栈越大，能压入的栈帧越多。
• 栈帧大小和代码本身的局部变量数量有关，方法里局部变量越多，一个栈帧占用的空间就越大，同样栈大小下能压入的帧数就越少。

再做一个对比实验：让递归方法里多声明几个局部变量数组引用，甚至直接在方法里声明一个比较大的基本类型数组。你会发现同样的-Xss256k，递归深度低了。这些细节是只背理论永远感受不到的。

4.3 用javap反编译字节码，亲眼看操作数栈的工作

在IDEA里写好一个类：

public class ComputeDemo { public int compute(int a, int b) { int c = a + b; return c; } }

编译后进入target/classes目录，执行：

javap -c ComputeDemo

你会看到类似这样的字节码输出：

public int compute(int, int); Code: 0: iload_1 1: iload_2 2: iadd 3: istore_3 4: iload_3 5: ireturn

这一段正好对应：把参数a压栈、b压栈、相加、把结果存入局部变量表第三个槽位、再加载返回。如果你的IDE装了jclasslib插件，还能看到每个方法Code属性里的max_stack和max_locals值。亲手看一遍之后，你对3.3里“操作数栈是草稿纸”的理解会彻底落地。

4.4 用jps加jstack定位线上线程栈问题

虚拟机栈在排查线上问题时最常用的工具组合是jps和jstack。

先启动一个Java服务，然后在命令行输入：

jps -l

输出里能看到Java进程的PID和主类名。用jstack查看线程栈快照：

jstack <PID> > thread_dump.txt

打开thread_dump.txt，能看到大量线程的栈信息：

• 线程名、是否守护线程、优先级、线程Id。
• 当前状态：RUNNABLE、BLOCKED、WAITING、TIMED_WAITING等。
• 调用栈：从当前正在执行的地方一直回溯到最外层方法。

实际排查死锁时，jstack输出的末尾通常会有死锁检测，类似：

Found one Java-level deadlock: ============================= "Thread-1": waiting to lock monitor 0x... ... which is held by "Thread-0"

这套操作一旦上手，你对“虚拟机栈”的理解就不是书上的概念，而是你能真正用来定位问题的能力。排查死锁的步骤建议收藏：先用jps找PID，再用jstack导出线程栈，最后看栈顶和锁的持有关系。

5. 新手常踩的坑和热搜里那些报错，真正原因是什么

5.1 “Error invoking method. Failed to launch JVM”：不是JVM源码问题，是启动参数打架

不少eclipse或IDE工具用户在启动时遇到过这个报错：

Error invoking method. Failed to launch JVM

我当年第一次看到这个错误时以为Java坏掉了，后来排查发现九成原因是启动参数里配置的内存超过了系统可分配内存。工具启动时通常会读eclipse.ini或者IDE的vmoptions文件，里面可能写着-Xmx2048m，但机器实际可用内存只有1.5GB，或者你是32位Java进程，地址空间根本分配不出2GB的连续内存。

常见的处理顺序：

1. 查看本机物理内存和空闲内存，确认-Xmx值是否合理。
2. 如果机器是32位系统或JDK是32位版本，把-Xmx调到1024m以下再试。
3. 检查环境变量JAVA_HOME是否指向了正确的JDK路径，路径不对会导致找不到jvm.dll。
4. 如果是容器环境，还要确认JVM读取到的可用CPU和内存是否被cgroup限制。

这里有个容易忽略的点：报错里的“Failed to launch JVM”并不是JVM内存结构某个区域抛出来的错，而是JVM进程在启动阶段直接失败。它可能发生在任何运行时数据区创建之前。所以不能用“堆溢出”或“栈溢出”的思路去套，要从启动参数和环境变量入手。

5.2 “无法编译为 JVM 目标 17 配置的模块……”：编译期问题别往运行时内存上赖

在热搜词里那串很长的问题：

java: 无法编译为 jvm 目标 17 配置的模块 'jeecg-boot-base-core': 指定的回退 s

这种报错十有八九出现在Maven/Gradle多模块项目编译时，核心原因是当前使用的JDK版本和Maven编译器插件指定的source/target/release版本不一致。比如pom里写了：

<properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties>

但你本机JAVA_HOME指向的是JDK 8，javac在编译时想把类编译成Java 17的class文件，结果当前的编译工具链根本不懂Java 17的字节码，于是抛出这类提示。

处理办法：

1. 确认本机安装了JDK 17或更高版本。
2. 把JAVA_HOME环境变量切到对应JDK路径。
3. IDEA里还要检查Project SDK和Java Compiler的Target bytecode version是否一致。
4. 在pom.xml里最好显式加maven-compiler-plugin的release配置，避免IDE和命令行行为不一致。

记住一点：这是编译期的错误，跟JVM运行时的内存结构没有直接关系。但它也和JVM相关，容易让新人混淆“JDK编译Java代码”和“JVM运行class文件”这两个阶段。

5.3 几个自己配置时最容易忽略的地方

日常开发JVM参数的配置里有几个容易忽略的细节，我自己踩过坑，写出来供参考。

第一，-Xss不是越大越好。栈内存是从操作系统那申请的，线程栈大小改大了，能创建的线程数量就变少。一个线程栈从1MB增加到2MB，相同物理内存下支持的线程并发数就腰斩。不建议在Web应用里盲目调大-Xss，除非你确认业务有深层递归需求。

第二，区分IDE的配置和运行时配置。在IDEA的Settings里改的VM options只对IDE启动项目时的进程生效；用命令行java -jar启动时，必须自己在启动脚本里写-Xss。生产环境排查栈问题时，先确认启动脚本里有没有显式配置过Xss。

第三，栈大小影响JIT优化。有个别框架会在编译期生成长方法，如果栈太小可能在编译器线程或特殊字节码处理时报SOF。这类问题非常隐蔽，排查时要把-Xss调大作为备选方案之一。

第四，不是所有StackOverflowError都是无限递归。正则表达式回溯过深、JSON序列化循环引用造成的递归、MyBatis等框架嵌套调用过深，都可能造成SOF。遇到StackOverflowError先jstack看调用栈，再决定是改代码逻辑还是调栈大小。

6. 高频面试题速答模板与后续学习路线

6.1 两道高频题，怎么答才算“稳准狠”

面试时最常遇到的两个问题是：JVM内存结构有哪些区域、哪些线程私有哪些线程共享。但很多人答完之后面试官会追一句“你说说虚拟机栈的组成”。这时候如果在第一层“背过”，第二层接不上，印象分会掉。

推荐两步答题法。

第一步先给全貌：“JVM内存分六大区域，程序计数器、虚拟机栈、本地方法栈是线程私有的；堆、方法区、运行时常量池是线程共享的。”

第二步再聚焦：“虚拟机栈里每个方法调用对应一个栈帧，栈帧里有局部变量表、操作数栈、动态链接、方法返回地址。局部变量表以Slot为单位存变量，long和double占两个Slot；操作数栈是字节码指令的表达式计算空间。方法调用层数超过-Xss设置的栈容量时会抛StackOverflowError，线程启动分配不到栈内存则抛OutOfMemoryError。”

如果面试官继续问“StackOverflowError和OutOfMemoryError为什么不一样”，你就把第3.5节里“杯子与水桶”的类比说出来，同时补充：SOF是单个线程栈深度超过容量，OOM是整个JVM内存申请失败。这块内容能答到这一层，已经超过绝大多数候选人了。

除了面试题，平时查阅资料时要注意区分三个相似概念：

很多初学Java的人把JDK和JRE混在一起，学JVM时也会绕晕。记住JDK能开发能运行，JRE只能运行，JVM是运行的核心，三者关系就顺了。

6.2 这个系列后续怎么学：内存结构part02该看什么

这篇文章算是“JVM入门学习”系列的第01篇，把程序计数器和虚拟机栈讲完。后续part02最应该补的是本地方法栈和堆。

本地方法栈在HotSpot里和虚拟机栈合二为一，理解难度不大，知道它服务于Native方法就可以。

堆就重要得多。几乎所有对象都在堆上分配，垃圾回收的年轻代、老年代、Eden、Survivor都在堆里。学堆的时候建议先搞懂三件事：

• 对象创建过程：类加载检查、分配内存、初始化零值、设置对象头、执行构造方法。
• 对象布局：对象头、实例数据、对齐填充。
• 如何判断对象可回收：引用计数法和可达性分析，以及GC Roots到底有哪些。

part03再学方法区和运行时常量池，part04进入垃圾收集算法和收集器，part05可以开始看类加载机制。整个路线走下来，前面的程序计数器和虚拟机栈就是地基。

学习材料上，我个人的建议是：官方《Java虚拟机规范》作为查证工具书，周志明的《深入理解Java虚拟机》适合精读前几章，但不要在入门阶段直接阅读规范的英文原文，那会打击信心。更好的方式是我在这篇里用的路子——先跑代码、再看工具输出，把原理和应用场景联系起来。遇到报错时耐心看异常栈，配合jstack反复验证，几个月后你会发现自己已经能独立排查很多JVM层面的问题了。

最后再分享一点个人体会：很多Java开发者工作了两三年，写的代码不少，但一遇到栈溢出、内存报错就只会重启。其实JVM并没有那么玄，它也只是个运行环境，有明确的边界和规则。初学阶段最重要的不是记住所有参数和细节，而是建立“每个方法调用都会分配一块内存”“对象和引用是不同的东西”“线程之间数据是隔离的”这三个基本直觉。程序计数器和虚拟机栈恰好是建立这种直觉成本最低的两个区域。把这篇文章里的实验亲手跑一遍，比读十篇理论文章都管用。