需要根據(jù)

GC

詳細

日志

來調(diào)整參數(shù)的

設(shè)置

，那么當(dāng)我們收集到日志后

如何分析，如何根據(jù)日志的情況來調(diào)整參數(shù)？這就是本文所要闡述的。

使用

IBM

的

JDK

的

Windows

平臺

和

AIX

平臺，

我們只要在

WebSphere

管理

控

制臺的

java

進程屬性里勾選“詳細垃圾回收”，

那么就會在

native_stdout.log

中生成如下的信息。

這幅圖很形象的給出了

gc

日志的主要關(guān)注點：垃圾回收的原因、垃圾回收

的間隔、垃圾回收前后的剩余空間、垃圾回收持續(xù)的時間??

“nursery”表示這次分配失敗(

Allocation?Failure

)發(fā)生在新生代

(

nursery

)

，

是第

44

次

(

id=44

)

因為新生代的分配失敗而進行垃圾回收了

(開

啟

GC

日志以來)，離上一次發(fā)生

GC

的間隔是

12746ms

，無法分配的空間大小是

8216Byte

，

而進行垃圾回收前，

新生代的可用空間為

1776Byte

，

小于

8216Byte

，

雖然年老區(qū)還剩余

45%

的空間，但是新的

內(nèi)存

空間是無法直接在年老區(qū)分配的，

由此引發(fā)了一次清理過程(

scavenger

)。

GC?type

表明了這次垃圾回收是一個清理過程，也是第

44

次

scavenger

過

程，同時恰是第

44

個

gc

過程，說明沒有發(fā)生過諸如

type=”global”>

的垃

圾回收過程。

flipped

objectcount

說明將要把

4523143

個存活下來的對象被復(fù)

制到了幸存區(qū)(

survivor?space

)，而

73768

個對象則經(jīng)過多次幸存區(qū)的復(fù)制，

有幸熬出頭，被轉(zhuǎn)移到了長存區(qū)(

tenured?space

)。我們看到清理的傾斜比率

(

scavenger

tiltratio

)為

89%

，而不是對半開，說明經(jīng)過多次復(fù)制清理，

JVM

已經(jīng)意識到每次只有很少的對象能存活下來，于是它自動增大了年輕代中

Eden

區(qū)的大小，以使得為新對象可以騰出更多的內(nèi)存。

接下來的就比較簡單，經(jīng)過垃圾回收，新生代的空間剩余

89%

，因為分配失

敗發(fā)生在新生代，

進行的是快速的

Minor

gc

，

所以長存區(qū)的可用空間依然是

45%

，

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。