在Java启动参数中加上 -Xloggc:log/gc.log -XX:+PrintGCDetails 就能生成gc日志,并保存在gc.log文件中。下面是我测试产生的gc日志
622.672: [GC 622.672: [DefNew: 90476K->16000K(144128K), 3.9711810 secs] 282557K->281543K(464264K), 3.9712800 secs] [Times: user=0.12 sys=1.15, real=1.29 secs]
629.652: [GC 629.652: [DefNew (promotion failed) : 144128K->144128K(144128K), 4.9220850 secs]634.574: [Tenured: 349568K->349567K(349568K), 1.7061220 secs] 409671K->350921K(493696K), [Perm : 88800K->88800K(131072K)], 6.6290260 secs] [Times: user=2.16 sys=1.43, real=4.69 secs]
636.790: [Full GC 636.790: [Tenured: 349567K->312198K(349568K), 2.3567650 secs] 506815K->450686K(506816K), [Perm : 88801K->87704K(131072K)], 2.3568620 secs] [Times: user=2.19 sys=0.01, real=2.23 secs]
第一行指GC将已使用堆内存从282557K降到281543K,释放464264K,持续时间 3.9712800s。其中DefNew所用的堆空间从90476K降到16000K。
“Times”部分包含了GC所使用的CPU时间信息,分别为操作系统的用户空间和系统空间所使用的时间。同时,它显示了GC运行的“真实”时间 。如果CPU时间明显多于”真实“时间,我们可 以得出结论:GC使用了多线程运行。这样的话CPU时间就是所有GC线程所花费的CPU时间的总和。实际上我们的例子中的垃圾收集器使用了8个线程。
其中的DefNew 、Tenured、Perm 解释如下:
DefNew(年轻代)
年轻代分三个区。一个Eden区,两个Survivor区。大部分对象在Eden区中生成。当Eden区满时,还存活的对象将被复制到Survivor区(两个中的一个),当这个Survivor区满时,此区的存活对象将被复制到另外一个Survivor区,当这个Survivor去也满了的时候,从第一个Survivor区复制过来的并且此时还存活的对象,将被复制“年老区(Tenured)”。需要注意,Survivor的两个区是对称的,没先后关系,所以同一个区中可能同时存在从Eden复制过来对象,和从前一个Survivor复制过来的对象,而复制到年老区的只有从第一个Survivor去过来的对象。而且,Survivor区总有一个是空 的。
Tenured(年老代)
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
Perm(持久代)
用于存放静态文件,如今Java类、方法等。持久代对垃圾回收没有显著影响,但是有些应用可能动态生成或者调用一些class,例如Hibernate等,在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置。
promotion failed指放弃gc转而full gc。
使用gc日志分析工具可以更直观地看到gc的情况。
用IBM Pattern Modeling and Analysis Tool for Java Garbage Collector打开日志文件,
table view视图如下,可以很清楚地观察每一次gc之后内存变化
graphic view视图如下,显示gc的曲线走势,还可以通过勾选右侧不同的区间区域观察走势图