G1（Gabage-First）收集器（详解）

G1是一款面向服务端应用的垃圾收集器，是从JDK1.7开始支持的。HotSpot开发团队赋予它的使命是未来可以替换JDK1.5中发布的CMS收集器，从局部看是基于“复制”算法实现的，意味着G1不会产生内存空间碎片。与其他GC收集器相比，G1最大的特点在于：可预测的停顿，这是G1相对于CMS的一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

 

1.G1的设计原则就是简单可行的性能调优。

控制参数：

-XX:+UseG1GC 开启G1垃圾收集器

-Xmx32g 设置堆内存的最大内存为32G

-XX:MaxGCPauseMillis=200 设置GC的最大暂停时间为200ms

如果我们需要调优，在内存大小一定的情况下，我们只需要修改最大暂停时间即可。

 

1. G1将新生代、老年代的物理空间划分取消了。

这样我们再也不用单独的对每个代进行设置了，不用担心每个代内存是否够用。取而代之的是，G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有CMS内存碎片问题的存在了。

在G1中，还有一种特殊的区域，叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在老年代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。