JVM垃圾回收算法与垃圾收集器

垃圾回收算法是内存回收的方法论，而垃圾收集器是内存回收的具体实现。

垃圾回收算法

主要包含 4 种垃圾回收算法

标记-清除算法

分为【标记】和【清除】两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

"标记-清除算法"是最基础的收集算法，效率也很高，但是会带来两个明显的问题：

1. 效率问题 
2. 空间问题（标记清除后会产生大量不连续的碎片）

复制算法

为了解决效率问题，“复制”收集算法出现了。

它将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。

在任意时间点，所有动态分配的对象都只能分配在其中一个区间（称为活动区间），而另外一个区间（称为空闲区间）则是空闲的。很显然，它有一个缺点：浪费了一半的内存。所以不是什么地方都可以使用它的。

jvm 新生代中的 from 区和 to 区用的就是复制算法。因为里面的对象回收率很高，而且这两个区一般设置得很小。

标记-整理算法

标记-整理算法是根据老年代的特点退出的一种回收算法，分为两个步骤：标记和整理。

标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

此算法适用于回收效率不高，回收的垃圾较少的情况。比如老年代。

分带收集算法

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块，然后根据每一块内存的特点选择合适的垃圾收集算法。

java堆分为新生代和老年代：

• 新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。
• 老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以选择“标记-清除”或“标记-整理”算法进行垃圾收集。

注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上

垃圾收集器

主要关注 5 种垃圾收集器

虽然JVM提供了很多垃圾收集器，但是直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器。我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。

Serail收集器

启用参数：-XX:+UseSerialGC(年轻代), -XX:+UseSerialOldGC(老年代)

Serial(串行)收集器是最基本、历史最悠久的垃圾收集器。它是一个单线程收集器。

它的“单线程”的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程(Stop The World)，直到它收集结束。

新生代采用复制算法，老年代采用标记-整理算法。

虚拟机的设计者们当然知道【Stop The World】带来的不良用户体验，所以在后续的垃圾收集器设计中，停顿时间在不断缩短（仍然还有停顿，寻找最优秀的垃圾收集器的过程仍然在继续）。

当然，Serial收集器也有它的优点：由于没有线程交互的开销，它有着很高的单线程收集效率。

Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。它有个用途是作为CMS收集器的后备方案。

ParNew收集器

启用参数：-XX:+UseParNewGC（启用ParNew只会影响年轻代的收集，不影响老年代）

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为(控制参数、收集算法、回收策略等等)和Serial收集器完全一样。

默认的收集线程数跟cpu核数相同，当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。

ParNew只能用于新生代垃圾回收！采用复制算法。

ParNew收集器是许多运行在Server模式下的虚拟机的首要选择。除了Serial收集器外，只有它能与CMS收集器配合工作。而且 ParNew+CMS 配合工作，也是常用的用法。

Parallel Scavenge收集器

启用参数：-XX:+UseParallelGC(年轻代), -XX:+UseParallelOldGC(老年代)

Parallel Scavenge收集器类似于ParNew收集器，是Server模式下的默认收集器(jdk8)。

java -XX:+PrintFlagsFinal -version | grep :

新生代采用复制算法，老年代采用标记-整理算法。

Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。

Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，可以选择把内存管理优化交给虚拟机去完成。

Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。如果注重吞吐量以及CPU资源，那么可以优先考虑Parallel Scavenge收集器和Parallel Old收集器。

CMS收集器

启用参数：-XX:+UseConcMarkSweepGC

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。

它非常符合在注重用户体验的应用上使用，是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程基本上同时工作。

CMS用于老年代垃圾回收！

CMS收集器是一种“标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

1. 初始标记：暂停所有的其他线程，并记录下 GC Roots 直接能引用的对象，速度很快
2. 并发标记：同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
3. 重新标记：为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
4. 并发清理：开启用户线程，同时GC线程开始对未标记的区域做清扫。

很显然，最耗时的就是并发标记阶段了。

 CMS收集器是一款优秀的垃圾收集器，它的优点主要是：并发收集、低停顿。

但也有一些缺点：

• 对CPU资源敏感（会和服务抢资源）
• 会产生浮动垃圾（在并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次GC再清理了）
• 它使用的是“标记-清除”算法，会导致收集结束时会有大量空间碎片产生。当然，可以通过设置参数 -XX:+UseCMSCompactAtFullCollection，让jvm在执行完标记清除后再做整理
• 执行过程中的不确定性。会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发 Full GC，也就是 "concurrent mode failure"，此时会进入 stop the world，用serial old垃圾收集器来回收

