各种垃圾收集器的优缺点及原理

Serial收集器

针对新生代；

采用复制算法；

单线程收集；

​ 进行垃圾收集时，必须暂停所有工作线程，直到完成；

​ 即会"Stop The World"；

ParNew收集器

ParNew垃圾收集器是Serial收集器的多线程版本。
Parallel Scavenge收集器

Parallel Scavenge垃圾收集器因为与吞吐量关系密切，也称为吞吐量收集器

（A）、有一些特点与ParNew收集器相似

新生代收集器；

采用复制算法；

多线程收集；

（B）、主要特点是：它的关注点与其他收集器不同

CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间；

而Parallel Scavenge收集器的目标则是达一个可控制的吞吐量

Serial Old收集器

针对老年代；

采用"标记-整理"算法（还有压缩，Mark-Sweep-Compact）；

单线程收集；

Parallel Old收集器

针对老年代；

采用"标记-整理"算法；

多线程收集；

cms

一种以获取最短回收停顿时间为目标的收集器，它非常符合那些集中在互联网站或者B/S系统的服务端上的Java应用，这些应用都非常重视服务的响应速度。从名字上（“Mark Sweep”）就可以看出它是基于“标记-清除”算法实现的。

针对老年代；

基于"标记-清除"算法(不进行压缩操作，产生内存碎片)；

以获取最短回收停顿时间为目标；

并发收集、低停顿；

需要更多的内存（看后面的缺点）

是HotSpot在JDK1.5推出的第一款真正意义上的并发（Concurrent）收集器；

第一次实现了让垃圾收集线程与用户线程（基本上）同时工作；

---

g1

---

G1在使用时，Java堆的内存布局与其他收集器有很大区别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，而都是一部分Region（不需要连续）的集合。

G1把Java堆分为多个Region，就是“化整为零”。但是Region不可能是孤立的，一个对象分配在某个Region中，可以与整个Java堆任意的对象发生引用关系。在做可达性分析确定对象是否存活的时候，需要扫描整个Java堆才能保证准确性，这显然是对GC效率的极大伤害。

为了避免全堆扫描的发生，虚拟机为G1中每个Region维护了一个与之对应的Remembered Set。虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作。

检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：

初始标记（Initial Marking） 仅仅只是标记一下GC Roots 能直接关联到的对象，并且修改TAMS（Nest Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以的Region中创建对象，此阶段需要停顿线程，但耗时很短。
并发标记（Concurrent Marking） 从GC Root 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行。
最终标记（Final Marking） 为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
筛选回收（Live Data Counting and Evacuation） 首先对各个Region中的回收价值和成本进行排序，根据用户所期望的GC 停顿是时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。