JVM垃圾收集器从原理到实战：轻松掌握GC调优与面试要点

JVM的垃圾收集器，是Java从业者绕不过去的一座山。面试要问，线上出问题要查，调优要调，可很多人在这个知识点上始终是"背得下来概念，排不了实际问题"的状态。我一直觉得，垃圾收集器这东西，与其当成面试题背，不如当成一套"内存管理兵法"来理解——每个收集器都是在特定的硬件条件、停顿时间诉求、吞吐量目标下做出的权衡，你只有搞懂了它们各自的性格和适用场景，线上遇到诡异问题的时候才能第一时间判断出该往哪个方向查。

这篇文章我会从垃圾收集最底层的两个问题讲起——怎么判断对象该死、怎么高效地把该死的内存收回来，然后逐个拆解从Serial到ZGC的各个收集器，最后再聊聊真正的调优实战和那些高频面试题背后的考察点。不管你是刚接触JVM的初学者，还是被线上GC问题折磨过的老手，这篇文章应该都能给你一些不一样的东西。

1. 垃圾收集器的本质矛盾：内存回收的"三难困境"

垃圾收集器这个名词听起来很高深，但你把它翻译成人话，其实就是一个极其朴素的系统：JVM在运行过程中会不断分配内存给新对象，内存是有限的，所以必须有一套机制，在合适的时间把那些"再也没有人用"的对象清理掉，腾出空间给新对象用。

但这件事一旦落到工程实现上，马上就遇到了一个矛盾——JVM压根不知道哪个对象再也用不到了。它不像你收拾房间，看着那堆旧杂志知道"我大概率不会再翻了"，程序运行时，JVM只能通过一套间接的规则去推测。这个推测过程越准确，收集效果越好；但越准确的推测往往意味着越高的成本。于是垃圾收集器的设计从一开始就面临三个相互拉扯的目标：

• 停顿时间（STW, Stop-The-World）：GC发生时，业务线程必须暂停，否则一边扫地一边扔垃圾，内存状态根本对不上。停顿越短，对用户体验越好。
• 吞吐量（Throughput）：GC占用的CPU时间越少，留给业务代码的时间就越多，整体效率越高。
• 内存占用（Footprint）：GC自己也需要额外的内存来记录对象信息、维护数据结构，这个开销越小越好。

这三者之间是典型的"既要又要还要"的不可能三角。追求低停顿，往往要牺牲吞吐量和内存占用；追求高吞吐量，停顿时间就可能很难看。

理解了这个矛盾，你再看市面上那些让人眼花缭乱的收集器，思路一下就清晰了——每一个收集器都是在为某种特定场景做取舍：

• Serial收集器：单线程，简单粗暴，停顿时间长，但它占用的内存少，适合客户端小应用。
• Parallel Scavenge：追求最大吞吐量，适合后台批处理、科学计算这类不太在乎单次停顿、但希望整体跑得快的场景。
• CMS收集器：第一次让"并发收集"成为可能，目标是低停顿，适合互联网Web应用。
• G1收集器：要在可控的停顿时间内尽量提高吞吐量，把大堆切成小块分而治之，是目前JDK 8/11/17时代的主流选择。
• ZGC / Shenandoah：把停顿时间压到10毫秒甚至更低，为超大堆、低延迟场景而生。

你把这些收集器在"停顿、吞吐、内存"三个轴向上排一排，会发现整个垃圾收集器的发展史，就是一部不断用更精细的内存布局和更复杂的并发算法，去换取更短的停顿时间的历史。

这个底层认知非常关键，因为你后面无论是看参数、读GC日志，还是排查线上问题，本质上都是在和这三个目标的博弈打交道。我在帮别人看JVM参数的时候经常发现，很多人拿着一套"网上抄来的优化参数"直接往线上怼，结果效果反而更差，原因就是没想清楚自己的业务到底是需要低停顿还是高吞吐，把CMS的配置套在需要高吞吐的批处理服务上，这属于一开始方向就错了。

2. 判断对象存活的底层机制：可达性分析到底在干嘛