相关参数：

1. -XX:+UseConcMarkSweepGC：启用cms 
2. -XX:ConcGCThreads：并发的GC线程数 
3. -XX:+UseCMSCompactAtFullCollection：Full GC 之后做压缩整理（减少碎片） 
4. -XX:CMSFullGCsBeforeCompaction：多少次Full GC之后压缩一次，默认是0，代表每次 Full GC 后都会压缩一次 
5. -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发 Full GC（默认是92，这是百分比） 
6. -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM 仅在第一次使用设定值，后续则会自动调整 
7. -XX:+CMSScavengeBeforeRemark：在 CMS GC 前启动一次 Minor GC，目的在于减少老年代对年轻代的引用，降低 CMS GC 的标记阶段时的开销，一般 CMS 的 GC 耗时 80% 都在 remark 阶段

G1收集器

G1(Garbage-First)是一款面向服务器的垃圾收集器，主要针对配备多颗处理器及大容量内存的机器。在极高概率满足GC停顿时间要求的同时，还具备高吞吐量性能特征。

G1收集器在内存划分上，跟我们熟悉的堆内存划分方式不一样！ 

内存划分

G1将Java堆划分为多个大小相等的独立区域(Region)，JVM最多可以有2048个Region。 一般Region大小等于堆大小除以2048，比如假设堆大小为4096M，则Region大小为2M。也可以用参数"-XX:G1HeapRegionSize"手动指定Region大小，但是推荐默认的计算方式。 

• G1保留了年轻代和老年代的概念，但不再是物理隔阂了，它们都是Region的集合(不一定连续)
• Region的区域功能是可能发生动态变化的，比如一开始是老年代，后面经过垃圾回收后被空出来了，之后又用它来做年轻代
• 默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region，可以通过“-XX:G1NewSizePercent”设置新生代初始占比
• 在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整
• 年轻代中的Eden和Survivor对应的region也跟之前一样，默认8:1:1，假设年轻代现在有1000个region，eden区对应800个，s0和s1各自对应100个

Humongous区

G1垃圾收集器对于对象什么时候会转移到老年代跟之前的原则一样，唯一不同的是对大对象的处理：

• G1有专门分配大对象的 Region 叫 Humongous区，而不是让大对象直接进入老年代的 Region 中
• 在G1中，大对象的判定规则就是一个大对象超过了一个 Region 大小的 50%。比如每个 Region 是 2M，只要一个对象超过了 1M，就认为是大对象，会将它放入 Humongous 中
• 一个大对象如果太大，可能会横跨多个 Region 来存放
• Humongous 区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销
• Full GC 的时候除了收集年轻代和老年代之外，也会将 Humongous 区一并回收

GC过程

G1收集器一次GC的运作过程大致分为以下几个步骤：

1. 初始标记(initial mark，STW)：暂停所有的其他线程，并记录下 GC Roots 直接能引用 的对象，速度很快
2. 并发标记(Concurrent Marking)：同CMS的并发标记
3. 最终标记(Remark，STW)：同CMS的重新标记
4. 筛选回收(Cleanup，STW)：筛选回收阶段首先对各个 Region 的回收价值和成本进行排序，根据用户所期望的GC停顿时间(-XX:MaxGCPauseMillis)来制定回收计划。比如说老年代此时有 1000 个 Region 都满了，但是因为根据预期停顿时间，本次垃圾回收假设只能停顿 200ms，那么通过之前回收成本计算得知，可能回收其中800个 Region 刚好需要 200ms，那么就只会回收800个 Region，尽量把GC导致的停顿时间控制在我们指定的范围内。

回收算法

G1收集器中，不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个 Region 中的存活对象复制到另一个 Region 中，不会有太多内存碎片。

最大的优势

G1收集器最大的一个优势是它可以设置垃圾收集的暂停时间，默认200ms！Parallel Scavenge 收集器也有类似的功能，不过 G1 的要强得多。

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来)。比如一个 Region 花 200ms 能回收 10M 垃圾，另外一个 Region 花 50ms 能回收 20M 垃圾，在回收时间有限情况下，G1当然会优先选择后面这个 Region 回收。这种方式保证了G1收集器在有限时间内可以尽可能高的收集效率。

