重点：cms与G1

minor gc 和full gc 都会产生stw现象。
stw原因：
如果不停止用户线程，会影像垃圾回收的准确性。

一、垃圾回收算法

1.分代收集理论

当前虚拟机的垃圾收集都采用分代收集算法，根据对象存活周期的不同，将内存分为几块。一般将java堆分为新生代和老年代，根据各个年代的特点选择合适的垃圾收集算法。
新生代：
每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。
老年代
对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上

| | 浪费空间 | 效率高、无内存碎片 | | 标记清除 | |
- [x]

| 效率低于复制算法，且产生内存空间碎片 | 实现简单 | | 标记整理 | |
- [x]

| 效率低于复制算法 | 无碎片 |

2.标记-复制算法[新生代]

一般用在年轻代（标记非垃圾算法），老年代不会使用标记复制算法，太浪费空间。（年轻代空间本来就不大，所以浪费不会太多）
将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块，然后再把使用的空间一次清理掉。每次的内存回收都是对内存区间的一半进行回收

3.标记-清除算法

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

两个明显的问题：
效率问题 (如果需要标记的对象太多，效率不高)
空间问题（标记清除后会产生大量不连续的碎片）

4.标记-整理算法[老年代]

适合老年代的的一种标记算法，
标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。垃圾回收后，内存不会出现碎片。

垃圾回收过程中，涉及到对象的移动，所以垃圾回收后，栈中指针指向的对象地址，会同步变更。

二、垃圾收集器

垃圾收集器，本质就是垃圾回收算法的具体实现。

Serial收集器（简单）

串行收集器，STW过程中，使用单线程回收垃圾
算法
年轻代：标记复制
年老代：标记整理
使用配置
-XX:+UseSerialGC，标记年轻代使用Serial收集器
-XX:+UseSerialOldGC，标记老年代使用Serial收集器
单核处理器，推荐使用，如果在单核处理器上使用多线程收集器，会增加线程切换，效率反而不高。

Parallel Scavenge收集器

Serial收集器的多线程版本（STW过程中，使用多线程回收垃圾），无法与CMS一起使用。与CMS相比，STW时间较长
算法选择
年轻代：标记复制
年老代：标记整理
（无法与cms收集器一起使用）
支持内存大小（1-2G）
使用配置
-XX:+UseParallelGC(年轻代),
-XX:+UseParallelOldGC(老年代)
垃圾回收时可以采用多线程（线程数与cpu核数一致）进行回收。
可以用参数(-XX:ParallelGCThreads)指定收集线程数，建议与核数相同。
Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)。

ParNew收集器（年轻代）

(-XX:+UseParNewGC)
（仅用于年轻代回收）
ParNew收集器与Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。

CMS[Concurrent Mark Sweep]收集器（老年代）

算法选择
标记清除算法
(-XX:+UseConcMarkSweepGC(old))【标记清除算法】
支持4-5G内存，用于老年代垃圾回收。一种获取最短回收停顿时间为目的的收集器。
回收过程，分多个阶段，虽然延长了整个垃圾回收的时间，但最终目的缩短了stw时间。

CMS回收过程

初始标记（stw）

标记在对象的对象头
记录下gc roots直接能引用的对象，速度快。
之所以stw，是为了防止不断新增新的对象，导致无法完成标记。处理的是某个镜像

并发标记

并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，
整个过程耗时会比较久，但不需要停止用户进程，即不需要（stw），用户线程可以与垃圾收集线程一起并发运行
可能会有已经标记过的对象状态发生改变。（1.标记时不是垃圾，标记结束后变成垃圾。2.标记时是垃圾，但标记结束后，不是垃圾对象使用finalize自救）

重新标记（stw）

为了修正并发标记期间，因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录
此阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。
主要用到三色标记里的增量更新算法

并发清理

开启用户线程，同时GC线程开始对未标记的区域做清扫。
这个阶段如果有新增对象会被标记为黑色不做任何处理

并发重置

重置本次GC过程中的标记数据，即复位

