深入理解JVM内存分配：从对象创建到GC回收的完整链路

1. 为什么JVM内存分配值得作为第一个攻坚目标

先别急着打开八股清单一条条背。很多人准备了三个月，问起来都能说出个大概，可一旦被追问细节就露馅，比如“对象到底分配在哪里”“为什么Java要分新生代老年代”“TLAB是什么”“栈上分配和逃逸分析有什么关系”。这些问题全部指向同一个源头：JVM内存分配。它是整个JVM知识树的根，GC、调优、内存泄漏排查、甚至并发编程里的可见性问题，全都长在这棵根上。

我说它最适合第一个梳理，原因有三个。第一，内存分配是高频面试题里最“客观”的部分，答案边界清晰：哪些区域是线程私有的、哪些是共享的、对象到底放哪儿、什么时候触发GC，这些都有标准答案，不像“你如何理解面向对象”这种主观题，背了也未必得分。第二，搞懂内存分配之后，再去看G1收集器、CMS、Full GC和OOM排查，你会发现那些看起来复杂的东西其实是顺理成章的结论，而不是孤立的知识点。第三，内存分配和实际工作直接挂钩——线上OOM、GC频繁、性能劣化，第一反应就是看堆、看分配速率、看各区域占用，这块基础不牢，排查问题连日志都看不懂。

另外，从面试策略上考虑，JVM内存分配是少数几个你可以“主动引导话题”的考点。面试官问“你了解JVM吗”，你如果能从内存分配讲起，把对象分配流程、内存区域职责、各种异常场景一条线讲清楚，后面基本是被你牵着走了。反过来，如果一上来就背GC算法，容易被追到很深的技术细节，一旦答不上来，印象分会掉得很明显。

我把这次梳理的目标定得很具体：用一条线把“对象从创建到销毁的完整过程”讲通。从字节码层面的new指令开始，到栈上分配、TLAB、Eden区、大对象、晋升老年代，再到GC和内存回收，一条链路串下来，里面涉及的每个名词、每个参数都能对上号。下面我按这条线展开，每个环节都附上我实际面试和排查问题时遇到的细节。

2. 面试官真正想听到的：六块区域的职责边界

很多人一上来就背“堆、栈、方法区”，但面试官问“JVM内存区域有哪些”的时候，真正的隐藏考点是你有没有理解“线程私有”和“线程共享”的划分逻辑，以及每个区域各自承担什么职责、什么情况下会抛异常。这比单纯列出名字重要得多。

2.1 线程私有的三块区域：程序计数器、虚拟机栈、本地方法栈

程序计数器是最容易被忽略的一块。它是当前线程所执行的字节码的行号指示器，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。这里有一个很刁钻的考点：如果线程执行的是一个Java方法，计数器记录的是正在执行的虚拟机字节码地址；如果是Native方法，计数器值为空（Undefined）。这也是唯一一个在Java虚拟机规范里没有规定任何OutOfMemoryError情况的区域，因为它的空间需求是确定的，不会随着程序运行自动增长。

虚拟机栈是真正的高频考点区。每个方法被执行的时候，JVM都会同步创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每个方法从调用到执行完毕的过程，对应一个栈帧在虚拟机栈里入栈到出栈的过程。你写一段递归代码把自己搞StackOverflowError，就是栈帧太多把栈空间塞满了。这个区域的异常有两种：线程请求的栈深度大于虚拟机允许的深度时抛StackOverflowError，栈扩展时无法申请到足够内存则抛OutOfMemoryError。面试被问“什么是StackOverflowError”，你要答的是这一层，而不是简单说“递归太深了”。

局部变量表里放的是八种基本数据类型、对象引用和returnAddress类型，编译期就确定了所需空间，所以局部变量表的大小在方法执行期间不会变。这一点也解释了为什么一个方法里定义了很多局部变量，不会动态影响栈帧内存大小——空间在编译期就规划好了。我面试过不少人，能说出栈帧存储的内容，但很少有人主动提到“局部变量表空间编译期确定”这个细节，提出来会是一个明显的加分项。

本地方法栈和虚拟机栈的作用类似，区别在于虚拟机栈为JVM执行Java方法服务，本地方法栈为Native方法服务。HotSpot虚拟机把这两者合二为一了，不同JVM实现可以有不同的做法，规范没做强制规定。这是一个拓宽知识面的点，说明你不仅看了八股，还知道规范是允许不同实现的。

