主流Java虚拟机收集器介绍

1. JVM内存区域介绍，简单易懂

名词解释：

》GC Roots：它是可达性分析的起点，哪些可以作为GC Roots的节点？

	1. 栈帧局部变量表的引用对象
	2. 方法区中静态引用的对象（引用类型静态变量）
	3. 方法区中常量引用的对象
	4. 本地方法中引用的对象
	5. Java虚拟机的内部引用，如基本数据类型的Class对象、异常对象、类加载器
	6. 被同步锁（Synchronized）持有的对象
	7. 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存

CMS收集器是一款以最短回收停顿时间为目标的收集器，从Mark Sweep可以看出它是基于标记清除算法实现的

1. 初始标记
2. 并发标记
3. 重新标记
4. 并发清除

初始标记、重新标记这两步需要 “Stopt The World”即暂停整个程序。

初始标记仅仅标记GC Roots直接关联的对象，速度很快

并发标记就是从GC Roots直接关联的类出发，遍历整个对象图的过程，这个过程相对耗时，但不会stop the world

重新标记：因为并发标记的过程中，用户线程也在执行，这就意味着会有些对象标记会变动，重新标记就是修正这一部分对象的标记记录，耗时通常比初始标记长，但也远小于并发标记

并发清除：清理被判定为死了的对象（标记清除不需要移动对象，所以可以和用户线程并发执行）



优点从名字上就体现出来了：并发收集、低停顿



缺点：

1. 对处理器资源很敏感：

   在并发阶段，他虽然不会导致用户线程停顿，但是也会因为本身占用了一部分线程而导致程序变慢。CMS默认启动的线程数是（处理器核心数量+3）/4，这意味着处理器核心数量大于等于四个时（4+3）/4 = 7/4 四分之七再除以4就是CMS所占的处理器资源比例，大于等于四，其比例为>25%,而且随着核心数量增多，比例越小；但是少于4个，CMS对程序的影响就很大了。

2. CMS无法处理“浮动垃圾”：

   什么是浮动垃圾？前面说了，清除阶段也是和用户线程并发执行的，所以清除的过程中可能会产生新的垃圾对象，只能下一次收集时再清理，这些垃圾对象就叫浮动垃圾；所以CMS不能等待老年代几乎满了才触发垃圾回收，必须预留一部分空间供并发收集时的程序使用。

   JDK5，CMS默认老年代达到68%就触发；JDK6达到92%触发，这时候就会出现一个问题，剩下的空间不足以分配新的对象，就会导致一次并发失败，这个时候虚拟机会启动应急方案：暂停用户线程，临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿的时间就很长了（所以：-XX:CMSInitiatingOccupancyFraction参数不要设置太高，根据实际情况设置）

3. 因为基于标记–清除，所以会产生大量的空间碎片，当找不到足够大的连续空间分配对象就会触发full gc整理空间碎片

G1是一款主要面向服务端应用的垃圾收集器。

G1不再坚持固定大小、固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域，每一个Region（区域）都可以根据需要，扮演新生代的Eden、Survivor或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略处理。

Region中有一类特殊的区域-----Humongous，见名知意，专门存储大对象的。G1认为只要一个对象超过了一个Region的一般，就将这个对象判定为大对象。

每个Region的大小可通过参数：-XX:G1HeapRegionSize设置，范围在1MB~32MB，取值应为2的N次方，如果一个对象超过了一个Region的大小时，这个对象会被放到N个连续的Humongous Region中，G1大多数时候都把Humongous Region作为老年代的一部分来看待。

虽然G1任然保留着新生代和老年代的概念，但是新生代和老年代已经不再是固定的了。它们都是一系列的Region（不需要是连续的）的动态集合。

G1之所以能建立可预测的停顿时间模型（即可通过参数设置允许的最大停顿时间），是因为它将Region作为作为每次回收的最小单位，即每次回收的内存都是Region内存大小的整数倍。

G1收集器跟踪每个Region里面的垃圾价值（能回收多少空间、耗时如何）大小，在后台维护一个优先级表，然后根据用户设置的允许停顿的时间：-XX:MaxGCPauseMills（默认200毫秒），优先处理回收价值最大的Region，这就是“Garbage First”名字的由来。

这里只是做了简单的介绍，让我们了解到G1，它还有很多重要的概念，我必须要先更新一下前面的知识才能在此加以介绍，因为那些是很重要的基础！