Chrome这功能隐藏太深了！

看起来这么大的内存，Survivor区 也足够大，这个晋升规则也比较严格，但是高并发的场景下，上面这个流程只要反复的来几次

老年代的对象就会越来越多

什么是 Mixed GC (混合回收)?

因为 G1 是基于 Region 的，并没有严格的区分老年代新生代，

G1有一个参数，XX:InitiatingHeapOccupancyPercent ，它的默认值是 45% ,意思就是说，如果 老年代 占据了堆内存的 45% 的 Region 的时候，此时就会尝试触发一个新生代+老年代一起回收的混合回收。

什么时候发生 Full GC(fgc) ?

异常情况

1. 大对象太多，对象都跑老年代去了，老年代内存吃紧会触发 fgc ，如果fgc 内存还是不够使用，那再申请内存的时候就会抛出 OOM 异常，然后再 fgc 如此往复循环，系统并不会直接挂掉，表现是系统假死，非常卡顿，用户体验极差。
2. 元空间、直接内存这些区域快满了都会触发 fgc

后续 堆空间、元空间、直接内存(堆外内存) OOM 都会有真实的生产环境案例 敬请期待

正常情况

1. fgc 都知道是一个很耗时的操作 , G1 正常的工作状态是没有 Full GC 概念的，老年代垃圾的收集任务全靠 Mixed GC 来处理。
2. 不过在进行 Mixed 回收的时候，无论是年轻代还是老年代都基于复制算法进行回收，都要把各个 Region 的存活对象拷贝到别的 Region 里去，
3. 此时万一出现拷贝的过程中发现没有空闲 Region 可以承载自己的存活对象了，就会触发一次失败。一旦失败，立马就会切换为停止系统程序，切换到 G1 之外的 Serial Old GC 来收集整个堆(包括 Young、Old、Metaspace )这才是真正的 Full GC(Full GC不在G1的控制范围内)
4. 进入这种状态的G1就跟使用参数 -XX:+UseSerialGC 的 Full GC 一样(背后的核心逻辑是一样的)。然后采用单线程进行标记、清理和压缩整理，空闲出来一批 Region ，使用单线程的进行 gc 这个过程是极慢极慢的。
5. 这也是 JVM 调优的关键所在，务必不要让你的系统触发 Full GC !

补充

-XX:MaxGCPauseMillis = 200 是一个默认值，停顿 200ms 也不算久，但一个高并发系统如果要求低延迟，快速响应

这个值就要再调低一点了，但是仍然不建议去把这个值改小，

很多时候设置的 200ms， 实际上也只有 20 - 80ms ，这是我观察过不下 30 个生产环境的 GC 得出来的结论。

跟做性能测试的大佬也讨论过这个的原因：G1 是一个 动态、灵活、自主、性能还不错 的垃圾收集器

如果设置太小 ，可能导致每次 Mixed GC or ygc 只能回收很小一部分 Region ，最终可能无法跟上程序分配内存的速度

从而触发 Full GC 所以很多系统并没有去把这个值改成 50 或是 100

如果设置太大 ，那么可能 G1 会允许你不停的在新生代理分配新的对象，然后积累了很多对象，再一次性回收几百个 Region

此时可能一次 GC 停顿时间就会达到几百毫秒，但是 GC 的频率很低。

比如说 30 分钟才触发一次新生代 GC，但是每次停顿 500ms ,毫无疑问， 500ms 对于一个高并发的系统来说实在是太久了

四、JVM 调优该怎么做?

主要优化在新生代

（编辑：济宁站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!