2.2 线程共享的两块核心区域：堆和方法区

堆是JVM管理的最大一块内存，也是所有线程共享的。几乎所有对象实例以及数组都在这里分配内存（注意是“几乎所有”，不是“全部”——栈上分配、TLAB这些优化后面会详细讲）。堆也是垃圾收集器管理的主要区域，所以它还有一个名字叫“GC堆”。面试官如果问你“堆的分代”，你要知道的是：现代JVM基本都把堆划分为新生代（Young Generation）和老年代（Old Generation），新生代又细分为Eden区和两个Survivor区（from和to）。这个划分是为了更高效地回收内存——大量对象朝生夕灭，把不同存活周期的对象分开放，可以采用不同的回收策略。

很多人会忽略一个点：堆的大小是可扩展的，物理上不连续，逻辑上连续即可。在实现上可以用固定大小，也可以用可扩展的方式（当前主流的HotSpot虚拟机用的可扩展方式，通过-Xms初始堆、-Xmx最大堆来控制）。如果堆中没有内存完成实例分配，且堆也无法再扩展，就会抛出OutOfMemoryError。这个“无法再扩展”的细节其实对排查问题特别重要，我看过很多线上OOM案例，最后定位下来根本不是代码问题，而是堆的Xmx设得比物理机剩余内存还大，导致GC后的扩展失败。

方法区这块，JDK 8以前叫永久代（PermGen），JDK 8以后改成了元空间（Metaspace），根本区别在于：永久代用的是JVM内存，元空间用的是本地内存（Native Memory）。这是什么意思呢？看参数就能明白——PermGen时代的参数是-XX:MaxPermSize，Metaspace时代换成了-XX:MaxMetaspaceSize，而且默认情况下元空间大小只受本地内存限制。所以你会看到很多文章说“Metaspace OOM问题变少了，但实际上更隐蔽了”，因为它不再受堆大小限制，一旦类加载器泄漏导致类卸载不了，Metaspace会一直在本地内存里涨，直到把机器内存吃光。

方法区里最常考的是常量池位置变化：JDK 7把运行时常量池从永久代移到了堆，JDK 8干脆把整个永久代移除，类元信息放进了元空间。这个概念特别容易混，尤其是字符串常量池。面试题问“String s = new String("abc")创建了几个对象”，答案的底层逻辑就在这里：字面量"abc"如果之前没出现过，会在字符串常量池里创建一个对象，new String又会在堆上创建一个对象。你要是搞不清字符串常量池到底在堆里还是在方法区里，这道题必然答错。JDK 7以后字符串常量池在堆里，这个考点值得反复确认。

2.3 一个容易被忽略的区域问法：直接内存

直接内存（Direct Memory）不在Java虚拟机规范里定义，也不是运行时数据区的一部分。但它是一个高频加分的衍生考点，尤其是在讨论堆外内存、NIO、Netty这种高性能框架的时候。JDK 1.4引入的NIO类支持通过DirectByteBuffer分配直接内存，它通过native函数库直接在堆外分配内存，然后用一个存储在堆里的DirectByteBuffer对象作为这块内存的引用进行操作。好处是避免了在Java堆和Native堆之间来回复制数据，坏处是它不受堆大小控制，只受本机总内存（包括物理内存和swap区）的限制。

这就能解释一个经典线上问题：堆内存设置得很大，Xmx设了8G，可是跑着跑着机器内存被吃满了，用jmap查堆发现只用了3个G。原因往往就是某处用DirectByteBuffer或MapByteBuffer（文件映射）分配了堆外内存，这块“看不见”的内存不在堆统计范围内。排查方式是去看Reserved Code Cache、Metaspace、Direct Buffer等非堆区域。

3. Java对象的一生：从new到堆区的完整分配路径

说完了区域划分，我们可以把视角收回到一个对象上，跟着它走一遍从创建到回收的全过程。这是面试里“JVM内存分配”最核心的延伸题——面试官会问“一个对象是怎么分配内存的”，回答的颗粒度决定你的层次。

3.1 字节码层面：new指令发生了什么

写一行代码 User user = new User();，编译器生成的字节码序列大致是：

