前言
在上一篇文章 你不得不了解的JVM(一)中，我们了解了

1. JVM运行时数据区域；
2. HotSpot 虚拟机对象的创建，内存布局以及访问定位；
   那么这篇文章我们就需要了解一下
3. 垃圾收集算法
4. 垃圾收集器。

首先我们了解一下垃圾收集算法这块内容。因为垃圾算法的实现设计大量程序细节，各个平台的虚拟机操作内存的方法各不相同，因此在本节中我们主要讲讲垃圾收集算法，并不涉及具体实现。 下面让我们来一一了解一下各种收集算法吧。
3) 垃圾收集算法

1）标记-清除算法

标记-清除.gif

上图为标记-清除算法的示意图。首先需要标记可回收的内存，然后再对可回收的内存进行回收。这样做是不是很简单粗暴呢？当然，这样做的2个不足分别是：1）标记-清除效率不高；2）标记-清除之后产生大量不连续的空间碎片。基于这样的不足，有了标记-整理算法。

2）标记-整理算法

标记-整理.png

如图是标记-整理算法示意图。相比标记-清除算法，不同的是整理过程。将存活对象移到一端，然后清除可回收对象。这样做的明显好处就是产生了连续的空间。

3）复制算法

复制算法.jpg

上图是复制算法实现图。它将内存分为大小相等的2块，每次只是使用其中一块。当一块内存用完之后，就将存活的对象复制到另外一块内存区域并将本块内存清理。这样做的大大降低了内存空间使用率。我们的HotSpot的年轻代就是使用复制算法，只不过它的比例不是1：1，而是8：1。这个稍后我们会讲到。

4）分代收集算法

分代.png

基于上面的几种收集算法，当前商业虚拟机基本采用的都是分代收集。结合了复制和标记-整理的优势。一般做法是将Java堆分为新生代和老年代。由于新生代会不断产生新生对象，因此采用了复制算法；而年老代的对象存活率较高，因此采用了标记-整理算法。
在新生代中，我们可以看到新生代=Eden+S0+S1；他们设计的默认比例是8：1：1；这个参数是可以通过虚拟机参数进行调整的。

以上，我们了解了基本的垃圾收集算法，只是了解哦！

4) 垃圾收集器。

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。上面说过，各个平台虚拟机对内存的操作各不相同，因此本章所讲的收集器是基于JDK1.7Update14之后的HotSpot虚拟机。

jvm_hotspot垃圾收集器.png

上图是基于java虚拟机的HotSpot虚拟机垃圾收集器。一共是7种收集器，接下来让我们一一做个了解吧。

1）Serial/Serial Old
Serial最基本，发展历史最悠久的收集器。具体原理让我们看一张图最明了

serial.jpeg

上图是Serial和Serial Old 两种垃圾收集器的运行示意图。其中Serial 和Serial Old的区别就是一个是运行在年轻代一个是运行在年老代。从图中我们可以看到，他是一个单线程模式的垃圾收集器。这里不仅仅是说该收集器是使用单线程或者一个CPU去完成垃圾收集，更重要的是它在进行垃圾收集的时候必须暂停用户线程，直到收集完成，也就是Stop the World。

2）ParNew
ParNew收集器其实是Serial收集器的多线程版本。它也是运行在年轻代中，如图：

parnew.jpeg

如图，在新生代中采用的是多线程模式进行垃圾收集同时也需要暂停用户线程直到垃圾收集完毕。这种模式和Serial相比，CPU数量越多的情况下优势更加明显。如果CPU数量很少，比如2个，那么这种收集效率可能比Serial更低，因为它存在线程交互的开销。

3)Parallel Scavenge/Parallel Old

Parallel Scavenge也是一个新生代，多线程收集器。那么这种收集器和之前的ParNew有什么区别呢？区别还是有的，不然怎么会出来这种收集器呢？其实Parallel Scavenge收集器的特点是它关注一个可控的吞吐量。那么什么是吞吐量，我这边也不做任何讲述，直接上一个公式大家就知道了。
吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）；
是不是很明白？垃圾收集时间越短，吞吐量就是越大。这里就有一个问题：垃圾收集时间越短，一般来讲收集的垃圾量就是越少，也就是回收的内存量越小，那么总内存一定的情况下，我们在一定时间内回收的次数就是越多。这就需要我们控制好回收时间来制约回收次数了。
同时，这里也有一个Parallel Old收集器，顾名思义是Parallel Scavenge收集器的年老代版本。
如下图：

parallel.jpeg

4）CMS
CMS(Concurrent Mark Sweep),从名字我们知道这是一款基于并发使用标记清除算法的垃圾收集器。他是一款以获得最短回收停顿时间为目标的收集器。让我们赶紧来看看他的实现吧。上图

cms.jpeg

如上图，它分为以下步骤：
1 初始标记：仅仅标记GC Roots能直接关联到的对象，时间很短，阻塞用户线程
2 并发标记：标记可回收对象，和用户线程并行。
3 重新标记：标记在并发阶段因用户线程继续运行产生的可回收对象，修正并发标记，此时是阻塞用户线程。
4 并发清理：使用标记-清除算法将垃圾进行清理。

这种收集算法存在3个缺点：
1 对CPU资源敏感。一般并发执行的程序对CPU数量都是比较敏感的
2 无法处理浮动垃圾。在并发清理阶段用户线程还在执行，这时产生的垃圾无法清理。
3 由于标记-清除算法产生大量的空间碎片。

下面，我们讲讲最后一个垃圾手机器G1

5）G1
G1，Garbage-First是当今收集器技术发展的最前沿成果之一，它是一款面向服务端的垃圾收集器。

g1.jpeg

实现思路：将整个java堆划分为多个大小相等的独立区域(Region),G1跟踪各个Region里面的垃圾堆积和价值大小，在后台维护一个优先列表，每次进行优先回收。那么Region不是孤立的。那么如何避免全堆扫描呢？
G1使用Remembered Set。每一个Region对应一个Remembered Set，在虚拟机对Reference类型的数据进行写操作的时候，会检查Reference引用的对象是否处于不同的Region中，如是则记录到Remembered Set中。

初始标记：标记GC Roots能直接关联到的对象，耗时短
并发标记：找出存活的对象，耗时长
最终标记：修正并发标记
筛选回收：根据用户所期望的GC停顿时间来制定回收计划
可以发现它和CMS的前半部分步骤是一样的。当然，其实G1收集器的实现是非常复杂的，这里只是蜻蜓点水般的讲到一点，如果有兴趣可以继续深入学习。欢迎多多进行技术交流......