把JVM理解成一家餐厅：内存与垃圾回收不再难懂

前阵子面试了一个五年经验的Java开发，前几个问题都答得不错。我问“你说说JVM是什么”，他流畅地背了一遍：Java虚拟机，负责加载字节码、管理内存、执行垃圾回收。我再追问“那你觉得JVM最像日常生活中的什么东西？”，他沉默了。

这个反应我见得太多了。JVM这个词几乎所有Java开发都不陌生，但要说清楚它到底在做什么，为什么需要堆、栈、方法区，为什么要有垃圾回收，很多人是懵的。面试题背了一堆，遇到线上OOM、GC停顿、JVM崩溃日志还是不知道从何下手。

这篇文章我想换个角度，把JVM理解成一家餐厅。这个类比我用了很多年，给新人讲、给非技术同事讲、给面试前临时抱佛脚的朋友讲，效果都还不错。它不能覆盖JVM的全部细节，但能帮你建立一张全景地图：知道什么东西在哪个位置、负责什么工作、它们之间怎么配合。有了这份地图，再去啃JVM相关的书、看JVM面试题、处理线上JVM问题，骨架就有了。

适合谁看：准备Java面试的、被JVM报错搞烦的、想系统理解JVM但看了几本书还是云里雾里的朋友。我会尽量用大白话讲，但毕竟涉及的是技术，该有的术语和参数我也会写清楚，方便你拿到真实场景里用。

1. 为什么说JVM更像一家餐厅，而不是一台机器

“虚拟机”这三个字，其实是个很大的误导。

很多人第一次听到JVM，脑子里浮现的是一台被软件模拟出来的“假电脑”：有虚拟CPU、虚拟内存、虚拟硬盘。这个想象不能说错，但特别容易把你带偏。因为一旦把JVM想象成模拟电脑，你就会不自觉地去想指令集、寄存器、内存地址，然后陷入“这跟我了解的操作系统有什么区别”的困惑里。

我自己理解JVM的转折点，恰恰是放弃“它是台机器”这个念头，改用“它是个组织”来想。

1.1 从输入到输出：一家餐厅到底在做什么

餐厅做的事情，本质上是这样的：你递过去一本菜谱（源文件），老板派人去采购食材（类加载），后厨按照菜谱把食材做成菜（执行引擎），前台上菜给你（输出结果）。而在这整个过程中，餐厅还要管采购预算（内存分配）、食材保鲜（内存回收）、厨师排班（线程调度）、处理客人投诉（异常处理）。

JVM做的事情，一模一样。

你写好的Java源代码，先被javac编译成.class文件，也就是字节码。字节码是什么？它就是一份“标准菜谱”，不依赖任何具体餐厅。这份菜谱拿到任何一家安装了JVM的餐厅，都能被认出来、做出来。

JVM拿到这份菜谱后，先由类加载器把菜品相关的内容读进来——就好比厨房确认菜谱、清点食材。然后把食材放进仓库（堆）、把厨师安排到各自工位（虚拟机栈）、把做菜需要的规章制度贴在墙上（方法区），最后由执行引擎这套“厨师班子”把菜一份份做出来。

这个链条走一遍，你对JVM的定位就清楚了：它不是一个孤立的技术名词，而是一整套“从字节码到运行结果”的加工流水线。

1.2 餐厅地图：JVM内部成员对照表

我把JVM主要的内部组件和餐厅角色做了个对照表，你先把这张表格记住，后面的章节基本就是围绕它展开的：

这张表里的每一行，后面都会展开讲。你可以把它当成整篇文章的目录。

1.3 这个类比为什么有效

我总结过原因：JVM本质上是一个“资源协调系统”。它要同时处理很多事情——多个线程并发执行、内存频繁分配和回收、代码被反复解释执行的性能优化。这些问题的共性是：资源有限、需求动态、还要保持整体稳定。而餐厅，恰好也是一个资源协调系统：座位有限、食材会过期、客人络绎不绝、后厨还要保证出菜速度。

所以，当你面对“为什么JVM要分堆和栈”“为什么要垃圾回收”“为什么要JIT编译”这类问题时，先想一想餐厅是怎么解决的：座位满了要排队等位（线程阻塞）、食材囤多了会坏（内存浪费）、客人点的菜反复出现就该写成标准流程（热点代码编译）。答案往往就藏在生活逻辑里。

不过类比的尽头也要说清楚：JVM是软件，它有一个明确规范的执行模型——Java虚拟机规范。餐厅是一个开放的人文组织，没有一本规范能规定“服务员必须怎么做”。所以类比是用来理解方向的，具体细节还要以规范为准。

