Java8应用young gc时间过长

发布于 2022-09-11 22:39:40 字数 1318 浏览 28 评论 0

问题描述

求教各位大神,Java 8应用young gc时间过长,平均耗时接近100ms,偶尔能到1.5s
使用垃圾收集器parNew + CMS,几乎没有触发过CMS gc
使用框架spring + mybatis + dubbo + rocketmq
JVM参数:
-server -Xmx5g -Xms5g -Xmn1g -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -Xss256k -XX:SurvivorRatio=8 -XX:+PrintGCDetails -Xloggc:/opt/apps/logs/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+PrintReferenceGC -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/opt/apps/logs/safepoint.log -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/apps/logs

问题出现的环境背景及自己尝试过哪些方法

首先打开了gc日志和停顿点日志
一开始怀疑是safepoint的问题,打印了safepoint日志后,发现spin + block的时间都很短,只有gc的时候vmop时间与gc日志的时间一致,都能到1s多,排除了安全点问题
后来怀疑是finalReference的回收问题,添加了JVM参数打印各类refenrence的回收时间,都非常短,与gc耗时不在一个量级,排除finalize

相关代码

以下是gc日志
图片描述
图片描述
图片描述

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

ゞ记忆︶ㄣ 2022-09-18 22:39:40

你设置了1G的年轻代,我觉得怎么样都会gc时间长,
而且我看你总占用才 1G,
是不是可以把JVM内存设置小一点,

update:
搜了搜一些博客:
https://www.cnblogs.com/sunzh...
感觉确实耗时比较多,而且也不是安全点原因,不知道你的机器核数是多少,我注意到你没设置ParallelGCThreads,不知道有几条线程用于paraNew的回收,要不你jstack下看看,

臻嫒无言 2022-09-18 22:39:40

年轻代一直回收说明一直在频繁创建新的对象,建议做个堆dump看看内存对象情况,可能是哪里代码写了循环一直创建对象,要是可以优化就先从代码层面优化。若内存对象都正常的话就把年轻代内存放小一点,这样回收时间短些,用户感知卡顿效果会好些。

陌上青苔 2022-09-18 22:39:40

问题找到了,是容器的原因。
背景信息没补充完全,应用是跑在docker里的,jstack看了下,新生代的gc线程有54条,但是容器给的配置只有6核,所以可以确认JVM拿错了CPU的核心数,拿到的是物理机的核心数。增加了参数-XX:ParallelGCThreads=6 -XX:ConcGCThreads=6,现在的新生代收集时间基本稳定在50ms以内。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文