有了底层目标，我们来看垃圾收集器每天都要做的基础判断——一个对象到底该不该被回收。

关于这个问题，初学者最容易记住两个词：引用计数法和可达性分析。引用计数法的思路非常直观：每个对象都有一个计数器，被引用一次就加一，引用失效就减一，计数器归零了就说明没人用了，可以回收。这个算法实现简单、判定高效，但有一个致命伤——解决不了循环引用问题。A引用了B，B也引用了A，但这两个对象都不再被外部引用了，它们的引用计数永远是1，永远不会变成0，于是就成了泄漏的内存。Python的早期版本和Objective-C的早期内存管理都吃过这个亏。

所以JVM采用的是可达性分析（Reachability Analysis）。

这个算法的核心思想是：从一组被称为"GC Roots"的根节点出发，沿着引用关系往下走，能走到的对象就是"活着的"，走不到的对象就是"可回收的"。

GC Roots包含哪些东西？这个知识点面试几乎必问，但很多人背了又忘，因为不理解为什么是这些节点。其实你想想，什么样的对象算"根部"？必然是那些不依赖堆内其他对象就能独立存活，并且是程序当前正在使用的入口。具体来说包括：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象——方法正在执行，局部变量指向的对象当然不能回收；
• 方法区中的静态属性引用的对象——static变量属于类的，类加载了就一直在；
• 方法区中的常量引用的对象——比如字符串常量池里的引用；
• 本地方法栈中JNI引用的对象——Native方法在用，不能动；
• JVM内部的引用，比如基本数据类型对应的Class对象、常驻的异常对象、系统类加载器等；
• 被synchronized持有的对象——正在被锁定的对象绝对不能回收；
• 反映Java虚拟机内部情况的JMXBean、JVMTI回调等。

你会发现这些根的共同特点是：它们都不在堆上，但是从它们出发可以触及堆上的对象。

理解了这个，你就知道为什么可达性分析的"可达"不等于"必须存活"——它只是从根出发能不能走到，完全是一个图遍历问题。从这些根节点开始遍历整个对象图，能走到的标记为存活，走不到的标记为待回收，这就是"标记"阶段做的事情。

这里有一个值得注意的细节：可达性分析本身必须在一个一致性的快照中进行，否则一边遍历一边有引用在变，结果就乱了。这就是为什么再先进的收集器，在初始标记阶段都需要STW——不是这个阶段有多耗时，而是必须保证这一刻的对象引用关系是冻结的。

另外，Java在引用层面还做了四个等级的细化，分别是强引用、软引用、弱引用和虚引用。很多人搞不懂为什么需要分这四级，其实是为了让程序员能够主动干预对象的死亡节奏：

软引用和弱引用的区别，你可以理解成：软引用是"能撑就撑"，弱引用是"一碰就碎"。在可达性分析的框架下，这四个级别对应的是不同的判定路径，SoftReference对象在内存充足时不回收，但在即将OOM前会先清理一批；WeakReference对象则是在每次GC时都可能被清掉。

理解了引用的层级，你就能解释很多实际开发中的现象。比如ThreadLocal的内存泄漏问题，本质上就是ThreadLocalMap中Entry的key是弱引用，value是强引用，当ThreadLocal被回收后，key变成了null，但value还挂在Thread上，如果不主动remove，就会一直存在。这不是GC的bug，而是"弱引用+强引用混用"必然出现的问题，需要用remove()来兜底。

还有一个经常被提起但实际作用很微妙的点——finalize()方法。一个对象覆盖了finalize()方法，在被判定为不可达之后，并不会立刻回收，而是会被放进一个叫F-Queue的队列，等待一个低优先级的Finalizer线程去执行它的finalize()方法。如果在finalize()里这个对象重新被某个GC Root引用了，它就能"逃过一劫"。听起来很神奇，但我强烈建议你永远不要依赖finalize()来释放资源，因为这个机制的执行时机完全不可控、执行顺序也不保证，而且会显著拖慢GC过程。JDK 9之后官方已经明确标记finalize()为废弃，Java 18里更是被移除了，用Cleaner或者try-with-resources才是正路。