java复制// 假设类路径为 com/example/User
0: new           // 创建一个 User 对象引用，将其引用值压入操作数栈顶
3: dup           // 复制栈顶数值并将复制值压入栈顶（复制出来的引用用于后续构造函数调用）
4: invokespecial com/example/User.<init>:()V  // 调用实例初始化方法
7: astore_1      // 将栈顶引用值存入局部变量表的第1个槽位

注意第一步new只做了两件事：在堆中为对象分配内存，并将对象的引用压入栈。此时对象内存已经被清零（初始化为零值），但还没调用构造函数。紧跟其后的dup是为了复制一个引用出来传给构造函数——注意这是Java虚拟机指令设计的一个细节：构造函数执行之后会“吞掉”栈顶引用，如果之前不复制一份，后面就没有引用可以用来赋值给局部变量了。

这个字节码层面的理解有什么用？至少能回答两个高频问题：第一，“new一个对象的过程是什么”——答案顺序是加载类、分配内存、内存空间零值初始化、设置对象头、执行init方法；第二，“构造函数里抛异常，对象会释放吗”——会释放，因为分配的内存还没被引用，GC会回收。很多把并发和高性能讲得头头是道的候选人，反而在这两道基础题上栽了。

3.2 内存分配的两大策略：指针碰撞与空闲列表

对象在堆中分配内存，具体怎么“分配”，取决于堆内存是否规整。指针碰撞（Bump the Pointer） 适用于堆内存规整的情况：已使用的内存放在一边，未使用的放在另一边，中间有一个分界指针。分配内存时只需要把指针向空闲方向移动一段与对象大小相等的距离。空闲列表（Free List） 适用于堆内存不规整的情况：已使用和未使用的内存交错在一起，虚拟机必须维护一个列表记录哪些内存块可用，分配时从列表中找到一块足够大的空间划分给对象，并更新列表记录。

这背后对应的是GC的整理策略。使用标记-整理算法的收集器（如Serial、Parallel），堆内存是规整的，所以可以采用指针碰撞；使用标记-清除算法的收集器（如CMS），堆内存不规整，只能采用空闲列表。G1是特例，它虽然是基于Region的复制整理，但由于每个Region内部不保证规整，用的是空闲列表。这个对应关系是八股里的经典考点，面试官只要听到你说“标记-清除”，大概率会追问一句“那它能用指针碰撞吗”，答不上来就可惜了。

3.3 并发分配的安全处理：CAS和TLAB

分配内存的动作在并发场景下不是一个安全操作——多个线程同时new对象，可能在同一个内存地址上发生竞争。JVM有两种处理方案：一种是对分配内存空间的动作进行同步处理（实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性），另一种是把内存分配的动作按照线程划分在不同的空间之中进行。后者就是TLAB（Thread Local Allocation Buffer）：每个线程在Eden区里预先分配一小块私有内存，线程在TLAB内分配对象不需要同步，只有TLAB用完并重新申请新的TLAB时才需要锁定。这个机制对性能影响非常大，尤其高并发场景，没有TLAB的话，每次new都要CAS，系统吞吐率会降低一个数量级。你可以通过-XX:UseTLAB参数开启，通过-XX:TLABSize手动指定TLAB大小（单位是KB）。

关于TLAB有几个面试追问的细节：第一，对象优先在TLAB上分配，但TLAB不是必须的，如果对象过大（比如超过TLAB剩余空间），会直接在Eden区分配；第二，TLAB空间中的内存浪费是允许的，JVM通过-XX:TLABWasteTargetPercent参数控制TLAB浪费的占比（默认是1%），如果分配对象后剩余空间小于这个比例，就直接放弃剩余空间，重新申请一个新的TLAB；第三，TLAB本身是一块Eden区的内存，所以TLAB中的对象最终还是会在新生代GC时被回收，并没有改变对象的存储位置。

3.4 对象的具体“去处”：Eden区、Survivor区、老年代

大多数情况下，对象优先在新生代的Eden区分配。当Eden区没有足够空间时，JVM会触发一次Minor GC（新生代回收），把存活对象移动到Survivor区（from区），并清空Eden和to区。这里有一个非常容易被误解的点：Minor GC不是只回收Eden区，而是回收整个新生代，包括Eden区和两个Survivor区。每次Minor GC后，Eden和from区存活的对象会转移到to区，然后from和to的角色互换。这样做的目的是：每次回收后总有一个Survivor是空的，用于存放下一次回收的存活对象。

