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
如果我们需要调优,在内存大小一定的情况下,我们只需要修改最大暂停时间即可。
- G1将新生代、老年代的物理空间划分取消了。
这样我们再也不用单独的对每个代进行设置了,不用担心每个代内存是否够用。取而代之的是,G1算法将堆划分为若干个区域(Region),它仍然属于分代收集器。不过,这些区域的一部分包含新生代,新生代的垃圾收集依然采用暂停所有应用线程的方式,将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域,G1收集器通过将对象从一个区域复制到另外一个区域,完成了清理工作。这就意味着,在正常的处理过程中,G1完成了堆的压缩(至少是部分堆的压缩),这样也就不会有CMS内存碎片问题的存在了。
在G1中,还有一种特殊的区域,叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上,G1收集器就认为这是一个巨型对象。这些巨型对象,默认直接会被分配在老年代,但是如果它是一个短期存在的巨型对象,就会对垃圾收集器造成负面影响。为了解决这个问题,G1划分了一个Humongous区,它用来专门存放巨型对象。如果一个H区装不下一个巨型对象,那么G1会寻找连续的H分区来存储。为了能找到连续的H区,有时候不得不启动Full GC。