G1 GC性能优化方案
G1的年轻代回收
External Root Regions
外部根区间扫描指的是从根部开始扫描通过JNI中本地的类中调用Malloc函数分配出的内存。这个步骤是并行任务的第一个任务。这个阶段堆外(off-heap)根节点被开始扫描，这些扫描范围包括JVM系统字典、VM数据结构、JNI线程句柄、硬件注册器、全局变量，以及线程栈根部等，这个过程主要是为了找到并行暂停阶段是否存在指向当前收集集合(CSet)的指针。
这里还有一个情况需要引起大家的重视，就是查看工作线程是否在处理一个单一的根节点时耗时过长，导致感觉类似挂起的现象。这个现象可以通过查看工作线程对应的“termination”日志看出来。如果存在这个现象，你需要去查看是否存在比较大的系统字典(JVM System Dictionary)，如果这个系统字典被当成了一个单一根节点进行处理，那么当存在大量的加载类时就会出现较长时间的耗时。
Rememebered Sets and Processed Buffers
Rset帮助维护和跟踪指向G1区间的引用，而这些区间本身拥有这些RSet。还记得我们在第4章介绍过的并行Refinement线程吗?这些线程的任务是扫描更新日志缓存，并且更新区间的RSet。为了更加有效地支援这些Refinement线程的工作，在并行回收阶段，所有未被处理的缓存(已经有日志写在里面了)都会被工作线程拿来处理，这些缓存也被称为日志里面的处理缓存。
为了限制花费在更新RSet上的时间，G1通过选项-XX:MaxGCPauseMills设置了目标暂停时间，采用相对于整个停顿目标时间百分比的方式，限制了更新RSet花费的总时长，让评估暂停阶段把最大量的时候花费在拷贝存活对象上。这个目标时间默认为整个停顿时间的10%，例如整个停顿时间是10s，那么花费在更新RSet上的时间最大为ls。G1 GC的设计目标是让更多的停顿时间花费在拷贝存活对象上面，因此暂停时间的10%被用于更新RSet也是比较合理的，百分比大了，花在干具体业务(各阶段拷贝存活对象)上的时间也就少了。
如果你发现这个值不太准确或者不符合你的实际需求，这里可以通过更新选项-XX:G1RSetUpdatingPauseTimePercent来改变这个更新RSet的目标时间值。切记，如果你改变了花费在更新RSet上的时间，那你必须有把握工作线程可以在回收暂停阶段完成它们的工作，如果不能，那这部分工作会被放到并行Refinement线程里面去执行，这会导致并行工作量增加、并行回收次数增多。最坏的情况是如果并行Refinement线程也不能完成任务，那么Java应用程序就会被暂停，原本负责执行Java应用程序的资源就会直接接手任务，这个画面“太美”不敢看!大家要尽量避免这种情况发生。
注意，-XX:G1ConcRefinementThreads选项的值默认和-XX:ParallelGCThreads的值一样，这意味着对于-XX:ParallelGCThreads选项的修改会同样改变-XX:G1ConcRefinementThreads选项的值。
在当前CSet里面回收之前，CSet内部的每个区间的Rset都需要被扫描，主要目的是找到CSet区间内部的引用关系。一个有较多存活对象的区间容易导致Rset的粒度变细，即每个区间对应的表格会从粗粒度变为细粒度，也可以理解为里面对象增多后扫描一个Rset需要更长的扫描时间，这样你就会看到更多的时间被花费在了扫描RSet上面。也可以理解为扫描时间取决于RSet数据结构的粗细粒度。
Summarizing Remembered Sets
XX:+G1SummarizeRSetStats选项用于统计RSet的密度数量(细粒度或者粗粒度)，这个密度帮助决定是否并行Refinement线程有能力去应对更新缓存的工作，并且收集更多关于Nmethods的信息。这个选项每隔n次GC暂停收集一次RSet的统计信息，这个n次由选项-XX:G1SummarizeRSetStatsPeriod=n决定，也是需要通过选项进行设置的。
注意，-XX:+G1SummarizeRSetStats选项是一个诊断选项，因此必须启用-XX:+UnlockDiagnosticVMOptions选项才可以启用-XX:+G1SummarizeRSetStats选项。
PDF书籍下载地址：
https://github.com/jiankunking/books-recommendation/tree/master/Java
- 本文链接： https://jiankunking.com/java-jvm-gc-g1-notes.html
- 版权声明： 本博客所有文章除特别声明外，均采用 BY-NC-ND 许可协议。转载请注明出处！
欢迎关注我的其它发布渠道
