背景

公司内部基于 spring boot 开发自有组件并顺利上线，为 api 同学的开发带来了极大的便利，许多重要业务迁移到该组件, 这种情况下我们对组件的性能做一次深度压测。并对一些逻辑进行了合理优化，其中发现一些比较有意思的点。

测试环境

测试机型为 linux 4.19.84-300.el7.x86_64t 系统，配置为 4 核 cup， 8 g 内存，模拟每秒 3700 吞吐量,请求大小为 500 B。

性能问题

cpu 使用率 350%

定位问题

查看什么线程在占用 cpu ？

top -Hp 9458

发现一个线程名称为 java 线程，看一下具体是那个线程。

转换tid, 通过16进制转换 printf %x 9473，nid 号为2501

jstack 看一下具体线程在干什么 jstack 9458 > /tmp/9458

发现是 G1 的 gc 线程在搞鬼

排查问题

G1 Concurrent Refinement Thread 这个线程是干什么的呢？

打开gc debug 功能看一下详细日志，增加配置-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:${LOGPATH}/gc.log

update rset 时间很长，生成大量的 Dcq 缓存，Dcq 主要是 Concurrent Refinement Thread 处理，尤其是 0# 线程是主力。

yong gc 时 rset 更新时间较长，增加参数跟踪 Refinement 线程，看一下是不是很忙。

-XX:+UnlockDiagnosticVMOptions -XX:+G1TraceConcRefinement

-XX:+G1SummarizeRSetStats -XX:G1SummarizeRSetStatsPeriod=2 查看一下 rset 占用情况

存在大量大对象时，会对 up rset 存在影响

-XX:-ReduceInitialCardMarks去掉批量更新 rset 的操作，为啥呢？

Spurious high Update RS times in combination with the application allocating large objects may be caused by an optimization that tries to reduce concurrent remembered set update work by batching it. If the application that created such a batch happens just before a garbage collection, then the garbage collection must process all this work in the Update RS times part of the pause. Use -XX:-ReduceInitialCardMarks to disable this behavior and potentially avoid these situations.

翻译一下就是，gc 希望通过批处理来减少更新 rset 时间,但是对但是对大对象不适用。我们的组件中涉及到一些压缩逻辑，需要申请大内存。

up rset 的时间变少了，是不是 G1 Concurrent Refinement Thread 也可以不那么耗时了。

果然，不再燥热了。

-XX:+ParallelRefProcEnable 开启并发引用处理

总结

JVM 在分配大对象时，会通过批处理的方式，来减少并发 rset 的更新。如果大量大对象在垃圾回收之前生成，垃圾回收时，需要在 Update Rset 阶段处理这些大对象的标记工作，会增加处理延时。使用-XX：-ReduceInitialCardMarks 可禁用这项优化。

参考文献

https://docs.oracle.com/javase/9/gctuning/garbage-first-garbage-collector-tuning.htm#JSGCT-GUID-70E3F150-B68E-4787-BBF1-F91315AC9AB9

G1 Concurrent Refinement Thread 在干啥?相关推荐

sharding-jdbc数据加密实践与坑
sharding-jdbc官方文档:https://shardingsphere.apache.org/document/legacy/4.x/document/cn/manual/sharding- ...
Java Hotspot G1 GC的一些关键技术
前言 G1 GC,全称Garbage-First Garbage Collector,通过-XX:+UseG1GC参数来启用,作为体验版随着JDK 6u14版本面世,在JDK 7u4版本发行时被正式推 ...
垃圾回收器之 G1 垃圾回收器
4.4 G1 定义:Garbage First 2004论文发布 2009 JDK 6u14 体验 2012 JDK 7u4 官方支持 2019 JDK9 默认 (废弃了之前的 CMS 垃圾回收器) ...
G1垃圾收集器之RSet
本文来说下G1垃圾收集器之RSet 文章目录堆内存 Region RSet RSet实现过程 RSet有什么好处 RSet有什么风险本文小结堆内存在G1的垃圾回收算法中,堆内存采用了另外一种完 ...
JVM学习-G1回收器
目录 1.简介 2.G1垃圾回收阶段 2.1.Young Collection 2.2.Young Collection + CM 2.3.Mixed Collection 2.4.FullGC 2. ...
(八)JVM成神路之GC分区篇：G1、ZGC、ShenandoahGC高性能收集器深入剖析
引言在<GC分代篇>中,我们曾对JVM中的分代GC收集器进行了全面阐述,而在本章中重点则是对JDK后续新版本中研发推出的高性能收集器进行深入剖析,但在开始前,先来看看JDK的发布记录中关 ...
G1 垃圾收集器详解
Garbage First(简称G1)收集器开创了收集器面向局部收集的设计思路和基于Region的内存布局形式.它是一款专门针对于拥有多核处理器和大内存的机器的收集器,在满足了GC响应时间的延迟可控的 ...
JDK8使用G1 垃圾回收器能解决大问题吗？
本文想突出两个问题: 解决问题的思路:从最原始的角度去思考,问题的本身是因为缓存数据导致的GC,那我们就应该去思考缓存数据是否合理,而不是去思考JVM的参数是否合理学习G1的知识,其关键的概念,关键 ...
用C++11 实现 thread pool
最近看了看我的计划,写道这里也算是到了一半,大部分都是讲的单一的C++11的用法,基本都是理论知识,就像我上大学的时候,老师一直讲理论知识,结局就是能去能不去的时候,我选择了后者.所以在这里穿插一下小 ...
[Done][DUBBO] dubbo Thread pool is EXHAUSTED!
异常信息: com.alibaba.dubbo.remoting.ExecutionException: class com.alibaba.dubbo.remoting.transport.disp ...

G1 Concurrent Refinement Thread 在干啥?

背景