本文首先简单介绍了垃圾收集的常见方式，然后再分析了G1收集器的收集原理，相比其他垃圾收集器的优势，最后给出了一些调优实践。
什么是垃圾回收
首先，在了解G1之前，我们需要清楚的知道，垃圾回收是什么？简单的说垃圾回收就是回收内存中不再使用的对象。
G1收集器
G1收集器（或者垃圾优先收集器）的设计初衷是为了尽量缩短处理超大堆（大于4GB）时产生的停顿。相对于CMS的优势而言是内存碎片的产生率大大降低。
开启G1收集器的方式
-XX:+UseG1GC
G1的发展原则
在2012年才在jdk1.7u4中可用。Oracle官方计划在【jdk9】中将G1变成默认的垃圾收集器，以替代CMS。为何Oracle要极力推荐G1呢，G1有哪些优点？
首先，G1的设计原则就是简单可行的性能调优
开发人员仅仅需要声明以下参数即可：
-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200
-XX:+UseG1GC：为开启G1垃圾收集器-Xmx32g：****设计堆内存的最大内存为32G**XX:MaxGCPauseMillis=200设置GC的最大暂停时间为200ms
如果我们需要调优，在内存大小一定的情况下，我们只需要修改最大暂停时间即可。
其次，G1将新生代，老年代的物理空间划分取消了。
这样我们再也不用单独的空间对每个代进行设置了，不用担心每个代内存是否足够。取而代之的是，G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。
这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式（STW），将存活对象拷贝到老年代或者Survivor空间。
老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。
这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有cms内存碎片问题的存在了。
G1中，有种特殊的区域，叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。
这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。
为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。
如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。
在java 8中，持久代也移动到了普通的堆内存空间中，改为元空间。
对象分配策略
说起大对象的分配，我们不得不谈谈对象的分配策略。它分为3个阶段：
TLAB(Thread Local Allocation Buffer)线程本地分配缓冲区
Eden区中分配
Humongous区分配
如果对象在一个共享的空间中分配，需要采用一些同步机制来管理这些空间内的空闲空间指针。
-
在Eden空间中，每一个线程都有一个固定的分区用于分配对象，即一个TLAB。分配对象时，线程之间不再需要进行任何的同步。
(-XX:+UseTLAB)TLAB为线程本地分配缓冲区，它的目的为了使对象尽可能快的分配出来。
对TLAB空间中无法分配的对象，JVM会尝试在Eden空间中进行分配。如果Eden空间无法容纳该对象，就只能在老年代中进行分配空间。
G1提供了两种GC模式，Young GC和Mixed GC，两种都是Stop The World(STW)的。
下面我们将分别介绍一下这2种模式。
G1 Young GC
Young GC主要是对Eden区进行GC，它在Eden空间耗尽时会被触发。
- 在这种情况下，Eden空间的数据移动到Survivor空间中，如果Survivor空间不够，Eden空间的部分数据会直接晋升到年老代空间。
- Survivor区的数据移动到新的Survivor区中，也有部分数据晋升到老年代空间中。
- 最终Eden空间的数据为空，GC停止工作，应用线程继续执行。
问题1：如果仅仅GC新生代对象，如何找到所有的根对象呢？老年代的所有对象都是根么？
G1引进了RSet的概念。它的全称是Remembered Set，作用是跟踪指向某个heap区内的对象引用。
-
在CMS中，也有RSet的概念，在[老年代]中有一块区域用来记录指向[新生代]的引用。
- 这是一种point-out，在进行Young GC时，扫描根时，仅仅需要扫描这一块区域，而不需要扫描整个老年代。
但在G1中，并没有使用point-out，这是由于一个分区太小，分区数量太多，如果是用point-out的话，会造成大量的扫描浪费（会存在重复定的扫描指针的数据块），有些根本不需要GC的分区引用也扫描了。
于是G1中使用point-in来解决。point-in的意思是哪些分区引用了当前分区中的对象。
问题2：根来扫描就避免了无效的扫描。由于新生代有多个，那么我们需要在新生代之间记录引用吗？
- 这是不必要的，原因在于每次GC时，所有新生代都会被扫描，所以只需要记录老年代到新生代之间的引用即可。
如果引用的对象很多，赋值器需要对每个引用做处理，赋值器开销会很大，为了解决赋值器开销这个问题，在G1中又引入了另外一个概念，卡表（Card Table）。
一个Card Table将一个分区在逻辑上划分为固定大小的连续区域，每个区域称之为卡表。
卡表通常较小，介于128到512字节之间。
Card Table通常为字节数组，由Card的索引（即数组下标）来标识每个分区的空间地址。
默认情况下，每个卡表都未被引用。当一个地址空间被引用时，这个地址空间对应的数组索引的值被标记为”0″，即标记为脏被引用，此外RSet也将这个数组下标记录下来。
一般情况下，这个RSet其实是一个Hash Table，Key是别的Region的起始地址，Value是一个集合，里面的元素是Card Table的Index。
Young GC 阶段
- 阶段1：根扫描：静态和本地对象被扫描
- 阶段2：更新RS：处理dirty card队列更新RS
- 阶段3：处理RS：检测从年轻代指向年老代的对象
- 阶段4：对象拷贝：拷贝存活的对象到survivor/old区域
- 阶段5：处理引用队列：软引用，弱引用，虚引用处理
G1 Mixed GC
Mixed GC不仅进行正常的新生代垃圾收集，同时也回收部分后台扫描线程标记的老年代分区。
GC步骤分2步：
全局并发标记（global concurrent marking）
拷贝存活对象（evacuation）
全局并发标记
进行Mixed GC之前，会先进行global concurrent marking（全局并发标记）。
在G1 GC中，它主要是为Mixed GC提供标记服务的，并不是一次GC过程的一个必须环节。global concurrent marking的执行过程分为五个步骤：
初始标记（initial mark，STW）
在此阶段，G1 GC 对根进行标记。该阶段与常规的 (STW) 年轻代垃圾回收密切相关。
根区域扫描（root region scan）
G1 GC 在初始标记的存活区扫描对老年代的引用(扫描CardTable和RSet)，并标记被引用的对象。该阶段与应用程序（非STW）同时运行，并且只有完成该阶段后，才能开始下一次STW年轻代垃圾回收。
并发标记（Concurrent Marking）
G1 GC 在整个堆中查找可访问的（存活的）对象。该阶段与应用程序同时运行，可以被STW年轻代垃圾回收中断。
最终标记（Remark，STW）
该阶段是 STW 回收，帮助完成标记周期。G1 GC清空SATB 缓冲区，跟踪未被访问的存活对象，并执行引用处理。
清除垃圾（Cleanup，STW）
-
最后阶段，G1 GC执行统计和RSet净化的STW操作。
在统计期间，G1 GC会识别完全空闲的区域和可供进行混合垃圾回收的区域。
清理阶段在将空白区域重置并返回到空闲列表时为部分并发。
三色标记算法
提到并发标记，我们不得不了解并发标记的三色标记算法。它是描述追踪式回收器的一种有用的方法，利用它可以推演回收器的正确性。
首先，我们将对象分成三种类型的。
黑色:根对象，或者该对象与它的子对象都被扫描
灰色:对象本身被扫描,但还没扫描完该对象中的子对象
白色:未被扫描对象，扫描完成所有对象之后，最终为白色的为不可达对象，即垃圾对象
当GC开始扫描对象时，按照如下图步骤进行对象的扫描：
根对象被置为黑色，子对象被置为灰色。
继续由灰色遍历,将已扫描了子对象的对象置为黑色。
遍历了所有可达的对象后，所有可达的对象都变成了黑色。不可达的对象即为白色，需要被清理。
这看起来很美好，但是如果在标记过程中，应用程序也在运行，那么对象的指针就有可能改变。这样的话，我们就会遇到一个问题：对象丢失问题
我们看下面一种情况，当垃圾收集器扫描到下面情况时：
这时候应用程序执行了以下操作：
A.c=C
B.c=null
这样，对象的状态图变成如下情形：
这时候垃圾收集器再标记扫描的时候就会下图成这样：
很显然，此时C是白色，被认为是垃圾需要清理掉，显然这是不合理的。那么我们如何保证应用程序在运行的时候，GC标记的对象不丢失呢？有如下2中可行的方式：
- 在插入的时候记录对象
- 在删除的时候记录对象
刚好这对应CMS和G1的2种不同实现方式：
CMS采用的是增量更新（Incremental update）
在CMS采用的是增量更新（Incremental update），只要在写屏障（write barrier）里发现要有一个白对象的引用被赋值到一个黑对象的字段里，那就把这个白对象变成灰色的。即插入的时候记录下来。
SATB（snapshot-at-the-beginning）的方式
在G1中，使用的是SATB（snapshot-at-the-beginning）的方式，删除的时候记录所有的对象，它有3个步骤：
在开始标记的时候生成一个快照图标记存活对象
在并发标记的时候所有被改变的对象入队（在write barrier里把所有旧的引用所指向的对象都变成非白的）
可能存在游离的垃圾，将在下次被收集
G1到现在可以知道哪些老的分区可回收垃圾最多。 当全局并发标记完成后，在某个时刻，就开始了Mix GC。这些垃圾回收被称作“混合式”是因为他们不仅仅进行正常的新生代垃圾收集，同时也回收部分后台扫描线程标记的分区。
混合式垃圾收集如下图：
混合式GC也是采用的复制的清理策略，当GC完成后，会重新释放空间。
至此，混合式GC告一段落了。下一小节我们讲进入调优实践。
调优实践
MaxGCPauseMillis调优
前面介绍过使用GC的最基本的参数：
-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200
前面2个参数都好理解，后面这个MaxGCPauseMillis参数该怎么配置呢？这个参数从字面的意思上看，就是允许的GC最大的暂停时间。G1尽量确保每次GC暂停的时间都在设置的MaxGCPauseMillis范围内。
那G1是如何做到最大暂停时间的呢？这涉及到另一个概念，CSet(collection set)。它的意思是在一次垃圾收集器中被收集的区域集合。
Young GC：选定所有新生代里的region。通过控制新生代的region个数来控制young GC的开销。
Mixed GC：选定所有新生代里的region，外加根据global concurrent marking统计得出收集收益高的若干老年代region。在用户指定的开销目标范围内尽可能选择收益高的老年代region。
问题3：需要在这个限度范围内设置。但是应该设置的值是多少呢？
我们需要在吞吐量跟MaxGCPauseMillis之间做一个平衡。如果MaxGCPauseMillis设置的过小，那么GC就会频繁，吞吐量就会下降。
如果MaxGCPauseMillis设置的过大，应用程序暂停时间就会变长。G1的默认暂停时间是200毫秒。
其他调优参数
-XX:G1HeapRegionSize=n
设置的 G1 区域的大小。值是 2 的幂，范围是 1 MB 到 32 MB 之间。目标是根据最小的 Java 堆大小划分出约 2048 个区域。
-XX:ParallelGCThreads=n
设置 STW 工作线程数的值。将 n 的值设置为逻辑处理器的数量。n 的值与逻辑处理器的数量相同，最多为 8。
如果逻辑处理器不止八个，则将 n 的值设置为逻辑处理器数的 5/8 左右。这适用于大多数情况，除非是较大的 SPARC 系统，其中 n 的值可以是逻辑处理器数的 5/16 左右。
-XX:ConcGCThreads=n
设置并发标记的线程数。将 n 设置为并行垃圾回收线程数 (ParallelGCThreads) 的 1/4 左右。
-XX:InitiatingHeapOccupancyPercent=45
设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%。
避免使用以下参数：
避免使用 -Xmn 选项或 -XX:NewRatio 等其他相关选项显式设置年轻代大小。固定年轻代的大小会覆盖暂停时间目标。
触发Full GC
在某些情况下，G1触发了Full GC，这时G1会退化使用Serial收集器来完成垃圾的清理工作，它仅仅使用单线程来完成GC工作，GC暂停时间将达到秒级别的。
整个应用处于假死状态，不能处理任何请求，我们的程序当然不希望看到这些。那么发生Full GC的情况有哪些呢？
并发模式失败
G1启动标记周期，但在Mix GC之前，老年代就被填满，这时候G1会放弃标记周期。这种情形下，需要增加堆大小，或者调整周期（例如增加线程数-XX:ConcGCThreads等）。
晋升失败或者疏散失败
G1在进行GC的时候没有足够的内存供存活对象或晋升对象使用，由此触发了Full GC。可以在日志中看到(to-space exhausted)或者（to-space overflow）。
解决这种问题的方式是：
增加 -XX:G1ReservePercent 选项的值（并相应增加总的堆大小），为“目标空间”增加预留内存量。
通过减少 -XX:InitiatingHeapOccupancyPercent 提前启动标记周期。
也可以通过增加 **-XX:ConcGCThreads **选项的值来增加并行标记线程的数目。
巨型对象分配失败
当巨型对象找不到合适的空间进行分配时，就会启动Full GC，来释放空间。这种情况下，应该避免分配大量的巨型对象，增加内存或者增大
-XX:G1HeapRegionSize，使巨型对象不再是巨型对象。