对象从新生代进入老年代有几个条件，面试常考：

• 年龄阈值：对象在Survivor区每熬过一次Minor GC，年龄就加1，默认达到15岁（由-XX:MaxTenuringThreshold设置）就会被移动到老年代。
• 动态年龄判定：HotSpot并不是严格等到对象年龄达到MaxTenuringThreshold才晋升，而是在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半时，年龄大于或等于该年龄的对象就可以直接进入老年代。这个机制叫“动态年龄判定”，很多人不知道。
• 大对象直接进入老年代：通过-XX:PretenureSizeThreshold参数设置阈值，大于这个值的对象直接在老年代分配。这样做的目的是避免大对象在Eden区和两个Survivor区之间发生大量的内存复制（大对象复制成本高）。

我画不出来图，但你在梳理的时候可以走一遍这个流程：一个对象new出来，如果开启了TLAB，优先在TLAB分配；TLAB空间不足，去Eden区分配；Eden区空间不足，触发Minor GC；Minor GC后存活对象根据年龄规则进入Survivor或老年代；如果Survivor区装不下，会通过“分配担保机制”提前进入老年代；如果是大对象，直接进老年代。整条链路就是JVM内存分配的核心骨架。

4. 容易被忽略的提速机制：栈上分配与TLAB的真实作用

面试问到“Java对象一定在堆上分配吗”，标准答案是“不一定，JIT编译器通过逃逸分析之后，标量替换可以让对象在栈上分配”。这句话很多人背下来了，但问他“逃逸分析具体怎么工作”“什么样的对象可以栈上分配”“和TLAB有什么关系”，就开始犯迷糊。这一节我们把这几个点掰开讲清楚。

4.1 逃逸分析：哪些对象可以不上堆

逃逸分析的目的是判断对象的作用域是否超出了当前方法或当前线程。如果对象只在方法内部使用，没有“逃逸”出方法，那么这个对象就可以被优化为在栈上分配（前提是JVM开启了-XX:+DoEscapeAnalysis，默认开启）。对象不逃逸有两种情况：方法逃逸（对象被方法外部引用）和线程逃逸（对象被其他线程访问）。只有两个都不满足，才能做栈上分配。

栈上分配的本质是标量替换。什么意思呢？如果对象的字段可以被拆解开，JIT编译时就不实际创建这个对象，而是直接创建它的若干个被方法使用的成员变量来代替。比如一个Point类有两个int字段x和y，如果Point p = new Point(1, 2);没有逃逸，JIT可能直接替换成两个局部变量int x=1、int y=2，根本不在堆上分配内存。这就是为什么你在做基准测试的时候，短生命周期的小对象在开启逃逸分析的情况下性能极高——它压根没发生堆分配。

现实中哪些代码容易被标量替换？最常见的是循环内的局部对象、集合迭代的临时变量、以及工具类返回的小VO。举一个例子：

java复制public long test() {
    long sum = 0;
    for (int i = 0; i < 1_000_000; i++) {
        Point p = new Point(i, i + 1); // 这个 Point 不会逃逸出循环体
        sum += p.x + p.y;
    }
    return sum;
}

只要Point的字段是基本类型且没有对外部引用，JIT很可能把它标量替换成两个局部变量，从而避免一百万次堆分配。但注意：如果Point对象被放进集合里返回出去，或者被赋值给成员变量，逃逸分析就会失败，老老实实去堆上分配。

4.2 TLAB和栈上分配的边界在哪里

TLAB和栈上分配经常被人搞混，原因在于它们都是“减少堆分配压制”的手段，但层级完全不同。TLAB是线程在Eden区里的一块私有空间，里面分配的对象还在堆上，只是分配动作不涉及并发竞争；栈上分配是对象根本不在堆上，分配在栈帧的局部变量表里（通过标量替换）。

这两个机制的真实边界是：栈上分配依赖逃逸分析，而逃逸分析是JIT编译器在运行时做的优化，不是JVM规范强制要求的行为。不同的JVM实现、不同的JIT编译器（C1还是C2）对逃逸分析的激进程度不一样，而且JIT编译本身有“热点阈值”，方法要执行到一定次数才触发编译。所以讨论“对象一定在堆上吗”要加一个前提——在开启逃逸分析的HotSpot中，特定条件下可以栈上分配。这也解释了为什么八股题的标准答案那么简短，却很难在面试里回答圆满。

