分代收集理论
当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将Java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
比如在新生代中，每次收集都会有大量的对象死去， 所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。
而老年代的对象存活几率是比较高的，而且没有额外的空降对它进行分配担保，所以我们必须要选择"标记-清除" 、 "标记-整理" 算法进行垃圾收集。
需要注意的是，"标记-清除" 或 "标记-整理"算法会比复制算法慢10倍以上。
标记-复制算法
为了解决效率问题，"复制"收集算法出现了，它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。
这样就使每次内存回收都是对内存区间的一半进行回收。
如上图所示，Java新生代的Survivor区就是用的该算法，Survivor存在to、from两个区，始终会有一个区是空的，当触Minor Gc时，会将存活的对象移动到为空的那个区。
标记-清除算法
算法分为"标记"、"清除"
- 标记存活的对象，统一回收所有未被标记的对象（一般选择这种）;
- 标记所有需要回收的对象，在标记完成后统一回收所有被标记的对象
它是最基础的收集算法，比较简单，但是会带来两个明显的问题：
- 1、效率问题：如果需要标记的对象太多，那么效率不高
- 2、空间问题：标记清除后悔产生大量不连续的碎片
如上图所示，处理之后，将需要回收的对象进行回收，内存是腾出来了，但是会造成大量的内存碎片，导致内存不连续。
标记-整理算法
根据老年代的特点特出的一种标记算法，标记过程仍然与"标记-清除"算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉边界以外的内存。
如下图所示：（ps：gif图做了一下加速，和压缩处理，所以看起来会有点模糊）
垃圾收集器
如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。
直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，我们所能做的就是根据具体应用场景选择适合自己的垃圾收集器。
Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)
Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了，而且它是一个单线程的收集器。
它的"单线程"的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集的时候，必须暂停其他所有的工作线程(Stop The World)，直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法
虚拟机的设计者们当然直到Stop The World带来的不良用户体验，所以在后续的垃圾收集器设计中停顿时间在不断缩短（仍然还有停顿，开发最优秀的垃圾收集器的过程仍然还在继续）。
但是Serial收集器的优点在于，它简单而高效（与其他收集器的单线程相比）。Serial收集器由于没有线程交互的开销，自然可以获得很高的单线程手机效率。
Serial Old 收集器是Serial收集器的老年代版本，它专注于收集老年代，同样是一个单线程收集器，它主要有两大作用：
- 在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用
- 作为CMS收集器的后备方案
Parallel Scaveng 收集器（ -XX:+UseParallelGC , -XX:+UseParallelOldGC ）
Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等） 和 Serial收集器类似。
默认的收集线程跟CPU核数相同，当然也可以用参数（-XX:ParallelGCThreads）指定收集线程数，但是一般不推荐修改。
Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。
Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于垃圾收集器运作不太了解的话，可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。
新生代采用复制算法，老年代采用标记-整理算法。
Parallel Old收集器是Parallel Scavenge收集器的老年代版本。
使用多线程和"标记-整理"算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑Parallel Scavenge收集器和Parallel Old收集器（JDK8默认的新生代和老年代收集器）。
ParNew收集器（ -XX:+UseParNewGC ）
ParNew 收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。
新生代采用复制算法，老年代采用标记-整理算法
它是许多运行在Server模式下虚拟机的首要选择，除了Serial收集器外，只要它能与CMS收集器（真正意义上的并发收集器）配合工作。
CMS收集器（ -XX:+UseConcMarkSweepGC(old) ）
CMS ( Concurrent Mark Sweep ) 收集器是一种以获取最短回收停顿时间为目标的收集器。
它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作
CMS收集器是一种"标记-清除"算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂
- 初始标记：暂停所有的工作线程（Stop The World），并记录下 GC Roots 直接能引用的对象，速度很快。
- 并发标记：并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集器一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
- 重新标记：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分的标记记录，这个阶段的停顿时间一般会比初始标记节点的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法做重新标记。
- 并发清理：恢复工作线程，同时GC线程开始对未标记的区域做清扫，这个阶段如果又新增对象会被标记为黑色不做任何处理（也就是浮动垃圾）。
- 并发重置：充值本次GC过程中的标记数据。
CMS的主要优点是：并发收集、低停顿。但是它也有几个明显的缺点：
- 对CPU资源敏感，（会和工作线程抢资源）;
- 无法处理浮动垃圾（在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次GC再清理了）;
- 它使用的回收算法-"标记-清除"算法会导致收集结束时会有大量空间碎片产生，可以通过参数-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后，再做整理
- 执行过程中的不确定性，一边回收，工作线程一边运行，也许还没回收完就再次触发full gc，也就是"concurrent mode failure",此时会停止CMS收集，用Serial Old垃圾收集器来回收，并且进入Stop The World。
CMS的相关核心参数
- -XX:UseConcMarkSweepGC （启用CMS）
- -XX:ConcGCThreads （并发的GC线程数）
- -XX:+UseCMSCompactAtFullCollection （FullGC之后做标记整理 减少碎片）
- -XX:CMSFullGCsBeforeCompaction（多少次FullGC之后压缩一次，默认是0，代表每次Full GC都会压缩一次）
- -XX:CMSInitiatingOccupancyFraction（当老年代使用达到该比例时会触发FullGc 默认是92，这是百分比）
- -XX:+UseCMSInitiatingOccupancyOnly（指定只使用设定的回收阈值百分比，如果不设置，JVM仅在第一次使用设定值百分比，后续则会自动调整）
- -XX:+CMSScavengBeforeRemark（在CMS GC前启动一次Minor GC，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时80%都处于标记阶段）
- -XX:CMSParallellnitialMarkEnabled（标识在初始标记的时候多线程执行，缩短STW）
- -XX:CMSParallelRemarkEnabled（在重新标记的时候多线程执行，缩短SWT）
三色标记算法
在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用肯能发生变化，多标和漏标的情况可能发生。
GC Roots 可达性算法分析遍历对象过程中遇到的对象，按照"是否访问过"这个条件标记为三种颜色
- 黑色: 标识该对象已经被垃圾收集器访问过，且对象中的所有引用都已经扫描过
- 黑色的对象代表已经扫描过，它是安全存活的，如果又其他对象引用指向了黑色对象，无无须重新扫描一遍，而且黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
- 灰色: 表示对象已经被垃圾收集器访问过，但这个对象至少存在一个引用还没有被扫描过。
- 白色: 表示对象尚未被垃圾收集器访问过。
- 在可达性分析开始之前，所有的对象都是白色的，如果在可达性分析结束之后，对象仍是白色的，即表示该对象不可达，不可达也就意味着没有任何引用，那么就可以回收了。
三色标记代码示例-1
public class MarkGC {
public static void main(String[] args) {
Class1 class1 = new Class1();
class1.class4.class2.class5 = class1.class4.class5;
}
static class Class1 {
Class4 class4 = new Class4();
}
static class Class2 {
Class5 class5 = null;
}
static class Class3 {
}
static class Class4 {
Class2 class2 = new Class2();
Class5 class5 = new Class5();
}
static class Class5 {
Class3 class3 = new Class3();
}
}
代码的引用关系，如下图所示，所有的对象，在可达性分析之前，都是白色的。
在可达性算法扫描开始时，会将class1作为GC Roots，也就是根节点，对根节点深入扫描。首先将Class1标记为灰色。
而Class1中有一个成员变量，是Class4，所以这里会深入成员变量扫描，也就是扫描Class4，把Class4标记为灰色。
现在有一个问题，Class4与 Class1、Class2、Class5相连，而Class1已经被标记过了，固然不会选择Class1去深入扫描，而是会从Class2 | Class5 之间选择一个，假设现在Class4选择了Class2，那么下一步会把Class2标记为灰色。
Class2与Class4、Class5已相连，Class4已标记过，不会再处理，下一步处理Class5，也就是把CLass5标记为灰色
最后一步，将Class3标记为灰色
标记到这里后，会发现Class3里面没有任何的成员变量，也就是没有继续可扫描的对象了，那么这时候会将Class3标记为黑色，标识Class3已经全部扫描完毕。
Class3处理后，回退到Class5，发现所有成员变量已经处理了后，那么把Class5标记为黑色，并且再向上回退一层，（也就是回退到Class2，因为之前是通过CLass2进入的Class5扫描）
回退到Class2后，Class2的成员变量也都被处理，所以这里继续把Class2标记为黑色，并且回到上一层，回到Class4。
回到Class4之后，它的成员变量Class2、Class5都已经被标记为了黑色，既然都处理完了，那么把Class4也标记为黑色，再向上回退，回退到Class1
回到Class1之后，可见Class1的成员变量也都被处理过了，所以Class1也标记为黑色，最后，这些对象都是非垃圾对象，且不会被回收。
三色标记代码示例-2
public static void main(String[] args) {
Class1 class1 = new Class1();
class1.class4.class2.class5 = class1.class4.class5;
class1.class4.class5.class3 = null;
}
将上面示例的代码修改，我们把Class5里面的class3变量置为null，那么这种情况下，虽然Class3这个对象确实是创建了，但是没有引用了已经，那么可达性算法就不会扫描到Class3，未扫描到的对象是初始化的白色，所以它最终会被清除掉。
多标-浮动垃圾
在并发标记过程中，如果由于方法运行结束导致部分局部变量（GC Roots）被销毁，而这个GC Roots引用的对象之前又被扫描过（被标记为非垃圾对象），那么本轮GC不会回收这部分内存。
这部分本应该回收但是没有回收到的内存，被称之为"浮动垃圾"。
浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。
另外，针对并发标记（还有并发清理）执行后开始产生的新对象，通常的做法是直接全部标记为黑色，本轮不会进行清除。这部分对象期间也可能会变为垃圾，但是不会被清除，这也算是浮动垃圾的一部分。
漏标-读写屏障
漏标的产生
public class MarkGC2 {
private static final Class1 class1 = new Class1();
public static void main(String[] args) {
class1.class2 = null;
}
static class Class1 {
Class2 class2 = new Class2();
}
static class Class2 {
{
new Timer().schedule(new TimerTask() {
@Override
public void run() {
//重新赋值引用
class1.class2 = Class2.this;
}
}, 3000);
}
}
}
如上述代码示例，class1作为静态变量，而mian方法中将class1中的class2置为null，如果这时候可达性算法运行，就会扫描不到class1里面的class2这个对象，因为引用已经被置为null了。
当可达性算法执行结束，class2这个对象将自己的引用赋值到了这个静态变量class1里面，按理说它这时候是有被引用，不能被清除，但是可达性算法已经结束了，不会去处理这个被引用的白色对象，那么最终这个class2对象会被回收，这就是漏标。
漏标会导致被引用的对象被当成垃圾误删除，这是严重的问题，必须要解决掉。
有两种解决方案
- 增量更新（Incremental Update）
- 增量更新就是当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。
- 可以简化理解为，黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了。
- 原始快照（Snapshot At The Beginning , SATB ）
- 原始快照就是当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色（目的是让这种对象在本轮GC清理中能存活下来，等待下一轮GC的时候重新扫描，这个对象也有可能是浮动垃圾）
- 以上，无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。
写屏障
所谓的写屏障，其实就是指在赋值操作前后，加入一些处理，记录下来，可以参考Spring AOP的概念。
- 写屏障实现 SATB
- 当对象的变量引用发生变化时，比如 class1.class2=null ，可以利用写屏障，将原来变量的引用记录下来 。
- 写屏障实现增量更新
- 当对象的变量引用发生变化时，比如class1.class2 = Class2.this ; 可以利用写屏障，将新的变量引用对象记录下来。
读屏障
读屏障就是当读取成员变量时，一律记录下来
漏标处理方案
对于读写屏障，以Java HotSpot VM为例，其并发标记时各垃圾收集器对漏标的处理方案如下：
- CMS：写屏障 + 增量更新
- G1，Shenandoah：写屏障+SATB
- ZGC：读屏障