JVM——垃圾收集器

概念补充

---

　　并行（Parallel）：指多条垃圾收集线程并行工做，但此时用户线程仍然处于等待状态。
　　并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不必定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另外一个CPU上。

　　全部的GC算法都将堆划分红了老年代和新生代。

　　全部的GC算法在清理新生代对象时，都使用了“时空停顿（stop-the-world）”方式的垃圾收集方式，一般这是一个能较快完成的操做。

Serial收集器：

---

　　Serial/Serial Old收集器是最基本、发展历史最悠久的收集器，属于单线程的收集器，采用复制算法进行垃圾收集，它在进行垃圾收集时，必须暂停其余全部的工做线程，直到它收集结束。
　　它是虚拟机运行在Client模式下的默认新生代收集器。
　　它也有着优于其余收集器的地方：简单而高效。
　　对于限定单个CPU的环境来讲，Serial收集器因为没有线程交互的开销，专心作垃圾收集天然能够得到最高的单线程收集效率。因此，Serial收集器对于运行在Client模式下的虚拟机来讲是一个很好的选择。

ParNew收集器：

---

　　并行，ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集以外，其他行为与Serial收集器彻底同样。
　　虽然它与Serial相比，除了多线程收集以外没有其余不一样之处，但它倒是许多运行在Server模式下的虚拟机中首选的新生代收集器，除了Serial收集器外，目前只有它能与CMS收集器配合工做。
　　在JDK1.5中使用CMS来收集老年代的时候，新生代只能选用ParNew或者Serial收集器中的一个。
　　ParNew收集器在单CPU环境中绝对不会有比Serial收集器更好的效果。不过，随着可使用的CPU的数量的增长，它对于GC时系统资源的有效利用仍是颇有好处的。

Parallel Scavenge收集器：

---

　　并行，Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器。
　　其特色是它的关注点与其余收集器不一样，CMS等收集器的关注点是尽量地缩短垃圾收集时用户线程的停顿时间，其目标则是达到一个可控制的吞吐量（Throughput）。
　　其提供两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间：-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
　　因为与吞吐量关系密切，其也常常称为“吞吐量优先”收集器。

Serial Old收集器：

---

　　串行，其是Serial收集器的老年代版本，一样是单线程收集器，使用“标记-整理”算法。

Parallel Old收集器：

---

　　并行，其是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

CMS收集器：

---

　　Sun也称其为Concurrent Low Pause Collector（并发低停顿收集器）其是一种以获取最短回收停顿时间为目标的收集器。其是基于“标记-清除”算法实现。

　　它的运做过程相对于前面几种收集器来讲更复杂一些，整个过程分为4个步骤：

• 初始标记：初始标记仅标记一下GC Roots能直接关联到的对象，速度很快；
• 并发标记：初始标记和从新标记任然须要“stop the world”，并发标记过程就是进行GC Roots Tracing的过程；
• 从新标记：修正并发标记期间因用户程序继续运做而致使标记产生变更的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但比并发标记时间短；
• 并发清除：标记-清除算法；

　　整个过程当中耗时最长的并发标记和并发清除过程收集器线程均可以与用户线程一块儿工做，因此，从整体上来讲，CMS收集器的内存回收过程是与用户线程一块儿并发执行的。
　　CMS是一款优秀的收集器，它的主要优势是：并发收集、低停顿，但他有如下3个明显的缺点：

1. CMS收集器对CPU资源很是敏感，在并发阶段，它虽然不会致使用户程序变慢，可是会由于占用了一部分线程（或者说CPU资源）而致使应用程序变慢，总吞吐量会下降；
2. CMS收集器没法处理浮动垃圾（Floating Garbage），可能出现”Concurrent Mode Failure“失败而致使另外一次Full GC的产生。因为在并发清理阶段用户线程还在运行，因此还会有新的垃圾不断产生，这部分并无被标记，也就没法被本次垃圾回收处理掉，只能等待下一次GC；
3. CMS是基于”标记-清除“算法实现的收集器，这就意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，每每出现老年代还有很大空间剩余，但没法找到足够大的连续空间来分配当前对象，不得不提早触发一次Full GC；

G1收集器：

---

　　是目前最刁的收集器技术之一，G1是一款面向服务端应用的垃圾收集器。它的使命是在将来能够替换掉JDK1.5中发布的CMS收集器。与其余GC收集器相比，G1具有以下特色：

• 并行与并发：G1能充分利用多CPU、多核环境下的硬件优点，使用多个CPU（或者CPU核心）缩短Stop-The-World停顿的时间，部分其它收集器本来须要停顿Java线程执行的GC动做，但G1收集器仍然能够经过并发的方式让Java程序继续执行。
• 分代收集：G1能够不须要其它收集器配合就能独立管理整个GC堆，但它可以采用不一样的方式去处理新建立的对象和已经存活了一段时间、熬过屡次GC的旧对象以获取更好的收集效果。
• 空间整合：与CMS的”标记-清理“算法不一样，G1从总体来看是基于”标记-整理“算法实现的收集器，从局部上看是基于”复制“算法实现的，这两种算法都意味着G1运做期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会由于没法找到连续内存空间而提早触发下一次GC。
• 可预测的停顿：这是G1相对于CMS的另外一大优点，下降停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能创建可预测的停顿时间模型，能让使用者明确指定一个长度为M毫秒的时间片断内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已是实现Java（RTSJ）的垃圾收集器的特征了。

　　在G1以前的其它收集器进行收集的范围都是整个新生代或者老年代，而G1再也不是这样。使用G1时，Java堆得内存布局就与其它收集器有很大差异，它将整个Java堆划分为多个大小相等的独立区域，虽然保留新生代和老年代的概念，但新生代和老年代再也不是物理隔离的了，它们都是一部分Region（不须要连续）的集合。
G1收集器之因此能创建可预测的停顿时间模型，是由于它能够有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所得到的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据容许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划份内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内能够获取尽量高的收集效率。
G1收集器的运做分为如下几个步骤：

1. 初始标记
2. 并发标记
3. 最终标记
4. 筛选回收