1、Mark-Sweep  标记-革除算法

算法分为“标记”和“革除”两个阶段：首先标记出所有须要回收的对象，在标记实现后，对立回收掉所有被标记的对象，也能够反过来，标记存活的对象，对立回收所有未被标记的对象。标记过程就是对象是否属于垃圾的断定过程。

毛病：

（1）执行效率不稳固：

如果Java堆中蕴含大量对象，而且其中大部分是须要被回收的，这时必须进行大量标记和革除的动作，导致标记和革除两个过程的执行效率都随对象数量增长而升高；

（2）内存空间的碎片化问题

标记、革除之后会产生大量不间断的内存碎片，空间碎片太多可能会导致当当前在程序运行过程中须要调配较大对象时无奈找到足够的间断内存而不得不提前触发另一次垃圾收集动作。

2、Copy 拷贝算法

标记-复制算法常被简称为复制算法。为了解决标记-革除算法面对大量可回收对象时执行效率低的问题，它将可用内存按容量划分为大小相等的两块，每次只应用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块下面，而后再把已应用过的内存空间一次清理掉。如果内存中少数对象都是存活的，这种算法将会产生大量的内存间复制的开销，但对于少数对象都是可回收的状况，算法须要复制的就是占多数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不必思考有空间碎片的简单状况，只有挪动堆顶指针，按程序调配即可。

毛病：

（1）节约空间
缺点也不言而喻，这种复制回收算法的代价是将可用内存放大为了原来的一半，空间节约未免太多了一点。

3、Mark-Compact 标记整顿算法

其中的标记过程依然与“标记-革除”算法一样，但后续步骤不是间接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端挪动，而后间接清理掉边界以外的内存。

毛病：

（1）批改援用消耗资源

整顿阶段挪动存活对象并更新所有援用这些对象的中央将会是一种极为负重的操作，而且这种对象挪动操作必须全程暂停用户应用程序能力进行。

依据各个算法的特点也能够得悉：在新生代存活对象少的状况下，应用Copy算法；在老年代或存活对象多的状况下，应用Mark-Sweep、Mark-Compact算法。

G1之前分代垃圾收集器的新生代，Serial、ParNew等收集器均采纳Copy算法设计新生代的内存布局；Parallel Scavenge收集器是基于标记-整顿算法的，而关注提早的CMS收集器则是基于标记-革除算法。

4、三色标记算法

G1和CMS里都有一个并发标记垃圾的过程，也就是此时GC线程和工作线程是同时工作的，也就是会呈现非垃圾变为垃圾（此时间接在下次回收时清理掉就能够，并没有大的影响）、垃圾变为非垃圾的状况，而垃圾变为非垃圾时如果没有及时发现解决而被回收了，那么会产生十分重大的结果，JVM是采纳三色标记算法来解决这种问题的。

把遍历过程中遇到的对象，依照“是否拜访过”这个条件标记成以下三种色彩：
（1）红色：示意对象尚未被垃圾收集器拜访过。
（2）彩色：示意对象曾经被垃圾收集器拜访过，且这个对象的所有援用都曾经扫描过。彩色的对象代表曾经扫描过，它是平安存活的，如果有其余对象援用指向了彩色对象，毋庸从新扫描一遍。彩色对象不可能间接（不通过灰色对象）指向某个红色对象。
（3）灰色：示意对象曾经被垃圾收集器拜访过，但这个对象上至多存在一个援用还没有被扫描过。

当且仅当以下两个条件同时满足时，会产生谬误回收的问题，即本来应该是彩色的对象被误标为红色：

1、赋值器插入了一条或多条从彩色对象到红色对象的新援用；

2、赋值器删除了全副从灰色对象到该红色对象的间接或间接援用。

因而，咱们要解决并发标记的这个问题，只需毁坏这两个条件的任意一个即可。由此别离产生了两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning， SATB）。

1、增量更新要毁坏的是第一个条件，当彩色对象插入新的指向红色对象的援用关系时，就将这个新插入的援用记录下来，等并发扫描完结之后，再将这些记录过的援用关系中的彩色对象为根，从新扫描一次。

这能够简化了解为，彩色对象一旦新插入了指向红色对象的援用之后，它就变回灰色对象了。

2、原始快照要毁坏的是第二个条件，当灰色对象要删除指向红色对象的援用关系时，就将这个要删除的援用记录下来，在并发扫描完结之后，再将这些记录过的援用关系中的灰色对象为根，从新扫描 一次。

这也能够简化了解为，无论援用关系删除与否，都会依照刚刚开始扫描那一刻的对象图快照来进行搜寻。

在 HotSpot虚拟机中，增量更新和原始快照这两种解决方案都有理论利用，譬如，CMS是基于增量更新来做并发标记的，G1、Shenandoah则是用原始快照来实现的。