2. JDK、JRE、JVM：总部、餐厅和灶台

面试里有一个高频题：JDK、JRE、JVM三者的区别是什么？很多人能背出“JDK包含JRE，JRE包含JVM”，但一旦追问“那我Docker部署Java程序，到底装哪个”，又犹豫了。

用餐厅类比，这句话可以变成：餐饮集团总部包含一家正常营业的餐厅，这家餐厅包含一座后厨的灶台。

2.1 三者的包含关系

展开一点说：

• JVM（Java Virtual Machine）：就是那个灶台加炒锅。它只负责“做菜”——加载字节码、执行指令、管理内存。它不是一个完整的运行环境，因为做菜还需要菜谱、还需要配菜台。

• JRE（Java Runtime Environment）：是一家正在营业的餐厅。它包含了灶台（JVM），也包含了菜谱库（Java类库，如java.util、java.io这些），还有必要的服务流程。只要你运行别人写好的Java程序，“开一家这样的餐厅”就够了。

• JDK（Java Development Kit）：是餐饮集团总部。它除了包含餐厅（JRE），还包含菜品研发中心（javac编译器）、质量检测室（各种调试工具），以及给厨师做培训用的教材（javadoc等）。

用集合关系写就是：JDK ⊃ JRE ⊃ JVM。

2.2 面试官真正想问的是什么

面试官问“JDK和JRE的区别”，表面考包含关系，深一层是考“你知不知道Java程序是怎么从源码变成可运行程序的”。你顺着这条线答，得分点就出来了：

1. 源文件(.java)经过JDK中的javac编译成字节码(.class)。
2. 字节码需要JRE这个运行时环境来解释/执行。
3. 实际执行字节码的，是JRE内嵌的JVM。
4. 因此，只运行Java程序装JRE就可以；要开发、编译、调试，才需要安装完整的JDK。

这里我建议大家记一个细节：现在很多云服务器、Docker镜像都直接装JDK，也有很多人只装JRE，但JRE在较新版本里也有变化。JDK 9开始Oracle不再提供独立的“服务器版JRE”安装包，而是通过jlink工具按需裁剪JRE。也就是说，“装JRE”这个动作，在JDK 9以后更多被“用jlink定制一个最小运行镜像”替代。

2.3 Docker部署时到底装什么

这个问题我在技术社区看到过很多次，顺带展开。用Docker部署Java程序，很多人直接拿一个带JDK的基础镜像build，图省事。但生产环境的话，能小则小：

• 跑一个Spring Boot应用，其实只需要JRE。
• 用jlink --module-path $JAVA_HOME/jmods --add-modules java.base,java.sql,java.naming --output /opt/jre这种方式定制一个精简JRE，可以把虚拟磁盘占用从几百MB降到几十MB。
• 基础镜像也可以选带JRE的发行版，比如eclipse-temurin:17-jre或amazoncorretto:17-alpine-jre。

网上很多镜像动不动1GB+，大部分体积都是JDK自带的编译器、调试器，运行期根本用不上。这就好比你的餐厅明明只是营业，却把集团总部的研发实验室、培训教室全部塞进营业面积里，很浪费。

当然，如果你需要在容器里做热部署、跑诊断命令（比如jcmd、jstack），那还是得装完整JDK。取舍的标准很简单：你的“餐厅”是否需要“研发功能”。

3. 内存不神秘：JVM各个区域就是餐厅的各个功能区

JVM面试题里出现频率最高的，应该就是内存模型。这一块我不打算罗列官方定义，而是带你“走进餐厅”，看看每个区域到底放什么、为什么放那。

3.1 程序计数器（Program Counter Register）：传菜员手里的单子

程序计数器是JVM里一块非常小的内存，线程私有的。

它的作用用一句话说：记录当前线程正在执行哪一条字节码指令。多线程切换的时候，CPU把执行权从线程A交给线程B，过一会儿再切回A。如果没有“刚才做到哪一步”的记录，线程A回来就不知道自己的菜做到哪了。程序计数器就好比传菜员手里的单子，记录着他这份菜送到了几号桌、送到哪一步了。

这个区域是JVM规范里唯一没有规定OOM（OutOfMemoryError）的地方。因为它的空间占用是极小且固定的，你不需要为它操心。

3.2 虚拟机栈（Java Virtual Machine Stack）：每个厨师的工位

