Serial收集器
Serial 是一种新生代的收集器。顾名思义“serial 串行”，它是一种单线程工作的收集器，它的“单线程”并不仅仅指的只有一个处理器或一个线程来实现垃圾的收集工作，更重要的是他在垃圾收集的过程中会暂停所有的用户线程（STW），直到它收集结束。
Serial/Serial Old收集器运行示意图：（Serial Old 收集器是Serial 的老年代版本，后面会提到)
Serial 新生代收集器它采用的是标记-复制的算法，并且在垃圾收集的时候会进行STW，暂停所有的用户线程。
ParNew收集器
ParNew收集器实质上是Serial收集器的多线程并行版本，可以同时使用多条线程进行并行垃圾收集，除此之外，与Serial 收集器相比并没有太多的创新之处。
ParNew/Serial Old收集器运行示意图：
和Serial 收集器一样，也采用的是标记-复制算法进行新生代的垃圾收集。
注意：ParNew收集器在单核心处理器的环境中绝对不会有比Serial 收集器更好的效果（存在线程的上下文切换）
Parallel Scavenge 收集器
Parallel Scavenge 收集器也是一款新生代的收集器，同样是基于标记-复制算法实现，也是能够并行收集的多线程收集器，那它相对于ParNew 收集器有什么特别之处呢？
Parallel Scavenge 它的关注点是尽可能的达到一个可控制的吞吐量。
它提供了两个参数用于精确的控制吞吐量：-XX:MaxGCPauseMillis：控制最大垃圾收集的停顿时间 -XX:GCTimeRatio ：直接设置吞吐量大小
-XX:MaxGCPauseMillis并不是简单的只要设置了最大停顿时间就能使得垃圾回收更快，垃圾收集停顿时间是以牺牲吞吐量的新生代空间为代价换取的：系统把新生代调的小一些，垃圾回收自然就快了，这也导致垃圾回收的次数增加，原来10秒收集一次，每次收集100ms，现在五秒收集一次，每次停顿70ms，吞吐量也下来了。
Parallel Scavenge 也可以设置自适应调节策略：虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整一些参数以提供最合适的停顿时间或者最大的吞吐量。
Serial Old收集器
Serial Old 是Serial收集器的老年代版本，同样是一个线程进行垃圾收集，采用标记-整理算法。
Parallel Old收集器
Parallel Old收集器是Parallel Scavenge 收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。只有Parallel Old出现以后，Parallel Scavenge新生代收集器才与之配合使用，“吞吐量优先”才算是名副其实，因为之前除了Serial Old这种单线程老年代的收集器之外，没有其他能和Parallel Scavenge收集器配合进行垃圾收集，（CMS无法和他配合工作）。
Parallel Scavenge/Parallel Old收集器运行示意图：
CMS收集器
CMS 收集器（Concurrent Mark Sweep）是一种以获取最短停顿时间位目标的老年代收集器。是基于标记-清除算法（不同于之前几款老年代收集器）实现的。
CMS 收集过程包含四个部分：
- 初始标记
- 并发标记
- 重新标记
- 并发清除
运行过程示意图
初始标记阶段只是标记一下GC Roots能直接关联到的对象，速度很快，需要进行STW，只不过这个STW时间很短；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，比较耗时但是不会进行STW，会和用户线程并发执行；重新标记阶段，并发标记阶段由于用户线程和垃圾收集线程并发运行，导致用户线程运行期间对象图的结构发生变化，可能导致漏标、多标的情况；重新标记阶段就是针对这些情况进行重新标记（采用增量更新的方式），需要进行STW（不然对象图结构一直变化，会一直存在漏标、多标的问题），时间也不会很长；最后进行并发清除。
由于最后的垃圾清除也是用户线程和垃圾收集线程并发运行，所以用户线程再这一时间段内也会产生垃圾，这些垃圾成为“浮动垃圾”，用于并发标记阶段已结束，只能等到下一次GC时进行标记收集。
最后用于线程和垃圾收集线程之所以能并发运行的原因也是因为CMS 是基于标记-清除算法实现的，不会涉及到对象的移动。像标记-整理算法涉及到对象的移动，必须进行STW.
CMS存在的问题：
- 由于CMS收集器无法处理“浮动垃圾”，当CMS的垃圾收集速度赶不上浮动垃圾产生的速度时，会出现“Concurrent Mode Failure”并发失败，而不得不进行STW（不进行STW的话会一直有浮动垃圾生成）的Full gc.
- 同样也是因为垃圾收集阶段用户线程也要运行，所以就必须预留一些空间给用户线程使用，（一般CMS不会等到老年代快要满的时候才进行收集，JDK5默认68%）如果预留的空间不足以放下用户线程再垃圾收集阶段产生的新对象时，就会时出现“Concurrent Mode Failure”并发失败，这时虚拟机将不得不采用后备案：临时启用Serial Old进行老年代收集。
- 由于采用标记清除算法，会导致收集结束会有大量的内存碎片，会给大对象的空间分配造成很大麻烦，当大对象没有足够大的连续空间分配时，不得不提前进行Full GC。
- CMS的重新标记阶段采用的是“增量更新”的方式（增量更新：当黑色对象插入新的指向白色对象的引用关系时，会对此黑色对象进行记录，并发标记结束后，对这些黑色对象再进行一次深度标记。）这也可能会导致STW时间过长，增加系统响应时间。
G1 收集器
它开创了收集器面向局部收集的思路和基于Region的内存布局形式。之前的收集器要么面向新生代（Minor GC），要么面向老年代（Major GC/Old GC）,要么就是整个Java堆（Full GC）。而G1则是面向堆内任何部分来组成垃圾“回收集”进行回收，衡量标准不再是哪个分代，而是那块内存中存放的垃圾数量最多，回收收益最大，就是G1收集器的Mixed GC模式。
G1之所以能实现以上，就是实现了基于Region的堆内存布局。
G1把Java堆划分为多个大小相等的独立的区域（Region），每一个Region都可以根据需要，扮演新生代的Eden、Survivor，或是老年代。
Region中还有一类特殊的Humongous区域，专门来存储大对象。
G1收集器的运行过程
- 初始标记：仅仅标记GC Roots能直接关联到的对象
- 并发标记：从GC Roots能直接关联到的对象开始对堆中的对象进行可达性分析
- 最终标记：类似于CMS的重新标记，只不过G1采用的时原始快照的方式
- 筛选回收：最后的垃圾回收并不会像CMS收集器那样对所有未标记的垃圾对象进行回收。再G1中，这一步会负责更新Regoin的统计数据，对每个Region的回收价值的成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Regio构成回收集，然后把回收集中的Region中的存活对象赋值到空的Region中，再清理掉整个旧Region的全部空间。（这里的赋值会涉及到对象的移动，所以是必须暂停用户线程的，由多条垃圾线程并发完成）
G1如何解决跨Region引用问题？
每个Region中都维护了一个记忆集，记忆集中记录着其他Region指向该Region的跨Region引用，并标记这些引用分别在哪些卡页（内存块）范围之内。
G1在并发标记阶段如何保证收集线程与用户线程互不干扰的运行？
首先，在并发标记阶段由于用户线程的运行，产生的多标、漏标，G1时使用原始快照（STAB）的方式解决的（CMS 是使用增量更新的方式解决）。
对于用户线程运行过程中产生的新对象的内存分配所需的空间，在每个Region中维护了两个名为TAMS的指针，把Region中的一部分空间划分出来用于并发标记阶段中产生的新对象（G1的最后的筛选回收阶段会进行STW，不会有新对象产生），新对象的地址必须在这两个指针位置以上。（这两个指针以上的地址默认被标记过不会被回收）。和CMS 的类似，如果并发标记阶段太慢，导致垃圾回收的速度赶不上新对象内存分配的速度，G1也会被迫冻结用户线程，进行STW的Full gc。
怎样建立可靠的停顿预测模型？
G1收集器的停顿预测模型是以”衰减均值“（可以理解为一种特殊的平均值，比普通的平均值更易受到新数据的影响，能更准确的代表每个Region的”最近的“平均状态）为理论基础来实现的，在垃圾收集过程中，G1收集器会记录每个Region的回收耗时、每个Region记忆集的脏卡数量等各个可测量的步骤花费的成本，并分析出平均值、标准偏差、置信度等统计信息。然后通过这些信息预测现在开始回收的话，由哪些Region组成的会收集可以在不超过期望停顿时间的约束下获得最高的收益。
《深入理解Java虚拟机》垃圾回收的一个总结。
