为了晴子高级岗的Java面试，问到JVM和GC，从来不应该是靠背概念应付过去的东西。我印象最深的一次社招面试，前面聊项目聊得挺好，到了“讲讲你的GC调优经历”这个环节，我说了些堆大小和收集器参数，对方没有继续追问细节，而是换了个角度问：“你负责的应用，老年代还有20%空间的时候，一个生命周期很短的请求对象，是怎么被回收掉的？”我当时一愣，能画出完整的GC流程图，却讲不清楚一个对象从创建到回收的完整决策链路。那次之后我把GC整个体系重新捋了一遍，才发现很多东西不是不懂，而是没有串起来理解。
这篇文章就按我后来整理这套体系时的思路来写：从对象的生存周期拆起，到内存结构的设计逻辑，到垃圾回收算法的演进原因，再到收集器的选型决策链，最后落到真实调优和线上事故排查。我不会罗列一个个孤立的知识点，而是尽量把“为什么这样设计”“面试官到底想问什么”串起来。不管是准备P7左右的Java面试，还是正在被线上GC长暂停困扰的开发者，按这条线读下来，应该能把JVM和GC的知识网格化，而不是碎片化。
1. GC问题的本质：延迟跟可控性之间的博弈
1.1 为什么Java应用会突然“卡”一下
很多业务同学骂Java“吃内存”、“一到大促就卡”，这个感受虽然笼统，但指向了一个真实存在的机制性的“停顿”。垃圾收集器回收内存时，为了不让你一边清理一边还往垃圾堆里扔新东西，必须把整个应用“暂停”住，让所有业务线程停下来，确保此刻的对象关系图是稳定的。这个暂停专业术语叫Stop The World，简写STW。只要是回收，几乎必然有STW，区别只在时间长短和影响范围。
举个贴切的例子：你收拾房间时，一边收一边往里扔快递盒，永远收拾不干净。最有效的做法是先让全家人停下来，站在门口不许动，你在房间里把所有垃圾一次性清出去，再喊大家继续活动。JVM的GC就是这个逻辑，业务线程一停，GC线程才能安全地移动对象、清理内存、修正引用。
理解了这一点，面试里很多问题就有了抓手。比如为什么G1会引入可预测的停顿时间模型，为什么ZGC要追求亚毫秒级暂停，背后的核心矛盾始终是同一个：在有限的内存里，既要保证垃圾回收足够彻底，又要让每次停顿尽量短、频率尽量低。而这两者往往是互相打架的——回收得越频繁越彻底，每次停顿很小，但整体消耗的CPU时间更多；回收得越少越慢，吞吐量好看，但单次停顿可能长到你怀疑应用是不是挂了。
1.2 哪些场景最容易显现出GC问题
把问题放到真实环境里看，GC延迟高的表现各不相同，但危害都很直接。常见的有三类场景。
第一类是高频请求的在线服务，典型的像订单中心、商品详情聚合接口。这类服务的特点是对响应时间极度敏感，哪怕一次Full GC停顿几百毫秒，就可能造成一批超时，继而引发上游重试风暴。你观察系统监控里的TP99曲线，如果每隔一段时间会出现明显的尖刺，排查时第一怀疑对象基本都是GC停顿。
第二类是内存占用巨大的数据处理任务，像离线报表、大量数据导入导出。这类任务的特点不是单次请求慢，而是对象存活率特别高，动不动就往老年代塞数据，最后触发Full GC时，年轻代、老年代全要清理，停顿时长可能达到数秒甚至有分钟级记录。我见过一个批量跑批任务，一次Full GC停下来后，整个集群都在等它恢复，那真是灾难现场。
第三类是基于JVM的中间件服务，比如搜索引擎或者HBase的RegionServer这类。它们跟普通Web应用不太一样，内部缓存了大量数据，内存中对象长期存活的比例非常高，而且对GC停顿比普通接口服务还要敏感。网上搜“hbase gc延迟太高”会看到大量案例，其实就是老年代回收时停顿时间过长，导致RegionServer的ZooKeeper会话超时，最后节点被判定为宕机、触发主备切换。这类故障的特征非常典型：GC日志里能看到超长的新生代或老年代回收停顿，紧接着就是region server挂掉的消息。它给的教训是，GC停顿不只是请求变慢的问题，它可能直接触发分布式系统里的心跳机制误判。
所以，理解GC不能只停留在算法原理层面，一定要结合分布式的视角去看，一个地方的停顿可能会被放大成整个集群的故障。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 想搞懂GC，先把JVM内存的“区域分工”重新捋一遍
2.1 堆内分区的设计动机：不是为了画图好看
JVM的堆内存被分成新生代（Young Generation）和老年代（Old Generation），新生代里又细分为Eden区和两个Survivor区，默认比例通常是8:1:1。笔试里画这个图谁都会，但真正要理解的是：为什么非要把堆拆成这样？
核心逻辑来自一个经验事实：绝大部分对象都是“朝生夕灭”的。你在一个请求里new出来的DTO、临时变量、中间结果，请求结束就没人引用了。有统计显示，在典型业务应用中，超过90%甚至接近99%的对象存活时间非常短。如果把所有对象都放在同一个大区域里统一管理，每次垃圾回收都要扫描全堆找出所有没人要的死对象，成本太高。
分代设计的本质是按对象存活概率分桶管理。新对象统一放到一个专门区域（新生代），这里绝大多数对象很快就会变成垃圾，回收时只需要扫描这一小块区域，而且能用上复制算法——后续会讲——把还活着的少量对象搬到另一个地方，剩下的整片空间直接清空。而一个对象如果在新生代历经多轮回收仍然存活，说明它大概率是长命对象，就把它晋升到空间更大的老年代，那里的回收频率自然不用太高。
面试时如果被问到“你能讲讲为什么要把堆分为新生代老年代吗”，比较好的回答不是描述分区规则，而是说出上面这个“按存活概率分桶”的设计动机，顺带说出那句经典结论：分代假设是绝大多数Java应用对象分配与存活模式的经验总结。
2.2 堆到底是什么时候“满了”，谁在替我们统计
聊到内存模型很容易忽略一个角色——分配担保机制，但它实际上影响了对象什么时候被扔到老年代，也是GC面试题里常被追问的暗礁。
先理清一个基础逻辑：普通对象优先在Eden区分配，Eden区空间紧张时触发Minor GC，把活着的对象往Survivor区搬。但新生代本身空间不够时怎么办？JVM引入了一个概念叫“分配担保”，说白了就是让老年代作为后备力量，由老年代来兜底存储新生代放不下的存活对象。
具体来说，在YGC（新生代回收）之前，JVM会做一次检查：老年代当前最大可用的连续空间，是否大于新生代所有对象的总大小？如果大于，说明就算所有新生代对象全活下来，老年代也接得住，这个Minor GC可以放心执行。如果不够，就再看一个配置：是否允许担保失败，以及历史上晋升到老年代对象的平均大小是否小于老年代剩余空间。如果条件满足，就冒险做一次Minor GC，万一实际晋升的对象太多导致担保失败（Handle Promotion Failure），会立即触发一次Full GC来兜底。如果不满足，干脆直接将这次Minor GC升级成Full GC，一次搞定，免得来回折腾。
这个地方对排查线上问题很有价值。如果你观察到YGC之后马上跟着一次Full GC，而且频率不低，除了考虑老年代空间本身不够之外，还要想想是不是晋升对象太多挤爆了老年代。常见的诱因包括：本地缓存、ThreadLocal误用导致对象一直持有、对象过大直接晋升（只要超过阈值就不用经过Survivor）、动态年龄判定导致大量对象提前进入老年代。
2.3 堆外的JVM内存同样会拖垮GC
很多人一说JVM内存只盯着堆，写到一半问我堆外出了GC怎么回事。其实JVM运行时的内存管理远不止堆。方法区在JDK 8以后改叫元空间，直接使用本地内存，默认情况下空间上限受操作系统可用内存限制。虚拟机栈是线程私有的，每个线程在创建时分配，里边的局部变量、操作数栈、动态链接和返回地址，这些跟GC没有直接关系。还有直接内存，它由NIO操作分配。
它们在GC讨论里的意义在于：不参与GC扫面的数据，往往才是内存泄漏的温床。比如直接内存泄漏了，堆一切正常，但你观察进程的RSS内存不断上涨，最后被操作系统OOM Kill。元空间存放的类元数据如果因为类加载器泄漏而一直增长，就会造成频繁Full GC，因为JVM需要清理已加载的类。
此外还有一个概念值得记牢：JVM的堆大小配置，不等于进程实际占用的内存。堆内几十个G，堆外还有线程栈、元空间、直接内存、JIT编译器、GC管理结构等一系列开销。生产上常用的经验值是给JVM进程预留不超过容器或物理机内存的70%左右做堆上限，其余留给堆外。
3. 判定“谁是可回收对象”，别只背可达性分析
3.1 为什么所有现代JVM都不用引用计数法
几乎所有讲GC的资料都会先提一个方案——引用计数法，然后说它有个循环引用的缺陷，所以不用。这个说法对，但面试官如果深问一句“除了循环引用，引用计数还有什么问题”，很多人会卡壳。
引用计数法的确很直观：每个对象维护一个计数器，被引用加一，引用失效减一，计数为零就回收。可它有两个绕不过去的毛病。一是循环引用解决不了，这属于算法层面的结构性死结，两个对象互相引着，外部已经没人能找到它们了，但各自计数器始终不为零。二是它需要每次引用赋值都同步做加减计数操作，非常烦琐，而且多线程环境下要保证计数操作本身线程安全，还得用CAS或者锁，开销很大。
可达性分析思路反过来了，它不追踪“谁引用我”，而是从一组被称为GC Roots的根节点出发，顺着引用关系往下遍历，像画树一样标出所有能到达的对象。凡是触达不到的对象，统一判为可回收。这样循环引用问题自动消失，遍历过程是只读的，不需要频繁做计数器修改。现代主流的HotSpot虚拟机等实现，用的基本都是这种思路。
3.2 GC Roots到底有哪些，以及面试的延伸追问
GC Roots的范围是个高频考点。归纳起来大致有这些：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象，也就是当前正在执行的方法里的局部变量；
- 方法区中的静态属性引用的对象，即类的static变量；
- 方法区中常量引用的对象；
- 本地方法栈中JNI引用的对象；
- 同步监视器锁定的对象（synchronized持有的对象）；
- JVM内部的引用，比如基本类型对应的Class对象、常驻的异常对象、系统类加载器等。
面试官如果追问“为什么不把堆里所有对象都当根”，你可以解释为：一个对象只要还能被栈上正在执行的线程触达，就说明它还有利用的可能；而堆内对象相互引用，并不代表从外部可达，外部不可达就意味着这整棵引用树都可以作废。
3.3 四种引用对判定只会严格，不会放水
Java在JDK 1.2之后把引用分成了强引用、软引用、弱引用、虚引用。它们真正影响的是对象在资源紧张时“有多容易死掉”，是判定逻辑叠加了“在何时回收”的约束。
- 强引用，最常见的Object obj = new Object()。只要强引用还在，对象就不会被回收，哪怕OOM也不收；
- 软引用，描述还有用但非必需的对象。系统在将要发生内存溢出异常之前，会先把软引用关联的对象列入回收范围，如果回收完还不够，才抛出OOM，用SoftReference实现；
- 弱引用，比软引用更短命。只要垃圾收集线程发现某个对象只被弱引用关联，下一次GC就会把它回收，不等到内存不够，用WeakReference实现；
- 虚引用，最特殊，它不影响对象的生命周期，无法通过它取得一个实例引用。它存在的唯一目的是在对象被回收时收到一个系统通知，用PhantomReference实现。
面试常问的软引用、弱引用真实使用场景，我的记忆方法很直接：软引用适合做内存敏感的缓存，比如图片缓存、一些浏览器的页面缓存；弱引用适合做规范映射或者数据结构的辅助结构，比如ThreadLocal的Key就是用弱引用，避免因为线程存活时间过长导致Key无法被回收，进而引发内存泄漏。
顺带一提，对象被判定为可回收之后不会立刻被物理销毁，它会先进入一个“缓刑期”，如果finalize方法被覆写且还没被执行过，对象会进入F-Queue队列，等待Finalizer线程调用它的finalize方法。如果在这个方法里对象又把自己重新引用了，它可以逃脱这次回收。但这个机制在工程上早就被官方标记为不推荐使用，代码里不要依赖它。
4. 三大垃圾回收算法的演进逻辑：每个新方案都在解决上一个的痛点
4.1 标记-清除：最朴素，但带了两颗雷
第一个供真正实现的算法是标记-清除，分成两个阶段：先按可达性分析标记所有可回收对象，再统一回收这些对象。
它的问题有两个，一个是效率不高，标记和清除两个阶段都需要遍历大量对象；另一个，也是更重要的问题，是产生大量不连续的内存碎片。想象一张白纸，你用铅笔在上面划掉一些词，划掉后纸面不会自己变得紧实，只会留下一个个空洞。等下次要分配一个比较大的对象时，明明剩余空间总容量够，但找不到一块足够大的连续区域，就得触发一次GC来处理分配失败，极端情况下，在对象创建这个很普通的动作上会频繁触发GC。
4.2 标记-复制：牺牲空间换整洁，新生代的默认打法
标记-复制算法把可用内存按容量划分为大小相等的两块，每次只使用其中一块。当这一块用完了，就把还存活的对象复制到另一块上，然后把已使用过的空间一次性清理干净。这样实现简单、运行高效，而且复制的目标端把对象紧凑排列，从根源上解决了碎片化。
代价是空间利用率只有一半，这对于堆积了大量长命对象的老年代来说太奢侈了。所以HotSpot并没有把新生代分成两个等大的区域，而是把新生代内部设计成一块较大的Eden区和两块较小的Survivor区，每次用Eden和其中一块Survivor，回收时把存活对象一次性复制到另一块Survivor，默认8:1:1的比例把空间浪费降到了10%。
日常开发中频繁发生的Minor GC用的就是标记-复制的变种。Eden区被塞满后，JVM把Eden和Survivor里活着的对象复制到另一块Survivor，同时给对象年龄加一，当年龄达到阈值时晋升到老年代。Survivor本身装不下时，会根据分配担保机制提前让多余对象进入老年代。这也是为什么YGC日志里能看到“Desired survivor size”这类字样，它代表Survivor区目标占用上限，超过这个值就倾向于直接晋升。
4.3 标记-整理：老年代不想复制，那就就地清理
老年代的对象存活率很高，用复制算法意味着大量对象来回搬动，代价极其高昂，所以专门设计了标记-整理算法。它同样先做标记，但后续不在是简单地清除，而是让所有存活对象都向内存空间一端移动，然后直接清理掉边界以外的内存。移动后，老年代空间变得规整，分配大对象更容易，但移动对象需要更新所有引用指针，说白了一次完整GC要遍历两次对象图：一次标记，一次移动。
标记-整理的过程通常会伴随较长的STW，因为移动引用要保证业务线程处于静止状态。这也就是CMS收集器一个非常尴尬的设计所在——它采用标记-清除，避免压缩导致的长时间停顿，代价是牺牲空间连续性；一旦碎片化严重，停顿反而更严重。
4.4 三种算法的核心取舍，一张表收尾
| 算法 | 是否移动对象 | 空间碎片 | 适用场景 | 核心短板 |
|---|---|---|---|---|
| 标记-清除 | 否 | 严重 | 老年代，CMS的基础方案 | 碎片化造成后续分配困难 |
| 标记-复制 | 是 | 无 | 新生代，对象存活率低 | 空间利用率降低，存活率高时复制成本巨大 |
| 标记-整理 | 是 | 无 | 老年代，对象存活率高 | 移动对象和更新引用的成本高，STW延长 |
面试时如果让你对比这三种算法，理想的回答框架是先讲清楚每种算法解决什么场景的问题，再说它们为什么可以共存——新生代复制因为存活对象少很划算，老年代不适合复制，只能用清除或整理。停顿时间的矛盾点，自然而然引到收集器设计差异上。
5. 垃圾收集器的一条完整决策线：从Serial到ZGC
5.1 单线程时代到并行时代：Serial、ParNew、Parallel Scavenge
最早的Serial收集器是单线程工作的，收集过程中必须暂停所有业务线程，适合客户端应用或内存较小的场景。它虽是“最古老”的收集器，有一个地方值得注意：它没有多线程交互的开销，所以在单核CPU或极小的堆上，实际表现往往不差。
ParNew是Serial的多线程版本，利用多核CPU并行回收新生代，是JDK 8默认组合中使用的新生代收集器。Parallel Scavenge从名字就能看出它的设计目标不太一样，它着重的是可控的吞吐量。吞吐量在这里指运行用户代码时间占总运行时间的比例，这个收集器提供了两个参数：-XX:MaxGCPauseMillis控制最大垃圾收集停顿时间，-XX:GCTimeRatio直接设置吞吐量大小。
不过并行并不代表不暂停，ParNew和Parallel Scavenge的STW时间不一定比Serial短，只是停顿期间多个GC线程并行干活，同样时间内能处理的区域更大，适合多核机器上的服务端应用。
5.2 老年代的传统方案：Serial Old、Parallel Old与CMS
老年代方向的演进也分了几派。Serial Old是Serial的老年代版本，单线程标记-整理；Parallel Old是Parallel Scavenge的老年代搭档，多线程标记-整理，吞吐量优先的应用通常选这个组合。
CMS（Concurrent Mark Sweep）曾经是互联网时代最有名的老年代收集器，也是第一个真正意义上的并发收集器。它追求最短停顿时间，设计了四个阶段：初始标记、并发标记、重新标记、并发清除。其中初始标记和重新标记依然需要STW，但并发标记和并发清除阶段可以和业务线程一起跑。
CMS有两个著名的缺陷，一个是它采用标记-清除，天生会产生碎片，老年代空间碎片太多时无法分配大对象，会提前触发Full GC。另一个是它处理“并发模式失败”的预案非常笨重，如果在并发标记阶段还有新的对象进入老年代导致预留空间不足，JVM会直接抛弃CMS的并发流程，退回Serial Old做一次漫长的Full GC。生产中经常能看到这种情况，简单说：CMS虽然设计得很美，但运行风险可控性比较差。这也解释了为什么它后来会被G1取代。
5.3 G1：从分代管理转向分区管理，一次架构上的范式转换
G1在JDK 9之后成为默认收集器。它不再严格地把堆划分为物理上独立的年轻代和老年代，而是把堆划分为一个个大小相等的Region，每个Region在逻辑上动态扮演Eden、Survivor或者Old的角色。这是一种“逻辑分代、物理分区”的思路，目标是兼顾可预测停顿与整体效率。
G1处理垃圾时并不要求全堆统一回收一次，而是跟踪各个Region里垃圾堆积的价值，优先回收垃圾最多的Region，并且在回收过程中维护一个停顿时间预测模型，通过-XX:MaxGCPauseMillis这个参数来控制每次回收的预期停顿。这也是“Garbage First”名字的来历——优先搞定垃圾最多的区域。
G1还有一个容易考到的点：跨区域引用问题的处理。Region之间存在互相引用，它为此设计了Remembered Set（记忆集），用卡表记录哪些Region的对象被外部引用了。回收时可以只扫描相关记忆集，避免全堆扫描。代价是维护记忆集会占用一些内存和运行开销，有时候这开销还不小，所以不能光看G1暂停短的优点。
5.4 ZGC与Shenandoah：把停顿压到亚毫秒
ZGC设计目标非常激进，不仅要支撑TB级别的堆，还要把GC停顿时间控制在10毫秒以内。从G1到ZGC，停顿时间降低的关键是引入了染色指针和读屏障。染色指针在对象指针的未使用位上记录状态，让GC线程能够安全地在业务线程运行的过程中移动对象，同时通过读屏障确保并发场景下业务线程访问到的引用永远是最新的。
ZGC的并发整理能力让老年代回收不再需要停止整个世界，这在超大规模堆和超低延迟场景里意义重大。Shenandoah走的是另一条技术路线，它也追求低停顿，同样使用并发转移，但对指针的处理方式完全不一样，这涉及具体的实现细节，真正回答的时候不用展开太深，重点说清楚它和ZGC的设计目标一致但技术路径不同。
选择哪款收集器，本质上是在吞吐量、停顿时间和内存占用之间找平衡。下面这张表能帮助快速定位：
| 收集器 | 工作模式 | 适用堆大小 | 核心特点 | 典型适用场景 |
|---|---|---|---|---|
| Serial / Serial Old | 串行 | 小堆 | 简单、无额外开销 | 客户端、单核环境 |
| ParNew / CMS | 并行+并发 | 中大型堆 | 低暂停经典方案 | JDK 8及以前的互联网服务 |
| Parallel Scavenge / Parallel Old | 并行 | 中大型堆 | 吞吐量优先 | 后台计算、批处理任务 |
| G1 | 分区+并发 | 大堆 | 可预测停顿，平衡性好 | JDK 9+的通用服务器应用 |
| ZGC | 并发 | 超大堆 | 亚毫秒级停顿 | 超大堆、超低延迟场景 |
6. 实战里怎么确定收集器和内存参数：从默认值到决策链
6.1 别一上来就调参，先用默认值跑通并看清数据
很多调优新手拿到一个服务就问：堆给多大？用G1还是CMS？MaxGCPauseMillis设置成多少？这种问法本身就是有问题的。调优的前提是有数据，没有监控数据、没有GC日志，调参纯粹是盲人摸象。
我自己的方法是四步走。第一步，把服务的GC日志打开，用G1时建议配合这些参数：-Xlog:gc*:file=gc.log:time,uptime,level,tags:filecount=10,filesize=20m，然后让服务在线下压测环境里按线上流量比例跑一段时间。第二步，看四类关键数据：YGC频率、每次YGC耗时、Full GC频率、每次Full GC耗时。第三步，判断这四类数据是否在可接受范围内。都正常，那就别动参数；不正常，再判断是分配速率太高、存活对象太多、还是晋升过早。第四步，根据判断结果沿着参数决策链逐项调整。
线上压测没跑就直接去调参，是我见过的导致各种诡异事故的最大原因。任何GC参数调整，都必须有前后的数据对照，否则无法评价是变好还是变坏。
6.2 三条最基础的参数决策链
先说堆大小的设定。生产上常见的初始方案是-Xms和-Xmx设置为一致。这里的逻辑并不是说堆一定要多大才好，而是避免在运行期动态扩容带来的性能抖动。堆的合理大小要结合实例规格来定，比如容器内存8G时，堆设定为5G到6G是一条常见的经验区间，剩下的留给堆外。
其次是新生代大小。新生代越大，Minor GC频率越低，每次停顿可能越久；新生代越小，Minor GC越频繁，但单次停顿短。在G1种，-XX:NewRatio的默认值是2，意思是老年代占两份、新生代占一份。对延迟敏感的小对象请求型应用，适当提高新生代比例能减少对象过早晋升；对大批量数据处理型应用，反而需要更高的老年代占比来容纳长期存活数据。
第三，MaxGCPauseMillis，这个参数影响了G1的停顿预测机制。设置太小，会导致G1频繁做回收以试图压住停顿，反而增加GC总开销；设置太大，停顿不可控。比较稳妥的做法是先设一个相对宽松的值，比如200ms，观察实际GC行为，再逐步下调到能稳定的阈值。
6.3 看GC日志能看出什么名堂来，举两个链路
假如线上用的还是JDK 8的默认组合Parallel Scavenge加Parallel Old，日志里频繁出现类似：
code复制[Full GC (Ergonomics) [PSYoungGen: 2048K->0K(7168K)] [ParOldGen: 101376K->102400K(102400K)] 103424K->102400K(109568K), [Metaspace: 34086K->34086K(34088K)], 0.2330222 secs]
注意观察ParOldGen的前后变化：老年代回收后几乎没降下来。这说明占住老年代的是长期存活对象或大对象，不是临时对象晋升导致的震动。这种Full GC不解决核心问题，再调年轻代比例治标不治本，得去查有没有对象被错误地长期持有，或者大对象是否可以直接绕开新生代。
另一个链路是最典型的CMS碎片问题。日志里出现“promotion failed”和“concurrent mode failure”，CMS并发清除后找不到连续空间给大对象分配，于是触发Full GC并退回Serial Old。要处理，一是参数层面调大老年代空间，或者打开-XX:UseCMSCompactAtFullCollection（在Full GC时做碎片压缩），二是排查代码层是否有大量大对象或长期存活对象被频繁创建。这类问题的根因排掉之后，另一个替代方案更直接，就是用G1替换掉CMS，因为它天生是整理式回收，没有碎片问题。
7. 线上GC延迟排查，一条真实链路复盘
7.1 现象与初期判断
有一个比较典型的案例，某中间件服务，功能本身不复杂，主要扛在线流量。监控面板显示，每隔大概6到8小时，就会有一次响应时间尖刺，TP99从几十毫秒跳到一两秒，尖刺过后业务自动恢复。服务的机器规格和堆配置看起来都很常规，8G堆，JDK 8跑在Parallel组合上。
从GC日志看一分钟内的GC频率并不算异常，YGC大约几十秒一次，停顿也在100毫秒左右，看不出明显毛病。但把时间线拉长到小时级，能看到每天有几个固定时间点后跟随着一次Full GC，而这个时间点对应的是某个定时任务做完批量缓存刷新的时间。
7.2 深挖根因：谁把老年代塞满了
顺着定时任务时间点排查，很快就发现这个任务会把一批热点数据加载进本地内存缓存，且缓存持有方式用的是static Map，没有设置过期时间。到了第二个周期，新数据加载前会把旧缓存手动清掉，但清掉的key对应的value在新数据写入前还被别的线程引用着，这些对象占用的内存比想象中大得多。
这个任务触发的同时，YGC频繁发生，存活对象一多，Survivor区装不下，大量对象被迫晋升到老年代。走读代码还发现这个任务的执行线程里有一个局部大List，把查出来的全量结果一次性放到内存里做过滤，这个大List超过JVM的PretenureSizeThreshold后直接进了老年代。数轮叠加之后，老年代空间被消耗到触发Full GC，就出现了响应时间尖刺。
7.3 治理方案不是光调参
这个问题的修复不是把-XX:MaxGCPauseMillis调小几毫秒，而是做了三件事：第一，把本地缓存改为带容量上限的Caffeine缓存，配合软引用存储value，并在配置上启用定期清理；第二，把批量任务里的大List改成分页处理，避免一次性加载全量数据到堆内；第三，在老年代使用率超过70%时接入了内存用量告警，避免每次都要等到Full GC来被动兜底。
调整之后，同样的业务高峰期下，YGC频次降了一半左右，Full GC基本从日志里消失，响应时间尖刺也不再出现。这个案例最大的价值在于，不是GC本身有问题，而是应用代码在内存使用方式上埋了雷，GC只是引爆器。
8. 面试高频追问：这些问题答不好，前面全白讲
8.1 对象什么时候进入老年代，能不能把规则说全
这道题基本上可以当做一个综合检查题，考察的是对GC全流程的理解。答题要点至少包含四条线：一是年龄阈值，对象在Survivor区每熬过一次Minor GC年龄加一，达到-XX:MaxTenuringThreshold默认值（Parallel组合里是15）时晋升；二是动态年龄判定，如果Survivor中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于等于该值的对象就可以直接晋升，不需要等达到阈值；三是大对象直接进入老年代，通过-XX:PretenureSizeThreshold控制，主要为了避免大对象在新生代里来回复制；四是分配担保机制，Survivor区空间不足时，多余存活对象会直接进老年代。
面试官如果问得再深一点，可以补充：晋升阈值并不是固定生效的，它受Survivor空间实际承载能力约束，如果存活对象体积已经明显大于Survivor容量，JVM会启动提前晋升机制，而不会强行等待阈值。
8.2 Full GC和Major GC到底怎么区分
这里有一个特别容易混淆的概念。Minor GC清理新生代，Major GC一般指的是清理老年代，但不少资料里Major GC和Full GC是混着用的。按HotSpot源码和官方文档的表达习惯，Major GC通常指老年代的回收，而Full GC清理范围覆盖整个堆，包括新生代、老年代、元空间等在内。但由于老年代GC和Full GC在传统收集器上经常是同一过程，所以混淆特别普遍。
建议直接跟面试官对齐定义，然后说明：在实际排查里其实不用过度纠结叫法，更关键的判断是这次GC的停顿时间有没有影响到业务，以及日志里回收前后的内存占用是否有效下降。很多线上问题里“Full GC频繁”，本质是“每次回收老年代但内存释放极少”，那就要查存活对象不合理增长的问题。
8.3 并发收集器的三色标记法会漏标吗
CMS和G1都是并发收集器，面试深入时会追问它们的正确性保障。三色标记法把对象分为白色（未访问）、灰色（自身已访问但其引用对象还没访问）、黑色（自身和引用对象都访问完成）三种，用来描述并发标记的过程。并发标记过程中业务线程可能修改引用关系，就可能出现两种问题：一种是把黑色对象引用的一个白色对象漏标了，导致活对象被误回收；另一种是已经标记成白色的对象重新被扫到。
为解决并发时的标记正确性，JVM采用两种手段之一：增量更新，例如CMS，它在黑色对象重新引用了白色对象时，把该黑色对象记录下来，重新标记阶段再度扫描；或者原始快照，G1，它在并发标记开始时把整个对象图快照保存下来，之后只要引用关系发生变化，就把变化记录下来，重新标记阶段按原始状态处理。这两套机制的核心目的都是防止活对象在并发标记中被漏掉。
如果你能把这个演进逻辑答出来，面试官基本能确认你确实理解并发GC的实现难点，而不只是会背名词。
8.4 安全点与安全区域：STW不是想停就能停
最后补充一个容易被忽略的知识点。GC发生STW时，不可能让线程在任何一条指令处都停下，不是想停就能停的。JVM要求线程执行到“安全点”才能暂停。安全点一般选在循环跳转、方法调用、异常跳转这类指令上。在安全点上，线程的寄存器状态、栈状态都是确定的，GC才能准确扫描它的引用关系。
如果线程在安全点执行过程中一直没到达，JVM就需要等它到达。忙等不够优雅时，有参数比如-XX:+UseCountedLoopSafetyCheck，它控制的是循环是否可以被认为是安全点。长时间运行的空循环代码如果没有安全点，可能导致这个线程迟迟无法被挂起，GC一直卡在“等待线程到达安全点”的阶段，表现为STW时间不正常地变长。排查这种问题时，可以从JVM的线程转储里观察到大量RUNNABLE状态的业务线程，它们实际停在某个特定指令上等待被挂起。
安全区域是对安全点的补充，它表示代码片段中引用关系不会发生变化，线程在进入安全区域时可以告知JVM，GC在扫描时就不用等它了。
9. 我的取舍心得：别盲目追新，也不要老抱着旧参数不放
最后这段算是我个人实践沉淀下来的几条判断标准。
第一，JDK版本和收集器升级要一起规划，不要只改JDK大版本还沿用旧的GC参数。比如从JDK 8升到JDK 11，默认收集器已经从Parallel换成了G1，如果你还带着之前的CMS参数跑，其实很多参数已经没有意义了。升级之前建议把无意义的参数清理掉，用新版本默认值跑一段时间，再按数据决定是否调整。JDK 17之后G1用起来顺手很多，ZGC在JDK 21里也进入了生产可用状态，但这不代表每个项目都该切ZGC，它更擅长超大堆和极低延迟的场景，常规的服务在G1下已经能把问题处理得很好。
第二，判断GC问题前先把代码问题排除掉。很多线上GC故障的根因其实是明显的代码级内存误用，比如不合理的静态缓存、线程内数据无界增长、大对象频繁创建、连接池对象没复用。这类问题调GC参数只是掩盖症状，真正修复代码后GC立刻恢复正常。所以我的排查顺序永远是代码路径、内存占用构成、堆内外增长曲线，最后才是收集器参数。
第三，调优是持续验证的过程，不是上线前的一次性动作。我会在每个发布迭代后都看一眼GC日志的核心指标，这花不了多少时间，成本很低。一些客观指标，比如GC平均停顿、Full GC发生次数、老年代内存增长斜率，只要出现趋势性恶化，尽早发现比事后抢救要容易得多。
以上就是我梳理JVM和GC体系时的完整思考路径。核心在于它本质上是一套内存管理和延迟控制策略，所有算法和参数都是针对不同场景的取舍，记住这个主线，面试时就不再是背答案，线上排查时也不再是无头苍蝇。