垃圾收集器

垃圾收集器

垃圾收集算法

复制算法和标记算法都是基于分代收集理论来的。

分代收集理论

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和
老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

比如在新生代中，每次收集都会有大量对象（近99%）死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。

而老年代的对象存活几率是比较高的。而且没有额外的空间对它进行分配担保，所以我们必须选择标记清除或者标记整理算法进行垃圾收集。注意，标记清除和标记整理算法会比复制算法慢10倍以上。

标记复制算法(eden区域算法)

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象
复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。（minor gc）

标记清除算法(老年代算法)

算法分为“标记”和“清除”阶段:标记存活的对象，统一回收所有未被标记的对象(一般选择这种);也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的收集算法，比较简单，但是会带来两个明显的问题:

1. 效率问题(如果需要标记的对象太多，效率不高)

2. 空间问题(标记清除后会产生大量不连续的碎片)

标记整理算法

根据老年代的特点特出的一种标记算法，标记过程仍然与"标记-清除"算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。(避免内存碎片化)

垃圾收集器种类

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现
虽然我们对各个收集器进行比较，但并非为了挑选出一个最好的收集器，因为直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器。我们能做的就是根据具体场景选择适合自己的垃圾收集器。试想一下:如果有一种四海之内、任何场景下都适用的完美收集器存在，那么我们的Java虚拟机就不会实现那么多不同的垃圾收集器了。

垃圾收集器之Serial（-XX:+useSerialGC -XX: +useSerialOldGC）

Serial(串行)收集器是最基本、历史最悠久的垃圾收集器了。看名字就知道这个收集是一个单线程收集器了。它的“单线程”的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾回收的时候必须暂停其他所有的工作线程（STOP THE WORLD）直到它收集结束。

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

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