实战中，如果你要优化性能，不要指望靠栈上分配解决大问题。更实际的做法是把对象设计成不可变的小对象、用基本类型代替包装类型、避免在循环内创建大对象。栈上分配更多是JVM白送的福利，你不需要写特殊的代码去触发它，但可以留意自己的对象有没有逃逸，有的话调整代码结构让JIT更容易优化。

4.3 关于TLAB的一个实用参数组合

TLAB和-XX:PretenureSizeThreshold之间有一个微妙的关系。大对象（超过PretenureSizeThreshold的值）会绕过TLAB直接进老年代，这时TLAB的参数对它没有影响。这就产生了一个常见调优问题：为什么设置了-XX:TLABSize，Eden区的使用率还是上不去，Young GC依然频繁？ 很可能是因为你的业务里有大量大对象，它们根本没有在Eden区分配，直接进老年代了，TLAB也拦不住。

所以排查GC问题时，第一步应该看“分配速率”而不是“堆大小”。用jstat -gcutil <pid> 1000观察Eden和Old的占用变化，如果Eden每秒钟涨很多，说明分配速率高，考虑调大新生代；如果Old区涨得快，说明有大对象或者晋升速度过快，去看代码里有没有把大对象放进缓存、有没有短周期大生命周期的对象。

5. 内存分配异常场景的排查链路：从堆溢出到栈溢出

讲完分配机制，必须落到异常处理上。面试官最喜欢问“线上OOM了你怎么办”，本质上考的是你能否把内存分配的知识转化为排障能力。这里我把五种常见的OOM场景串起来，按实际排查顺序讲。

5.1 区分五种OutOfMemoryError的典型特征

Java heap space是最常见的堆内存溢出，特征是你去查堆占用时发现堆已经满了且GC后仍然无法回收足够空间。常见原因有三个：内存泄漏（对象无法被GC回收）、堆太小（高并发场景下对象分配速率超过回收速率）、大对象过多。排查路线是：用jmap -heap <pid>看堆参数，用jmap -histo <pid> | head -30看占用最高的类，用jstack <pid>看线程栈上有没有可疑的分配行为，再用jmap -dump:format=b,file=heap.hprof <pid>导出堆快照配合MAT分析。

GC Overhead Limit Exceeded是HotSpot虚拟机的一个保护机制：当GC花费超过98%的时间却回收不了2%的内存时，直接抛出这个错误。它本质不是一种独立的OOM，而是JVM在“GC已经无效”的情况下做的死循环检测。遇到这种错误，先别急着调堆大小，大概率是代码里有严重的内存泄漏或者静态持有大量无用对象，先把泄漏点找出来。

Metaspace溢出和类的加载数量直接相关。如果你用了大量的动态代理、反射生成类、CGLIB增强类，或者有自定义类加载器但没有正确卸载类，Metaspace就会持续增长。排查方法是看jstat -gcmetacapacity <pid>，如果Metaspace容量持续上升且Full GC后不下降，基本可以断定是类加载器泄漏。

Unable to create new native thread严格来说不是JVM堆内存的问题，而是操作系统层面无法创建新的线程。因为Java线程创建时会映射到操作系统原生线程，每创建一个线程都要占一块线程栈内存（默认1MB，单位由-Xss指定），当进程的线程数达到操作系统的ulimit -u限制，或者本地内存不足时，就会抛这个错误。生产上出现这种问题，优先检查线程数是不是有泄漏（比如线程池没关闭、连接池无限创建线程），而不是盲目加内存。

StackOverflowError触发的是无限递归或者方法调用层级过深。它的特点是一般不会导致进程崩溃，只会让当前线程退出，但如果你用的是固定大小的线程池，一个线程栈溢出很可能吞掉整个业务请求。

5.2 一个真实排查案例：堆内存越涨越高的完整链路

这里我拿一个实际遇到的问题演示整个排查链路。某天线上服务报警，Young GC频率从每秒1次涨到每100毫秒1次，Full GC也开始出现，响应时间明显劣化。

我的排查顺序是这样的：

