关于G1收集器

G1（Garbage First）收集器是Oracle公司开发的一款主要面向服务端的拥有可靠的停顿预测模型的垃圾收集器。在垃圾收集器的历史上有着里程碑式的意义。在jdk9以后被设置为服务器端默认的垃圾收集器。

与之前的收集器不同，G1不在基于固定的新生代与老年代的内存分配方式，而是使用了基于Region的内存分配的方式。这种方式使得G1在进行垃圾清理的时候不需要对整个新生代或老年代甚至整个Java堆进行垃圾清理，这样就明显减少了标记期间所需时间。

设计思路

面向局部（Region）收集

内存布局

基于Region的内存布局形式

Region(域)

G1会将Java堆分为多个大小相等的区域，每个区域都是一个Region，收集器在处理垃圾的时候都是以Region为单位进行的。同时为更好分配大对象，G1还设计了一种Humongous的特殊Region，对象大小（一般是单个Region的一半大小）在到达一定阈值会被分配到这里，对于一些更大的对象（超过单个Region容量）则会被分配在连续的Humongous中。

对象间的跨Region引用

通过记忆集实现来处理。G1收集器会为每个Region都维护一个记忆集，这些记忆集在存储结构本质是一种哈希表，在这些中哈希表会存有每个Region的起始地址和对应的卡表索引号，然而由于Region的数量比较多而且要给每个Region都要维护一个记忆集，所以G1收集器在工作的时候会占用Java堆比较多的资源，大概在10-20%左右。

并发标记

实现并发标记的方式主要有两种：1.增量更新；2.原始快照。

G1收集器使用的是原始快照的方式。由于此时用户线程仍在进行，所以很大概率还会有新的对象被创建，为了方便维护，G1为每个Region设置了TAMS（Top at Mark Start）指针并且拿出该Region一部分空间存放新对象，在并发标记期间创建的对象都会被分配在这里，并且这些对象都会被隐式标记使其在本次垃圾回收中不会被回收。此外，如果内存回收的速度比不上内存分配的速度，G1收集器会强制冻结用户线程进行一次Full GC，这样的话用户线程就会因此停顿较长的时间。

可靠的停顿预测模型

停顿预测模型是基于衰减均值的理论基础建立的，强调衰减是因为对于新信息更加敏感，可以更好的反应最近的平均状态，统计状态越新越能体现出Region的回收价值，可以根据这些信息去预测下次垃圾回收。

停顿预测模型的意思是能够支持指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集的时间大概率不超过N毫秒这样的目标。                《深入理解Java虚拟机》

在进行垃圾回收的时候G1收集器会对每个Region的情况进行统计，并据此计算出哪些Region的回收收益更高，并将这些高回报率的Region组成一个回收集对其进行垃圾回收。

垃圾回收

G1收集器进行垃圾收集的过程可以分为以下4个过程：

1、初始标记

        遍历并标记那些与GCRoots直接关联的对象并修改TAMS指针的值，在这个过程中用户线程会有短暂停顿

2、并发标记

        从GCRoots开始对Java堆的对象进行可达性分析，找到并标记那些需要回收的对象，该过程耗时较长但可以与用户线程并发执行。在标记完成后，还会有一次操作，就是对并发过程中引用发生过变化的对象重新扫描标记一次。

3、最终标记

        处理那些在并发标记阶段结束后仍然残留的引用有变更的对象记录。该过程中用户线程会短暂停顿。

4、筛选回收

        对各个Region进行统计，计算出哪些Region可以进行回收、可以组成回收集来获得较高的收益，并将此次的统计信息记录下来，便于下次垃圾回收时可以根据这些信息预测那些Region的回收收益。该过程用户线程会被暂停。

关于G1

对于G1来说，基于Region的内存布局和可靠的停顿预测模型使得G1在众多收集器中脱颖而出。基于Region的内存布局方式使得G1在垃圾回收时更加高效率，而可靠的停顿预测模型使得G1可以把停顿时间控制在用户的期望时间内，当然这个时间不能太短，否则每次只能收集到很少的垃圾，导致垃圾回收速度跟不上对象分配的速度而出现Full GC，最终反而会降低程序执行的效率，降低系统的吞吐量。同时G1在内存、cpu等资源占用上也比较高，这也算是G1的不足之处了。

关于收集器的选择，并没有完美的虚拟机，再好的虚拟机也总有几处做的不是很好的地方。要想在某些方面突出，就要接受另外一些方面的不足，要么采用折中的思想，即没有某些比较突出特点但也没有比较差劲的方面。

所以要选择合适的收集器，更重要的是要看用途、服务领域、面向人群，因地制宜，而且还有一些具体的虚拟机的参数可以供人去优化调控。

第一次写，感觉逻辑有些混乱，想到啥写啥。。。