JVM虚拟机(九)如何开启 GC 日志、使用GCeasy在线解析?

一、引言

在 Java 应用程序的运行过程中,垃圾收集(Garbage Collection,简称 GC)是一个非常重要的环节。GC 负责自动管理内存,回收不再使用的对象所占用的内存空间。为了了解 GC 的行为和性能,我们通常需要开启 JVM 的 GC 日志功能,收集并分析 GC 日志数据。


二、开启 GC 日志

Java 项目中,默认情况下 GC 日志功能是关闭的,有多种方法能够开启 GC 的日志功能,使用 -verbose:gc-XX:+PrintGC 都能创建基本的 GC日志(这两个日志表示实际上互为别名) ,但是使用 -XX:+PrintGCDetails 标志会创建更详细的 GC 日志。

先提供一个比较通用的开启日志方式供参考:

java -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=14 -XX:GCLogFileSize=20M -XX:+PrintHeapAtGC -XX:+HeapDumpOnOutOfMemoryError -Xloggc:springboot-demo-gc".log" -jar springboot-demo.jar
  • -XX:+PrintGCDetails:打印更详细的 GC 日志信息,包括各个内存区域的使用情况、GC 的触发原因等。
  • -XX:+PrintGCTimeStamps:打印 GC 发生的时间戳。(以基准时间的形式)
  • -XX:+PrintGCDateStamps:打印 GC 发生的时间戳。(以标准时间的形式,如:2024-04-13T17:35:04.859+0800)
  • -XX:+UseGCLogFileRotation:启用 GC 日志文件的自动轮转功能,维持日志目录中的日志文件在一定的数目。
  • -XX:NumberOfGCLogFiles=14:GC 日志文件的滚动数量,使 GC 日志文件数量维持在 14 个,超出 14 个后,将日志覆盖写入到最早的日志文件中。
  • -XX:GCLogFileSize=20M:GC 日志文件的大小,超出大小后触发日志的轮转,将日志覆盖写入到最早的日志文件中。
  • -XX:+PrintHeapAtGC:在进行 GC 的前后打印出堆的信息。
  • -XX:+HeapDumpOnOutOfMemoryError:内存溢出的时候生成 dump 文件。
  • -XX:HeapDumpPath=目录/xxx.hprof:指定内存溢出时,dump 文件的生成路径,默认为当前目录。
  • -Xloggc:springboot-demo-gc".log":指定 GC 日志的输出文件。

三、解析 GC 日志

在解析 GC 日志前,推荐一个在线解析 GC 日志的地址,我个人感觉比较好用:

在这里插入图片描述

当然,我们也可以完全自己进行分析。

GC 日志的格式和内容可以因 JVM 版本和 GC 算法的不同而会有所差异。下面是一个典型的 GC 日志示例:

2023-04-25T10:30:00.123+0800: 1.234: [GC (Allocation Failure) [PSYoungGen: 123456K->12345K(153600K)] 185432K->67890K(579200K), 0.0123456 secs] [Times: user=0.009876, sys=0.002468, real=0.012345]
  • 2023-04-25T10:30:00.123+0800:在2023年4月25日10点30分00.123秒(UTC+8时区)时,发生了一次GC。
  • [PSYoungGen: 123456K->12345K(153600K)]:GC前,新生代(PSYoungGen)使用了123456K内存,GC后减少到12345K。
  • 185432K->67890K(579200K), 0.0123456 secs:整个堆内存(包括老年代和新生代)GC前使用了185432K,GC后减少到67890K。GC持续了0.0123456秒。
  • [Times: user=0.009876, sys=0.002468, real=0.012345]:用户态CPU时间为0.009876秒,内核态CPU时间为0.002468秒,实际耗时为0.012345秒,最后这个是最重要的考察维度。

通过解析GC日志,我们可以了解GC的频率、持续时间、回收的内存量等信息,从而分析应用程序的内存使用情况和性能瓶颈。


四、优化建议

根据 GC 日志的分析结果,我们可以采取一些优化措施来提高应用程式的性能:

  1. 调整堆内存大小: 根据应用程序的实际需求,适当增加或减少堆内存的大小。
  2. 选择合适的 GC 算法: 不同的 GC 算法适用于不同的应用场景。根据 GC 日志的分析结果,选择最适合当前应用程序的 GC 算法。
  3. 优化代码: 减少对象的创建和长时间持有,避免内存泄漏等问题。
  4. 使用内存分析工具: 结合内存分析工具(如MAT)。

五、GCeasy解析结果示例

在这里插入图片描述

整理完毕,完结撒花~🌻





参考地址:

1.深入解析Java日志:如何开启JVM GC日志获取,https://developer.baidu.com/article/details/3210478
2.JVM 配置GC日志,https://blog.csdn.net/Coco_chun/article/details/120332428
3.【Java8】jvm 开启GC日志(ParNew+CMS),https://blog.csdn.net/smallbirdnq/article/details/132906468

  • 12
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
您好!对于JVM(Java虚拟机)在进行Full GC(垃圾回收)后无法重启的情况,可能有多种原因导致。以下是一些常见的可能原因和解决方法: 1. 内存设置不当:Full GC 可能由于内存不足而导致无法重启。您可以尝试增加JVM的内存限制(通过调整-Xmx和-Xms参数)来解决该问题。 2. 系统资源不足:Full GC 执行期间,系统资源(如CPU、磁盘空间等)可能出现瓶颈,导致无法重启。您可以检查系统资源使用情况,并进行相应的优化或增加资源。 3. 线程死锁:Full GC 可能会暂停应用程序的所有线程,如果存在线程死锁,可能导致无法恢复。您可以使用线程转储工具(如jstack)来检查是否存在线程死锁,并解决死锁问题。 4. 第三方库或框架问题:某些第三方库或框架可能存在与Full GC 不兼容的问题,导致无法重启。您可以尝试更新相关库或框架版本,或者联系供应商以获取支持。 5. JVM Bug:在某些情况下,Full GC 无法重启的问题可能是由于JVM本身的Bug引起的。您可以尝试更新JVM版本,或者向JVM的开发者报告该问题以获取解决方案。 请注意,以上只是一些可能的原因和解决方法,具体情况需要根据实际环境和日志信息进行分析和判断。如果问题仍然存在,请尝试记录相关错误信息并查看相应的日志文件,这有助于更好地定位和解决问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不愿放下技术的小赵

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值