但是Serial收集器有没有优于其他垃圾收集器的地方呢?当然有，它简单而高效(与其它垃圾收集器的单线程相比），Serial收集器由于没有线程交互的开销，自
然可以获得很高的单线程收集效率。

Serial 0ld收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途:一种用途是在JDK1.5以及以前的版本中与Paralel
Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。

垃圾收集器之Parallel Scavenge(-XX:+useParallelGC -XX:+useParallelOldGC) （JDK8默认垃圾收集器）

Parallel收集器其实就是serial收集器的多线程版本,除了使用多线程进行垃圾收集外,其余行为(控制参数、收集算法、回收策略等等)和Serial收集器类似。默认的收集线程数跟cpu核数相同，当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。

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

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

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

垃圾收集器之CMS收集器（-XX: +useConcMarkSweepGC(old)）

CMS(Concurrent Mark sweep)收集器是一种以获取最短回收停顿时间(STW)为目标的收集器。它非常符合在注重用户体验的应用上使用，它是Hotspot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种“标记-清除"算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

• 初始标记: 暂停所有的其他线程(STW),并记录下GC Roots直接能引用的对象，速度很快，找出GC ROOTS能直接引用的对象就停止
• 并发标记: 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
• 重新标记: 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法做重新标记。
• 并发清理: 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色(``三色标记`)不做任何处理。
• 并发重置:重置本次GC过程中的标记数据，将标记清除

CMS通过将STW分成两次来做，但是STW的时间在不变的情况下，缩短了每次STW的时间，让用户在感知上，基本感知不了STW。

CMS适用于大内存的JVM，Parallel适合几个G的JVM内存

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点:并发收集、低停顿。但是它有下面几个明显的缺点:

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

CMS的相关核心参数

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仅在第一次使用设定值，后续则会自动调整。也就是说该值不设定的话，JVM会在第一次FULL GC时，使用-XX: CMSInitiatingOccupancyFraction设定的值，后续会自动调整回收阈值，也就是说，一次FULL GC 后 -XX: CMSInitiatingOccupancyFraction设定的值会失效

7. -XX: +CMSScavengeBeforeRemark 在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记时段开销，一般CMS的GC耗时80%都是在标记阶段

8. -XX: +CMSParallelInitiatingMarkEnabled 标识在初始化标记的时候多线程执行，缩短STW

9. -XX: +CMSParallelRemarkEnabled 在重新标记的时候多线程执行，缩短STW

垃圾收集器之G1(-XX: useG1GC) JDK9默认垃圾收集器

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

• G1将Java堆划分为多个大小相等的独立区域(Region)，JVM最多可以有2048个Region。
• 一般Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M，当然也可以用参数"-XX: G1HeapRegionSize"手动指定Region大小，但是推荐默认的计算方式。
• G1保留了年轻代和老年代的概念，但不再是物理隔阂它们都是(可以不连续)Region的集合。
• 默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region，可以通过“-XX:G1NewSizePercent”设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。年轻代中的Eden和Survivor对应的region也跟之前一样，默认8:1:1。假设年轻代现在有1000个region，eden区对应800个,s0对应100个，s1对应100个。
• 一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能可能会动态变化。(标记-复制算法导致)
• G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样，唯一不同的是对大对象的处理，G1有专门分配大对象的Regjon叫Humongous区，而不是让大对象直接进入老年代的Region中，在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Regjon,是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。
• Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。
• FULL GC的时候除了收集年轻代和老年代之外，也将Humongous区域一块回收。

G1收集器的运作过程

• 初始标记(initial mark，STW):暂停所有的其他线程，并记录下gcroots直接能引用的对象，速度很快
• 并发标记(Concurrent Marking):同CMS的并发标记
• 最终标记(Remark，STW):同CMS的重新标记
• 筛选回收(Cleanup，STW):筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿STW时间(可以用JVM参数-XX:MaxGCPauseMilis指定)来制定回收计划，比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收中800个Region刚好需要200ms，那么就只会回收800个Region(Collection set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代。回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中,这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意:CMS回收阶段是跟用户线程一起并发执于的，G1因为内部实现太复杂暂时没实现并发回收，不过到了ZGC，Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

G1对Region回收的优先级

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

G1垃圾收集分类

• YoungGc

YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间,如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数-XX:MaxGCPauseMills 设定的值，那么就会触发YoungGC (达不到设定的值的时间，则不会马上进行，等到垃圾对象放到一定地步，再清理)

• MixedGc

不是FuIGC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC

• Full GC

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

G1收集器参数设置

-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区

-XX:MaxGCPauseMillis:目标（期望）暂停时间(默认200ms)

-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:G1MixedGCLiveThresholdPercent(默认85%)region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的意义不大。

-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。

-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region。然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

G1垃圾收集器优化建议

假设参数 -XX:MaxGCPauseMills 设置的值很大,导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc，那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代。

或者是年轻代gc过后，存活下来的对象过多导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。

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

什么场景适合使用G1

1. 50%以上的堆被存活对象占用

2. 对象分配和晋升的速度变化非常大

3. 垃圾回收时间特别长，超过1秒

4. 8GB以上的堆内存(建议值)

5. 停顿时间是500ms以内

垃圾收集器之ZGC（-XX：+useZGC）(JDK11新加入）

• 支持TB量级的堆。我们生产环境的硬盘还没有上TB呢，这应该可以满足未来十年内，所有JAVA应用的需求了吧。
• 最大GC停顿时间不超10ms。目前一般线上环境运行良好的JAVA应用Minor GC停顿时间在10ms左右，Major GC一般都需要100ms以上(G1可以调节停顿时间，但是如果调的过低的话，反而会适得其反)，之所以能做到这一点是因为它的停顿时间主要跟Ro0t扫描有关，而Root数量和堆大小是没有任何关系的。
• 奠定未来GC特性的基础。
• 最糟糕的情况下吞吐量会降低15%，这都不是事，停顿时间足够优秀。至于吞吐量，通过扩容分分钟解决。另外，Oracle官方提到了它最大的优点是:它的停顿时间不会随着堆的增大而增长!也就是说，几十G堆的停顿时间是10ms以下，几百G甚至上T堆的停顿时间也是10ms以下。

如何选择垃圾收集器

1. 优先调整堆的大小让服务器自己来选择

2. 如果内存小于100M，使用串行收集器

3. 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择

4. 如果允许停顿时间超过1秒，选择并行或者JVM自己选

5. 如果响应时间最重要，并且不能超过1秒，使用并发收集器

6. 4G以下可以用parallel,4-8G可以用ParNew+CMS，8G及以上可以用G1，几百G以上用ZGC