3. 分代收集理论的由来：为什么JVM要把堆切分成新生代和老年代

搞清楚"哪些该回收"之后，下一个核心问题是"怎么收最高效"。这就引出了JVM堆内存最经典的设计——分代收集。

分代理论的建立基于两条被大量实践验证过的经验法则：

• 弱分代假说：绝大多数对象的生命周期都非常短，刚创建出来没多久就变成垃圾了。你写一段业务代码，大把new出来的临时对象活不过一个方法调用。
• 强分代假说：熬过了多次GC的对象，往往会存活更久。比如一些缓存对象、单例对象，一旦活下来，就很难被回收。

这两条假说合在一起，直接引出了经典的堆内存布局：新生代（Young Generation）+ 老年代（Old Generation）。

新生代里面再细分三块区域：一个Eden区和两个Survivor区（S0和S1），比例默认是8:1:1。为什么需要Survivor区？因为新生代对象的存活率很低，大部分对象在第一次GC后就被回收了，剩下那一小撮"幸存者"需要从一个地方搬到另一个地方，避免老年代过早被塞满。这就是我们常说的"复制算法"。

复制算法可以这样理解：假设有一张白纸（Eden+S0），你在上面画了很多草稿，大部分都画废了，只有几笔是需要的。与其在原纸上小心翼翼地擦掉废稿、保留好稿，不如直接拿一张新纸（S1），把好稿临摹过去，然后把旧纸一扔。这个算法实现简单、没有内存碎片、分配效率高，代价就是需要浪费一块区域作为复制目标。8:1:1的比例设计就是希望Survivor区足够小，减少内存浪费，同时又够用。

对象在新生代里经历的生命周期大概是这样的：

1. 新对象首先分配在Eden区（以及TLAB，即线程本地分配缓冲区，后面细说）；
2. Eden区快满时，触发Minor GC，把Eden和S0中还活着的对象复制到S1，同时把对象的年龄加一；
3. 下一次Minor GC时，把Eden和S1中活着的对象复制到S0，年龄再加一；
4. 对象年龄达到晋升阈值（默认15，可以用-XX:MaxTenuringThreshold调整），或者S区装不下了，就会被晋升到老年代。

这里有个很多初学者困惑的问题：为什么晋升阈值默认是15？ 这是因为对象头中记录年龄的区域只有4个bit，所以最大值就是15。你如果非要把阈值调成16甚至更高，它会被截断为15——这个细节我见过不止一个人踩坑。

大对象直接进入老年代也是一个重要规则。-XX:PretenureSizeThreshold参数可以让超过指定大小的对象绕过新生代直接进入老年代，目的是避免大对象在Eden区和两个Survivor区之间来回复制，复制大对象的代价太高了。但也有很多场景下大家不会刻意设置这个参数，因为大对象进老年代会加速老年代的GC，需要根据实际业务权衡。

老年代里的对象因为存活率高，不能再用复制算法，否则大部分对象都要被复制一遍，成本太高。老年代的主流算法是标记-整理（Mark-Compact）：先标记存活对象，然后把存活对象向内存的一端移动，最后清理掉边界以外的内存。这个算法的好处是没有内存碎片，代价是压缩过程需要STW，移动对象的成本在对象很多时会很高。

现在再回头看整个分代设计，你会发现它本质上是一套组合优化：新生代用复制算法，因为每次回收能干掉大部分对象，复制成本低；老年代用标记-整理，因为存活率高，移动成本虽然高但必须要压缩，否则碎片化会让大对象分配直接失败。

这里也解释了一个线上常见现象：为什么有时候Young GC很快，有时候Old GC卡了很久。 Young GC只处理新生代，大部分对象本来就是垃圾，复制量小，所以快；Old GC要扫描整个老年代，还要做压缩整理，对象多的时候自然就慢。理解了这一点，你就明白了为什么"尽量让对象死在新生代"是JVM调优的核心思路之一——对象一旦晋升到老年代，回收它们的代价就指数级上升。