1. 先看进程状态，top -Hp <pid>确认CPU占用和线程情况，排除死循环导致的CPU飙高，同时确认JVM进程没有挂死。
2. 用jstat -gcutil <pid> 1000看分代变化，发现Eden区每秒钟都在满，而且Old区在缓慢爬升，说明有对象晋升过快。
3. 用jmap -histo <pid> | head -30看对象直方图，发现有一个自定义的MessageBuffer类实例数量高达几百万——这在正常业务量下极不合理。
4. 继续追代码，发现这个MessageBuffer被放进了一个ConcurrentHashMap缓存里，key是业务单号，但只有在业务流程成功结束时才移除缓存条目，如果流程中途异常，缓存永远不会删。
5. 修复方式很简单：用try-finally保证缓存条目一定会被移除，或者对缓存设置过期策略。

整个过程如果对内存分配链路不熟，很容易卡在第一步——看见Eden区满了就直接调大堆，美其名曰“调优”，实际上掩盖了问题。这也是为什么我一直强调，八股不只是背题，它本质上是让你建立一套“内存怎么分配→什么时候GC→哪些对象会残留→怎么定位”的思维模型。

5.3 关于大对象处理和Survivor空间不足的“坑”

还有一个特别容易踩的坑是Survivor空间不足时对象的去向。正常情况下，Minor GC后存活对象会进入Survivor的to区，但如果to区空间不够放（比如存活对象太大或太多），多余的对象会通过“分配担保”（Handle Promotion）直接进入老年代。这个机制看起来很正常，但它会造成一个隐蔽的问题：老年代会凭空增加一批“不应晋升”的对象，导致老年代提前变满，Full GC提前到来。如果用jstat看到Minor GC频繁且每次都有对象进入老年代，但代码逻辑上又没有大对象，就要考虑Survivor区是不是太小了。

参数调整方向有两个：调大Survivor区比例（-XX:SurvivorRatio，默认8，表示Eden:Survivor=8:1，两个Survivor各占一份），或者调大晋升阈值（-XX:MaxTenuringThreshold，最大15）。但这里有个微妙的权衡：Survivor区调大了，Eden区就变小了，Young GC反而更频繁；晋升阈值调大了，对象在Survivor区滞留时间变长，增加了复制次数。实际调优中要结合业务对象的大小分布来做决定，没有固定答案。

6. 延伸出去：内存分配如何决定垃圾回收的行为

最后一节，我们把内存分配放到更大的视角里看。你搞懂了对象怎么分配，接下来要面对的问题就是：这些对象什么时候被回收？谁来判断哪些对象可以回收？不同的垃圾收集器对内存分配策略有什么影响？理解了内存分配和GC的衔接点，你的JVM知识体系基本就搭起来了。

6.1 从分配角度看GC Roots

GC Roots是一组活跃引用的集合，JVM从这个集合出发，沿着引用链遍历所有可达对象，不可达的对象被判定为可回收。常见的GC Roots包括：虚拟机栈中引用的对象（每个栈帧局部变量表里的引用）、方法区中静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象、以及所有被同步锁（synchronized）持有的对象。

这里要理解的是为什么GC Roots和内存分配是连着的。你在代码里通过某个变量new了一个对象，这个变量就在栈帧的局部变量表里，是一个GC Root。当你把这个变量的值置null，或者方法执行完毕栈帧出栈，这个GC Root就消失了，对象变成了不可达，可以被回收。这也解释了为什么要“避免持有不必要的引用”——比如静态集合持有一堆对象，静态字段是GC Root，整个集合链上的东西全部无法回收，这就是内存泄漏的根源。

我之前见过一个很典型的问题：一个大List在方法结束后依然被某个成员变量引用，导致服务长时间运行后老年代被撑爆。排查原理和刚才的线上案例一样——就是找GC Roots到问题对象之间的引用链路，MAT里的“Path to GC Roots”功能就是干这个的。所以你在准备面试时，不要孤立地背“什么是GC Roots”，而是理解“引用从哪儿来、到哪儿去，哪些引用会保留对象”。

6.2 不同收集器对内存分配策略的影响

讲完GC Roots，我们把对象分配和收集器串起来看。

Serial / Serial Old是最简单的收集器组合，新生代用复制算法，老年代用标记-整理算法。内存分配采用的是指针碰撞方式（因为是复制+整理，内存规整）。单线程收集，适合客户端小应用，卡顿明显但实现简单。

