深刻了解 JVM – G1 调优简述

前言

​ G1 收集器是一个不太好调优的收集器，因为他不能像固定分代的收集器那样能够本人想划分多少就划分多少，更多的调配动作是由收集器动作，因为 region 是一块块的，同时主动增长也是由 G1 管制，如同的确不太好调优。

​ 这篇文章更多的是提供调优的一个大抵方向，更多的内容须要后续介绍 JVM 的工具进行解说。

案例实战

​ 这次应用一个在线的教育平台作为案例解释 G1 是如何进行优化的。

​ 在线教育平台的压力来自于哪里？首先孩子白天须要上学同时家长也须要下班，所以白天的访问量不会很大，同时次要的业务也不在在线教育平台解决。然而一旦到了早晨，机器的压力就上来了，同时孩子也会在线进行听课上课，这时候用户量会暴增，会有上万人同时在线听课。这时候能够发现在线教育平台的压力在于直播，而直播的流量顶峰在于课堂的互动环节，为什么是互动环节呢，因为孩子不喜爱干燥的课堂，为了带动课堂气氛，课堂中的游戏肯定是沉闷氛围的要害，也是零碎压力的外围，这时零碎须要记录各种数据，比方流动时长，得分，积分处分等等，同时也会呈现大量的对象调配，为了保障直播的晦涩，零碎要求非常低的提早响应工夫。

​ 所以最终的论断是：在线教育平台大略在直播的互动环节压力会倍增，零碎要求非常低的提早响应工夫。

​ 通过了下面的状况剖析，咱们假如 单台机器每秒大略有 600 个申请，假如每一个申请占用 10KB，则是 6000KB 的大小占用也就是最终 6M 左右的内存占用。同时部署在一个 4 外围 8G 的零碎下面。

同样的，这种案例也只是模仿和假如，具体情况受到各种因素的限度，切勿过于深究细节。

如何剖析零碎

传统的分代概念

​ 咱们用传统分代的概念部署一下这个零碎，依据每一秒的申请为 6M 的对象大小，同时依据零碎 4 外围 8 的配置，那么给 JVM 的内存大略是 4G，咱们晓得直播的互动环节产生的积分，处分，计算等对象根本都是朝生夕死的小对象，所以咱们不太须要给老年代过大的空间，所以进来办法区和虚拟机线程栈的内存，咱们给大概会给新生代 3G 和老年代 1G 左右的内容。

​ 如果每秒产生 6M 的对象，那么一分钟就是 300 多 M，依照默认的新生代配比 8：1：1 则 Eden 区域大略为 2.4G 的大小，survior 区域为两个 300M 的大小空间。一分钟 300M，那么基本上 8 分钟左右新生代就会满，此时假如有 300M 左右对象存活进入 Survior 区域，这时候 Survior 区域尽管能够装的下，然而因为超过了 50% 的配比，最终还是有约 150M 的对象进入老年代。

​ 这时候再推算，老年代每 8 分钟进入 150M 的对象，大概 40 分钟左右就会整个零碎进展一次，这个进展工夫还是乐观预计，因为零碎不可能只运作这一块的内容，单单是推算直播互动这一块就会产生这样的成果，可想而知加上整个零碎的其余模块，实际上 5、6 分钟可能会进展一次！！！这样必定是不行的，试想下你玩游戏隔几分钟就停一下，对于小孩子来说忽然卡一下导致丢分最初问题不佳孩子又哭又闹，家长这时候不必想必定会大量的投诉，被骂也不远了 ……

应用 G1 收集器

​ 咱们接着应用 G1 的收集器进行替换，零碎部署在一个 4 外围 8G 的零碎下面，假如机器在 JVM 上调配 4G 给堆，新生代默认初始化比例为 5%，最大占比为 60%，JAVA 线程堆栈为 1M，则大概开启几百个线程须要 200，300M 的空间，而办法区占用 256M 够用。