还有一个很多人容易忽略的点是TLAB（Thread Local Allocation Buffer）。JVM在Eden区里为每个线程划分了一块专有缓冲区，线程new对象时优先在自己的TLAB里分配，不需要和其他线程竞争同一块内存，这样大大提升了并发分配效率。TLAB的空间大小可以通过-XX:TLABSize调整，但大多数情况下默认配置就够了。如果TLAB装不下新对象，JVM会尝试直接在Eden区分配；如果Eden区也装不下，才会触发Minor GC。这就是为什么GC日志里会有tlab相关的统计——那是在告诉你TLAB的分配和浪费情况，如果TLAB waste过高，说明有很多对象在TLAB里没分配完就被迫触发GC了，可能需要调大TLAB。

4. 各代收集器的演进路线：从Serial到G1，每个收集器在做什么选择

了解了分代模型之后，我们终于可以逐个看看具体的收集器了。这部分我会按照历史演进的脉络来讲，因为每个新收集器的出现，都是在解决前代收集器留下的某个具体痛点。

4.1 初代选手：Serial和Serial Old

Serial是JVM诞生之初就有的收集器，也是所有收集器里实现最简单的：单线程、STW、复制算法处理新生代。它的逻辑非常简单粗暴——要GC了，先停掉所有业务线程，然后用一个GC线程认认真真地扫描、复制、清理，干完再恢复业务线程。

Serial Old则是它的老年代版本，用标记-整理算法，同样是单线程STW。

听起来很原始对吧？但实际上它有个巨大的优点：因为只有一个GC线程，没有线程交互和调度开销，在单核CPU或者内存很小的环境下，它反而是效率最高的收集器。 所以JDK里默认的Client模式虚拟机就是用它。即使在今天，如果你跑的是一个小型命令行工具、批量处理脚本，或者给嵌入式设备写的Java服务，Serial依然够用甚至更优。

4.2 多线程登场：ParNew和Parallel Scavenge

随着CPU多核化，单线程GC就成了瓶颈。于是ParNew来了——它是Serial新生代的多线程版本，多个GC线程并行执行复制算法，并行（Parallel）的意思是GC线程之间并行，但业务线程仍然要STW。

ParNew在JDK 8及以前的版本里经常和CMS搭配使用，因为CMS只负责老年代，新生代需要一个高效的多线程收集器来配合。它有一个参数-XX:ParallelGCThreads可以控制GC线程数，默认会自动根据CPU核心数计算。

和ParNew同时期的Parallel Scavenge，虽然也是新生代多线程收集器，但它走的是另一条路线——它更关注吞吐量，而不是停顿时间。它引入了一个非常独特的参数体系：

• -XX:MaxGCPauseMillis：设置期望的最大停顿时间，但Parallel Scavenge并不是保证一定低于这个值，而是会根据历史统计动态调整新生代大小来尽量逼近这个目标；
• -XX:GCTimeRatio：设置GC时间占总时间的比例，默认是99，即允许1%的时间用于GC；
• -XX:+UseAdaptiveSizePolicy：开启自适应调整策略，JVM自动调整Eden、Survivor的比例和晋升阈值，不需要人工干预。

你如果追求的是整体吞吐量而不是单次停顿时间——比如跑报表、做数据分析、离线任务——Parallel Scavenge + Parallel Old这套组合是JDK 8时代的经典高效选择。

4.3 CMS的里程碑意义和它的无奈

CMS（Concurrent Mark Sweep）是垃圾收集器演进史上一个里程碑式的作品，它是第一个真正意义上的并发收集器——GC线程和业务线程大部分时间可以同时工作。它的目标非常明确：降低老年代GC的停顿时间。

CMS的整个回收过程分为四个阶段：

