一、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