​ 在上一节在文章中介绍过，能够把 G1 的工作机制设想成开盘子，然而放到零碎上就很头疼了，G1 什么时候回来收垃圾是咱们无奈预测的！！这里就须要通过一些辅助伎俩，同时这部分的监控操作须要工具和日志进行解读，所以将会放到后续的专门一篇文章进行解读。

如何计算 Region 的占用和大小：

​ 依照 4096M/2048 每个 region 是 2M，如果依照新生代初始为 5%，则依据参数 5% 新生代的大小为 100 个 Region 左右，4G 的内存机器后果能够得出新生代初始 200M 左右的内存占用大小

至关重要的参数：

​ -XX:MaxGCPauseMills 参数：默认值为 200，代表了 200MS，示意最大的进展工夫为 200MS。

​ 如果应用 G1 收集器，这个参数间接影响了整个 JVM 零碎的性能，如果这个数值过大，会导致垃圾收集的工夫过长而导致前台卡顿，也容易导致新生代来不及触发垃圾回收就满了，或者导致老年代内存无奈及时的回收。

多久会触发新生代回收操作

​ 依据之前的阐明，新生代最大能够应用 60% 的空间，同时也阐明了新生代应用复制算法，依据 8:1:1 的规定，大略达到新生代的 80% 左右就会触发垃圾的回收操作？这种做法显然不合乎 G1 基于全堆以及混合回收的操作。所以不能用固定大小的回收思路思考 g1 的回收操作。

​ 正确做法：G1 会依据 200MS 的要求，定时去断定以后的新生代是否能够合乎 200MS 的收集操作要求，粗心就是当新生代的垃圾回收须要耗时 200MS 的时候，就会触发新生代的回收。

​ 这里也能够间接依照之前的了解餐厅的服务员定时过去开盘子的操作了解新生代多久进行一次回收操作。

如何优化：

​ 下面的探讨几点之后，这就头疼了，这要这么优化？这时咱们须要用上一些压测的工具以及 GC 日志和内存剖析工具来思考了，然而也不要让 GC 挺多进展工夫预设值太大了导致 GC 进展工夫太长，应该给个正当的值。

Mixed gc 如何优化？

​ 既然新生代的优化都曾经很麻烦了，更不用说老年代回收了。而老年代的回收自身也没有了 Old GC，取而代之的是 Mixed GC，所以须要小心看待，咱们从根本上还是须要避免让对象进入到老年代一直扩大导致 mixed gc，这更加须要关注工夫进展模型这个参数。

最终剖析

​ 新生代：

1. 因为是复制算法，所以须要从根本上解决的话仍然须要管制新生代的存活对象进入 survior 的大小，同时管制在 50% 以内。尽量避免 GC 之后对象间接进入老年代。另外 60% 的新生代空间通常也不必怎么调整，除非业务对象频繁创立新生代会产生大量对象才须要思考。
2. 新生代有一个参数是存活对象大于 85% 的时候不须要进行拷贝，这个值如果设置小一点可能会进步回收效率，然而有可能造成大量的长寿对象进入老年代的危险。

​ 老年代：

1. 依照 G1 的最初一个步骤，垃圾回收和零碎回交替 8 次，同时在回到 5% 的 region 的时候进行收集，这个参数其实能够适当调大一些：G1HeapWastePercent
2. 45% 的老年代占用触发垃圾回收的机制，这个参数也不须要大改，因为 JDK 设置这个参数必定是通过了很多测试和考量之后的后果。

总结

​ 这一篇更多的是提供优化思路，JVM 调优没有万金油的解决方案，特地是 G1 收集器这种算法细节十分复杂的收集器，调优须要更多的精力和工夫测试调优成果。

写在最初

​ 下一篇章会做一个整个系列到目前为止的大节，温故而知新，人的遗忘曲线更加须要咱们重复的坚固常识和内容。