Parallel Scavenge / Parallel Old是JDK 8默认的收集器组合，也叫吞吐量优先收集器。它的核心关注点是达到一个可控制的吞吐量，所以提供了-XX:MaxGCPauseMillis（控制最大停顿时间）和-XX:GCTimeRatio（控制吞吐量比例）两个参数。因为采用复制+整理，内存规整，内存分配用指针碰撞。

CMS是一个以获取最短回收停顿时间为目标的收集器，采用标记-清除算法，所以内存不规整，只能使用空闲列表。这也是CMS一个著名的缺陷来源：因为使用空闲列表，内存分配完成后会产生大量内存碎片，几年后可能出现“老年代空间足够但分配大对象失败，触发Full GC”的情况。CMS还有一个Concurrent Mode Failure的问题：在并发清除阶段，如果老年代预留空间不足，会退化成Serial Old的Full GC，导致超长停顿。

G1把堆划分成多个大小相等的Region，每个Region根据需求可以扮演Eden、Survivor、Old或者Humongous（大对象区）。G1不再要求物理上的连续内存，所以它用的是空闲列表。它维护了一个“优先级列表”，每次回收时优先回收价值最大的Region（回收后能腾出最多空间、GC时间最短的Region优先）。这也是它名字的来源：Garbage First。大对象在G1里有专门的Humongous区域，比Region大小一半还大的对象直接分配在这个区。这和前面讲的“大对象直接进老年代”是同一个逻辑思路——避免大对象在新生代反复复制。

Shenandoah和ZGC则是更激进的低延迟收集器，做到了几乎不暂停的并发回收，但原理链路更深，通常面试问到G1就足够了。理解每一代收集器选型的出发点：单线程→多线程→并发→分Region+并发，背后就是吞吐量和停顿时间的不断权衡，而这个权衡的根基就是内存分配策略——对象在哪儿分配、怎么分配、怎么回收，三个问题是一体的。

6.3 参数对照：从分配到GC的关键JVM参数速查

网上列的JVM参数一大堆，但对刚梳理完内存分配的人来说，需要优先掌握的其实就这几组：

这里我要特别提醒一点：参数不是越多越好，别把网上流传的“性能优化参数大全”直接往生产上抄。我见过一个服务，运维同学在网上抄了一套所谓的“最优参数”，包括-XX:+UseConcMarkSweepGC、各种-XX:CMSInitiatingOccupancyFraction=70，结果JDK 14直接不认CMS（被移除），启动就报错。现代JDK版本（11+）默认就是G1收集器，很多参数根本不需要调，你要做的是把堆大小、新生代大小、GC日志开好，然后根据日志去调，而不是盲目堆参数。

6.4 梳理完内存分配之后，下一步往哪儿走

如果你是把这篇当作八股梳理路线的第一个节点，那完成内存分配之后，合理的下一步有两个方向：一个是垃圾回收算法和收集器，因为GC的底层逻辑完全是建立在分配策略之上的，顺着对象分配链路去理解回收逻辑会非常顺畅；另一个是工具实战，就是学会用jps、jstat、jmap、jstack、jcmd、arthas这些工具观察实际运行中的JVM内存变化。工具和理论是互相验证的关系，只背理论不会看日志，面试时聊不到具体场景；只会看日志不懂理论，排查问题就是瞎猫碰死耗子。

实际学习路径上，我比较推荐的做法是：先在本地写一个简单的Spring Boot应用，手动用jmap -histo、jstat -gcutil观察不同请求压力下堆内存的变化，再人为造一个内存泄漏场景（比如模拟用静态Map缓存大量数据而不清理），用MAT分析堆快照。整个过程做下来，你对内存分配、GC、OOM的认知深度会超过80%的面试候选人，因为大多数人真的是在背八股，而你已经亲手验证过了。

最后再分享一个小技巧：准备面试时，可以把“内存分配”这个主题当成一个三分钟口述训练——从new User()开始，讲到TLAB、Eden、Minor GC、晋升老年代、Full GC、OOM排查，全程不用看稿。如果能顺畅讲完并且逻辑闭环，这一块基本就稳了；讲的时候卡住的地方，就是你需要回头再查资料的薄弱点。这个训练方法我推荐给很多人都说有效，尤其是对JVM这种知识体系性强的内容，比自己按章节死记硬背高效得多。