栈是另一个线程私有区域，对应每个厨师（线程）自己的工位。一次方法调用，对应一个栈帧，你可以把它理解成“做一道菜的完整操作流程”：需要哪些食材（局部变量表）、做到哪一步了（操作数栈）、万一要回锅该找谁（动态链接）、做完之后传给谁（方法出口）。

一个线程执行了很多方法，栈里就会压入很多栈帧。方法嵌套调用太深，比如递归没有终止条件，栈帧就会一直往工位上叠，把工位占满，这时候就会报StackOverflowError。这跟你把一堆菜板、调料、食材全堆到一个厨师操作台上，最后连炒锅都放不下的场景，是一样的。

新手比较容易混淆的是：栈里的局部变量，存的到底是对象本身还是对象的引用？其实栈里存的是基本类型的值，或者引用类型的一个引用（说白了就是一个“指向仓库货架的编号”），而真正的对象是放在堆里的。这个细节面试也常考，记牢了。

3.3 堆（Heap）：全餐厅最大的食材仓库

堆是JVM内存里最大的一块，也是GC（垃圾回收）的主战场。几乎所有通过new创建出来的对象都存放在这里。

你既然是开餐厅的，就要接受一个现实：食材仓库一定是全餐厅最大的区域，因为有的菜要现做现卖（朝生夕灭的对象），有的菜要炖很久（存活时间长的对象）。所以JVM又把堆细分为新生代和老年代：

• 新生代：存放“新采购的食材”，对象刚被new出来，大多活不长久，很快就会被回收。
• 老年代：存放“熬过了多次GC的对象”，比如Spring容器里的单例Bean、连接池对象，它们生命周期长，就像餐厅里的老卤，越熬越有味道。

新生代内部又分了Eden区和两个Survivor区（S0、S1）。对象分配先走Eden，Eden满了触发MinorGC，把还活着的对象挪到Survivor区，反复几次还在，就晋升到老年代。这套机制背后的目的很简单：把大部分短命对象在新生代就处理掉，避免全堆扫描，让GC停顿时间更短。

顺便说一个常见误解：堆内存越大越好？不是。堆设得太大，GC时扫描范围也大，单次停顿时间会变长；堆设得太小，对象频繁触发GC，吞吐量下降。调堆大小是一个平衡，不是数字越大越牛。

3.4 方法区/元空间（Method Area/Metaspace）：餐厅的菜谱库和规章墙

方法区存放类的结构信息：类的字段、方法定义、常量、静态变量，还有JIT编译后的代码缓存。用餐厅类比，它就是贴在厨房墙上的菜谱大全和规章制度：什么菜用什么料、按什么步骤做、有哪些禁忌，全部写在这。

这里有个非常重要的演进：JDK 8之前，方法区叫“永久代”（PermGen），在JVM堆内存里。JDK 8开始，永久代被移除，方法区改叫“元空间”（Metaspace），并且“搬出了餐厅”，使用本地内存。

为什么要搬？因为原先放在堆里的永久代，大小受-XX:MaxPermSize限制，类加载很多的应用很容易OutOfMemoryError: PermGen space。就好比你餐厅面积有限，但菜谱年年增加，贴满整面墙也不够用。搬去本地内存后，元空间默认不受上限约束（实际上受本机物理内存限制），由操作系统管，就不再容易因为“墙贴不下”而崩溃了。

3.5 本地方法栈（Native Method Stack）：外聘厨师的工作台

Java程序有时候要调用C/C++写的本地方法，比如Java NIO底层的一些操作、Java调操作系统API。这些方法不是在JVM内部“做标准菜”，而是请外面的“本地大厨”来做。本地方法栈，就是这些外聘厨师的操作台。

大多数应用不太会直接写本地方法，但你用的框架底层可能已经用到了。知道它的存在，面试被问到“JVM内存区域有哪些”时，别漏掉这块就行。

4. 垃圾回收：定时打扫餐厅，G1是分区保洁

垃圾回收可能是JVM里劝退感最强的主题。引用计数、可达性分析、GCRoots、复制算法、标记清除、标记整理、G1、ZGC……名词多得能绕晕人。我们还是回到餐厅，用“谁在打扫、怎么判断该扔、怎么高效打扫”来串起来。

4.1 先判断：这份食材到底还能不能用

GC要回收一个对象，先要判断它是不是“垃圾”。最朴素的想法是引用计数：每个对象记一个数，有几个地方引用它，引用清零就回收。但这个方法有著名的缺陷——循环引用。A引用了B，B也引用了A，但外部已经没有任何对象引用它们俩了。引用计数算下来，A和B互相“觉得对方还被用到”，计数永远不会归零，就成了永远占着仓库不放的僵尸食材。

