要理解 GC 的演进我们打个极度通俗的比方JVM 的堆内存就是一家正在营业的“疯狂大餐厅”里面挤满了客人活着的对象同时也满地都是别人吃剩的骨头和纸巾死掉的垃圾对象。垃圾回收器 (GC)就是餐厅的保洁团队。保洁团队面临的最大痛点是如果一边打扫一边有客人在扔垃圾这地永远扫不干净甚至会把还没吃完的客人的盘子给收走。为了绝对的安全最早期的 GC如 Serial / Parallel 收集器采用了最暴力的做法砸瓦鲁多时停大喊一声“所有客人不许动”引发 Stop-The-World然后保洁团队冲进去疯狂打扫。打扫完了再打个响指时间恢复流动。吞吐量很高但每次打扫要停顿几百毫秒甚至几秒这在现代互联网应用中是绝对不可接受的。于是漫长而伟大的“消灭 STW 战役”打响了。 史前突破CMS (Concurrent Mark Sweep) —— 边吃边扫的先驱CMS 是 JVM 历史上第一个真正意义上的并发收集器。它的核心目标极其明确把 STW 的时间降到最低。它是怎么做的它把打扫卫生的过程拆成了四步初始标记 (Initial Mark)引发短暂的 STW。保洁阿姨只看一眼“距离门口最近的主桌”GC Roots记住他们。速度极快。并发标记 (Concurrent Mark)不引发 STW保洁阿姨顺着刚才记住的主桌挨个去问全场的人“你们吃完了吗”。此时客人们还在正常吃饭、走动。重新标记 (Remark)引发短暂的 STW。因为刚才第二步是“边吃边扫”肯定有客人偷偷换了座位或者新扔了垃圾。所以必须再时停一下快速核对修正。并发清除 (Concurrent Sweep)不引发 STW确认完毕保洁阿姨开始悄悄把垃圾收走不打扰客人吃饭。致命缺陷内存碎片与退化灾难CMS 最大的败笔在于它的名字Sweep清除。它只管把垃圾扔出去不管把活着的客人排整齐。久而久之餐厅里虽然空座很多但都是东一个西一个的“内存碎片”。突然来了一个需要连座的大客户大对象发现没地方坐了此时 CMS 会当场崩溃直接退化为上古时期的Serial Old收集器。大喊一声“所有人不许动”然后花几秒甚至十几秒时间来做全局碎片整理。一场史诗级的线上灾难就此诞生。 划分战场G1 (Garbage-First) —— 局部化作战的战术大师为了解决 CMS 的内存碎片问题JDK 9 将G1设为了默认的垃圾回收器。G1 带来了颠覆性的架构改变。核心变革打破物理边界的 Region 化G1 觉得一整个大餐厅太难管了它用屏风把大厅隔成了 2048 个小包厢每个包厢叫一个Region。包厢的身份是不固定的今天可以是新生代明天打扫干净了就能作为老年代。G1 的神奇魔法复制算法 (Evacuation) 消灭碎片G1 打扫包厢时不是原地捡垃圾。而是大喊一声“1 号包厢里还没吃完的客人全部端着盘子去空着的 2 号包厢聚一聚”等活着的客人全搬走后直接把 1 号包厢整个炸掉清空。内存瞬间紧凑再无碎片可预测的停顿时间 (Pause Prediction)你可以给 G1 下死命令“我要求每次 STW 最大不能超过 200 毫秒”。G1 就会在后台算笔账发现打扫 10 个包厢刚好需要 200 毫秒那它这次就只挑垃圾最多、收益最高的 10 个包厢去打扫这就是 Garbage-First 名字的由来。瓶颈初现搬家的代价G1 虽然很强但在执行“让客人搬包厢”对象复制转移的这个动作时依然必须触发 STW因为如果对象在内存中的物理地址变了而此时业务线程刚好去读旧地址就会发生恐怖的指针错乱。所以 G1 转移对象时必须时停。堆内存越大需要搬的对象越多STW 依然无法突破 10 毫秒的极限。 最终神话ZGC (Z Garbage Collector) —— 挑战 1 毫秒的黑科技随着 128G、甚至 TB 级别的内存越来越普遍G1 搬家引发的 STW 又成了痛点。终于在 JDK 11实验和 JDK 15转正中Oracle 发布了惊为天人的ZGC。ZGC 极其狂妄地定下了一个小目标无论你的堆内存是 8MB 还是 16TBSTW 停顿时间绝对不超过 10 毫秒在 JDK 16 之后甚至被压缩到了不可思议的1 毫秒以内。ZGC 是怎么做到在业务线程还在狂奔的时候把对象从 A 地址搬到 B 地址还不会读错乱的核武器一染色指针 (Colored Pointers)传统的 JVM 里指针引用就是纯纯用来记录对象的内存地址的。但 ZGC 在 64 位的指针里动了手脚它只拿前面的几十位存地址硬生生抠出了几个标志位Mark0, Mark1, Remapped用来当做“状态标签”。这就像给每个客人的头顶装了个红绿灯。一看指针的颜色GC 就能瞬间知道这个对象“有没有被扫描过”、“是不是正在搬家中”。核武器二读屏障 (Load Barrier)这是 ZGC 敢于“并发转移对象”的终极底气。当 ZGC 正在后台偷偷把对象从 A 地址搬到 B 地址时业务线程突然来读取这个对象了。此时会触发类似 Spring AOP 一样的拦截机制——读屏障。微观视角的极限拉扯业务线程试图去 A 地址读数据。触发读屏障读屏障看了一眼指针的“颜色”发现这个对象刚好处于“搬家状态”或者已经被搬到了 B 地址。神级操作读屏障会瞬间拦住业务线程直接把业务线程手里的旧指针A 地址强行修复成新指针B 地址然后再让业务线程去 B 地址拿数据。这个过程叫做指针自愈 Self-Healing。下一次业务线程再去读因为指针已经修复了直接去 B 地址拿毫无阻碍。震撼的结果因为有了染色指针和读屏障的“指针自愈”魔法ZGC 转移对象这件最耗时的事情完全可以和业务线程同时并发执行ZGC 唯一需要 STW 的地方仅仅只剩下扫描极少数 GC Roots 的初始那一瞬间。所以哪怕你有 16TB 的内存它也只需要停顿不到 1 毫秒 总结没有银弹的取舍架构学纵观 JVM GC 的演进史其实是一场旷日持久的**“吞吐量 (Throughput)” 与 “延迟 (Latency)” 的零和博弈**。Parallel (吃苦耐劳的老黄牛)吞吐量极高适合在后台跑离线数据批处理不在乎卡顿几秒钟。CMS (老兵不死)Web 时代的第一代功臣但败给了内存碎片引起的退化。G1 (中流砥柱)目前 JDK 8 生产环境的绝对主力用 Region 划分完美平衡了吞吐量与停顿时间。ZGC (未来之光)为了追求极致的 1 毫秒低延迟它消耗了大量的 CPU 资源去执行并发搬家和读屏障拦截吞吐量相比 G1 会有大约 10%~15% 的下降。要理解 GC 的演进我们打个极度通俗的比方JVM 的堆内存就是一家正在营业的“疯狂大餐厅”里面挤满了客人活着的对象同时也满地都是别人吃剩的骨头和纸巾死掉的垃圾对象。垃圾回收器 (GC)就是餐厅的保洁团队。保洁团队面临的最大痛点是如果一边打扫一边有客人在扔垃圾这地永远扫不干净甚至会把还没吃完的客人的盘子给收走。为了绝对的安全最早期的 GC如 Serial / Parallel 收集器采用了最暴力的做法砸瓦鲁多时停大喊一声“所有客人不许动”引发 Stop-The-World然后保洁团队冲进去疯狂打扫。打扫完了再打个响指时间恢复流动。吞吐量很高但每次打扫要停顿几百毫秒甚至几秒这在现代互联网应用中是绝对不可接受的。于是漫长而伟大的“消灭 STW 战役”打响了。 史前突破CMS (Concurrent Mark Sweep) —— 边吃边扫的先驱CMS 是 JVM 历史上第一个真正意义上的并发收集器。它的核心目标极其明确把 STW 的时间降到最低。它是怎么做的它把打扫卫生的过程拆成了四步初始标记 (Initial Mark)引发短暂的 STW。保洁阿姨只看一眼“距离门口最近的主桌”GC Roots记住他们。速度极快。并发标记 (Concurrent Mark)不引发 STW保洁阿姨顺着刚才记住的主桌挨个去问全场的人“你们吃完了吗”。此时客人们还在正常吃饭、走动。重新标记 (Remark)引发短暂的 STW。因为刚才第二步是“边吃边扫”肯定有客人偷偷换了座位或者新扔了垃圾。所以必须再时停一下快速核对修正。并发清除 (Concurrent Sweep)不引发 STW确认完毕保洁阿姨开始悄悄把垃圾收走不打扰客人吃饭。致命缺陷内存碎片与退化灾难CMS 最大的败笔在于它的名字Sweep清除。它只管把垃圾扔出去不管把活着的客人排整齐。久而久之餐厅里虽然空座很多但都是东一个西一个的“内存碎片”。突然来了一个需要连座的大客户大对象发现没地方坐了此时 CMS 会当场崩溃直接退化为上古时期的Serial Old收集器。大喊一声“所有人不许动”然后花几秒甚至十几秒时间来做全局碎片整理。一场史诗级的线上灾难就此诞生。 划分战场G1 (Garbage-First) —— 局部化作战的战术大师为了解决 CMS 的内存碎片问题JDK 9 将G1设为了默认的垃圾回收器。G1 带来了颠覆性的架构改变。核心变革打破物理边界的 Region 化G1 觉得一整个大餐厅太难管了它用屏风把大厅隔成了 2048 个小包厢每个包厢叫一个Region。包厢的身份是不固定的今天可以是新生代明天打扫干净了就能作为老年代。G1 的神奇魔法复制算法 (Evacuation) 消灭碎片G1 打扫包厢时不是原地捡垃圾。而是大喊一声“1 号包厢里还没吃完的客人全部端着盘子去空着的 2 号包厢聚一聚”等活着的客人全搬走后直接把 1 号包厢整个炸掉清空。内存瞬间紧凑再无碎片可预测的停顿时间 (Pause Prediction)你可以给 G1 下死命令“我要求每次 STW 最大不能超过 200 毫秒”。G1 就会在后台算笔账发现打扫 10 个包厢刚好需要 200 毫秒那它这次就只挑垃圾最多、收益最高的 10 个包厢去打扫这就是 Garbage-First 名字的由来。瓶颈初现搬家的代价G1 虽然很强但在执行“让客人搬包厢”对象复制转移的这个动作时依然必须触发 STW因为如果对象在内存中的物理地址变了而此时业务线程刚好去读旧地址就会发生恐怖的指针错乱。所以 G1 转移对象时必须时停。堆内存越大需要搬的对象越多STW 依然无法突破 10 毫秒的极限。 最终神话ZGC (Z Garbage Collector) —— 挑战 1 毫秒的黑科技随着 128G、甚至 TB 级别的内存越来越普遍G1 搬家引发的 STW 又成了痛点。终于在 JDK 11实验和 JDK 15转正中Oracle 发布了惊为天人的ZGC。ZGC 极其狂妄地定下了一个小目标无论你的堆内存是 8MB 还是 16TBSTW 停顿时间绝对不超过 10 毫秒在 JDK 16 之后甚至被压缩到了不可思议的1 毫秒以内。ZGC 是怎么做到在业务线程还在狂奔的时候把对象从 A 地址搬到 B 地址还不会读错乱的核武器一染色指针 (Colored Pointers)传统的 JVM 里指针引用就是纯纯用来记录对象的内存地址的。但 ZGC 在 64 位的指针里动了手脚它只拿前面的几十位存地址硬生生抠出了几个标志位Mark0, Mark1, Remapped用来当做“状态标签”。这就像给每个客人的头顶装了个红绿灯。一看指针的颜色GC 就能瞬间知道这个对象“有没有被扫描过”、“是不是正在搬家中”。核武器二读屏障 (Load Barrier)这是 ZGC 敢于“并发转移对象”的终极底气。当 ZGC 正在后台偷偷把对象从 A 地址搬到 B 地址时业务线程突然来读取这个对象了。此时会触发类似 Spring AOP 一样的拦截机制——读屏障。微观视角的极限拉扯业务线程试图去 A 地址读数据。触发读屏障读屏障看了一眼指针的“颜色”发现这个对象刚好处于“搬家状态”或者已经被搬到了 B 地址。神级操作读屏障会瞬间拦住业务线程直接把业务线程手里的旧指针A 地址强行修复成新指针B 地址然后再让业务线程去 B 地址拿数据。这个过程叫做指针自愈 Self-Healing。下一次业务线程再去读因为指针已经修复了直接去 B 地址拿毫无阻碍。震撼的结果因为有了染色指针和读屏障的“指针自愈”魔法ZGC 转移对象这件最耗时的事情完全可以和业务线程同时并发执行ZGC 唯一需要 STW 的地方仅仅只剩下扫描极少数 GC Roots 的初始那一瞬间。所以哪怕你有 16TB 的内存它也只需要停顿不到 1 毫秒 总结没有银弹的取舍架构学纵观 JVM GC 的演进史其实是一场旷日持久的**“吞吐量 (Throughput)” 与 “延迟 (Latency)” 的零和博弈**。Parallel (吃苦耐劳的老黄牛)吞吐量极高适合在后台跑离线数据批处理不在乎卡顿几秒钟。CMS (老兵不死)Web 时代的第一代功臣但败给了内存碎片引起的退化。G1 (中流砥柱)目前 JDK 8 生产环境的绝对主力用 Region 划分完美平衡了吞吐量与停顿时间。ZGC (未来之光)为了追求极致的 1 毫秒低延迟它消耗了大量的 CPU 资源去执行并发搬家和读屏障拦截吞吐量相比 G1 会有大约 10%~15% 的下降。