缺点

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

  CMS的相关核心参数

  -XX:+UseConcMarkSweepGC：启用cms
  -XX:ConcGCThreads：并发的GC线程数
  -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
  -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次
  -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92%。当存在较多大对象时，这个比例应该调小一些）
  -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定此参数，JVM仅在第一次使用设定值，后续则会自动调整
  -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，降低CMS GC标记阶段(如果存在跨代引用。也会对年轻代一起做标记，如果在minor gc时，回收大部分对垃圾对象，标记阶段就会减少一些标记时间)时的开销，一般CMS的GC耗时 80%都在标记阶段
  -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
  -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

  G1垃圾回收机制

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

  内存结构变更

  原内存结构
  
  G1内存结构
  
  G1将Java堆划分为多个大小相等的独立区域（Region），JVM目标是不超过2048个Region(JVM源码里TARGET_REGION_NUMBER 定义)，实际可以超过该值，但是不推荐。

  Region大小计算

  一般Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M，当然也可以用参数”-XX:G1HeapRegionSize”手动指定Region大小，但是推荐默认的计算方式。

  G1的分代方式

  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垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样，
大对象
唯一不同的是对大对象的处理，G1有专门分配大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。

Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。
Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

G1回收果过程

初始标记（initial mark，STW）

暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；

并发标记（Concurrent Marking）

同CMS的并发标记

最终标记（Remark，STW）

同CMS的重新标记

筛选回收（Cleanup，STW）

根据用户期望GC停顿，指定回收计划。压缩的是筛选回收时间
首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿STW时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，尽量把GC导致的停顿时间控制在我们指定的范围内（保证用户体验）
比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集合)。
这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。

