六、G1垃圾收集器

一、JVM类加载机制——自定义类加载器
二、JVM——对象内存分配机制
三、JVM内存模型
四、JVM垃圾收集算法和垃圾收集器
五、CMS垃圾回收器——三色标记算法
六、G1垃圾收集器
七、JVM调优实战——基本命令使用
八、JVM调优实战——arthas使用
九、大流量电商系统JVM调优案例

G1垃圾处理器使用范围：

服务器拥有多个服务器，大内存；
G1：将JVM堆划分为大小相等的region，最多有2048个reqion，region的角色是变化；可能显示是Eden区域，一次垃圾回收之后就是Old区域了。
年轻代默认占比5%，由参数-XX:G1NewSizePercent指定;
年轻代最大占比不超过60%，由参数-XX:G1MaxNewSizePercent指定；

G1的特殊之处之一是对大对象的处理：

大对象就是上图中显示的H区域，H区域判断条件是一个对象的大小>region的一半。
举例：JVM内存4096M，划分为2048个region；每个region的大小为2M；如果一个对象的大于1M，就直接放入H区域中。

G1的mixGC会收集年轻代、老年代和Humongous区域；
G1中的垃圾回收采用的复制清理算法，解决了碎片问题；
G1在垃圾回收的时候会维护一个collectionset表格，计算回收的效益(最短的时间，回收最多的对象)；
G1引进了RSet的概念。它的全称是Remembered Set，作用是跟踪指向某个heap区内的对象引用。

G1的垃圾回收过程：

初始标记（stw）——并发标记——最终标记（stw）——筛选标记（stw）

并发标记的过程中可能会存在漏标问题，CMS用增量更新解决，G1用原始快照技术解决，为什么？
增量更新的原理是从根引用开始沿着引用链进行扫面，这种方式如果G1使用的话，会存在跨区域扫描的问题，过程比较耗时；与G1控制垃圾回收时间，提高用户体验的目标不符合。

G1的几个重要参数：

-XX：MaxGcPauseMilis：垃圾回收的停顿时间，默认200ms；该值不建议设置过小；该值过小，每次垃圾回收不充分，可能会引发full GC(单线程回收垃圾，是个灾难)
-XX：InitiaaingHeapOccucry:指定old区域的占比；默认值值45%，超过该值时，会触发mixGc；
-XX；G1MixGcLiveThreadholePercent:85%；一个region中存活对象的比例；
-XX：G1MixGcCountTarget：默认8次；一次垃圾回收过程中，筛选回收的次数；说白了就是为了减小stw时间，分多次执行。

G1:使用场景：

部署kafaka应用的服务器一般拥有大内存，实时要求比较高；所以适合使用G1垃圾回收器。

对G1垃圾回收器的理解：https://blog.csdn.net/z69183787/article/details/93207364

G1 垃圾收集器架构和如何做到可预测的停顿(阿里)：
https://www.cnblogs.com/aspirant/p/8663872.html