G1调优很难？记住这些经验技巧~

2023-10-27 10:25:04

点击上方 "编程技术圈"关注, 星标或置顶一起成长

后台回复“大礼包”有惊喜礼包！

每日英文

Once in your world, I lost himself; without your world now, I find better.

曾经在你的世界里，我迷失了自己；现在在没有你的世界里，我找到了更好的自己。

每日掏心话

人生就是这样的匆匆，谁也不知道是谁对谁错，曾经的一场错过，成了彼此生命中永远解不开的纠葛。如若，没有那场的相遇，或许就没有今生如此多的劫难。

责编：乐乐 | 来自：占小狼的博客

编程技术圈(ID:study_tech)第 1178 次推文

往日回顾：23 种设计模式的通俗解释，虽然有点污，但是秒懂

正文

G1 GC是启发式算法，会动态调整年轻代的空间大小。目标也就是为了达到接近预期的暂停时间。G1提供了两种GC模式，Young GC和Mixed GC，两种都是Stop The World(STW)的。

Young GC

Young GC主要是对Eden区进行GC，它在Eden空间耗尽时会被触发。在这种情况下，Eden空间的数据移动到Survivor空间中，如果Survivor空间不够，Eden空间的部分数据会直接晋升到老年代空间。Survivor区的数据移动到新的Survivor区中，也有部分数据晋升到老年代空间中。最终Eden空间的数据为空，GC停止工作，应用线程继续执行。

Mixed GC

Mix GC不仅进行正常的新生代垃圾收集，同时也回收部分后台扫描线程标记的老年代分区。GC步骤分2步：全局并发标记（global concurrent marking）和拷贝存活对象（evacuation）。

在进行Mix GC之前，会先进行global concurrent marking（全局并发标记）。global concurrent marking的执行过程是怎样的呢？在G1 GC中，它主要是为Mixed GC提供标记服务的，并不是一次GC过程的一个必须环节。

-XX:MaxGCPauseMillis

暂停时间，默认值200ms。这是一个软性目标，G1会尽量达成，如果达不成，会逐渐做自我调整。

对于Young GC来说，会逐渐减少Eden区个数，减少Eden空间那么Young GC的处理时间就会相应减少。对于Mixed GC，G1会调整每次Choose Cset的比例，默认最大值是10%，当然每次选择的Cset少了，所要经历的Mixed GC的次数会相应增加。

减少Eden的总空间时，就会更加频繁的触发Young GC，也就是会加快Mixed GC的执行频率，因为Mixed GC是由Young GC触发的，或者说借机同时执行的。频繁GC会对对应用的吞吐量造成影响，每次Mixed GC回收时间太短，回收的垃圾量太少，可能最后GC的垃圾清理速度赶不上应用产生的速度，那么可能会造成串行的Full GC，这是要极力避免的。所以暂停时间肯定不是设置的越小越好，当然也不能设置的偏大，转而指望G1自己会尽快的处理，这样可能会导致一次全部并发标记后触发的Mixed GC次数变少，但每次的时间变长，STW时间变长，对应用的影响更加明显。

-XX:G1HeapRegionSize

Region大小，若未指定则默认最多生成2048块，每块的大小需要为2的幂次方，如1,2,4,8,16,32，最大值为32M。Region的大小主要是关系到Humongous Object的判定，当一个对象超过Region大小的一半时，则为巨型对象，那么其会至少独占一个Region，如果一个放不下，会占用连续的多个Region。当一个Humongous Region放入了一个巨型对象，可能还有不少剩余空间，但是不能用于存放其他对象，这些空间就浪费了。所以如果应用里有很多大小差不多的巨型对象，可以适当调整Region的大小，尽量让他们以普通对象的形式分配，合理利用Region空间。

-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent

