尽管Hotspot 最新的垃圾回收器G1是在2006年推出的。但是G1从推行至今的市场反响来看，但现在足以证明这款垃圾收集器是经得起考验的，从java9开始，就默认为G1垃圾收集器。G1是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是(在比较长期的)未来可以替换掉JDK1.5中发布的CMS收集器。与其他GC收集器相比，G1具备如下特点。
并行与并发、分代收集的垃圾收集算法、可预测的停顿、空间整合。
特点
从分代来看，G1依然属于分代垃圾收集器，她会区分年轻代和老年代，依然有eden区和survivor区，但从堆的结构来看，它并不要求整个eden、年轻代或者老年代都连续，它使用了分区算法。
并行性: 在回收期间，可以由多个GC线程同时工作，有效利用多核计算能力。
井发性： GI 拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此一 般来说，不会在整个回收期间完全阻塞应用程序。
分代 GC : Gl 依然是一个分代收集器，但是和之前回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，它们或者工作在年轻代，或者工作在老年代。因此，这里是一个很大的不同。
空间整理： Gl 在回收过程中，会进行适当的对象移动，不像CMS,只是简单地标记清理对象，在若干次 GC 后，CMS 必须进行一次碎片整理。而Gl不同，它每次回收都会有效地复制对象，减少空间碎片。
G1把内存“化整为零”的思路，理解起来似乎很容易，但其中的实现细节却远远没有想象中那样简单，否则也不会从2004年Sun实验室发表第一篇G1的论文开始直到今天(将近10年时间)才开发出G1的商用版。
笔者以一个细节为例：把Java堆分为多个Region后，垃圾收集是否就真的能以Region为单位进行了？听起来顺理成章，再仔细想想就很容易发现问题所在：Region不可能是孤立的。一个对象分配在某个Region中，它并非只能被本Region中的其他对象引用，而是可以与整个Java堆任意的对象发生引用关系。那在做可达性判定确定对象是否存活的时候，岂不是还得扫描整个Java堆才能保证准确性？这个问题其实并非在G1中才有，只是在G1中更加突出而已。在以前的分代收集中，新生代的规模一般都比老年代要小许多，新生代的收集也比老年代要频繁许多，那回收新生代中的对象时也面临相同的问题，如果回收新生代时也不得不同时扫描老年代的话，那么Minor GC的效率可能下降不少。
在G1收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中(在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象)，如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的RememberedSet之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。
G1的内存划分和主要收集过程
G1收集器讲堆进行分区，划分为一个个区域，每次收集时，只收集其中几个区域，以此来控制垃圾回收产生的一次停顿时间。
G1收集过程四个阶段:
新生代GC(YGC)
并发标记周期
混合收集
如果需要进行full GC
G1的新生代GC
新生代GC的主要工作是回收eden区和survivor区。 一旦eden 区被占满，新生代GC就会启动。新生代GC收集前后的堆数据如图5.6所示，其中E表示eden区，S表示survivor区， o表示老年代。可以看到，新生代GC只处理eden和survivor区，回收后，所有的eden区都应该被消空，而survivor区会被收集一 部分数据，但是应该至少仍然存在一 个 survivor 区，类比其他的新生代收集器，这一 点似乎并没有太大变化。另一 个亟要的变化是老年代的区域增多，因为部分survivor区或者eden区的对象可能会晋升到老年代。
从日志中可以看到，eden区原本占用235MB空间，回收后被清空，survivor区从5MB增长到了11MB, 这是因为部分对象从eden区复制到survivor区，整个堆合计为400MB, 从回收前的239MB下降到10.5MB。
G1的井发标记周期
G1的并发阶段与CMS有点类似，他们都是为了降低一次停顿时间，而将可以和应用程序并发的部分单独提取出来执行。
并发标记周期可以分为以下几步。如果不计算维护RememberedSet的操作，G1收集器的运作大致可划分为以下几个步骤：
初始标记(Initial Marking)
根区域扫描
并发标记(Concurrent Marking)
最终标记(Final Marking)
独占清理
筛选回收(Live Data Counting and Evacuation)
复制代码
初始标记: 标记从根节点直接可达的对象。这个阶段会伴随一次新生代GC，它会产生全局停顿。
根区域扫描: 由于初始标记必然会伴随一次新生代的GC，所以在初始化标记后，eden被清空，并且存活对象被移入survivor区。这个阶段，将扫面survivor区直接可达的老年代对象，并标记这些直接可达的对象。根区域扫描不能和新生代GC同时执行。
并发标记: 和CMS类似，扫面查找整个对存活的对象，这是一个并发的过程，可以被一次新生代GC打断。
重新标记: 由于并发标记过程中，应用仍在执行，因此标记结果需要修正，所以对上一次的标记结果进行补充，在G1中，这个过程使用STAB算法完成。即G1会在标记之初为存活对象创建一个快照，有助于加速重新标记速度。
独占清理: 这个阶段会引起停顿。
并发清理阶段: 识别并清理完全空闲的区域。它是并发的清理，不会引起停顿。
在并发标记周期时，G1会产生如下日志:
(1)、初始标记，伴随一次新生代GC
[GC pause (G1 Humongous Allocation) (young) (initial-mark), 0.0117414 secs]
...
[Eden: 1024.0K(4096.0K)->0.0B(2048.0K) Survivors: 2048.0K->1024.0K Heap: 9581.8K(20.0M)->12.3M(20.0M)]
[Times: user=0.11 sys=0.00, real=0.01 secs]
复制代码
可以看到初始化标记时，eden被清空，并部分复制到survivor区
(2)、这是一次并发的根区域扫描，并发扫面过程中，不能被新生代GC打断。
[GC concurrent-root-region-scan-start]
[GC concurrent-root-region-scan-end, 0.0007368 secs]
复制代码
(3)、下面这个是指并发标记
[GC concurrent-mark-start]
[GC pause (G1 Evacuation Pause) (young) (to-space exhausted), 0.0427113 secs]
.....
[Eden: 2048.0K(2048.0K)->0.0B(1024.0K) Survivors: 1024.0K->1024.0K Heap: 16.4M(20.0M)->18.0M(20.0M)]
[Times: user=0.05 sys=0.02, real=0.04 secs]
...
[GC concurrent-mark-abort]
复制代码
(4)、重新标记引起全局停顿
[Ref Proc: 0.3 ms]
复制代码
(5)、重新标记后进行独占清理
4.088: [GC cleanup 117M->106M(138M), 0.0015198 secs]
复制代码
(6)、并发清理是并发执行的，会根据独占清理阶段计算出的每个区域的存活对象数量，直接回收已经不包含存活对象的区域。
4.090: [GC concurrent-cleanup-start]
并发清理阶段开始，它释放被发现为空的区域(不包含任何的活跃数据的区域)，在上一个stop-the-world阶段期间。
4.091: [GC concurrent-cleanup-end, 0.0002721]
并发清理阶段清理空的区域用时0.0002721秒。
复制代码
关于G1日志，想要知道所有内容的，可以看这篇文章，适合查询:
blog.csdn.net/zhanggang80…
混合回收
在并发标记周期中，虽然有部分对象被回收，但是从整体上来说，回收的比例是相当低的。但是在并发标记周期后，G1已经明确知道哪些区域含有比较多的垃圾对象了，在混合阶段，就是对这些区域进行回收的。当然，会优先回收垃圾比例比较高的区域。因为回收这些区域的性价比比较高。
G1是指垃圾优先的垃圾回收器，全称"Garbage First Garbage Collector".
在混合回收中，即会执行正常年轻代GC，也会选取被标记的老年代区域进行回收，它同时处理了新生代和老年代。因为新生代GC的原因，eden区域必然被清空，此外，如下图，有两块区域被标记为G的垃圾回收比例最高的区域被清理。被清理区域的存活对象会被移动到其他区域，这样的好处是可以减少空间碎片。
混合GC产生如下日志:
混合GC执行多次，直到回收了足够多的内存空间，触发一次新生代GC。新生代GC后，有可能会发生一次并发标记周期的清理，最后又引起混合GC。整个流程见下图:
必要时的Full GC
与CMS类似，并发收集由于让应用和GC线程交替工作，因此总是不能避免在特别的繁忙场合在回收过程导致内存不足，此时，G1也会执行一个Full GC回收。
此外，在混合GC和新生代GC时，survivor与老年代无法无法容纳幸存对象，都会导致Full GC产生
完整的G1日志分析
G1 的相关参数
对于Gl收集器，可以使用-XX:+UseGIGC标记打开Gl收集器开关，对Gt收集器进行设置时，最重要的一 个参数就是-XX :MaxGCPauseMillis,它用于指定目标最大停顿时间。如果任何一次停顿超过这个设置值时，Gl就会尝试调整新生代和老年代的比例、调整堆大小、调整晋升年龄等手段，试图达到预设目标。对于性能调优来说，
有时候，总是鱼和熊掌不可兼得的，如果停顿时间缩短，对千新生代来说，这意味着很可能要增加新生代GC的次数，GC反而会变得更加频繁。对于老年代区域来说，为了获得更短的停顿时间，那么在混合GC收集时，一次收集的区域数量也会变少，这样无疑增加了进行FullGC的可能性。另外一个重要的参数是-XX :ParallelGCThreads, 它用于设置并行回收时，GC的工作线程数量。
此外，-XX:InitiatingHeapOccupancyPercent参数可以指定当整个堆使用率达到多少时，触发并发标记周期的执行。默认值是45, 即当整个堆占用率达到45%时，执行并发标记周期。 InitiatingHeapOccupancyPercent 一 旦设置，始终都不会被G l收集器修改，这意味着G I收集器不会试图改变这个值，来满足MaxGCPause汕His的目标。如果InitiatingHeapOccupancyPercent值设置偏大，会导致并发周期迟迟得不到启动，那么引起Full GC的可能性也大大增加，反之，一 个过小的 InitiatingHeapOccupancyPercent值，会使得并发周期非常频繁，大整 GC 线程抢占CPU, 会导致应用程序的性能有所下降。
来自《深入理解JVM虚拟机》JVM高级特性与最佳实现。
《实战java虚拟机》复制代码
