日志文件中的部分内容如下:
分析:
让我们来挑几条典型的日志进行分析:
第一条:63.971: [GC (Allocation Failure) [PSYoungGen: 31073K->4210K(38400K)]
31073K->4234K(125952K), 0.0049946 secs] [Times: user=0.05 sys=0.02, real=0.01 secs]
1. 63.971:gc发生时,虚拟机运行了多少秒。
2. GC (Allocation Failure) : 发生了一次垃圾回收,这是一次Minor GC 。注意它不表示只GC新生代,括号里的内容是gc发生的原因,这里的Allocation Failure的原因是年轻代中没有足够区域能够存放需要分配的数据而失败。
3. PSYoungGen: 使用的垃圾收集器的名字。
4. 31073K->4210K(38400K)指的是垃圾收集前->垃圾收集后(年轻代堆总大小)
5. 31073K->4234K(125952K),指的是垃圾收集前后,Java堆的大小(总堆125952K,堆大小包括新生代和年老代)
因此可以计算出年老代占用空间为125952k-38400k = 87552k
6. 0.0049946 secs:整个GC过程持续时间
7. [Times: user=0.05 sys=0.02, real=0.01 secs]分别表示用户态耗时,内核态耗时和总耗时。也是对gc耗时的一个记录。
第二条:106.840: [GC (System.gc()) [PSYoungGen: 130695K->5216K(472576K)] 228903K->121835K(644608K), 0.0342911 secs] [Times: user=0.13 sys=0.00, real=0.03 secs]
先对于第一条的(Allocation Failure) 变成了(System.gc()),说明这是一次成功的垃圾回收。
第三条:83.783: [Full GC (System.gc()) [PSYoungGen: 15361K->0K(372224K)] [ParOldGen: 83468K->98200K(172032K)] 98829K->98200K(544256K), [Metaspace: 9989K->9989K(1058816K)], 0.3036213 secs] [Times: user=1.03 sys=0.00, real=0.30 secs]
对于Full GC:
1 [PSYoungGen: 15361K->0K(372224K)] :年轻代:垃圾收集前->垃圾收集后(年轻代堆总大小)
2 [ParOldGen: 83468K->98200K(172032K)] :年老代:垃圾收集前->垃圾收集后(年老代堆总大小)
3 98829K->98200K(544256K), :垃圾收集前->垃圾收集后(总堆大小)
4 [[Metaspace: 9989K->9989K(1058816K)], Metaspace空间信息,同上
5 0.3036213 secs:整个GC过程持续时间
6 [Times: user=1.03 sys=0.00, real=0.30 secs] 分别表示用户态耗时,内核态耗时和总耗时。也是对gc耗时的一个记录。
第四条:71.601: [Full GC (Ergonomics) [PSYoungGen: 20555K->0K(367616K)] [ParOldGen: 104080K->83460K(172032K)] 124636K->83460K(539648K), [Metaspace: 9959K->9959K(1058816K)], 0.2146493 secs] [Times: user=0.64 sys=0.00, real=0.21 secs]
这里可以到full gc的reason是Ergonomics,是因为开启了UseAdaptiveSizePolicy,jvm自己进行自适应调整引发的full gc。
对于底下Heap的输出情况,和上面是完全一致的。
只是增加了堆中每个部分total总大小,used使用情况。
PSYoungGen分为eden space 530336K, 3% used , from space 48128K, 0% used , to space 47104K, 0% used三个部分,分别显示了它们的大小和used比例。
ParOldGen分为object space246784K, 1% used,显示了其大小和used比例。
Metaspace中used大小为10174k。
解决方式:直接修改配置参数 -Xmn2g (这里需要根据需求来设置)