不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。
(注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了ZGC，Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

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

合理利用用户指定期望停顿时间

由用户指定期望的停顿时间是G1收集器很强大的一个功能， 设置不同的期望停顿时间， 可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。 不过， 这里设置的“期望值”必须是符合实际的
毕竟G1是要冻结用户线程来复制对象的， 停顿时间再怎么低也得有个限度。 它默认的停顿目标为两百毫秒，
一般来说， 回收阶段占到几十到一百甚至接近两百毫秒都很正常， 但如果我们把停顿时间调得非常低， 譬如设置为二十毫秒， 很可能出现的结果就是由于停顿目标时间太短， 导致每次选出来的回收集只占堆内存很小的一部分， 收集器收集的速度逐渐跟不上分配器分配的速度， 导致垃圾慢慢堆积。 很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间， 但应用运行时间一长就不行了， 最终占满堆引发Full GC反而降低性能， 所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

G1垃圾收集分类

YoungGC

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

MixedGC

与Full GC类似，但不是FullGC。
老年代的堆占有率达到参数(-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垃圾收集器优化建议

合理设置用户期望停顿时间、避免触发Full GC
假设参数 -XX:MaxGCPauseMills 设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。
或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。
所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.

G1适合场景

50%以上的堆被存活对象占用
对象分配和晋升的速度变化非常大
垃圾回收时间特别长，超过1秒
8GB以上的堆内存(建议值)
停顿时间是500ms以内

ZGC垃圾回收机制

不分代，无法解决对象生命周期不一致问题。

三、垃圾收集底层算法实现

三色标记

在并发标记期间中，应用线程还在继续执行，对象间的引用，随时发生变化。多标、漏标情况随时可能发生。
利用三色标记，将gc roots可达性分析遍历对象过程中遇到的对象，按照“是否访问过”条件，标记成三种颜色。颜色标记在对象上（ZGC除外）
黑色
表示对象已经被垃圾收集器访问过， 且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过， 它是安全存活的， 如果有其他对象引用指向了黑色对象， 无须重新扫描一遍。 黑色对象不可能直接（不经过灰色对象） 指向某个白色对象。
并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色
灰色
表示对象已经被垃圾收集器访问过， 但这个对象上至少存在一个引用还没有被扫描过
白色
表示对象尚未被垃圾收集器访问过。 （GC Root无法访问到的对象）
可达性分析刚刚开始的阶段， 所有的对象都是白色的， 若在分析结束的阶段， 仍然是白色的对象， 即代表不可达。

多标-浮动垃圾

浮动垃圾
在并发标记过程中，如果由于方法运行结束导致部分局部变量(gc root)被销毁，已经被扫描的gc root，对应的引用对象已经被扫描过(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。
浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。
针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，也是浮动垃圾一个来源

漏标-读写屏障

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决
两种解决方案： 增量更新（Incremental Update） 和原始快照（Snapshot At The Beginning，SATB） 。

增量更新（记录新的关系）

当黑色对象插入新的指向白色对象的引用关系时， 就将这个新插入的引用记录下来， 等并发扫描结束之后， 再将这些记录过的引用关系中的黑色对象为根， 重新扫描一次。
这可以简化理解为， 黑色对象一旦新插入了指向白色对象的引用之后， 它就变回灰色对象了。

原始快照（记录旧的关系）

当灰色对象要删除指向白色对象的引用关系时， 就将这个要删除的引用记录下来， 在并发扫描结束之后， 再将这些记录过的引用关系中的灰色对象为根， 重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色(目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾)
以上无论是对引用关系记录的插入还是删除， 虚拟机的记录操作都是通过写屏障实现的。

追踪式（可达性分析）的垃圾回收器几乎都借鉴了三色标记的算法思想，尽管实现的方式不尽相同：比如白色/黑色集合一般都不会出现（但是有其他体现颜色的地方）、灰色集合可以通过栈/队列/缓存日志等方式进行实现、遍历方式可以是广度/深度遍历等等。
对于读写屏障，以Java HotSpot VM为例，其并发标记时对漏标的处理方案如下：
CMS：写屏障 + 增量更新
G1，Shenandoah：写屏障 + SATB
ZGC：读屏障

为什么G1用SATB？CMS用增量更新？

SATB相对增量更新效率会高(当然SATB可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象。
而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。
SATB：不会重新进行遍历，保证效率，但会出现大量浮动垃圾。
增量更新：会进行对象的重新标记，虽然可以一定程度减少浮动垃圾。但当内存比较大时，无法保证效率。

四、记忆集与卡表

主要用于解决跨代引用。

新生代做GC Roots 可达性扫描过程中可能会碰到跨代引用的对象。若在存在跨代引用时，又去扫描老年代，效率太低，为了重新扫描老年代问题。
在新生代引入记录集（Remember Set）数据结构【记录从非收集区到收集区的指针集合】，避免将整个老年代加入GC Roots扫描返回。

跨代引用场景

并非只有新生代、老年代才有跨代引用问题。所有涉及部分区域收集行为的垃圾收集器【G1、ZGC、Shenandoah】都存在这样的问题。

在垃圾收集过程中，收集器只需通过记忆集判断出某一块非收集区域是否存在指向收集区域的指针即可，无需了解跨代引用指针的全部细节。

卡表

hotspot使用一种叫做“卡表”(Cardtable)的方式实现记忆集，也是目前最常用的一种方式。关于卡表与记忆集的关系， 可以类比为Java语言中HashMap与Map的关系。
卡表是使用一个字节数组实现：CARD_TABLE[ ]，每个元素对应着其标识的内存区域一块特定大小的内存块，称为“卡页”。
hotSpot使用的卡页是2^9大小，即512字节

卡表在年轻代。卡页在老年代
一个卡页中可包含多个对象，只要有一个对象的字段存在跨代指针，其对应的卡表的元素标识就变成1，表示该元素变脏，否则为0.
GC时，只要筛选本收集区的卡表中变脏的元素加入GCRoots里。
卡表的维护
卡表变脏上面已经说了，但是需要知道如何让卡表变脏，即发生引用字段赋值时，如何更新卡表对应的标识为1。
Hotspot使用写屏障维护卡表状态。

参考文档：
https://note.youdao.com/ynoteshare1/index.html?id=21b50d8595b245f7d7d01a6bbfefe6c4&type=note
https://note.youdao.com/ynoteshare1/index.html?id=74c84c1ab69727580cdb2646d35674fc&type=note