新生代比例有两个数值指定，下限：-XX:G1NewSizePercent，默认值5%，上限：-XX:G1MaxNewSizePercent，默认值60%。G1会根据实际的GC情况(主要是暂停时间)来动态的调整新生代的大小，主要是Eden Region的个数。最好是Eden的空间大一点，毕竟Young GC的频率更大，大的Eden空间能够降低Young GC的发生次数。但是Mixed GC是伴随着Young GC一起的，如果暂停时间短，那么需要更加频繁的Young GC，同时也需要平衡好Mixed GC中新生代和老年代的Region，因为新生代的所有Region都会被回收，如果Eden很大，那么留给老年代回收空间就不多了，最后可能会导致Full GC。

-XX:ConcGCThreads

通过 -XX:ConcGCThreads来指定并发GC线程数，默认是-XX:ParallelGCThreads/4，也就是在非STW期间的GC工作线程数，当然其他的线程很多工作在应用上。当并发周期时间过长时，可以尝试调大GC工作线程数，但是这也意味着此期间应用所占的线程数减少，会对吞吐量有一定影响。

ConcGCThreads = (3 + ParallelGCThreads) / 4

-XX:ParallelGCThreads

通过-XX:ParallelGCThreads来指定并行GC线程数，也就是在STW阶段工作的GC线程数，其值遵循以下原则：

如果用户显示指定了ParallelGCThreads，则使用用户指定的值。否则需要根据实际的CPU所能够支持的线程数来计算ParallelGCThreads的值。如果物理CPU所能够支持线程数小于8，则ParallelGCThreads的值为CPU所支持的线程数。这里的阀值为8，是因为JVM中调用nof_parallel_worker_threads接口所传入的switch_pt的值均为8。如果物理CPU所能够支持线程数大于8，则ParallelGCThreads的值为8加上一个调整值，调整值的计算方式为：物理CPU所支持的线程数减去8所得值的5/8或者5/16，JVM会根据实际的情况来选择具体是乘以5/8还是5/16。ParallelGCThreads= 8 + (N - 8) * 5 / 8 比如，在64线程的x86 CPU上，如果用户未指定ParallelGCThreads的值，则默认的计算方式为：ParallelGCThreads = 8 + (64 - 8) * (5/8) = 8 + 35 = 43。

-XX:G1MixedGCLiveThresholdPercent

通过这个参数指定被纳入Cset的Region的存活空间占比阈值，不同版本默认值不同，有65%和85%。在全局并发标记阶段，如果一个Region的存活对象的空间占比低于此值，则会被纳入Cset。此值直接影响到Mixed GC选择回收的区域，当发现GC时间较长时，可以尝试调低此阈值，尽量优先选择回收垃圾占比高的Region，但此举也可能导致垃圾回收的不够彻底，最终触发Full GC。

-XX:InitiatingHeapOccupancyPercent

通过这个参数指定触发全局并发标记的老年代使用占比，默认值45%，也就是老年代占堆的比例超过45%。如果Mixed GC周期结束后老年代使用率还是超过45%,那么会再次触发全局并发标记过程，这样就会导致频繁的老年代GC，影响应用吞吐量。同时老年代空间不大，Mixed GC回收的空间肯定是偏少的。可以适当调高IHOP的值，当然如果此值太高，很容易导致年轻代晋升失败而触发Full GC，所以需要多次调整测试。

搜索后端架构师公众号回复“架构整洁”，送你一份惊喜礼包。

-XX:G1HeapWastePercent

通过这个参数指定触发Mixed GC的堆垃圾占比，默认值5%，也就是在全局标记结束后能够统计出所有Cset内可被回收的垃圾占整对的比例值，如果超过5%，那么就会触发之后的多轮Mixed GC，如果不超过，那么会在之后的某次Young GC中重新执行全局并发标记。可以尝试适当的调高此阈值，能够适当的降低Mixed GC的频率。

-XX:G1OldCSetRegionThresholdPercent

通过这个参数指定每轮Mixed GC回收的Region最大比例，默认10%，也就是每轮Mixed GC附加的Cset的Region不超过全部Region的10%，最多10%，如果暂停时间短，那么可能会少于10%。一般这个值不需要额外调整。

