一、垃圾收集算法

1、分带收集理论

基于新生代和老年代选择不同垃圾回收算法，比如新生代，都是一些暂存对象，而且内存分区域的，可以采用标记复制算法。而老年代只有一块内存区域，使用复制算法比较占用内存空间，不适合复制算法，可以使用标记清除或者标记整理，标记复制比标记清除和标记整理要快（可以这么想，复制算法只需要把标记存活对象，然后转移；标记清除和标记整理都需要先标记然后找到垃圾对象进行清除，标记整理最后还要整理）

2、标记-复制算法

把一块内存区域一分为二，一块是已使用内存区域，另一块是未使用内存区域，然后在已使用区域，根据根可达算法，gc标记存活的对象，把存活的对象复制到未使用的内存区域，原来的已使用内存区域直接清空（需要一半内存空间，对内存空间有要求）

3、标记-清除算法

在一块内存区域上先标记，分为两种：一种是标记存活的对象，把未标记的进行回收（一般选这种）；另外一种是专门找那些垃圾对象，然后进行清理

要根据实际业务情况进行选择，垃圾对象多那就选择标记存活的对象，不过一般选择标记存活的对象如果比较多的话会比较耗费实际，另外一个就是清理之后内存不连续

4、标记-整理算法

标记过程和标记清除算法一样，但是后面的整理是所有存活的对象往一边移动，有垃圾对象占用直接替换，另外的垃圾对象再清理

二、垃圾收集器

CMS红线连接到Seria Old表示如果CMS出现“concurrent mode failure”，就会用到Serial Old进行收集，直到收集到有足够可用空间才切换到CMS，黑线相互连接都是表示可以年轻代老年代的垃圾收集器相互配合使用的

1、Serial收集器（-XX:+UseSerialGC -XX:+UseSerialOldGC）

gc过程是暂停所有用户线程，用一个单线程进行垃圾收集，直到垃圾收集结束用户线程才能继续

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

2、Parallel Scavenge收集器（-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代)）【jdk1.8默认垃圾收集器】

在serial垃圾收集器版本做的提升（线程版本），可以设置收集线程数（-XX:ParallelGCThreads），一般不推荐修改

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

3、ParNew收集器（-XX:+UseParNewGC）

ParNew和Parallel收集器类似，唯一区别是ParNew可以配合CMS收集器使用

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

4、CMS收集器（-XX:+UseConcMarkSweepGC(old)）

CMS（Concurrent Mark Sweep），垃圾收集时间延长，但是STW时间缩短，用户线程和gc线程可以同步进行，中间涉及的问题下面会做解释，整体的过程如下：

初始标记：暂停所有用户线程，根据可达性分析找到gc root直接引用对象（这一步就是为了下一步，如果直接从gc root就开始gc线程和用户线程同时进行，程序会一直创建对象如果都放到老年代，那样永远都标记不完，初始标记就是把源头gc root确定了，即使产生了放到了老年代，等待下一次gc做初始标记就行了），需要STW
并发标记：从gc直接引用的对象开始往下找其引用的对象，这一步是用户线程和gc线程是同时进行的，可能会导致已经标记过的对象引用发生了变化，不需要STW
重新标记：修正并发标记中引用被修改的问题，多标没关系，下次gc自然不会再标记了，主要是漏标（三色标记的增量更新算法），会STW（因为记录了新增的引用只能STW来修正，不允许再有引用发生变化）
并发清理：用户线程和gc线程同时进行，gc开始把未标记的对象做清理操作，这个阶段如果有新对象产生或者垃圾对象又重新被引用都会被标记成黑色不做处理，不需要STW
并发重置：重置本次gc的标记对象，下次gc好再次标记

它是一款用户体验好，低停顿，但人无完人，但会完蛋，总有不足的地方，有以下几个缺点：

用户线程会和gc线程抢占资源
存在浮动垃圾（在并发标记和并发清理阶段产生的垃圾对象）
使用标记清除会产生大量的内存碎片（设置参数-XX:+UseCMSCompactAtFullCollection可以清除完后做整理）
在并发标记和并发清理阶段正在做标记和清除，内存还没空出来这个时候从年轻代来了一批对象放到老年代，这个时候放不下，此时full gc正在进行中，不可能再用CMS了，因为CMS是用户线程和gc线程并行收集对象，这个时候出现"concurrent mode failure"，会STW，用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和ZGC后面博客再做解释

三、垃圾收集底层算法

1、三色标记

主要用来解决并发标记中漏标的问题

黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都被扫描过
灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用
白色：表示对象尚未被垃圾收集器访问过，开始阶段所有对象都是白色，结束时若对象还为白色，表示对象不可达

2、多标-浮动垃圾

在并发标记的过程中，用户线程和gc线程同时进行，方法结束gc root被回收，gc线程基于gc root往下标记的引用对象就称为浮动垃圾，等到下一轮gc自然就会被标记回收

并发整理阶段有新的对象产生或者原本是垃圾对象被引用了成为非垃圾对象、非垃圾对象引用突然断了成为垃圾对象，通常做法是直接标记成黑色，这阶段也会产生浮动垃圾

3、漏标-读写屏障

因为漏标产生的误删除有两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning, SATB）

增量更新：当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。这可以简化理解为，黑色对象一旦插入了指向白色对象的引用之后，它就变回灰色对象了
原始快照：当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色（有记录是删除的，不知道有没有其它对象指向这个已删除记录，现在记录下来就是为了让这种对象在本轮gc清理中能够存活下来，也可能是浮动，如果是的话下轮gc被回收）

以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的