JVM用的是可达性分析（GC Roots Tracing）。它从一组被称为“GC Roots”的根节点出发，沿着引用链往下找。能被找到的对象视为“活着的客人”，找不到的，就是没人认领的废弃食材，可以清理。

GC Roots包括：虚拟机栈里的引用、静态变量引用的对象、JNI引用的对象等。你可以理解为：无论从哪个活着的厨师（线程）手里，还是从墙上（方法区）的号令，都找不到这个对象，那它确实没用了。

4.2 分代回收：新菜区和老汤区

判断完哪些能扔之后，接下来是“怎么高效地扔”。

如果不分代，每次GC都要扫描整个堆，餐厅每次大扫除都要把所有房间翻一遍，效率很低。分代收集就是给食材按“新鲜程度”分区管理：

• 新生代里的对象大多朝生夕死，用复制算法。把Eden区和Survivor区里还活着的对象，一次性复制到另一个Survivor区，然后整块清空原来区域。存活对象少，复制成本低，效率高。
• 老年代里的对象存活率高，用标记-清除或标记-整理。标记一片区域的垃圾，直接清掉；或者把存活对象往一端移动，避免内存碎片化。

有了分代，餐厅保洁就变成了：每天重点清理新菜区（新生代）的临时囤货，老汤区（老年代）偶尔大扫除即可。这比每天把整个仓库翻一遍高效得多。

4.3 从CMS到G1：分区保洁、垃圾优先

JVM发展到今天，垃圾收集器也换了好几代。逐个讲会没完没了，我挑你一定会碰到的一个讲：G1。

G1之前，CMS是主流。CMS主打“并发收集，减少停顿”，但有个很头疼的毛病：它用标记-清除算法，会产生大量内存碎片。碎片多了，大对象分配不下了，就得触发Full GC，反而带来更长的停顿。就像是餐厅用“只清理垃圾、不动家具”的方式搞卫生，垃圾清走了，但餐桌摆位东一块西一块，最后大桌客人来了坐不下，还得关门重新排一遍。

G1的思路完全不同。它不再把堆分成固定的新生代、老年代两大块，而是把整个堆分成一个个大小相等的Region（区域）。新生代、老年代不再是物理上连续的区域，而是一组Region的集合。

这个设计用餐厅类比最直观：你家餐厅不是开放大平层，而是隔成了很多小包间（Region）。G1保洁员心里有本账，知道哪些包间垃圾最多。每次GC，它优先处理垃圾最多的那些包间（这就是G1名字的由来——Garbage First，垃圾优先）。这样一来，你可以通过-XX:MaxGCPauseMillis设定期望的停顿时间，比如200毫秒，G1会在这个约束下尽量多回收垃圾。

现在新版本的JDK（JDK 9之后）默认收集器就是G1，很多团队调优也都是围绕着G1的参数在调。你只要理解了“分区保洁、垃圾优先”这八个字，G1的核心思想就抓住了。

4.4 关于调优的一个真实提醒

我见过不少同学，一遇到GC问题就盲目加堆内存，以为“堆越大GC越少”。实际可能正好相反。

有一个业务，把-Xmx从2G调到8G，结果GC次数是少了，但每次GC停顿时间翻了一倍，请求超时率更高了。后来我们把重心放在“减少对象的创建”“调整新生代比例”“设置合理的G1目标停顿时间”上，反而稳定了。

调GC最忌讳“头痛医头”。GC是结果，不是病根。病根通常是代码里创建了过多不必要的对象、大对象直接进了老年代、或者某段逻辑持有对象时间过长。先把代码层面的问题清理掉，再考虑调GC参数，顺序不能反。

5. JVM参数不是玄学：那些高频参数到底在调什么

JVM相关的热搜词里，“jvm参数 -xx:compilethreshold”这个我特别有印象，因为真的很多人搜。说明大家在网上看到了五花八门的参数，却不知道这些参数是干嘛的、怎么用。

5.1 先给参数分个类

JVM启动参数可以分为三类：

• 标准参数：以-开头，所有JVM实现都支持。比如-version、-cp。
• 非标准参数：以-X开头，特定JDK实现支持。比如-Xms、-Xmx、-Xmn。
• 高级参数：以-XX开头，属于内部参数，不稳定，不能指望在所有版本里行为一致。比如-XX:+UseG1GC。

其中-XX参数里，带+表示开启，带-表示关闭，后面接=表示赋值。比如`-XX:+Heap