gc日志一般关注什么_GC日志说明

需要根据

GC

详细

日志

来调整参数的

设置

，那么当我们收集到日志后

如何分析，如何根据日志的情况来调整参数？这就是本文所要阐述的。

使用

IBM

的

JDK

的

Windows

平台

和

AIX

平台，

我们只要在

WebSphere

管理

控

制台的

java

进程属性里勾选“详细垃圾回收”，

那么就会在

native_stdout.log

中生成如下的信息。

这幅图很形象的给出了

gc

日志的主要关注点：垃圾回收的原因、垃圾回收

的间隔、垃圾回收前后的剩余空间、垃圾回收持续的时间„„

“nursery”表示这次分配失败(

Allocation Failure

)发生在新生代

(

nursery

)

，

是第

44

次

(

id=44

)

因为新生代的分配失败而进行垃圾回收了

(开

启

GC

日志以来)，离上一次发生

GC

的间隔是

12746ms

，无法分配的空间大小是

8216Byte

，

而进行垃圾回收前，

新生代的可用空间为

1776Byte

，

小于

8216Byte

，

虽然年老区还剩余

45%

的空间，但是新的

内存

空间是无法直接在年老区分配的，

由此引发了一次清理过程(

scavenger

)。

GC type

表明了这次垃圾回收是一个清理过程，也是第

44

次

scavenger

过

程，同时恰是第

44

个

gc

过程，说明没有发生过诸如

type=”global”>

的垃

圾回收过程。

flipped

objectcount

说明将要把

4523143

个存活下来的对象被复

制到了幸存区(

survivor space

)，而

73768

个对象则经过多次幸存区的复制，

有幸熬出头，被转移到了长存区(

tenured space

)。我们看到清理的倾斜比率

(

scavenger

tiltratio

)为

89%

，而不是对半开，说明经过多次复制清理，

JVM

已经意识到每次只有很少的对象能存活下来，于是它自动增大了年轻代中

Eden

区的大小，以使得为新对象可以腾出更多的内存。

接下来的就比较简单，经过垃圾回收，新生代的空间剩余

89%

，因为分配失

败发生在新生代，

进行的是快速的

Minor

gc

，

所以长存区的可用空间依然是

45%

，