為什么JVM做這么多垃圾collections

Question

下面是來自 JVM 的jstat output，使用以下參數運行

-Xmx10240m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 

jstat output 是帶參數的

jstat -gcutil <pid> 10s

該部分是一段 80 秒的片段，據統計，其中近 70 秒用於 GC。 它們都是正在觸發的完整 GC。

Timestamp   S0  S1  E       O       P       YGC     YGCT        FGC     FGCT        GCT         Diff
1040430.2   0   0   23.69   24.58   95.03   168048  22187.057   3672    4483.931    26670.988   8.175
1040440.2   0   0   0.1     24.58   95.02   168048  22187.057   3674    4495.551    26682.608   11.62
1040450.2   0   0   4.19    24.59   95.03   168048  22187.057   3677    4506.731    26693.788   11.18
1040460.2   0   0   0.01    24.45   95.02   168048  22187.057   3679    4517.391    26704.448   10.66
1040470.2   0   0   0.33    24.45   95.03   168048  22187.057   3681    4522.213    26709.27    4.822
1040480.2   0   0   0       24.43   95.02   168048  22187.057   3684    4534.816    26721.874   12.604

PermGen 空間幾乎已滿，但我不認為 Sun GC 機制會嘗試在這里收集，我可以看到基於 Eden 或 Old 空間收集的原因。

任何能夠給我一些指示的人都可能會發生什么？

Answer 1

為什么JVM做那么多垃圾collections。

這很可能是因為永久代占用率非常高。 使用 CMS 算法時，僅當老代或永久代占用率超過定義的閾值時，才會啟動主要收集。 除非我弄錯了，否則老年代的默認占用閾值為 68%，這可以使用-XX:CMSInitiatingOccupancyFraction=n標志進行更改。 然而，就所提供的數據而言，這個值似乎並不重要，因為在進行統計時，老一代的占用率似乎低於 25%（這並不意味着老一代在此期間沒有被填滿） ，但當永久代本身表現出更高的占用率時，這是不可能的）。

請注意，默認情況下，CMS 收集器不會從永久代中聲明對象。 這需要打開CMSClassUnloading標志。 如果行為沒有改善，那么很可能永久代的大小不正確，並且必須給它更多的 memory，因為很明顯永久代中只有少數對象有資格在每個主要的收集周期。