JVM G1GC的混合gc沒有收集太多舊區域

Question

我的服務器在CentOS 6.7上使用1.8.0_92，GC參數是'-Xms16g -Xmx16g -XX：+ UseG1GC'。 所以默認的InitiatingHeapOccupancyPercent是45，G1HeapWastePercent是5，而G1MixedGCLiveThresholdPercent是85.我的服務器的混合GC從7.2GB開始，但它越來越少，最后老一代保持大於7.2GB，所以它總是嘗試做並發標記。 最后所有堆都耗盡並且發生了完整的GC。 完全GC后，使用的舊版本低於500MB。

我很好奇為什么我的混合GC不能收集更多，看起來像實時數據不是那么多......

我曾嘗試打印g1相關信息，並發現許多消息如下，看起來我的舊版本包含很多實時數據，但為什么完整的GC可以收集這么多......

G1Ergonomics (Mixed GCs) do not continue mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 190 regions, reclaimable: 856223240 bytes (4.98 %),  threshold: 5.00 %

以下日志是將InitiatingHeapOccupancyPercent修改為15（啟動並發標記為2.4GB）以加快速度的結果。

### PHASE Post-Marking
......
### SUMMARY  capacity: 16384.00 MB  used: 2918.42 MB / 17.81 %  prev-live: 2407.92 MB / 14.70 %  next-live: 2395.00 MB / 14.62 %  remset: 56.66 MB  code-roots: 0.91 MB
### PHASE Post-Sorting
....
### SUMMARY  capacity: 1624.00 MB  used: 1624.00 MB / 100.00 %  prev-live: 1123.70 MB / 69.19 %  next-live: 0.00 MB / 0.00 %  remset: 35.90 MB  code-roots: 0.89 MB

編輯：

我嘗試在混合GC后觸發完整的GC，它仍然可以減少到4xx MB，所以看起來我的舊版有更多的數據可以收集。

在完全gc之前，混合的gc日志是

 32654.979: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 457 regions, reclaimable: 2956666176 bytes (17.21 %), threshold: 5.00 %], 0.1106810 secs]
 ....
 [Eden: 6680.0M(6680.0M)->0.0B(536.0M) Survivors: 344.0M->280.0M Heap: 14.0G(16.0G)->7606.6M(16.0G)]
 [Times: user=2.31 sys=0.01, real=0.11 secs]
 ...
 [GC pause (G1 Evacuation Pause) (mixed)
 ...
 32656.876: [G1Ergonomics (CSet Construction) finish adding old regions to CSet, reason: old CSet region num reached max, old: 205 regions, max: 205 regions]
 32656.876: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 67 regions, survivors: 35 regions, old: 205 regions, predicted pause time: 173.84 ms, target pause time: 200.00 ms]
 32656.992: [G1Ergonomics (Mixed GCs) continue mixed GCs, reason: candidate old regions available, candidate old regions: 252 regions, reclaimable: 1321193600 bytes (7.69 %), threshold: 5.00 %]
 [Eden: 536.0M(536.0M)->0.0B(720.0M) Survivors: 280.0M->96.0M Heap: 8142.6M(16.0G)->6029.9M(16.0G)]
 [Times: user=2.49 sys=0.01, real=0.12 secs]
 ...
 [GC pause (G1 Evacuation Pause) (mixed)
 ...
 32659.727: [G1Ergonomics (CSet Construction) finish adding old regions to CSet, reason: reclaimable percentage not over threshold, old: 66 regions, max: 205 regions, reclaimable: 857822432 bytes (4.99 %), threshold: 5.00 %]
 32659.727: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 90 regions, survivors: 12 regions, old: 66 regions, predicted pause time: 120.51 ms, target pause time: 200.00 ms]
 32659.785: [G1Ergonomics (Mixed GCs) do not continue mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 186 regions, reclaimable: 857822432 bytes (4.99 %), threshold: 5.00 %]
 [Eden: 720.0M(720.0M)->0.0B(9064.0M) Survivors: 96.0M->64.0M Heap: 6749.9M(16.0G)->5572.0M(16.0G)]
 [Times: user=1.20 sys=0.00, real=0.06 secs]

編輯： 2016/12/11

我用-Xmx4G從另一台機器上轉儲了堆。

我使用萵苣作為我的redis客戶端，它使用LatencyUtils進行跟蹤。 它使LatencyStats（其中包含一些具有近3000個元素的long[] ）實例每10分鍾被弱化一次（默認情況下，發布后的重置延遲為真， https：//github.com/mp911de/lettuce/wiki/Command-Latency-Metrics ）。 所以它會在很長一段時間后對LatencyStats進行大量的弱引用。

在Full GC之前。

完全GC后。

目前我不需要從生菜跟蹤，所以只需禁用它，它就不再有完整的GC了。 但不確定為什么混合gc不會清除它們。

Answer 1

好吧，你沒有提到你設定的所有論點，但是

你可以嘗試設置

-XX:+ScavengeBeforeFullGC

你還應該考慮你的Object的生命周期。 多長時間做你的應用程序Object小號生活，什么大小的Object秒。

想一想，看看下面的論點

-XX:NewRatio=n              old/new ration (default 2)
-XX:SurvivorRatio=n         eden/survivor ratio (default 8)
-XX:MaxTenuringThreshold=n  number of times, objects are moved from survivor one to survivor two and vice versa before objects are moved to old-gen (default 15)

默認值Xms和Xmx設置為32gb - > old gen = 16gb和new gen 16gb - > eden 14gb - >幸存者2gb（有兩個，每個大小為1gb）

伊甸包含所有Object由實例化小號new Object 。

一名幸存者（幸存者）總是空着的。 其他的（來自幸存者）包含在較小的gc中存活的Object

幸存的來自伊甸園的Object和來自幸存者的Object進入未成年人的幸存者

如果這個'default-configuration'的1gb的標准大小超過，則Object進入old-gen

如果它沒有超過15個次要gc（ -XX:MaxTenuringThreshold的默認值），則Object進入舊版本

通過調整這些值，總是要記住，老一代必須與新一代一樣大或大，導致一個gc可以導致整個新一代進入老一代

編輯

你的第一張“老一代：用過的”圖片的時間表會有所幫助

請記住，在老一代不超過之前不需要做一個完整的gc - 一個完整的gc導致整個“世界”停止一段時間

在這種特殊情況下，我會說你可以

1. 將-Xms和-Xmx減少到8gb
2. 設置/減少-XX:SurvivorRatio的值為2
3. 設置/增加-XX:MaxTenuringThreshold為50

你會得到一個新老一代，每個4gb，

伊甸園大小為2gb，

兩名幸存者，每人1gb，

在Object進入舊世代之前，大約有50個小gc