• 初始标记（CMS initial mark）：STW，但只标记GC Roots能直接关联到的对象，速度很快；
• 并发标记（CMS concurrent mark）：和业务线程并发执行，从GC Roots开始遍历整个对象图，标记所有存活对象，这一步是最耗时的，但不需要停顿；
• 重新标记（CMS remark）：STW，修正并发标记期间业务线程修改引用关系导致的漏标和误标，需要遍历整个对象图，通常比初始标记慢一些；
• 并发清除（CMS concurrent sweep）：和业务线程并发执行，把标记为垃圾的对象从内存中清除。

CMS的核心思想是把耗时最长的标记阶段拆成"初始标记+并发标记+重新标记"，让GC线程和业务线程尽可能并行，从而把STW时间压缩到最短。

但CMS也有几个原生缺陷，这些缺陷在后来成了面试高频题：

1. CMS使用的是标记-清除算法，会产生大量内存碎片。 因为它在清除阶段不压缩，老年代空间会被一点点切成碎片。碎片多了以后，即使老年代总剩余空间还够，但找不到一块连续空间分配给大对象，就会触发一次Full GC。JVM对此有一个兜底策略：-XX:CMSFullGCsBeforeCompaction（JDK 9之前有效，之后被废弃），它会让JVM在若干次CMS GC之后容忍一次带压缩的Full GC。

2. CMS不适合CPU核数太少的机器。 并发阶段要占用CPU，如果机器核数少，CMS线程会抢掉业务线程的CPU，反而导致吞吐量下降。

3. CMS无法处理"浮动垃圾"。 并发标记和并发清除阶段，业务线程还在不停地产生新垃圾，这些垃圾只能留到下次GC再处理，所以CMS不能等到老年代完全满了才开始GC，必须预留一部分空间给浮动垃圾，通过-XX:CMSInitiatingOccupancyFraction设置触发阈值。

4. CMS在JDK 9之后被标记为废弃，JDK 14被正式移除。 它不是不够好，而是G1在绝大多数场景下已经能覆盖它的能力，而且没有它的碎片问题。

4.4 G1：把堆切成小块的分治大师

G1（Garbage First）从JDK 7开始出现，JDK 9之后成为默认收集器，是当前Java 8后期、Java 11、Java 17时代最主流的收集器。它跟前面所有收集器最大的不同在于：G1堆的内存布局完全不是物理上的新生代/老年代分代结构。

G1把整个堆划分成了一个个大小相等的小区域（Region），每个Region的大小默认1MB到32MB不等，可以通过-XX:G1HeapRegionSize指定。Region在逻辑上仍然会被标记为Eden、Survivor、Old、Humongous（存放大对象）等角色，但每个Region的角色不是固定的，可以动态变化。这就好比你原本住的是一个固定三居室——一间卧室、一间书房、一间客厅，现在改成了一片共享办公区，每个工位今天可以当会议室、明天也能当工位，灵活性大幅提升。

G1的回收同样是分代进行的，回收思路也有一个著名的"Garbage First"特性——它每次回收时优先回收价值最大的Region，所谓"价值"指的是回收后能腾出最多内存、且GC停顿时间可控的区域。为此G1维护了一个优先级列表，每次回收前会预测一下各个Region的回收效率和开销，优先处理那些"垃圾比例高、回收成本低"的Region。

G1的回收流程大致是：

• 年轻代回收（Young GC）：和传统新生代回收类似，把Eden中存活对象复制到Survivor或晋升到Old Region，这个阶段是STW的，但因为是优先处理高价值Region，停顿通常是可控的；
• 混合回收（Mixed GC）：在老年代占用达到一定比例后触发，同时回收年轻代的一部分Region和一部分老年代Region，核心目标是在停顿时间限制内尽可能多地回收老年代空间；
• Full GC：G1的兜底操作，通常在Mixed GC无法回收足够内存、或者出现晋升失败、大对象分配失败等情况下触发，这时的G1会退化成Serial Old式的单线程/多线程STW Full GC，停顿时间会很长，所以线上G1如果频繁Full GC，基本可以断定是配置或代码出了问题。

G1的另一大优势是它从根本上解决了CMS的碎片问题，因为每当Region里的存活对象要整理时，G1直接把存活对象复制到另一个Region，即用复制算法天然地完成了压缩，不会产生内存碎片。

