Java语言与虚拟机GC算法与垃圾回收器先聊点实际的。不管是校招刚入门还是大厂面试已经背到烂熟Java开发者总会撞上一个绕不开的名词——GC也就是垃圾回收。工作几年后你可能会发现线上服务频繁Full GC、接口突然卡顿几十秒、内存监控曲线像过山车这些问题排查到最后几乎都会落到对JVM内存管理和垃圾回收器的理解上。GC不是某个工具类的功能也不是什么锦上添花的优化技巧它直接决定了你的Java程序能够跑多快、能扛多大压力、遇到内存瓶颈时能不能快速定位问题。这篇文章我会从GC要解决的根问题讲起逐层拆解三种经典垃圾回收算法的原理和取舍再结合主流垃圾回收器的实际选型和调优参数最后给出生产环境下的排查思路。无论你是准备面试、写业务代码时被OOM折磨过还是纯粹想搞懂JVM内部在干什么这篇文章都能帮你把GC这条线彻底打通。1. 内容整体设计与思路拆解1.1 为什么先搞懂GC再谈JVM优化很多初学者对JVM的认知是从“启动参数”开始的比如-Xmx、-Xms调完发现内存还是不释放就开始怀疑参数没生效。其实问题的根源在于GC管理的内存和操作系统层面的内存不是一回事JVM内部的堆内存回收有自己的节奏和规则。不懂GC的工作机制调参基本靠猜出了问题也只能重启。我们得先回到最底层的问题上Java程序运行时会创建大量对象这些对象在堆内存中分配空间但Java不像C/C那样需要开发者手动释放内存。JVM里的垃圾回收器负责自动识别“已经没人使用的对象”并回收其占用的内存。这个过程如果设计得好程序和内存都能保持在健康状态设计不好就会频繁触发回收甚至长期占用CPU。所以整张知识地图应该是这样的先理解对象在堆里的生命周期再搞清楚垃圾回收器靠什么判断“垃圾”然后顺着算法的演进逻辑看懂各代回收器的设计差异最后落到实际调优与排障上。这也是我写这篇文章的结构安排。1.2 从对象生命周期看GC解决的核心矛盾先说一个很容易混淆的概念GC并不等于“清理内存”。它真正要做的事情有两件一是找出已经没有引用指向的对象二是回收它们占用的堆空间同时尽量不影响正在运行的程序。这背后有一个核心矛盾吞吐量和响应时间的矛盾。如果要快速回收大量内存就需要长时间暂停业务线程这在批处理场景下可以接受但在高并发的在线服务里就是灾难。如果为了避免长时间停顿而把回收拆得很碎又会引入频繁的上下文切换和额外的记录开销。不同垃圾回收器本质上就是在吞吐量、低延迟、内存占用这三者之间做取舍。还有一个让新手头疼的点JVM把堆内存分成年轻代和老年代并不是随手设计的。统计表明绝大多数Java对象“朝生夕灭”存活时间极短。分代设计让回收器可以针对不同区域使用不同算法年轻代复制回收老年代标记整理这样整体效率远高于每次都对整堆做全量扫描。2. 核心细节解析三大GC算法的原理与取舍2.1 标记-清除算法最朴素的思路但藏着一个大坑标记-清除Mark-Sweep是最基础的垃圾回收算法思路非常直白分两步走标记阶段从GC Roots出发把所有被引用的对象打上标记。清除阶段遍历堆内存把没有标记的对象所占空间回收。乍一看没什么问题但它有两个明显的毛病。第一个毛病就是内存碎片化。回收掉的对象在堆上留下很多不连续的空洞后续如果有一个比较大的对象要分配即使总空闲空间足够也可能因为找不到连续区域而再次触发Full GC。这就像停车场里到处是零散的空位但一辆大巴进来却停不进去只能等小车挪走更多位置。第二个毛病是效率问题。如果堆中有大量存活对象标记阶段需要遍历整个引用链清除阶段又要扫一遍全部内存这两个阶段都会消耗可观的CPU时间。在实际应用中纯粹的标记-清除算法很少被直接使用。但它是理解后续一切算法的基础垃圾回收器的很多设计本质上都是在解决标记-清除暴露出的这两个问题。比如下面的标记-复制算法基本就是冲着“碎片化”去的。2.2 标记-复制算法用空间换时间的经典方案标记-复制Copying算法的思路很有趣把一块内存分成大小相等的两块每次只使用其中一块。回收时把存活对象复制到另一块空的内存区域然后把原来那块内存整体清空。这个算法的优点非常突出复制后内存排列是紧凑的不会产生碎片而且分配内存时只需要移动一个指针就行非常高效。同时因为只处理存活对象当存活率很低时比如年轻代它的效率要远高于标记-清除。但它也有明显的代价——可用内存减半。如果存活率较高复制操作会变得非常频繁反而拖慢性能。所以这个算法不适合老年代这种存活对象多的场景却天然契合年轻代的特点。JVM的年轻代回收就采用了复制算法但不是简单的1:1等分而是把内存划分为一个较大的Eden区和两个较小的Survivor区比例通常是8:1:1。这样设计的精妙之处在于每次回收只有少量存活对象需要复制到Survivor不需要牺牲一半内存同时还能保证内存的紧凑性。2.3 标记-整理算法让老年代不再碎片化的折中之道老年代里存活对象多、生命周期长直接用复制算法显然不行因为复制的成本和空间浪费都难以承受。于是有了标记-整理Mark-Compact算法。流程也很清楚标记阶段和标记-清除一样从GC Roots标记所有存活对象但清除阶段不一样。它不像标记-清除那样直接清掉垃圾对象而是把所有存活对象向内存的一端移动然后清理掉边界以外的所有空间。这就像是整理一间乱糟糟的屋子把有用的东西归拢到墙边剩下的杂物集中倒掉空间一下子就清爽了。整理后内存是连续的分配新对象时就不需要为了找连续空间而发愁。缺点是移动对象需要更新所有引用这个过程要遍历整个堆所以停顿时间通常比标记-清除更长。但考虑到老年代对象变动频率低这个代价换来的内存连续性长期来看是划算的。2.4 三种算法对比什么时候选谁用一张表可以比较直观地看到它们的定位差异算法内存碎片内存利用率适用场景核心成本标记-清除严重高老年代CMS曾使用碎片问题标记-复制无低浪费空间年轻代复制开销标记-整理无高老年代移动对象与更新引用理解了这张表再看垃圾回收器你会发现它们其实是组合拳。年轻代天生适合复制老年代更适合标记-整理但不同的垃圾回收器在处理边界情况时有不同的策略这也带来了不同的性能表现和停顿特征。3. 分代模型与根节点枚举避免误判“垃圾”的关键3.1 分代收集的具体划分与对象晋升机制JVM把堆分成年轻代Young Generation和老年代Old Generation年轻代内部又分成Eden区和两个Survivor区。新创建的对象几乎都在Eden区分配Eden区满了会触发Minor GC过程是这样的新对象优先在Eden区分配Survivor区只存放经历过数次Minor GC后仍然存活的对象。Minor GC触发时把Eden区和其中一个Survivor区的存活对象复制到另一个空闲的Survivor区。每经历一次Minor GC存活对象的年龄加1。当年龄超过阈值默认15可通过-XX:MaxTenuringThreshold调整对象会晋升到老年代。这里有一个非常值得注意的细节大对象直接进入老年代。如果一个对象特别大比如一个超大的数组放到Eden区会导致Eden区的复制逻辑复杂化而且大对象在Survivor区之间来回复制代价很大。JVM提供了-XX:PretenureSizeThreshold参数超过阈值的大对象直接进入老年代避免反复复制。另一个晋升机制是动态年龄判定。如果Survivor区中相同年龄的所有对象大小总和超过Survivor空间的一半年龄大于或等于该年龄的对象就直接晋升到老年代不用等达到阈值。这个机制设计得很聪明防止Survivor区被长期存活对象慢慢塞满。3.2 GC Roots的枚举与安全点判断对象是否存活不是逐个遍历对象看有没有引用它而是从一组根对象出发遍历整个引用链。能作为GC Roots的有虚拟机栈中局部变量表引用的对象。方法区中类的静态属性引用的对象、常量引用的对象。本地方法栈中JNI引用的对象。Java虚拟机内部的引用比如基本数据类型对应的Class对象、常驻的异常对象、系统类加载器等。被同步锁synchronized持有的对象。根节点枚举必须在一个“快照”状态下完成否则一边遍历一边有新的引用产生结果就不准确。所以在GC开始时JVM会暂停所有业务线程也就是STWStop The World进入一个一致性的状态。即使是最追求低延迟的垃圾回收器根节点枚举这一小段停顿也是无法完全避免的。这里还有一个关键概念叫安全点。JVM不会在任何指令位置都能暂停线程而是在特定的指令位置比如循环跳转、方法返回、异常跳转设置安全点。线程运行到安全点时才能停下来进入GC状态。这也是为什么GC日志里有时会看到线程等待进入安全点的时间如果业务线程长时间运行到不了安全点GC就只能一直等着造成额外的停顿。3.3 三色标记法与并发漏标问题现代主流垃圾回收器比如CMS和G1都在尝试缩短STW时间做法是把标记阶段的一部分工作放到业务线程并发执行。这就引出了一个更细致的问题并发标记时引用关系在不断变化怎么避免把仍被引用的对象误判为垃圾这里就要提三色标记法了。它把对象分成三种颜色白色尚未被访问过的对象标记结束后仍然为白色的对象会被判定为垃圾。灰色当前对象已被访问但其引用的对象还没全部被访问完。黑色对象及其所有引用都已被访问完存活对象。并发标记过程中业务线程会不断修改引用指向可能出现一种危险情形一个黑色对象原本引用的白色对象被业务线程改成引用另一个尚未被访问的白色对象同时原先的引用被删除导致那个尚未访问的白色对象失去了被标记的机会最终被误回收。解决这个问题的标准方案有两个增量更新和原始快照。CMS用的是增量更新当黑色对象插入新的指向白色对象的引用时把这个引用记录下来重新标记阶段再去扫描处理。G1用的是原始快照在删除引用前先把旧的引用关系记录下来确保之前被引用的对象不会漏标。这两种方式各有取舍但都是为了让并发标记不“误杀”存活对象。4. 主流垃圾回收器选型与实战参数解读4.1 从Serial到CMS低延迟方向的探索聊完算法层面还是要落回到生产环境中用到的具体垃圾回收器上。Serial回收器是最老牌的回收器单线程工作回收时会暂停所有业务线程。它简单可靠但在多核服务器上浪费资源只适合小内存、客户端模式或者嵌入式场景。Parallel回收器也叫Parallel Scavenge是JDK 8默认的回收器组合关注点是可控的吞吐量。它支持通过-XX:MaxGCPauseMillis设置期望的停顿时间通过-XX:GCTimeRatio设置吞吐量目标。Parallel回收器的核心思想是既然停顿无法完全消除那就在指定目标内尽量提高总吞吐量。对计算密集型的离线任务来说Parallel仍然是很合适的选择。CMS回收器Concurrent Mark Sweep第一次把“并发回收”带进了主流视野。它的设计目标是降低停顿时间老年代回收时大部分阶段和业务线程并发执行只有初始标记和重新标记阶段需要STW。CMS的问题也不少它基于标记-清除算法会产生内存碎片并发标记时如果业务线程分配内存太快可能触发“并发模式失败”退化为Serial Old进行全量Full GC反而造成超大停顿。这些痛点也直接推动了G1回收器的诞生。4.2 G1回收器区域化大内存时代的默认选择G1在JDK 9之后成为默认垃圾回收器它的核心设计是把堆划分为多个大小相等的Region区域每个Region既可能是年轻代也可能是老年代。G1的“Garbage First”不是指全局优先回收垃圾最多的地方而是跟踪每个Region的回收价值每次回收时优先处理垃圾比例最高、回收代价最小的Region区域。G1的特色之一是可预测的停顿时间模型。通过-XX:MaxGCPauseMillis参数设定目标停顿时间G1会根据这个目标动态调整各代Region的数量尽量在用户期望的时间窗内完成回收。它不是绝对保证但在大多数场景下表现非常稳定。G1的年轻代回收和老年代回收混合进行。全局并发标记周期完成后进入混合回收阶段既回收年轻代Region也回收垃圾比例高的老年代Region。这个过程中G1依靠记忆集Remembered Set来维护Region之间跨区域引用关系。记忆集本质上是一个“反向指针列表”记录了外部Region对本Region的引用位置好处是回收一个Region时不需要扫描整个堆代价是维护记忆集本身有额外的内存和CPU开销。对大堆场景G1有明显的优势它可以避免全堆扫描停顿时间更可控内存碎片的困扰也基本消失。如果你的服务内存超过4GB甚至达到几十GBG1是首选。4.3 ZGC与Shenandoah迈向近乎无停顿的未来如果说G1还在“尽量缩短停顿”那ZGC的设计目标就是“把停顿时间压到几乎为零”而且停顿时间不随堆大小线性增长。ZGC的关键技术是染色指针和读屏障。染色指针Colored Pointer是一种很巧妙的设计它把标记信息直接存储在指针的高位比特中这样对象本身不需要额外的标记字段GC可以通过读取指针值快速判断对象状态。配合读屏障在业务线程读取引用时如果发现对象被移动了可以通过转发表自动修正指向。这让对象移动可以和业务线程并发进行而不需要暂停全体线程。Shenandoah的路线类似同样使用读屏障实现并发移动对象设计目标也是低停顿。不过ZGC的默认堆支持从16MB到16TB可以说是为超大堆场景设计的。选择建议很简单如果你的线上服务延迟很敏感堆内存又比较大可以认真评估ZGC如果堆控制在4GB到16GB之间用G1通常就是最优解。JDK 11及之后版本对ZGC的支持已经相当成熟不是试验特性了。4.4 回收器参数速查与实践建议实际配置时不要无脑加参数先理解每个参数背后的目的。下面这几个是我在项目中常用的参数作用建议-Xms / -Xmx设置初始堆大小和最大堆大小生产环境建议设相同值避免堆扩展抖动-XX:UseG1GC使用G1回收器JDK 9默认已开启-XX:MaxGCPauseMillis设置目标停顿时间不要设太小否则G1会为了迎合目标频繁回收-XX:ParallelGCThreads设置GC线程数通常默认即可-XX:MetaspaceSize设置元空间大小防止元空间频繁扩容-XX:HeapDumpOnOutOfMemoryErrorOOM时导出堆转储文件强烈建议开启-XX:HeapDumpPath指定堆转储文件路径配合上一条使用G1的MaxGCPauseMillis默认是200ms。很多团队一上来就拍脑袋设成50ms结果G1为了达到这个目标会大幅提高Mixed GC的频率把停顿拆成很多次小型回收吞吐量反而下降。正确做法是观察真实业务的停顿分布设定一个“可以接受但不过分激进”的值。5. 从理论到实战GC日志分析与调优案例5.1 开日志看现象GC日志怎么读不谈日志的GC讲解都是纸上谈兵。生产环境JVM默认不打印GC日志需要显式开启。推荐这样设置-Xlog:gc*:file/opt/applogs/gc-%t.log:time,uptime,level,tags:filecount5,filesize20m在JDK 8及更早版本使用-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/path/to/gc.log。JDK 9以后日志系统重构统一用-Xlog语法。G1日志中一段典型的Minor GC输出长这样[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0234567 secs] [Parallel Time: 20.0 ms, GC Workers: 8] [Eden: 512.0M(512.0M)-0.0B(486.0M) Survivors: 20.0M-24.0M Heap: 1.2G(4.0G)-700.0M(4.0G)]读日志最关键的是看三个指标单次停顿时间、频率、吞吐量损失。如果单次停顿长说明堆中对象太多或回收器配置与业务不匹配如果停顿频繁说明堆太小或对象分配速度太快如果吞吐量损失大说明GC占用的CPU比例过高。5.2 一次线上Full GC频繁的真实排障去年我们一个订单服务频繁报警现象是接口P99延迟从50ms飙升到3秒查看监控发现Full GC每五分钟一次每次停顿接近2秒。排查过程是这样的先看GC日志确认Full GC确实由老年代空间不足触发。用jstat -gcutil pid 1000观察每秒钟Eden、Survivor、老年代使用率的实时变化发现老年代一直以肉眼可见的速度增长。用jmap -dump:live,formatb,fileheap.bin pid导出堆转储然后用MAT分析发现一个名为OrderCache的静态HashMap占用了老年代将近70%的内存而且key是永远不会重复的订单号。最终定位为缓存未设置过期时间和最大容量限制导致缓存无限增长。修复方式很简单给缓存加上容量上限和过期策略Full GC立刻消失接口延迟恢复到正常水平。这个案例说明GC调优不只是调参数。遇到Full GC频繁第一件事永远是看堆里到底装了什么而不是先调大堆内存。调大堆内存只会让“爆雷”的时间更晚不会解决根因。5.3 参数调优的思路先定目标再动参数调优启动参数前先明确你的服务是延迟敏感型还是吞吐量敏感型在线交易、实时推荐等服务对响应时间要求高优先用G1或ZGC把MaxGCPauseMillis设成一个现实中能达到的值。离线批处理、数据导入等任务更关心总耗时用Parallel回收器尽量增大吞吐量容忍单次停顿时间长一些。其次是堆大小设置。我见过不少团队把-Xmx设得很大美其名曰“反正内存够”实际导致GC耗时暴涨。原理很简单堆越大标记和整理需要遍历的对象越多。建议先按程序正常运行时的常驻内存乘以1.5到2倍来估算堆大小不要一开始就给满机器内存。还有一点容易被忽略Metaspace的扩容也会触发Full GC。如果服务频繁加载新类比如使用大量动态代理或热部署元空间不够用时也会触发Full GC。可以观察GC日志中Metaspace的容量增长曲线必要时用-XX:MetaspaceSize和-XX:MaxMetaspaceSize固定空间。6. 常见问题与排查技巧实录6.1 高发问题速查表现象可能原因排查思路频繁Full GC老年代空间不足导出堆转储用MAT分析对象分布GC后内存不降静态集合持有引用或未回收缓存检查全局静态变量、缓存组件配置单次GC停顿过长堆中有超大对象或大数组检查是否一次性加载大量数据到内存并发模式失败业务线程分配对象速度超过CMS回收速度换用G1或调整堆大小Metaspace频繁扩容动态生成类过多增加MetaspaceSize检查类加载器是否泄漏线程等待进入安全点高并发循环密集代码无安全点关注编译热点适当调整安全点参数6.2 几个常被忽视的细节技巧设置JVM参数前先确认JDK版本。JDK 8和JDK 11的默认回收器不同CMS在JDK 14中已经移除很多网上资料已经过时。先执行java -version确认版本再用java -XX:PrintFlagsFinal -version | grep GC查看当前默认回收器。谨慎使用System.gc()。这个方法只是“建议”JVM执行GC但很多框架底层会调用它比如NIO的堆外内存分配失败时。如果不想让业务代码触发Full GC可以用-XX:DisableExplicitGC禁用显式GC。留意大页内存配置。如果操作系统启用了透明大页THPJVM的内存分配行为会受影响可能导致偶发延迟。对延迟敏感的服务建议在操作系统层面关闭THP这个优化成本极低但收益往往很明显。学会用Arthas做在线诊断。Arthas的dashboard命令可以实时查看内存区域使用率、GC次数和耗时不需要频繁重启服务。定位到具体问题后再用heapdump导出快照做离线分析整个排障效率会高很多。6.3 关于GC调优的最终建议从事Java开发这些年我见过太多人一上来就追求“把GC日志优化成一张完美的图表”结果陷入不断调参的死循环。实际上GC调优要解决的永远是问题不是数据。先确认业务是否真的有问题比如延迟变高、CPU飙高、频繁OOM然后再决定要不要调。如果服务运行稳定典型停顿在可接受范围内即使GC频率偏高也不要因为“强迫症”而改动参数。任何参数的调整都意味着一种新的风险尤其在生产环境没有充分验证的情况下默认参数往往比自以为是的“优化”更可靠。对于刚接触JVM的读者我建议从打开GC日志开始先好好观察你的应用每天发生了什么再逐步理解每个回收器为什么那么设计。看得多了你自然会知道什么时候该用G1什么时候该考虑ZGC哪些参数是救命稻草哪些只是心理安慰。这种能力不是背八股文能得来的是真的需要在实际项目中一点点积累的。
Java语言与虚拟机GC算法与垃圾回收器先聊点实际的。不管是校招刚入门还是大厂面试已经背到烂熟Java开发者总会撞上一个绕不开的名词——GC也就是垃圾回收。工作几年后你可能会发现线上服务频繁Full GC、接口突然卡顿几十秒、内存监控曲线像过山车这些问题排查到最后几乎都会落到对JVM内存管理和垃圾回收器的理解上。GC不是某个工具类的功能也不是什么锦上添花的优化技巧它直接决定了你的Java程序能够跑多快、能扛多大压力、遇到内存瓶颈时能不能快速定位问题。这篇文章我会从GC要解决的根问题讲起逐层拆解三种经典垃圾回收算法的原理和取舍再结合主流垃圾回收器的实际选型和调优参数最后给出生产环境下的排查思路。无论你是准备面试、写业务代码时被OOM折磨过还是纯粹想搞懂JVM内部在干什么这篇文章都能帮你把GC这条线彻底打通。1. 内容整体设计与思路拆解1.1 为什么先搞懂GC再谈JVM优化很多初学者对JVM的认知是从“启动参数”开始的比如-Xmx、-Xms调完发现内存还是不释放就开始怀疑参数没生效。其实问题的根源在于GC管理的内存和操作系统层面的内存不是一回事JVM内部的堆内存回收有自己的节奏和规则。不懂GC的工作机制调参基本靠猜出了问题也只能重启。我们得先回到最底层的问题上Java程序运行时会创建大量对象这些对象在堆内存中分配空间但Java不像C/C那样需要开发者手动释放内存。JVM里的垃圾回收器负责自动识别“已经没人使用的对象”并回收其占用的内存。这个过程如果设计得好程序和内存都能保持在健康状态设计不好就会频繁触发回收甚至长期占用CPU。所以整张知识地图应该是这样的先理解对象在堆里的生命周期再搞清楚垃圾回收器靠什么判断“垃圾”然后顺着算法的演进逻辑看懂各代回收器的设计差异最后落到实际调优与排障上。这也是我写这篇文章的结构安排。1.2 从对象生命周期看GC解决的核心矛盾先说一个很容易混淆的概念GC并不等于“清理内存”。它真正要做的事情有两件一是找出已经没有引用指向的对象二是回收它们占用的堆空间同时尽量不影响正在运行的程序。这背后有一个核心矛盾吞吐量和响应时间的矛盾。如果要快速回收大量内存就需要长时间暂停业务线程这在批处理场景下可以接受但在高并发的在线服务里就是灾难。如果为了避免长时间停顿而把回收拆得很碎又会引入频繁的上下文切换和额外的记录开销。不同垃圾回收器本质上就是在吞吐量、低延迟、内存占用这三者之间做取舍。还有一个让新手头疼的点JVM把堆内存分成年轻代和老年代并不是随手设计的。统计表明绝大多数Java对象“朝生夕灭”存活时间极短。分代设计让回收器可以针对不同区域使用不同算法年轻代复制回收老年代标记整理这样整体效率远高于每次都对整堆做全量扫描。2. 核心细节解析三大GC算法的原理与取舍2.1 标记-清除算法最朴素的思路但藏着一个大坑标记-清除Mark-Sweep是最基础的垃圾回收算法思路非常直白分两步走标记阶段从GC Roots出发把所有被引用的对象打上标记。清除阶段遍历堆内存把没有标记的对象所占空间回收。乍一看没什么问题但它有两个明显的毛病。第一个毛病就是内存碎片化。回收掉的对象在堆上留下很多不连续的空洞后续如果有一个比较大的对象要分配即使总空闲空间足够也可能因为找不到连续区域而再次触发Full GC。这就像停车场里到处是零散的空位但一辆大巴进来却停不进去只能等小车挪走更多位置。第二个毛病是效率问题。如果堆中有大量存活对象标记阶段需要遍历整个引用链清除阶段又要扫一遍全部内存这两个阶段都会消耗可观的CPU时间。在实际应用中纯粹的标记-清除算法很少被直接使用。但它是理解后续一切算法的基础垃圾回收器的很多设计本质上都是在解决标记-清除暴露出的这两个问题。比如下面的标记-复制算法基本就是冲着“碎片化”去的。2.2 标记-复制算法用空间换时间的经典方案标记-复制Copying算法的思路很有趣把一块内存分成大小相等的两块每次只使用其中一块。回收时把存活对象复制到另一块空的内存区域然后把原来那块内存整体清空。这个算法的优点非常突出复制后内存排列是紧凑的不会产生碎片而且分配内存时只需要移动一个指针就行非常高效。同时因为只处理存活对象当存活率很低时比如年轻代它的效率要远高于标记-清除。但它也有明显的代价——可用内存减半。如果存活率较高复制操作会变得非常频繁反而拖慢性能。所以这个算法不适合老年代这种存活对象多的场景却天然契合年轻代的特点。JVM的年轻代回收就采用了复制算法但不是简单的1:1等分而是把内存划分为一个较大的Eden区和两个较小的Survivor区比例通常是8:1:1。这样设计的精妙之处在于每次回收只有少量存活对象需要复制到Survivor不需要牺牲一半内存同时还能保证内存的紧凑性。2.3 标记-整理算法让老年代不再碎片化的折中之道老年代里存活对象多、生命周期长直接用复制算法显然不行因为复制的成本和空间浪费都难以承受。于是有了标记-整理Mark-Compact算法。流程也很清楚标记阶段和标记-清除一样从GC Roots标记所有存活对象但清除阶段不一样。它不像标记-清除那样直接清掉垃圾对象而是把所有存活对象向内存的一端移动然后清理掉边界以外的所有空间。这就像是整理一间乱糟糟的屋子把有用的东西归拢到墙边剩下的杂物集中倒掉空间一下子就清爽了。整理后内存是连续的分配新对象时就不需要为了找连续空间而发愁。缺点是移动对象需要更新所有引用这个过程要遍历整个堆所以停顿时间通常比标记-清除更长。但考虑到老年代对象变动频率低这个代价换来的内存连续性长期来看是划算的。2.4 三种算法对比什么时候选谁用一张表可以比较直观地看到它们的定位差异算法内存碎片内存利用率适用场景核心成本标记-清除严重高老年代CMS曾使用碎片问题标记-复制无低浪费空间年轻代复制开销标记-整理无高老年代移动对象与更新引用理解了这张表再看垃圾回收器你会发现它们其实是组合拳。年轻代天生适合复制老年代更适合标记-整理但不同的垃圾回收器在处理边界情况时有不同的策略这也带来了不同的性能表现和停顿特征。3. 分代模型与根节点枚举避免误判“垃圾”的关键3.1 分代收集的具体划分与对象晋升机制JVM把堆分成年轻代Young Generation和老年代Old Generation年轻代内部又分成Eden区和两个Survivor区。新创建的对象几乎都在Eden区分配Eden区满了会触发Minor GC过程是这样的新对象优先在Eden区分配Survivor区只存放经历过数次Minor GC后仍然存活的对象。Minor GC触发时把Eden区和其中一个Survivor区的存活对象复制到另一个空闲的Survivor区。每经历一次Minor GC存活对象的年龄加1。当年龄超过阈值默认15可通过-XX:MaxTenuringThreshold调整对象会晋升到老年代。这里有一个非常值得注意的细节大对象直接进入老年代。如果一个对象特别大比如一个超大的数组放到Eden区会导致Eden区的复制逻辑复杂化而且大对象在Survivor区之间来回复制代价很大。JVM提供了-XX:PretenureSizeThreshold参数超过阈值的大对象直接进入老年代避免反复复制。另一个晋升机制是动态年龄判定。如果Survivor区中相同年龄的所有对象大小总和超过Survivor空间的一半年龄大于或等于该年龄的对象就直接晋升到老年代不用等达到阈值。这个机制设计得很聪明防止Survivor区被长期存活对象慢慢塞满。3.2 GC Roots的枚举与安全点判断对象是否存活不是逐个遍历对象看有没有引用它而是从一组根对象出发遍历整个引用链。能作为GC Roots的有虚拟机栈中局部变量表引用的对象。方法区中类的静态属性引用的对象、常量引用的对象。本地方法栈中JNI引用的对象。Java虚拟机内部的引用比如基本数据类型对应的Class对象、常驻的异常对象、系统类加载器等。被同步锁synchronized持有的对象。根节点枚举必须在一个“快照”状态下完成否则一边遍历一边有新的引用产生结果就不准确。所以在GC开始时JVM会暂停所有业务线程也就是STWStop The World进入一个一致性的状态。即使是最追求低延迟的垃圾回收器根节点枚举这一小段停顿也是无法完全避免的。这里还有一个关键概念叫安全点。JVM不会在任何指令位置都能暂停线程而是在特定的指令位置比如循环跳转、方法返回、异常跳转设置安全点。线程运行到安全点时才能停下来进入GC状态。这也是为什么GC日志里有时会看到线程等待进入安全点的时间如果业务线程长时间运行到不了安全点GC就只能一直等着造成额外的停顿。3.3 三色标记法与并发漏标问题现代主流垃圾回收器比如CMS和G1都在尝试缩短STW时间做法是把标记阶段的一部分工作放到业务线程并发执行。这就引出了一个更细致的问题并发标记时引用关系在不断变化怎么避免把仍被引用的对象误判为垃圾这里就要提三色标记法了。它把对象分成三种颜色白色尚未被访问过的对象标记结束后仍然为白色的对象会被判定为垃圾。灰色当前对象已被访问但其引用的对象还没全部被访问完。黑色对象及其所有引用都已被访问完存活对象。并发标记过程中业务线程会不断修改引用指向可能出现一种危险情形一个黑色对象原本引用的白色对象被业务线程改成引用另一个尚未被访问的白色对象同时原先的引用被删除导致那个尚未访问的白色对象失去了被标记的机会最终被误回收。解决这个问题的标准方案有两个增量更新和原始快照。CMS用的是增量更新当黑色对象插入新的指向白色对象的引用时把这个引用记录下来重新标记阶段再去扫描处理。G1用的是原始快照在删除引用前先把旧的引用关系记录下来确保之前被引用的对象不会漏标。这两种方式各有取舍但都是为了让并发标记不“误杀”存活对象。4. 主流垃圾回收器选型与实战参数解读4.1 从Serial到CMS低延迟方向的探索聊完算法层面还是要落回到生产环境中用到的具体垃圾回收器上。Serial回收器是最老牌的回收器单线程工作回收时会暂停所有业务线程。它简单可靠但在多核服务器上浪费资源只适合小内存、客户端模式或者嵌入式场景。Parallel回收器也叫Parallel Scavenge是JDK 8默认的回收器组合关注点是可控的吞吐量。它支持通过-XX:MaxGCPauseMillis设置期望的停顿时间通过-XX:GCTimeRatio设置吞吐量目标。Parallel回收器的核心思想是既然停顿无法完全消除那就在指定目标内尽量提高总吞吐量。对计算密集型的离线任务来说Parallel仍然是很合适的选择。CMS回收器Concurrent Mark Sweep第一次把“并发回收”带进了主流视野。它的设计目标是降低停顿时间老年代回收时大部分阶段和业务线程并发执行只有初始标记和重新标记阶段需要STW。CMS的问题也不少它基于标记-清除算法会产生内存碎片并发标记时如果业务线程分配内存太快可能触发“并发模式失败”退化为Serial Old进行全量Full GC反而造成超大停顿。这些痛点也直接推动了G1回收器的诞生。4.2 G1回收器区域化大内存时代的默认选择G1在JDK 9之后成为默认垃圾回收器它的核心设计是把堆划分为多个大小相等的Region区域每个Region既可能是年轻代也可能是老年代。G1的“Garbage First”不是指全局优先回收垃圾最多的地方而是跟踪每个Region的回收价值每次回收时优先处理垃圾比例最高、回收代价最小的Region区域。G1的特色之一是可预测的停顿时间模型。通过-XX:MaxGCPauseMillis参数设定目标停顿时间G1会根据这个目标动态调整各代Region的数量尽量在用户期望的时间窗内完成回收。它不是绝对保证但在大多数场景下表现非常稳定。G1的年轻代回收和老年代回收混合进行。全局并发标记周期完成后进入混合回收阶段既回收年轻代Region也回收垃圾比例高的老年代Region。这个过程中G1依靠记忆集Remembered Set来维护Region之间跨区域引用关系。记忆集本质上是一个“反向指针列表”记录了外部Region对本Region的引用位置好处是回收一个Region时不需要扫描整个堆代价是维护记忆集本身有额外的内存和CPU开销。对大堆场景G1有明显的优势它可以避免全堆扫描停顿时间更可控内存碎片的困扰也基本消失。如果你的服务内存超过4GB甚至达到几十GBG1是首选。4.3 ZGC与Shenandoah迈向近乎无停顿的未来如果说G1还在“尽量缩短停顿”那ZGC的设计目标就是“把停顿时间压到几乎为零”而且停顿时间不随堆大小线性增长。ZGC的关键技术是染色指针和读屏障。染色指针Colored Pointer是一种很巧妙的设计它把标记信息直接存储在指针的高位比特中这样对象本身不需要额外的标记字段GC可以通过读取指针值快速判断对象状态。配合读屏障在业务线程读取引用时如果发现对象被移动了可以通过转发表自动修正指向。这让对象移动可以和业务线程并发进行而不需要暂停全体线程。Shenandoah的路线类似同样使用读屏障实现并发移动对象设计目标也是低停顿。不过ZGC的默认堆支持从16MB到16TB可以说是为超大堆场景设计的。选择建议很简单如果你的线上服务延迟很敏感堆内存又比较大可以认真评估ZGC如果堆控制在4GB到16GB之间用G1通常就是最优解。JDK 11及之后版本对ZGC的支持已经相当成熟不是试验特性了。4.4 回收器参数速查与实践建议实际配置时不要无脑加参数先理解每个参数背后的目的。下面这几个是我在项目中常用的参数作用建议-Xms / -Xmx设置初始堆大小和最大堆大小生产环境建议设相同值避免堆扩展抖动-XX:UseG1GC使用G1回收器JDK 9默认已开启-XX:MaxGCPauseMillis设置目标停顿时间不要设太小否则G1会为了迎合目标频繁回收-XX:ParallelGCThreads设置GC线程数通常默认即可-XX:MetaspaceSize设置元空间大小防止元空间频繁扩容-XX:HeapDumpOnOutOfMemoryErrorOOM时导出堆转储文件强烈建议开启-XX:HeapDumpPath指定堆转储文件路径配合上一条使用G1的MaxGCPauseMillis默认是200ms。很多团队一上来就拍脑袋设成50ms结果G1为了达到这个目标会大幅提高Mixed GC的频率把停顿拆成很多次小型回收吞吐量反而下降。正确做法是观察真实业务的停顿分布设定一个“可以接受但不过分激进”的值。5. 从理论到实战GC日志分析与调优案例5.1 开日志看现象GC日志怎么读不谈日志的GC讲解都是纸上谈兵。生产环境JVM默认不打印GC日志需要显式开启。推荐这样设置-Xlog:gc*:file/opt/applogs/gc-%t.log:time,uptime,level,tags:filecount5,filesize20m在JDK 8及更早版本使用-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/path/to/gc.log。JDK 9以后日志系统重构统一用-Xlog语法。G1日志中一段典型的Minor GC输出长这样[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0234567 secs] [Parallel Time: 20.0 ms, GC Workers: 8] [Eden: 512.0M(512.0M)-0.0B(486.0M) Survivors: 20.0M-24.0M Heap: 1.2G(4.0G)-700.0M(4.0G)]读日志最关键的是看三个指标单次停顿时间、频率、吞吐量损失。如果单次停顿长说明堆中对象太多或回收器配置与业务不匹配如果停顿频繁说明堆太小或对象分配速度太快如果吞吐量损失大说明GC占用的CPU比例过高。5.2 一次线上Full GC频繁的真实排障去年我们一个订单服务频繁报警现象是接口P99延迟从50ms飙升到3秒查看监控发现Full GC每五分钟一次每次停顿接近2秒。排查过程是这样的先看GC日志确认Full GC确实由老年代空间不足触发。用jstat -gcutil pid 1000观察每秒钟Eden、Survivor、老年代使用率的实时变化发现老年代一直以肉眼可见的速度增长。用jmap -dump:live,formatb,fileheap.bin pid导出堆转储然后用MAT分析发现一个名为OrderCache的静态HashMap占用了老年代将近70%的内存而且key是永远不会重复的订单号。最终定位为缓存未设置过期时间和最大容量限制导致缓存无限增长。修复方式很简单给缓存加上容量上限和过期策略Full GC立刻消失接口延迟恢复到正常水平。这个案例说明GC调优不只是调参数。遇到Full GC频繁第一件事永远是看堆里到底装了什么而不是先调大堆内存。调大堆内存只会让“爆雷”的时间更晚不会解决根因。5.3 参数调优的思路先定目标再动参数调优启动参数前先明确你的服务是延迟敏感型还是吞吐量敏感型在线交易、实时推荐等服务对响应时间要求高优先用G1或ZGC把MaxGCPauseMillis设成一个现实中能达到的值。离线批处理、数据导入等任务更关心总耗时用Parallel回收器尽量增大吞吐量容忍单次停顿时间长一些。其次是堆大小设置。我见过不少团队把-Xmx设得很大美其名曰“反正内存够”实际导致GC耗时暴涨。原理很简单堆越大标记和整理需要遍历的对象越多。建议先按程序正常运行时的常驻内存乘以1.5到2倍来估算堆大小不要一开始就给满机器内存。还有一点容易被忽略Metaspace的扩容也会触发Full GC。如果服务频繁加载新类比如使用大量动态代理或热部署元空间不够用时也会触发Full GC。可以观察GC日志中Metaspace的容量增长曲线必要时用-XX:MetaspaceSize和-XX:MaxMetaspaceSize固定空间。6. 常见问题与排查技巧实录6.1 高发问题速查表现象可能原因排查思路频繁Full GC老年代空间不足导出堆转储用MAT分析对象分布GC后内存不降静态集合持有引用或未回收缓存检查全局静态变量、缓存组件配置单次GC停顿过长堆中有超大对象或大数组检查是否一次性加载大量数据到内存并发模式失败业务线程分配对象速度超过CMS回收速度换用G1或调整堆大小Metaspace频繁扩容动态生成类过多增加MetaspaceSize检查类加载器是否泄漏线程等待进入安全点高并发循环密集代码无安全点关注编译热点适当调整安全点参数6.2 几个常被忽视的细节技巧设置JVM参数前先确认JDK版本。JDK 8和JDK 11的默认回收器不同CMS在JDK 14中已经移除很多网上资料已经过时。先执行java -version确认版本再用java -XX:PrintFlagsFinal -version | grep GC查看当前默认回收器。谨慎使用System.gc()。这个方法只是“建议”JVM执行GC但很多框架底层会调用它比如NIO的堆外内存分配失败时。如果不想让业务代码触发Full GC可以用-XX:DisableExplicitGC禁用显式GC。留意大页内存配置。如果操作系统启用了透明大页THPJVM的内存分配行为会受影响可能导致偶发延迟。对延迟敏感的服务建议在操作系统层面关闭THP这个优化成本极低但收益往往很明显。学会用Arthas做在线诊断。Arthas的dashboard命令可以实时查看内存区域使用率、GC次数和耗时不需要频繁重启服务。定位到具体问题后再用heapdump导出快照做离线分析整个排障效率会高很多。6.3 关于GC调优的最终建议从事Java开发这些年我见过太多人一上来就追求“把GC日志优化成一张完美的图表”结果陷入不断调参的死循环。实际上GC调优要解决的永远是问题不是数据。先确认业务是否真的有问题比如延迟变高、CPU飙高、频繁OOM然后再决定要不要调。如果服务运行稳定典型停顿在可接受范围内即使GC频率偏高也不要因为“强迫症”而改动参数。任何参数的调整都意味着一种新的风险尤其在生产环境没有充分验证的情况下默认参数往往比自以为是的“优化”更可靠。对于刚接触JVM的读者我建议从打开GC日志开始先好好观察你的应用每天发生了什么再逐步理解每个回收器为什么那么设计。看得多了你自然会知道什么时候该用G1什么时候该考虑ZGC哪些参数是救命稻草哪些只是心理安慰。这种能力不是背八股文能得来的是真的需要在实际项目中一点点积累的。
