本篇是对Java官网G1收集器调优的精简版。针对G1垃圾的收集阶段可能出现的问题，非合理内存分配，大对象占用，Full GC等问题作出解决方式和操作参数。
G1是一个吞吐量和时间延迟之间相互平衡的收集器。目标是高吞吐量下提供相对较小、统一的暂停。
所以如果是交互性强的应用程序，使用G1时需要基于时延优先进行考虑。
虚拟机从操作系统内存中分配或归还内存可能会导致不必要的延迟。通过使用选项-Xms和-Xmx将最小和最大堆大小设置为相同的值，并使用 - XX:+AlwaysPreTouch 预触摸所有内存，以将这项工作移到VM启动阶段，从而避免延迟。
并行处理 Reference对象，ParallelRefProcEnabled默认值false，若 GC log 里出现 Reference 处理时间较长的日志，可以开启此参数- XX:+ParalleRefProcEnabled 。开启后会使用jvm可用的线程数进行处理，但官网上提到的-XX:ReferencesPerThread参数在jdk17的版本中没有找到，猜测可能是jvm内部控制不再作可调试的参数。
年轻代收集所花费的时间大致与年轻代的大小成正比。官网给出的两个参数- XX:G1NewSizePercent ，-XX: G1MaxNewSizePercent 在jdk17中没有找到，在没有固定年轻代大小时，G1会进行动态调整，所以这个调优的参考性不大，可以忽略。
减少老年代regions暂停时间
RS是一个抽象的数据结构，具体的实现由table card完成。一般会把记忆集和卡表放在一起讨论。简单来讲就是所有对象引用关系的一个集合，GCRoot时扫描的不是去实际的内存区域，否则跨代引用时从新生代到老年代会是一个漫长的过程。RS很好的解决了跨代引用的问题。由于RS会动态更新，垃圾收集必须先等RS更新完毕后才去执行。所以RS更新如果耗时过长则会影响回收时间。
RS的大小跟堆空间是成正比的。
扫描RS时间也由G1为保持低存储容量而执行的压缩量决定。记忆的集合存储在内存中越紧凑，在垃圾收集期间检索存储的值所花费的时间就越多。G1自动执行这种压缩，称为记忆集粗化，同时根据该区域记忆集的当前大小更新记忆集。特别是在最高压缩级别时，检索实际数据可能非常慢。
使用选项- XX:G1SummarizeRSetStatsPeriod 结合gc+remset=trace级别日志显示是否发生粗化。
解决方案
操作选项