但G1并不完美，它也有自己的问题：Region本身会带来一定的内存占用和额外的记录开销；它的RSet（Remembered Set，用于记录跨Region引用）在大型堆上会很庞大，占用不少内存；而且G1在并发标记阶段如果存活对象特别多，停顿时间可能会超过预期。不过总体上，对于4GB以上堆、延迟敏感型应用，G1是当前最稳妥的默认选择。

4.5 ZGC：把停顿压进10毫秒的极限挑战

再往后是ZGC，它把目标推到了一个极致——无论堆多大，停顿时间都不超过10毫秒。ZGC采用的技术包括染色指针（Colored Pointers）、读屏障（Load Barrier）和基于Region的内存布局，它把标记、转移、重映射等大部分工作都做成了并发操作，只有在极短的阶段才需要STW。

ZGC在JDK 11引入实验状态，JDK 15转正。它的实现细节确实比G1复杂得多，但对大多数开发者来说，更重要的认知是：ZGC适合超大堆（比如几十GB甚至TB级）、极低延迟的金融、搜索、在线交易场景；如果堆只有几个GB，ZGC的优势并不明显，甚至可能因为读屏障和指针压缩等额外开销，导致吞吐量不如G1。

选择收集器从来不是"哪个新就选哪个"，而是要根据业务场景来决定。这是我在实际项目中反复强调的一点。

5. 关键参数配置与参数背后的设计逻辑

聊完了收集器家族，我们来实操层面的参数。JVM参数多如牛毛，但对垃圾收集器来说，你需要掌握的核心参数其实就那么二十来个。

这些参数看着多，但真正需要记住的设计逻辑就几条：

第一，-Xms和-Xmx一定要设成一样。 如果两者不同，JVM会根据需要动态扩容或缩容堆内存，这个过程中STW时间会明显增加，尤其在流量波动大的服务上，堆忽大忽小会导致GC行为不可预测。我见过一个极端案例，某服务没设-Xms，启动后堆只有512MB，流量一上来JVM反复扩容，每次扩容都伴随一次Full GC，接口超时率飙升。把-Xms提到和-Xmx一致之后，问题立刻消失。

第二，期望停顿时间不是设置完就生效的。 比如你用Parallel Scavenge并且设置-XX:MaxGCPauseMillis=100，JVM会尝试通过调整新生代大小来满足这个目标——它可能把新生代调小以减少单次GC的对象复制量，但这样会导致GC更频繁，吞吐量下降。所以这个参数更像是一个"指导方向"，不是绝对承诺。

第三，G1的-XX:MaxGCPauseMillis（默认200ms）同样不是硬性指标。 G1会用预测模型来估算各种Region组合下的回收时间，尽量把停顿控制在目标值附近，但如果目标设得过于激进，比如设成50ms，G1可能会缩小年轻代来压制停顿，结果Minor GC变得特别频繁，整体吞吐量惨不忍睹。我建议在大多数Web服务上，G1的停顿目标维持默认的200ms，或者根据自己的SLA设到150-250ms之间，不要盲目追求低值。

第四，IHOP（-XX:InitiatingHeapOccupancyPercent）在G1中非常重要。 它默认是45，意思是当老年代占用达到堆的45%时，G1会启动并发标记周期，为后续的Mixed GC做准备。如果IHOP设得太低，并发标记会过于频繁，浪费CPU；设得太高，可能还没标记完老年代就满了，直接触发Full GC。这个参数的调整需要结合GC日志来看，不要凭感觉改。

第五，关于GC日志，JDK 9之后老参数-XX:+PrintGCDetails已经废弃，统一用-Xlog语法。 简单好用的一套配置是：

bash复制-Xlog:gc*:file=/var/log/app-gc.log:time,uptime,level,tags:filecount=10,filesize=10m

这会把GC日志输出到文件，滚动保留10个文件、每个10MB。线上环境一定要开GC日志，而且是长期开，不要等到出了事才想起来加。

