JVM GC日志(一)

1.JVM启动参数

-Xloggc:D:/gc.log   日志文件保存的路径
-XX:+PrintGCDetails     打印回收详情
-XX:+PrintGCTimeStamps  打印JVM执行时间
-XX:+UseSerialGC  指定JVM使用串行垃圾收集器

2.执行代码

public class SimpleGc {
    public static void main(String[] args) {
        List<byte[]> l=new ArrayList<byte[]>();
        for(int i=0;i<1000000;i++){
            byte[] bytes= new byte[64];
            l.add(bytes);
            if(l.size()*64/1024/1024>13){
                l.clear();
            }
        }
    }
}

3.输出日志
这样配置以后,发生GC时输出的日志就类似于下面这种格式(为了显示方便,已手动换行):

0.341: [GC (Allocation Failure) 
    0.341:[DefNew: 34944K->4352K(39296K), 0.0235464 secs] 34944K->13487K(126720K), 0.0237237 secs] 
    [Times: user=0.00 sys=0.01, real=0.02 secs] 

0.381: [GC (Allocation Failure) 
    0.381: [DefNew: 39296K->4351K(39296K), 0.0197736 secs] 48431K->21422K(126720K), 0.0198706 secs] 
    [Times: user=0.03 sys=0.00, real=0.02 secs]

这个日志片段中发生了 2 次垃圾回收事件(Garbage Collection events)。两次清理的都是年轻代(Young generation)。下面我们来看,如何解读第一次GC事件,发生在年轻代中的小型GC(Minor GC):
这里写图片描述

1.0.341 GC时间的开始时间,相对于JVM的启动时间,单位是秒(Measured in seconds)

2.GC 用来区分(distinguish)是 Minor GC 还是 Full GC 的标志(Flag). 这里的 GC 表明本次发生的是 Minor GC

3.Allocation Failure 引起垃圾回收的原因. 本次GC是因为年轻代中没有任何合适的区域能够存放需要分配的数据结构而触发的

4.DefNew 使用的垃圾收集器的名字. DefNew 这个名字代表的是: 单线程(single-threaded), 采用标记复制(mark-copy)算法的, 使整个JVM暂停运行(stop-the-world)的年轻代(Young generation) 垃圾收集器(garbage collector)

5.34944K->4352K 在本次垃圾收集之前和之后的年轻代内存使用情况(Usage)

6.(39296K) 年轻代的总的大小(Total size)

7.34944K->13487K 在本次垃圾收集之前和之后整个堆内存的使用情况(Total used heap)

8.(126720K) 总的可用的堆内存(Total available heap)

9.0.0237237 secs GC事件的持续时间(Duration),单位是秒

10.[Times: user=0.00 sys=0.01, real=0.02 secs] GC事件的持续时间,通过多种分类来进行衡量
(1)user – 此次垃圾回收, 垃圾收集线程消耗的所有CPU时间(Total CPU time)
(2)sys – 操作系统调用(OS call) 以及等待系统事件的时间(waiting for system event)
(3)real – 应用程序暂停的时间(Clock time). 由于串行垃圾收集器(Serial Garbage Collector)只会使用单个线程, 所以 real time 等于 user 以及 system time 的总和.

通过上面的分析, 我们可以计算出在垃圾收集期间, JVM 中的内存使用情况。在垃圾收集之前, 堆内存总的使用了 34.125M (34,944K)。其中, 年轻代也是34.125M(34,944K)。可以算出老年代使用的内存为0。

垃圾回收后,年轻带的内存下降了29.8M(30,592K),但总的堆内存使用(total heap usage)只减少了 20.9M(21457k) .通过这一点,我们可以计算出, 有 8.9M(9135K) 的年轻代对象被提升到老年代(Old)中。

这个GC事件可以用下面的示意图来表示, 上方表示GC之前的内存使用情况, 下方表示结束后的内存使用情况:
这里写图片描述

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 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
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值