JVM垃圾回收面试题几乎可以说是Java面试的“必考大题”。无论校招还是社招面试官基本都会从内存模型切入一路追问到垃圾回收的算法、收集器、调优参数。很多候选人基础题背得滚瓜烂熟一到“为什么这样设计”“两者对比怎么选”就卡壳。这篇文章把JVM垃圾回收环节的高频面试题按知识链路拆开从对象判活讲到三色标记从Serial收集器一路聊到ZGC配合我实际面试和被面试的经验给出一份可以直接拿来复习、也能当“考前冲刺提纲”的完整梳理。如果你是准备面试的Java开发或者工作两三年想系统补一下JVM底层的同学这文章值得花二十分钟从头读到尾。已经对GC有经验的人可以直接跳到第五章的调优实战和第六章的高频问答速查。1. 对象判活垃圾回收先回答“回收谁”1.1 引用计数法为什么被淘汰面试官特别喜欢从“怎么判断一个对象该被回收”开始问。最直观的方案是引用计数每个对象维护一个计数器被引用就加一引用失效就减一归零就回收。听起来很完美但有一个绕不过去的坑——循环引用。两个对象互相持有对方外部没有任何引用了引用计数依然不为零这两个对象就永远无法回收。经典场景是父子节点互相关联class Node { public Node parent; public ListNode children new ArrayList(); } // 构建互相引用的对象图后从外部移除引用这段代码在实际运行中引用计数法无法回收这个对象图。所以主流JVM都没有采用引用计数而是用可达性分析。1.2 可达性分析与GC Roots可达性分析的思路很朴素从一组称为“GC Roots”的根对象出发沿着引用链往下走能走到的对象就视为存活走不到的就是可回收垃圾。这个概念用生活化类比就是地铁路网GC Roots是始发站能到达的所有站点都是活人住的到不了的站就是废弃站。面试常问的进阶点是“GC Roots包含哪些”。按HotSpot实现主要包括虚拟机栈中局部变量表引用的对象正在执行的方法里的参数、局部变量静态变量引用的对象方法区中类静态属性常量引用的对象字符串常量池等JNI引用的对象Native方法中引用的Java对象同步监视器锁持有的对象被synchronized锁住的对象JVM内部的引用系统类加载器、基本类型Class对象等回答这个问题的关键不是背全而是理解“根”的共同特征它们都是当前存活的、外界可以直接触达的入口。面试官接着问“GC Roots管理和谁相关”你可以顺带提一句和线程栈、方法区、JNI这三块运行时数据区强相关这也解释了为什么判断对象存活必须STW——因为要保证引用关系在分析期间不变化。1.3 四种引用类型与ThreadLocal内存泄漏判活之后常跟着“四种引用有什么区别”。强引用、软引用、弱引用、虚引用很多候选人能背定义但说不清场景。强引用就是正常Object obj new Object()只要强引用还在GC宁可抛OOM也不回收。软引用在内存充足时不回收内存不足时才回收典型场景是缓存框架像MyBatis的缓存、一些图片加载库都会用SoftReference做内存敏感的缓存。弱引用更短命每次GC只要发现就被回收典型场景是ThreadLocal的ThreadLocalMap。ThreadLocal的Entry为什么设计成弱引用这是面试官最爱追问的细节。ThreadLocalMap里Entry继承WeakReferencekey是ThreadLocal的弱引用value还是强引用。好处是ThreadLocal对象失去外部强引用后key在下一次GC即被清理Entry变为“key为null”value虽然还存在但至少避免了key无法回收的问题。遗留的value就是“内存泄漏”隐患——这也是必须在finally里调用remove()的原因。回答到这里把“弱引用解决key回收问题remove解决value残留问题”讲清楚这一串基本就是加分回答。虚引用不能通过get()拿到对象唯一用途是对象被回收时收到系统通知。主要用于堆外内存的回收追踪比如NIO的DirectByteBuffer就是通过虚引用关联Cleaner实现堆外内存释放。安全校验注意不要写成“虚引用能让对象复活”那是finalize的机制下文单独讲。1.4 finalize与对象自救finalize是古老的兜底机制面试常问但实际工作中没人用。一个对象覆盖了finalize()方法并且第一次标记为不可达时会进入F-Queue等待执行finalize执行期间如果重新被引用就能“自救”不被回收。但注意finalize只执行一次第二次不可达就直接回收了。这个机制设计的初衷是类似C析构函数的资源释放但问题很多执行时机不确定、性能差、可能复活意外对象所以早已被官方标记为不推荐使用。面试答到这个点时补充一句“用try-with-resources或者Cleaner机制替代”就能体现你了解现代写法。2. 回收算法与分代收集面试官递进提问的套路2.1 三大基础GC算法对比对象判活解决“谁是垃圾”接下来就是“怎么回收”。基础算法就三个标记-清除、标记-复制、标记-整理。标记-清除是两阶段先标记可回收对象再统一回收。问题有两个一是产生大量不连续的内存碎片后续分配大对象可能因找不到连续空间提前触发GC二是标记和清除两个阶段效率都不高。这个算法是后面所有方案的“地基”但实际使用中很少单独用。标记-复制把内存分成两块只使用一块回收时把存活对象整体复制到另一块再清空当前块。优点是没有碎片、分配简单缺点是浪费一半空间。HotSpot的新生代就是这个算法的变体——不按1:1分而是Eden:Survivor 8:1用一块Eden加两块Survivor把浪费压缩到10%。标记-整理面向老年代标记存活对象后把存活对象往一端移动再清理边界外的内存。避免了复制的高开销也解决了碎片问题但移动对象需要更新所有引用这个过程中必须STW。面试真题往往是对比题“复制算法和整理算法各自适合哪一代为什么”新生代对象存活率低复制成本小老年代存活率高复制一遍太贵整理更划算。这个答案能引到分代收集。2.2 分代假说与堆内存划分分代收集不是什么高深概念核心是两条经验统计规律绝大多数对象朝生夕灭熬过多次GC的对象越难被回收。用IBM研究的数据来说新生代对象98%活不过第一轮GC。既然存活率这么低用复制算法很划算老年代对象存活率高用标记-整理或标记-清除。堆内存划分为新生代Young和老年代Old。新生代又拆为Eden和两个Survivor区默认比例Eden:S0:S1 8:1:1可以通过-XX:SurvivorRatio调整。为什么需要两个Survivor因为复制算法需要一块空的保留区来放存活对象一块不够用。两个Survivor轮流当from和to保证每次复制后总有一块干净区域。还有一块常被忽略的“元空间”JDK8以后方法区被移到了元空间。元空间使用本地内存默认不受堆大小限制但依然需要GC来回收废弃的类和无用的常量。2.3 Minor GC完整流程与对象晋升规则把对象分配和GC流程串起来是面试中“连环问”的高发区。新对象分配路径优先在Eden区分配Eden不够时触发Minor GC也叫Young GC。Minor GC过程可以背诵式描述Eden区存活对象复制到S0from区年龄1S0from区的存活对象复制到S1to区年龄1原Eden和from区清空from和to交换身份年龄达到阈值默认15的对象晋升到老年代这里面试官会立刻追问晋升条件只有一个年龄阈值吗当然不是。至少还有四个大对象直接进老年代动态年龄判定空间分配担保失败Survivor区装不下的对象直接晋升老年代。动态年龄判定是容易被忽略的点。HotSpot不是等所有对象都到15岁才晋升而是统计Survivor中同龄对象大小总和如果超过Survivor空间的一半年龄大于等于这些对象的就直接晋升。这个设计是为了适应不同应用的对象年龄分布。大对象默认阈值临界点是-XX:PretenureSizeThreshold大于该值的对象直接进老年代避免在Eden和Survivor之间来回复制。但注意这个参数只对Serial和ParNew有效搭配Parallel收集器时不生效。空间分配担保是另一个高频考点。Minor GC前JVM会检查老年代最大可用连续空间是否大于新生代所有对象总大小如果大于本次Minor GC可以确保安全如果小于再看-XX:HandlePromotionFailure是否允许担保失败。允许时冒险试试不行再触发Full GC不允许就直接Full GC。JDK6以后这个开关默认开启且废弃当出现“担保失败”时老年代会进行一次Full GC回收空间代价是停顿时间显著上升。2.4 Full GC的触发条件Full GC是老年代的GC一般伴随Metaspace回收。触发条件包括老年代空间不足、Metaspace空间不足、调用System.gc()只是建议但通常也会触发、CMS并发模式失败、分配担保失败等。面试常踩的坑是把Full GC和Major GC混为一谈。严谨地说Major GC指老年代的GCFull GC指对整个堆新生代老年代元空间的GC。比如Parallel收集器下Full GC实际同时回收新生代和老年代用的还是单线程的Serial Old算法。性能杀手就是Full GC全堆扫描、STW时间长、执行完后可用空间依然不足时会连续Full GC直至OOM。3. 并发回收的三座大山STW、安全点、三色标记3.1 为什么垃圾回收必须STW“为什么GC要暂停所有用户线程”是面试官必问的底层题。直接原因是可达性分析必须基于一个稳定快照如果在分析过程中引用关系不断变化要么漏标存活对象导致误回收致命要么多标垃圾对象导致回收不彻底可接受但会积累浮动垃圾。为了保准确HotSpot最朴素的方案就是暂停业务线程也就是STWStop The World。这里常有个误解STW不是所有收集器的固有问题而是“枚举根节点”和“移动对象”时的必要手段。CMS的初始标记和最终标记阶段依然要STW只是把最耗时的并发标记阶段做成了用户线程同时运行。G1、ZGC更是通过并发根扫描和并发标记进一步缩短STW。3.2 安全点与安全区域STW不是想停就能停线程必须在“安全点”停下。安全点是JVM预设的指令位置比如方法调用、循环跳转、异常跳转等。在这些位置停下才能保证线程状态一致不会出现栈帧正在被修改、寄存器中的引用无法枚举的情况。一个线程从开始执行到安全点之间的时间被称为“安全区域外的运行时间”。如果用-XX:UseCountedLoopSafetyCheck这类参数优化循环次数过多可能导致线程迟迟进不了安全点这在高并发低延迟场景是个隐患。除了安全点还有安全区域的概念线程进入Sleep或Blocked状态时无法响应中断请求因此只要进入安全区域GC就可以认为该线程“已暂停”不需要等它响应。面试答到这个层面面试官能感受到你不只是背概念而是真的理解线程运行状态和GC的交互。3.3 三色标记算法与漏标问题三色标记是并发标记的理论模型很多候选人栽在这里。把对象分成三种颜色白色未被访问、灰色自身被访问但引用子对象未被全部访问、黑色自身和引用子对象都被访问。从GC Roots出发初始时根对象为灰色不断把灰色对象标记为黑色、把白色引用对象标记为灰色直到没有灰色对象剩下的白色就是可回收对象。并发标记的难点不是标记本身而是“一边标记、一边改引用”会漏标。经典的漏标场景黑色对象A原本没有引用C标记过程中A新增了引用指向C而C还没被访问到此时如果标记线程已经处理完A就不会再去扫描A的新引用C就会被误判为垃圾。漏标必须满足两个条件黑色对象新增了指向白色对象的引用该白色对象的所有灰色引用被删除。只要打破任一条件就不会漏。因此两种解决方案诞生了增量更新Incremental Update记录黑色对象新增的引用最终标记阶段重新扫描这些引用。CMS采用。原始快照Snapshot At The BeginningSATB记录被删除的灰色引用并发标记期间把这些引用指向的对象当作存活对象处理。G1采用。面试回答这个点最好画一个简单示意口头描述A、B、C三个对象的引用变化然后分别解释增量更新和SATB如何打破漏标条件。能说清楚“增量更新是记录新增、SATB是记录删除”已经能区分绝大多数候选人。4. 收集器选型从Serial聊到ZGC4.1 经典收集器组合速查收集器矩阵是面试经典环节。HotSpot JDK8默认是Parallel Scavenge Parallel OldJDK9以后默认G1JDK11起ZGC成为可选项JDK21正式GA了ZGC的分代模式。下面这张表建议记牢收集器适用代算法线程特点Serial新生代复制单线程简单Client模式默认单核友好ParNew新生代复制多线程CMS的默认搭档追求低延迟Parallel Scavenge新生代复制多线程关注吞吐量可自适应调节Serial Old老年代标记-整理单线程CMS失败的后备方案Parallel Old老年代标记-整理多线程与Parallel Scavenge配套CMS老年代标记-清除并发低延迟有碎片和浮动垃圾问题G1全堆Region复制整理多线程可预测停顿JDK9默认ZGC全堆Region并发整理多线程超低停顿停顿不随堆增长面试官大概率问“你项目用的什么收集器”。千万不要报个“G1默认”就完了要能说出为什么选它。常见答法业务对延迟敏感G1支持指定最大停顿时间且能做到并发收集适合大堆如果追求吞吐量且对停顿不敏感Parallel更合适。4.2 CMS的运行流程与经典坑点CMSConcurrent Mark Sweep是低延迟时代的代表四个阶段初始标记STW标记GC Roots直接关联的对象很快并发标记从GC Roots开始遍历对象图和用户线程并发重新标记STW修正并发期间引用变化导致的漏标用增量更新并发清除和用户线程并发清理垃圾对象两个经典坑必须掌握。第一个是“并发模式失败”并发标记或清除期间老年代空间被用户线程的新对象耗尽CMS无法继续并发收集只能退化为Serial Old单线程Full GC停顿时间瞬间飙升。解决方法预留足够空间-XX:CMSInitiatingOccupancyFraction例如设68%让CMS在老年代用到68%时就开始收集避免撑满或调大堆内存。第二个坑是内存碎片。CMS用标记-清除算法不整理内存运行久了老年代碎片化严重大对象分配困难提前触发Full GC。解决方案是开-XX:UseCMSCompactAtFullCollection在Full GC时进行碎片整理但会增加停顿。现代JDK8u和JDK9已经逐步废弃CMS面试只需说明原理和缺点不要推荐生产环境再用CMS。4.3 G1的核心设计Region、RSet与回收集G1Garbage First是目前工作的主力面试地位极高。它的核心创新是把堆划分为大小相等的Region默认2048个每个Region独立扮演Eden、Survivor、Old或Humongous大对象区。Region的引入让G1不必对整个堆做GC每次只回收一部分Region实现“可预测的停顿”。G1的另一个核心是RSetRemembered Set用来记录哪些Region中的对象引用了当前Region。说白了就是跨Region引用的“反向指针索引”。当GC需要扫描某个Region的存活对象时不用全堆扫描只要查RSet就能知道谁引用了它。RSet的建立和维护依赖写屏障这也是“每条引用赋值指令都需要额外开销”的原因。G1的回收过程可以概括为初始标记STW标记GC Roots直接关联对象在Minor GC顺带完成并发标记三色标记用SATB记录引用删除避免漏标最终标记STW处理SATB队列中的引用记录筛选回收STW根据RSet统计各Region的回收价值和成本计算性价比优先回收垃圾最多的Region“Mixed GC”概念常被问到G1的回收不只是老年代而是从所有Region中挑选回收价值最高的若干Region。回答时提一句“筛选阶段会计算每个Region的回收收益和耗时选择垃圾占比高、回收成本低的Region”就能体现你理解了G1为什么叫Garbage First。G1的停顿时间由-XX:MaxGCPauseMillis指定目标但注意这不是硬性保证只是一个预测模型。G1会基于历史数据估算每个Region的回收耗时尽量让停顿控制在目标以内。如果堆非常大比如上百GBG1的RSet维护成本会明显上升这就是为什么ZGC在超大堆上更占优势。4.4 ZGC颜色指针与读屏障ZGC是追求极致低延迟的收集器。最吸引人的特性是GC停顿时间不随堆大小线性增长JDK16以后ZGC支持在16TB堆上以几十毫秒内完成GC。ZGC的关键技术是染色指针Colored Pointer。在64位Linux上ZGC把对象指针的前几位用作标记位用来记录对象状态Marked0、Marked1、Remapped、Finalizable。GC标记时不需要访问对象本身直接在指针上操作状态位即可。ZGC还引入了读屏障每次从堆中加载引用时读屏障会检查指针状态如果指针指向的对象需要重定位就立即修正指针。这个设计让“对象移动”和“用户线程访问对象”可以并发进行这就是ZGC能实现极短STW的根本原因。面试中只要把“ZGC把GC信息放进指针本身通过读屏障并发修正引用”讲清楚面试官就会比较满意。如果追问面向对象内存,可以说ZGC初始化时会保留一段虚拟地址空间用于映射多个视图这也是加载指针能实现单次解引用的前提。5. 调优与排查面试加分项与实战技巧5.1 常用GC参数速查面试不仅问原理还问“你平时怎么调优”。常用参数要能随口报出参数作用-Xms / -Xmx初始堆/最大堆-Xmn新生代大小-XX:SurvivorRatioEden/Survivor比例默认8-XX:MaxTenuringThreshold晋升阈值默认15-XX:PrintGCDetails打印GC日志JDK9前-Xlog:gc*JDK9统一日志-XX:HeapDumpOnOutOfMemoryErrorOOM时自动导出堆快照-XX:MaxGCPauseMillisG1目标停顿时间-XX:ConcGCThreads并发GC线程数注意一个细节-Xlog:gc*是JDK9以后统一日志体系的写法老参数-XX:PrintGCDetails在JDK9虽然还能生效但推荐迁移到新语法。面试时能主动提这一点说明你用过新版本。5.2 GC日志分析实战翻GC日志是定位问题的入口。举个例子JDK8下用-XX:PrintGCDetails日志片段长这样[GC (Allocation Failure) [PSYoungGen: 61440K-8191K(71680K)] 122880K-65407K(190464K), 0.0234567 secs] [Full GC (Ergonomics) [PSYoungGen: 32767K-0K(71680K)] [ParOldGen: 131512K-147456K(182272K)] 163471K-147456K(254080K), 1.2345678 secs]解析要点Allocation Failure本次Minor GC因Eden区分配失败触发箭头前是GC前占用箭头后是GC后占用括号里是总量0.0234 secs是本次GC耗时PSYoungGen和ParOldGen说明用的是Parallel收集器Full GC的耗时往往数倍于Minor GC连续多个Full GC日志就是内存泄漏的典型信号确认堆内存不足时排查顺序应该是先看OS物理内存和容器限制再看进程启动参数最后才是业务代码。很多“频繁Full GC”其实是-Xms和-Xmx不一致导致堆反复伸缩GC触发频繁。生产经验是-Xms和-Xmx设置相同避免运行时扩容带来的额外负担。5.3 常见性能问题排查思路面试常问“线上频繁Full GC你怎么排查”。我给一个实战套路jstat -gcutil pid 1000连续观察看到FGC次数不断增长、FCTFull GC时间持续增加基本确认Full GC频繁jmap -dump:formatb,fileheap.bin pid导出堆快照再用MAT或VisualVM分析找大对象和“类加载器泄漏”MAT中看Dominator Tree挑Retained Heap最大的对象追到业务代码如果是System.gc()触发的查代码里有没有显示调用如果是CMS触发查CMSInitiatingOccupancyFraction是否设置过小用jstat -gcutil看Eden、Survivor、Old各自的占用趋势定位是对象分配过快还是回收不了一个容易被忽略但很实际的技巧是排查GC之前先确认是不是CPU限制导致GC线程抢不到CPU很多“GC停顿异常长”其实是CPU配额不足这时调整GC参数是没用的得先解决资源问题。6. 高频问答速查表面试前10分钟必背清单最后把高频问题浓缩成表格适合面试前一天快速过一遍问题核心答法判断对象存活的方法可达性分析GC Roots起点GC Roots有哪些栈引用、静态变量、常量、JNI、锁、JVM内部四种引用区别强引用不会回收软引用内存不足回收弱引用每次GC回收虚引用回收通知复制算法适合哪代新生代对象存活率低复制开销小CMS为什么有碎片标记-清除不整理内存解决需Compact三色标记漏标的原理黑色对象新增白色引用同时该白色引用被删除增量更新或SATB修复G1和CMS的区别G1按Region回收可预测停顿CMS标记-清除低延迟但有碎片Full GC触发条件老年代满、元空间满、担保失败、System.gc生产环境怎么选收集器延迟敏感选G1/ZGC吞吐优先选Parallel调优基本步骤确认目标资源配置日志监控定位瓶颈这个表可以作为冲刺记忆卡但请记住面试官不会照着表问他们会把一个表中的点横向展开问到你怎么排查、为什么这样选、遇到过什么问题。只有把前面的原理真正理解了这张表才是加分项否则就是背题模板。7. 我聊几个真实面试中的感受做面试官这些年我最深的感触是候选人背题和真懂的区别非常明显。问“什么是可达性分析”几乎人人会答但追问“为什么可达性分析必须STW”很多人开始支支吾吾。再追问“如果有一种收集器不需要STW做标记应该怎么做”能聊出三色标记和SATB的人就明显少了一大截。如果你准备面试建议不要只盯着收集器对比表背而是把“对象分配→Minor GC→晋升→Full GC→并发标记→三色标记→各种收集器设计取舍”当成一条流水线去理解。顺着这条线走一遍从原理到实战会非常顺畅。这个思路不仅对面试有效日常排查线上问题也会少走很多弯路。最后分享一个我在实际调优中反复验证过的经验所有GC参数都要结合监控数据调整不要上来就抄别人的参数组合。我见过太多“面试背了一堆参数生产直接套用然后出问题”的例子。-Xms、-Xmx设置相等、根据对象分配速率调-Xmn、根据停顿目标选G1还是Parallel这些基础决策做好比追求冷门参数有意义得多。真正的JVM调优永远是先有监控数据再有针对性调整最后用数据验证效果而不是靠参数堆砌。
JVM垃圾回收面试题几乎可以说是Java面试的“必考大题”。无论校招还是社招面试官基本都会从内存模型切入一路追问到垃圾回收的算法、收集器、调优参数。很多候选人基础题背得滚瓜烂熟一到“为什么这样设计”“两者对比怎么选”就卡壳。这篇文章把JVM垃圾回收环节的高频面试题按知识链路拆开从对象判活讲到三色标记从Serial收集器一路聊到ZGC配合我实际面试和被面试的经验给出一份可以直接拿来复习、也能当“考前冲刺提纲”的完整梳理。如果你是准备面试的Java开发或者工作两三年想系统补一下JVM底层的同学这文章值得花二十分钟从头读到尾。已经对GC有经验的人可以直接跳到第五章的调优实战和第六章的高频问答速查。1. 对象判活垃圾回收先回答“回收谁”1.1 引用计数法为什么被淘汰面试官特别喜欢从“怎么判断一个对象该被回收”开始问。最直观的方案是引用计数每个对象维护一个计数器被引用就加一引用失效就减一归零就回收。听起来很完美但有一个绕不过去的坑——循环引用。两个对象互相持有对方外部没有任何引用了引用计数依然不为零这两个对象就永远无法回收。经典场景是父子节点互相关联class Node { public Node parent; public ListNode children new ArrayList(); } // 构建互相引用的对象图后从外部移除引用这段代码在实际运行中引用计数法无法回收这个对象图。所以主流JVM都没有采用引用计数而是用可达性分析。1.2 可达性分析与GC Roots可达性分析的思路很朴素从一组称为“GC Roots”的根对象出发沿着引用链往下走能走到的对象就视为存活走不到的就是可回收垃圾。这个概念用生活化类比就是地铁路网GC Roots是始发站能到达的所有站点都是活人住的到不了的站就是废弃站。面试常问的进阶点是“GC Roots包含哪些”。按HotSpot实现主要包括虚拟机栈中局部变量表引用的对象正在执行的方法里的参数、局部变量静态变量引用的对象方法区中类静态属性常量引用的对象字符串常量池等JNI引用的对象Native方法中引用的Java对象同步监视器锁持有的对象被synchronized锁住的对象JVM内部的引用系统类加载器、基本类型Class对象等回答这个问题的关键不是背全而是理解“根”的共同特征它们都是当前存活的、外界可以直接触达的入口。面试官接着问“GC Roots管理和谁相关”你可以顺带提一句和线程栈、方法区、JNI这三块运行时数据区强相关这也解释了为什么判断对象存活必须STW——因为要保证引用关系在分析期间不变化。1.3 四种引用类型与ThreadLocal内存泄漏判活之后常跟着“四种引用有什么区别”。强引用、软引用、弱引用、虚引用很多候选人能背定义但说不清场景。强引用就是正常Object obj new Object()只要强引用还在GC宁可抛OOM也不回收。软引用在内存充足时不回收内存不足时才回收典型场景是缓存框架像MyBatis的缓存、一些图片加载库都会用SoftReference做内存敏感的缓存。弱引用更短命每次GC只要发现就被回收典型场景是ThreadLocal的ThreadLocalMap。ThreadLocal的Entry为什么设计成弱引用这是面试官最爱追问的细节。ThreadLocalMap里Entry继承WeakReferencekey是ThreadLocal的弱引用value还是强引用。好处是ThreadLocal对象失去外部强引用后key在下一次GC即被清理Entry变为“key为null”value虽然还存在但至少避免了key无法回收的问题。遗留的value就是“内存泄漏”隐患——这也是必须在finally里调用remove()的原因。回答到这里把“弱引用解决key回收问题remove解决value残留问题”讲清楚这一串基本就是加分回答。虚引用不能通过get()拿到对象唯一用途是对象被回收时收到系统通知。主要用于堆外内存的回收追踪比如NIO的DirectByteBuffer就是通过虚引用关联Cleaner实现堆外内存释放。安全校验注意不要写成“虚引用能让对象复活”那是finalize的机制下文单独讲。1.4 finalize与对象自救finalize是古老的兜底机制面试常问但实际工作中没人用。一个对象覆盖了finalize()方法并且第一次标记为不可达时会进入F-Queue等待执行finalize执行期间如果重新被引用就能“自救”不被回收。但注意finalize只执行一次第二次不可达就直接回收了。这个机制设计的初衷是类似C析构函数的资源释放但问题很多执行时机不确定、性能差、可能复活意外对象所以早已被官方标记为不推荐使用。面试答到这个点时补充一句“用try-with-resources或者Cleaner机制替代”就能体现你了解现代写法。2. 回收算法与分代收集面试官递进提问的套路2.1 三大基础GC算法对比对象判活解决“谁是垃圾”接下来就是“怎么回收”。基础算法就三个标记-清除、标记-复制、标记-整理。标记-清除是两阶段先标记可回收对象再统一回收。问题有两个一是产生大量不连续的内存碎片后续分配大对象可能因找不到连续空间提前触发GC二是标记和清除两个阶段效率都不高。这个算法是后面所有方案的“地基”但实际使用中很少单独用。标记-复制把内存分成两块只使用一块回收时把存活对象整体复制到另一块再清空当前块。优点是没有碎片、分配简单缺点是浪费一半空间。HotSpot的新生代就是这个算法的变体——不按1:1分而是Eden:Survivor 8:1用一块Eden加两块Survivor把浪费压缩到10%。标记-整理面向老年代标记存活对象后把存活对象往一端移动再清理边界外的内存。避免了复制的高开销也解决了碎片问题但移动对象需要更新所有引用这个过程中必须STW。面试真题往往是对比题“复制算法和整理算法各自适合哪一代为什么”新生代对象存活率低复制成本小老年代存活率高复制一遍太贵整理更划算。这个答案能引到分代收集。2.2 分代假说与堆内存划分分代收集不是什么高深概念核心是两条经验统计规律绝大多数对象朝生夕灭熬过多次GC的对象越难被回收。用IBM研究的数据来说新生代对象98%活不过第一轮GC。既然存活率这么低用复制算法很划算老年代对象存活率高用标记-整理或标记-清除。堆内存划分为新生代Young和老年代Old。新生代又拆为Eden和两个Survivor区默认比例Eden:S0:S1 8:1:1可以通过-XX:SurvivorRatio调整。为什么需要两个Survivor因为复制算法需要一块空的保留区来放存活对象一块不够用。两个Survivor轮流当from和to保证每次复制后总有一块干净区域。还有一块常被忽略的“元空间”JDK8以后方法区被移到了元空间。元空间使用本地内存默认不受堆大小限制但依然需要GC来回收废弃的类和无用的常量。2.3 Minor GC完整流程与对象晋升规则把对象分配和GC流程串起来是面试中“连环问”的高发区。新对象分配路径优先在Eden区分配Eden不够时触发Minor GC也叫Young GC。Minor GC过程可以背诵式描述Eden区存活对象复制到S0from区年龄1S0from区的存活对象复制到S1to区年龄1原Eden和from区清空from和to交换身份年龄达到阈值默认15的对象晋升到老年代这里面试官会立刻追问晋升条件只有一个年龄阈值吗当然不是。至少还有四个大对象直接进老年代动态年龄判定空间分配担保失败Survivor区装不下的对象直接晋升老年代。动态年龄判定是容易被忽略的点。HotSpot不是等所有对象都到15岁才晋升而是统计Survivor中同龄对象大小总和如果超过Survivor空间的一半年龄大于等于这些对象的就直接晋升。这个设计是为了适应不同应用的对象年龄分布。大对象默认阈值临界点是-XX:PretenureSizeThreshold大于该值的对象直接进老年代避免在Eden和Survivor之间来回复制。但注意这个参数只对Serial和ParNew有效搭配Parallel收集器时不生效。空间分配担保是另一个高频考点。Minor GC前JVM会检查老年代最大可用连续空间是否大于新生代所有对象总大小如果大于本次Minor GC可以确保安全如果小于再看-XX:HandlePromotionFailure是否允许担保失败。允许时冒险试试不行再触发Full GC不允许就直接Full GC。JDK6以后这个开关默认开启且废弃当出现“担保失败”时老年代会进行一次Full GC回收空间代价是停顿时间显著上升。2.4 Full GC的触发条件Full GC是老年代的GC一般伴随Metaspace回收。触发条件包括老年代空间不足、Metaspace空间不足、调用System.gc()只是建议但通常也会触发、CMS并发模式失败、分配担保失败等。面试常踩的坑是把Full GC和Major GC混为一谈。严谨地说Major GC指老年代的GCFull GC指对整个堆新生代老年代元空间的GC。比如Parallel收集器下Full GC实际同时回收新生代和老年代用的还是单线程的Serial Old算法。性能杀手就是Full GC全堆扫描、STW时间长、执行完后可用空间依然不足时会连续Full GC直至OOM。3. 并发回收的三座大山STW、安全点、三色标记3.1 为什么垃圾回收必须STW“为什么GC要暂停所有用户线程”是面试官必问的底层题。直接原因是可达性分析必须基于一个稳定快照如果在分析过程中引用关系不断变化要么漏标存活对象导致误回收致命要么多标垃圾对象导致回收不彻底可接受但会积累浮动垃圾。为了保准确HotSpot最朴素的方案就是暂停业务线程也就是STWStop The World。这里常有个误解STW不是所有收集器的固有问题而是“枚举根节点”和“移动对象”时的必要手段。CMS的初始标记和最终标记阶段依然要STW只是把最耗时的并发标记阶段做成了用户线程同时运行。G1、ZGC更是通过并发根扫描和并发标记进一步缩短STW。3.2 安全点与安全区域STW不是想停就能停线程必须在“安全点”停下。安全点是JVM预设的指令位置比如方法调用、循环跳转、异常跳转等。在这些位置停下才能保证线程状态一致不会出现栈帧正在被修改、寄存器中的引用无法枚举的情况。一个线程从开始执行到安全点之间的时间被称为“安全区域外的运行时间”。如果用-XX:UseCountedLoopSafetyCheck这类参数优化循环次数过多可能导致线程迟迟进不了安全点这在高并发低延迟场景是个隐患。除了安全点还有安全区域的概念线程进入Sleep或Blocked状态时无法响应中断请求因此只要进入安全区域GC就可以认为该线程“已暂停”不需要等它响应。面试答到这个层面面试官能感受到你不只是背概念而是真的理解线程运行状态和GC的交互。3.3 三色标记算法与漏标问题三色标记是并发标记的理论模型很多候选人栽在这里。把对象分成三种颜色白色未被访问、灰色自身被访问但引用子对象未被全部访问、黑色自身和引用子对象都被访问。从GC Roots出发初始时根对象为灰色不断把灰色对象标记为黑色、把白色引用对象标记为灰色直到没有灰色对象剩下的白色就是可回收对象。并发标记的难点不是标记本身而是“一边标记、一边改引用”会漏标。经典的漏标场景黑色对象A原本没有引用C标记过程中A新增了引用指向C而C还没被访问到此时如果标记线程已经处理完A就不会再去扫描A的新引用C就会被误判为垃圾。漏标必须满足两个条件黑色对象新增了指向白色对象的引用该白色对象的所有灰色引用被删除。只要打破任一条件就不会漏。因此两种解决方案诞生了增量更新Incremental Update记录黑色对象新增的引用最终标记阶段重新扫描这些引用。CMS采用。原始快照Snapshot At The BeginningSATB记录被删除的灰色引用并发标记期间把这些引用指向的对象当作存活对象处理。G1采用。面试回答这个点最好画一个简单示意口头描述A、B、C三个对象的引用变化然后分别解释增量更新和SATB如何打破漏标条件。能说清楚“增量更新是记录新增、SATB是记录删除”已经能区分绝大多数候选人。4. 收集器选型从Serial聊到ZGC4.1 经典收集器组合速查收集器矩阵是面试经典环节。HotSpot JDK8默认是Parallel Scavenge Parallel OldJDK9以后默认G1JDK11起ZGC成为可选项JDK21正式GA了ZGC的分代模式。下面这张表建议记牢收集器适用代算法线程特点Serial新生代复制单线程简单Client模式默认单核友好ParNew新生代复制多线程CMS的默认搭档追求低延迟Parallel Scavenge新生代复制多线程关注吞吐量可自适应调节Serial Old老年代标记-整理单线程CMS失败的后备方案Parallel Old老年代标记-整理多线程与Parallel Scavenge配套CMS老年代标记-清除并发低延迟有碎片和浮动垃圾问题G1全堆Region复制整理多线程可预测停顿JDK9默认ZGC全堆Region并发整理多线程超低停顿停顿不随堆增长面试官大概率问“你项目用的什么收集器”。千万不要报个“G1默认”就完了要能说出为什么选它。常见答法业务对延迟敏感G1支持指定最大停顿时间且能做到并发收集适合大堆如果追求吞吐量且对停顿不敏感Parallel更合适。4.2 CMS的运行流程与经典坑点CMSConcurrent Mark Sweep是低延迟时代的代表四个阶段初始标记STW标记GC Roots直接关联的对象很快并发标记从GC Roots开始遍历对象图和用户线程并发重新标记STW修正并发期间引用变化导致的漏标用增量更新并发清除和用户线程并发清理垃圾对象两个经典坑必须掌握。第一个是“并发模式失败”并发标记或清除期间老年代空间被用户线程的新对象耗尽CMS无法继续并发收集只能退化为Serial Old单线程Full GC停顿时间瞬间飙升。解决方法预留足够空间-XX:CMSInitiatingOccupancyFraction例如设68%让CMS在老年代用到68%时就开始收集避免撑满或调大堆内存。第二个坑是内存碎片。CMS用标记-清除算法不整理内存运行久了老年代碎片化严重大对象分配困难提前触发Full GC。解决方案是开-XX:UseCMSCompactAtFullCollection在Full GC时进行碎片整理但会增加停顿。现代JDK8u和JDK9已经逐步废弃CMS面试只需说明原理和缺点不要推荐生产环境再用CMS。4.3 G1的核心设计Region、RSet与回收集G1Garbage First是目前工作的主力面试地位极高。它的核心创新是把堆划分为大小相等的Region默认2048个每个Region独立扮演Eden、Survivor、Old或Humongous大对象区。Region的引入让G1不必对整个堆做GC每次只回收一部分Region实现“可预测的停顿”。G1的另一个核心是RSetRemembered Set用来记录哪些Region中的对象引用了当前Region。说白了就是跨Region引用的“反向指针索引”。当GC需要扫描某个Region的存活对象时不用全堆扫描只要查RSet就能知道谁引用了它。RSet的建立和维护依赖写屏障这也是“每条引用赋值指令都需要额外开销”的原因。G1的回收过程可以概括为初始标记STW标记GC Roots直接关联对象在Minor GC顺带完成并发标记三色标记用SATB记录引用删除避免漏标最终标记STW处理SATB队列中的引用记录筛选回收STW根据RSet统计各Region的回收价值和成本计算性价比优先回收垃圾最多的Region“Mixed GC”概念常被问到G1的回收不只是老年代而是从所有Region中挑选回收价值最高的若干Region。回答时提一句“筛选阶段会计算每个Region的回收收益和耗时选择垃圾占比高、回收成本低的Region”就能体现你理解了G1为什么叫Garbage First。G1的停顿时间由-XX:MaxGCPauseMillis指定目标但注意这不是硬性保证只是一个预测模型。G1会基于历史数据估算每个Region的回收耗时尽量让停顿控制在目标以内。如果堆非常大比如上百GBG1的RSet维护成本会明显上升这就是为什么ZGC在超大堆上更占优势。4.4 ZGC颜色指针与读屏障ZGC是追求极致低延迟的收集器。最吸引人的特性是GC停顿时间不随堆大小线性增长JDK16以后ZGC支持在16TB堆上以几十毫秒内完成GC。ZGC的关键技术是染色指针Colored Pointer。在64位Linux上ZGC把对象指针的前几位用作标记位用来记录对象状态Marked0、Marked1、Remapped、Finalizable。GC标记时不需要访问对象本身直接在指针上操作状态位即可。ZGC还引入了读屏障每次从堆中加载引用时读屏障会检查指针状态如果指针指向的对象需要重定位就立即修正指针。这个设计让“对象移动”和“用户线程访问对象”可以并发进行这就是ZGC能实现极短STW的根本原因。面试中只要把“ZGC把GC信息放进指针本身通过读屏障并发修正引用”讲清楚面试官就会比较满意。如果追问面向对象内存,可以说ZGC初始化时会保留一段虚拟地址空间用于映射多个视图这也是加载指针能实现单次解引用的前提。5. 调优与排查面试加分项与实战技巧5.1 常用GC参数速查面试不仅问原理还问“你平时怎么调优”。常用参数要能随口报出参数作用-Xms / -Xmx初始堆/最大堆-Xmn新生代大小-XX:SurvivorRatioEden/Survivor比例默认8-XX:MaxTenuringThreshold晋升阈值默认15-XX:PrintGCDetails打印GC日志JDK9前-Xlog:gc*JDK9统一日志-XX:HeapDumpOnOutOfMemoryErrorOOM时自动导出堆快照-XX:MaxGCPauseMillisG1目标停顿时间-XX:ConcGCThreads并发GC线程数注意一个细节-Xlog:gc*是JDK9以后统一日志体系的写法老参数-XX:PrintGCDetails在JDK9虽然还能生效但推荐迁移到新语法。面试时能主动提这一点说明你用过新版本。5.2 GC日志分析实战翻GC日志是定位问题的入口。举个例子JDK8下用-XX:PrintGCDetails日志片段长这样[GC (Allocation Failure) [PSYoungGen: 61440K-8191K(71680K)] 122880K-65407K(190464K), 0.0234567 secs] [Full GC (Ergonomics) [PSYoungGen: 32767K-0K(71680K)] [ParOldGen: 131512K-147456K(182272K)] 163471K-147456K(254080K), 1.2345678 secs]解析要点Allocation Failure本次Minor GC因Eden区分配失败触发箭头前是GC前占用箭头后是GC后占用括号里是总量0.0234 secs是本次GC耗时PSYoungGen和ParOldGen说明用的是Parallel收集器Full GC的耗时往往数倍于Minor GC连续多个Full GC日志就是内存泄漏的典型信号确认堆内存不足时排查顺序应该是先看OS物理内存和容器限制再看进程启动参数最后才是业务代码。很多“频繁Full GC”其实是-Xms和-Xmx不一致导致堆反复伸缩GC触发频繁。生产经验是-Xms和-Xmx设置相同避免运行时扩容带来的额外负担。5.3 常见性能问题排查思路面试常问“线上频繁Full GC你怎么排查”。我给一个实战套路jstat -gcutil pid 1000连续观察看到FGC次数不断增长、FCTFull GC时间持续增加基本确认Full GC频繁jmap -dump:formatb,fileheap.bin pid导出堆快照再用MAT或VisualVM分析找大对象和“类加载器泄漏”MAT中看Dominator Tree挑Retained Heap最大的对象追到业务代码如果是System.gc()触发的查代码里有没有显示调用如果是CMS触发查CMSInitiatingOccupancyFraction是否设置过小用jstat -gcutil看Eden、Survivor、Old各自的占用趋势定位是对象分配过快还是回收不了一个容易被忽略但很实际的技巧是排查GC之前先确认是不是CPU限制导致GC线程抢不到CPU很多“GC停顿异常长”其实是CPU配额不足这时调整GC参数是没用的得先解决资源问题。6. 高频问答速查表面试前10分钟必背清单最后把高频问题浓缩成表格适合面试前一天快速过一遍问题核心答法判断对象存活的方法可达性分析GC Roots起点GC Roots有哪些栈引用、静态变量、常量、JNI、锁、JVM内部四种引用区别强引用不会回收软引用内存不足回收弱引用每次GC回收虚引用回收通知复制算法适合哪代新生代对象存活率低复制开销小CMS为什么有碎片标记-清除不整理内存解决需Compact三色标记漏标的原理黑色对象新增白色引用同时该白色引用被删除增量更新或SATB修复G1和CMS的区别G1按Region回收可预测停顿CMS标记-清除低延迟但有碎片Full GC触发条件老年代满、元空间满、担保失败、System.gc生产环境怎么选收集器延迟敏感选G1/ZGC吞吐优先选Parallel调优基本步骤确认目标资源配置日志监控定位瓶颈这个表可以作为冲刺记忆卡但请记住面试官不会照着表问他们会把一个表中的点横向展开问到你怎么排查、为什么这样选、遇到过什么问题。只有把前面的原理真正理解了这张表才是加分项否则就是背题模板。7. 我聊几个真实面试中的感受做面试官这些年我最深的感触是候选人背题和真懂的区别非常明显。问“什么是可达性分析”几乎人人会答但追问“为什么可达性分析必须STW”很多人开始支支吾吾。再追问“如果有一种收集器不需要STW做标记应该怎么做”能聊出三色标记和SATB的人就明显少了一大截。如果你准备面试建议不要只盯着收集器对比表背而是把“对象分配→Minor GC→晋升→Full GC→并发标记→三色标记→各种收集器设计取舍”当成一条流水线去理解。顺着这条线走一遍从原理到实战会非常顺畅。这个思路不仅对面试有效日常排查线上问题也会少走很多弯路。最后分享一个我在实际调优中反复验证过的经验所有GC参数都要结合监控数据调整不要上来就抄别人的参数组合。我见过太多“面试背了一堆参数生产直接套用然后出问题”的例子。-Xms、-Xmx设置相等、根据对象分配速率调-Xmn、根据停顿目标选G1还是Parallel这些基础决策做好比追求冷门参数有意义得多。真正的JVM调优永远是先有监控数据再有针对性调整最后用数据验证效果而不是靠参数堆砌。