6. 线上调优实战经验：GC日志怎么读、问题怎么排查、常见的坑

参数和原理讲了一大堆，最终都要落到线上问题上。这一节我分享几个我自己在排查GC问题时的实战经验，这些经验都不是从官方文档上能直接抄到的。

6.1 第一件事：会看GC日志

不管用什么工具，GC日志永远是最底层的证据。一份典型的G1 GC日志长这样：

code复制[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0123456 secs]
   [Parallel Time: 3.2 ms, GC Workers: 8]
      [GC Worker Start (ms): Min: 1234.5, Avg: 1234.6, Max: 1234.7, Diff: 0.2]
      ...
   [Eden: 1024.0M(1024.0M)->0.0B(1024.0M) Survivors: 16.0M->16.0M Heap: 2048.0M->1024.0M]
   [Times: user=0.02 sys=0.01, real=0.01 secs]

我们来拆解一下几个关键点：

• GC pause (G1 Evacuation Pause) (young)：这是一次年轻代回收，STW停顿了12毫秒；
• GC Workers: 8：用了8个GC线程；
• Eden: 1024.0M(1024.0M)->0.0B(1024.0M)：Eden区从1024MB清到了0，清理了1024MB的容量，回收后Eden还是1024MB，说明这是次正常的年轻代回收；
• Heap: 2048.0M->1024.0M：整个堆从2GB降到了1GB，说明大部分都是可回收对象。

如果日志里出现Full GC (Allocation Failure)，说明有对象分配失败，堆内存不够，JVM被迫做完整的全局STW回收，这是最需要警惕的。Full GC在G1下出现，通常意味着Mixed GC没有及时释放空间，或者老年代真的满了。

6.2 从现象反推根因：我踩过的三个典型坑

第一个坑是晋升太快导致老年代迅速占满。我印象非常深，有一次某服务运行环境给新生代只分了很小的空间，大概是堆的1/4，结果大多数对象还没来得及在新生代里熬到被回收，就因为Survivor区装不下而晋升到了老年代。老年代很快就满了，CMS触发Full GC，每次Full GC停顿好几秒，然后没过多久又满了，形成恶性循环。最后解决方式是重设新生代比例，同时通过GC日志分析对象的晋升情况，把大对象提前优化掉了（比如把一个反复创建的大数组改成复用对象池）。

第二个坑是并发标记不及时，老年代被塞满触发Full GC。在G1模式下，如果IHOP设置不合理，比如低到默认45但业务老年代增长特别快，并发标记还没完成，老年代就满了，这时候直接触发Full GC。排查时要看GC日志中并发标记周期（Concurrent Mark Cycle）的完成时间和老年代占用情况。可以通过调高IHOP、让老年代有更多缓冲，或者优化业务代码减少老年代对象增长来解决。

第三个坑是设置不合理的-Xmx导致GC过频。有一个测试环境的应用，堆设置得特别小（比如256MB），但其实它的常驻对象就有200MB，结果GC每秒钟触发好几次，CPU全花在GC上。这类问题查起来快，看GC日志里"Allocation Failure"频次和堆使用率就一目了然了。解决方式很简单——给够堆内存，或者优化业务常驻对象。

6.3 调优的推荐流程

很多人一上来就翻各种JVM参数调优秘籍，结果越调越乱。我的建议是先测基线、再定点优化：

1. 不优化，先观察。维持默认参数（或者只设置-Xms/-Xmx/GC日志），让服务在压测或试用环境下跑一段时间，收集GC日志；
2. 读日志，找异常。看看Young GC频率、Old GC频率、Full GC次数、平均停顿时间、P99停顿时间，判断是否存在明显问题；
3. 定位问题来源。如果对象分配过于频繁，用jmap -histo:live或jstat看哪些对象占了大量空间；如果是晋升问题，看Survivor区是否够用；如果是老年代增长过快，结合代码分析是否有大对象一直在累积；
4. 做一个改动，验一次效果。每次只调一个参数，用同样的压测场景跑，对比GC日志和TPS/响应时间的变化。不要一次改五个参数，出了问题根本不知道是谁的锅；
5. 最终确认。新参数在小流量验证通过后再放大流量，稳妥推进。

