需要根據

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%

，

總結

以上是生活随笔為你收集整理的gc日志一般关注什么_GC日志说明的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。