每个 Region 都有一个预估需要的回收时间，这样可以按照回收时间从小到大依次开始回收，直到总时间达到了设置的暂停时间(默认200ms)，就停止回收。

有了这个功能，就可以在卡顿几乎无感知的情况下，一边处理业务一边收集垃圾。

垃圾收集分类

1）YoungGC

首先要注意一点：YoungGC 并不是说现有的Eden区放满了就会马上触发。

G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数 [-XX:MaxGCPauseMills (暂停时间)] 设定的值（比如暂停时间设置200ms，而Eden区回收时间只要10ms），那么不会马上做 Young GC，而是会增加年轻代的 Region，继续存放新对象！直到下一次Eden区放满，G1计算回收时间接近参数 [-XX:MaxGCPauseMills] 设定的值，才会触发 Young GC。

2）MixedGC

老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercen)设定的值则触发，回收所有的Young 和 部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区。

正常情况G1的垃圾收集是先做 MixedGC，主要使用复制算法，把各个 Region 中存活的对象拷贝到别的 Region 里去，拷贝过程中如果发现没有足够的空 Region 能够承载拷贝对象就会触发一次 Full GC。

3）Full GC 

停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批 Region 来供下一次 MixedGC 使用，这个过程是非常耗时的。

优化建议

假设参数 [-XX:MaxGCPauseMills] 设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。

所以这里核心还是在于调节 [-XX:MaxGCPauseMills] 参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少，避免存活对象太多快速进入老年代，频繁触发 Mixed GC。

相关参数

• -XX:+UseG1GC：使用G1收集器 
• -XX:MaxGCPauseMillis：目标暂停时间(默认200ms)
• -XX:ParallelGCThreads：指定GC工作的线程数量 
• -XX:G1HeapRegionSize：指定分区大小(1MB~32MB，且必须是2的幂)，默认将整堆划分为 2048个分区 
• -XX:G1NewSizePercent：新生代内存初始空间(默认整堆5%) 
• -XX:G1MaxNewSizePercent：新生代内存最大空间 
• -XX:TargetSurvivorRatio：Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄 1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对 象都放入老年代 
• -XX:MaxTenuringThreshold：最大年龄阈值(默认15) 
• -XX:InitiatingHeapOccupancyPercent：老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了
• -XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否到达阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他 Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。 
• -XX:G1MixedGCLiveThresholdPercent(默认85%)：region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。 
• -XX:G1MixedGCCountTarget：在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。

适用场景

G1收集器特别适用于大内存的场景：

Kafka类似的支撑高并发消息系统大家肯定不陌生，对于kafka来说，每秒处理几万甚至几十万消息时很正常的，一般来说部署kafka需要用大内存机器(比如64G)，也就是说可以给年轻代分配个三四十G的内存用来支撑高并发处理。

这里就涉及到一个问题了，对于Eden区的Young GC是很快的，这种情况下它的执行还会很快吗？很显然，不可能，因为内存太大，处理还是要花不少时间的，假设三四十G内存回收可能最快也要几秒钟，按kafka这个并发量放满三四十G的eden区可能也就一两分钟吧，那么意味着整个系统每运行一两分钟就会因为Young GC卡顿几秒钟没法处理新消息，显然是不行的！

那么对于这种情况如何优化呢？可以使用G1收集器，设置 [-XX:MaxGCPauseMills] 为50ms，假设50ms能够回收三到四个G内存，然后50ms的卡顿其实完全能够接受，用户几乎无感知，那么整个系统就可以在卡顿几乎无感知的情况下一边处理业务一边收集垃圾。

如何选择垃圾收集器

• 如果不确定的话，优先调整堆的大小，让服务器自己来选择回收器
• 单CPU或者小内存，单机程序，使用Serial收集器 => [-XX:+UseSerialGC]
• 多CPU，需要大吞吐量，如后台计算型应用，适合使用Parallel收集器 => [-XX:+UseParallelGC -XX:+UseParallelOldGC]
• 多CPU，追求低停顿时间，快速响应如互联网应用，使用使用ParNew + CMD => [-XX:+UseParNewGC -XX:+UseConcMarkSweepGC]
• 大内存场景，适合使用G1收集器 => [-XX:+UseG1GC]

下图有连线的可以搭配使用（打红叉的是jvm已经不推荐使用的）：