本文主要是介绍揭底JVM，怎么能不了解G1垃圾收集器，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
G1垃圾收集器并非横空出世，早在JDK1.7的时候就已经存在了。随着后续的优化，终于在JDK1.9的时候被Oracle付以重任，替换CMS成为默认的垃圾收集器。
G1相较于CMS的显著特点是，减少了空间碎片。CMS的空间碎片很严重，Mark-Sweep之后的空间，有很多小碎片，但是都比要分配的小，然后触发一次Full GC，让人崩溃。
一、啥是G1垃圾收集器
Garbage-First（G1，垃圾优先）收集器是服务类型的收集器，目标是多处理器机器、大内存机器。它高度符合垃圾收集暂停时间的目标，同时实现高吞吐量。Oracle JDK 7 update 4 以及更新发布版完全支持G1垃圾收集器。G1垃圾回集器为以下应用设计：
- 类似CMS收集器，可以和应用线程同时并发的执行
- 压缩空闲空间时没有GC引起的暂停时间
- 需要更可预言的GC暂停时间
- 不想牺牲大量的吞吐量性能
- 不需要特别大的Java堆
G1垃圾收集器计划长期替换并发标记清除收集器（CMS，Concurrent Mark-Sweep Collector）。G1和CMS比较，有一些不同点让G1成为一个更好的解决方案。一个不同点是G1是一个压缩收集器。G1收集器充分地压缩空间以完全避免分配空间使用细粒度的空闲列表，而不是依赖于区块。这相当简化了收集器的部件，和尽量消除可能的碎片问题。同时，G1收集器相比CMS收集器而方言，提供更可预言的垃圾收集暂停时间，允许用户指定想要暂停时间指标。
二、G1如何进行垃圾收集
老的垃圾收集器都把堆结构化为三个部分：年轻代、年老代和永久代（或元数据区）。 G1则采用了新的结构，堆空间被分割成一些相同大小的堆区域，每一个都是连续范围的虚拟内存。特定的区域集合像旧的收集器一样被指派为相同的角色（伊甸：eden、幸存：survivor、年老：old），但是它们没有一个固定大小。这在内存使用上提供了更强大的灵活性。
当执行垃圾收集时，G1收集器以与CMS收集器类似的方式操作。G1收集器执行一个全局的并发标记阶段来决定堆中的对象的活跃度。之后标记阶段就完成了。G1收集器知道哪个区域基本上是空的。它首先会收集那些产出大量空闲空间的区域。这就是为什么这个垃圾收集的方法叫做垃圾优先的原因。就像名称显示的那样，G1收集器集中它的收集和压缩活动在堆里的那些可完全被回收的区域，那就是垃圾。G1收集器使用一个暂停预言的模式去达到一个用户定义的暂停时间指标，基于用户指定的暂停时间指标去选择收集区域的数量。
被G1收集器鉴定为可以回收的区域就是垃圾，使用抽空的方式收集。G1收集器从堆空间的一个或多个区域里复制对象到堆空间的一个单独的区域内，这个过程中同时压缩和释放内存。这个抽空过程在多处理上以并行的方式运行，以减小暂停时间和增加吞吐量。因此，每一次垃圾收集G1收集器连续不断地去减少碎片，在用户指定的暂停时间内工作。这超越了以往方法的能力。并发标记-清除（CMS，Concurrent Mark Sweep）垃圾收集器不做压缩操作。并行年老代（ParallelOld）垃圾收集只进行整个堆的压缩，会导致相当大的暂停时间。
注意： G1收集器不是实时的收集器非常重要。它在很大程度上符合用户设定的暂停时间指标但是并不绝对符合。基于前面垃圾收集的数据来看，G1收集器会估算在用户指定的时间指标能收集多少区域。因此，收集器有一个合理的精确的收集这些区域的代价模型，它使用这个模型决定在用户指定的暂停时间内收集哪些、多少个区域。
三、适合G1垃圾收集的场景
G1收集器首要关注的是为用户运行着需要大堆空间、限制的垃圾回收延迟的应用提供一个解决方案。这意味着堆大小为6GB左右或者更大，稳定的、可预言的暂停时间小于0.5秒。
如果应用有以下一个或多个特点，当下运行着CMS或ParallelOldGC垃圾收集器的应用把收集器切换到G1收集器的话，会从中受益的：
- Full GC持续时间太长或者太频繁
- 对象分配比率或者提升有显著的变化
- 不期望的长时间垃圾收集或者压缩暂停（大于0.5到1秒）
现实项目中，大家可以根据实际情况具体选择。
这篇关于揭底JVM，怎么能不了解G1垃圾收集器的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