-XX:G1MixedGCCountTarget

通过这个参数指定一个周期内触发Mixed GC最大次数，默认值8。一次全局并发标记后，最多接着8次Mixed GC，把全局并发标记阶段生成的Cset里的Region拆分为最多8部分，然后在每轮Mixed GC里收集一部分。这个值要和上一个参数配合使用，8*10%=80%，应该来说会大于每次标记阶段的Cset集合了。一般此参数也不需额外调整。

-XX:G1ReservePercent

通过这个参数指定G1为分配担保预留的空间比例，默认10%。也就是老年代会预留10%的空间来给新生代的对象晋升，如果经常发生新生代晋升失败而导致Full GC，那么可以适当调高此阈值。但是调高此值同时也意味着降低了老年代的实际可用空间。

-XX:MaxTenuringThreshold

晋升年龄阈值，默认值15。一般新生对象经过15次Young GC会晋升到老年代，巨型对象会直接分配在老年代，同时在Young GC时，如果相同age的对象占Survivors空间的比例超过 -XX:TargetSurvivorRatio的值(默认50%)，则会自动将此次晋升年龄阈值设置为此age的值，所有年龄超过此值的对象都会被晋升到老年代，此举可能会导致老年代需要不少空间应对此种晋升。一般这个值不需要额外调整。

调优建议

不要手动设置新生代和老年代的大小，只设置这个堆的大小 G1收集器在运行过程中，会自己调整新生代和老年代的大小其实是通过adapt代的大小来调整对象晋升的速度和年龄，从而达到为收集器设置的暂停时间目标, 如果手动设置了大小就意味着放弃了G1的自动调优。

不断调优暂停时间目标-XX:MaxGCPauseMillis，一般情况下这个值设置到100ms或者200ms，暂停时间设置的太短，就会导致出现G1跟不上垃圾产生的速度。最终退化成Full GC。所以对这个参数的调优是一个持续的过程，逐步调整到最佳状态。暂停时间只是一个目标，并不能总是得到满足。

MixedGC调优

-XX:InitiatingHeapOccupancyPercent
-XX:G1MixedGCLiveThresholdPercent
-XX:G1MixedGCCountTarger

适当增加堆内存大小

G1里的Java堆尺寸通常是分区的整数倍。除去这个限制，G1和其他HotSpot垃圾收集器一样，可以在 -Xms与 -Xmx之间动态地扩大或缩小堆大小。

以下几种情况，G1可能会增加Java堆尺寸：

在一次full GC中，基于堆尺寸的计算结果会调整堆的空间。

当发生年轻代收集或混合收集，G1会计算执行GC所花费的时间以及执行Java应用所花费的时间。根据命令行配置-XX:GCTimeRatio，如果将太多时间用在垃圾收集上，Java堆尺寸就会增加。这个情况下增加Java堆尺寸，其背后的想法就是允许GC减少发生频度，这样与花在应用上的时间相比，花在GC上的时间也可以随之降低。

G1中-XX:GCTimeRatio的缺省值为9，而其他所有HotSpot垃圾收集器都缺省使用99。GCTimeRatio的值越大，Java堆尺寸的增长就会更加得积极。其他HotSpot收集器在增加Java堆尺寸的策略上会更加激进，因为它们的目标是：相对于执行应用的开销，用于GC的时间越少越好。

如果一个对象分配失败了（甚至是在做了一次GC之后），G1会尝试通过增加堆尺寸来满足对象分配，而不是马上退回去做一次full GC。

如果一个巨型对象分配无法找到足够的连续分区来容纳这个对象，G1会尝试扩展Java堆来获得更多可用分区，而不是做一次full GC。

当GC需要一个新的分区来转移对象时，G1更倾向于通过增加Java堆空间来获得一个新的分区，而不是通过返回GC失败并开始做一次full GC来找到一个可用分区。

PS：欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，欢迎转发分享给更多人。