这一步一步下来，绝大多数线上GC问题都能找到根源，而不是靠感觉蒙参数。

6.4 常用的排查工具

工具不在多，在精。我日常用的就这几样：

• jstat -gcutil <pid> 1000：每秒打印一次GC利用率，快速看GC频率和堆占用；
• jmap -histo:live <pid> | head -50：看堆里的对象分布，定位大对象或异常对象；
• jcmd <pid> GC.heap_info：查看堆各个分区的使用情况；
• jvisualvm / JMC：图形化看堆和GC趋势，适合本地和测试环境；
• GCViewer / gceasy.io：把GC日志文件丢进去，自动生成图表，快速看各阶段的停顿、频率、吞吐量；
• Arthas：很多快捷命令可以动态排查内存和GC问题，比如memory、thread、dashboard。

排查GC问题的时候一定要记住：工具只是帮你定位的手段，真正要落脚的是业务代码和内存分配行为。绝大多数GC问题，本质上都是代码问题，不是JVM参数问题。

7. 高频面试题背后的考点拆解

最后聊聊JVM垃圾收集器相关的高频面试题。面试官问这些题，考察的往往不是你能不能背出答案，而是你对底层机制的理解深度。

"JVM怎么判断对象可以回收？"
答到可达性分析之后，最好主动提一下GC Roots的组成和四种引用类型的差异，说明你不仅知道算法，还知道它在实际场景中的表现。

"讲一下CMS收集器的流程和优缺点。"
这种题你要展现出对比思维。能主动指出CMS的四个阶段、碎片问题和浮动垃圾问题，还能顺手提一句G1是怎么解决这些问题的，面试官会认为你确实理解收集器，而不只是背概念。

"G1和CMS的区别？"
可以从内存布局（Region vs 物理分代）、回收方式（复制 vs 标记-清除）、停顿可控性（G1预测模型 vs CMS不可控）、碎片处理（G1无碎片 vs CMS有碎片）几个维度展开。如果你能补充一句"G1适合多大堆、CMS适合多大堆"这类的经验判断，分就会更高。

"了解ZGC吗？它为什么能实现那么短的停顿？"
如果你能讲到染色指针和读屏障（基本概念即可），说明你关注新技术的原理，不是停留在写CRUD的层面。

"一次完整的GC过程是怎么样的？对象怎么从新生代到老年代？"
这是一道说透了分代的题。从对象分配（Eden的TLAB）讲到Minor GC（复制算法）讲到晋升条件（年龄阈值、Survivor空间不足、大对象直接晋升），再讲到老年代的回收算法。能把这个流程描述得完整且准确，说明你对JVM运行时有了扎实的理解。

面试题背后其实只有一个考察核心——你有没有真正理解JVM是怎么管理内存的。如果只是背答案，稍微追问一句"为什么Survivor需要两块”，很多人就答不上来了。

我个人在实际排查过程中还有一种体会，就是不要神话任何收集器。G1确实是当前最均衡的默认选择，ZGC也确实很惊艳，但线上真正决定GC效果的，往往不是收集器本身，而是业务代码的内存行为是否健康。一组设计糟糕的代码，比如在循环里狂new大对象、缓存不设上限、用静态集合无限收对象，任何收集器都救不了你。反过来，代码内存行为干净，默认参数也能跑得很稳。所以每次有人让我推荐"最好的JVM配置"时，我的回答都是同一句：先把GC日志打开，把堆模型参数设置合理，然后把业务代码的内存分配习惯弄规范，最后再根据日志数据来精调，这才是王道。

最后再分享一个排查小技巧：如果某天线上突然出现频繁Full GC，别急着去调参数，先看一眼是不是有发布变更或者上游调用量突然暴涨，很多时候是流量把内存打爆了，跟JVM配置半毛钱关系都没有。改配置前先确认问题域，能帮你少走很多弯路。