?希望您對G1有所了解。在jdk8中，我們很多會使用G1垃圾收集器，她是目前唯一跨越年輕代和年老代的垃圾收集器。里面有一個混合垃圾收集，可以清理全部的年輕代和部分年老代。G1里面東西還有很多，希望讀者有一定的基礎，下面我們來說說gc日志中常出現的兩個組詞：Evacuation Failure和Humongous Allocation。為什么只說這兩個呢？很簡單，因為它們耗時多！直接關系到系統性能。

Evacuation Failure
???當沒有更多的空閑region被提升到老一代或者復制到幸存空間時，并且由于堆已經達到最大值，堆不能擴展，從而發生Evacuation Failure。對于G1 GC，它是非常耗時的。?

?a.對于成功復制的對象，G1需要更新引用，并且該region被一直引用。

?b.對于未成功復制的對象，G1將自動轉發它們，并保留這些region。

解決方案：

①.不要過度加一些jvm參數。比如-Xmn,這個參數會限制G1的參數的自動擴展。可以僅使用-Xms，-Xmx和暫停時間目標-XX：MaxGCPauseMillis，刪除任何額外的堆大小，例如-Xmn，-XX：NewSize，-XX：MaxNewSize，-XX：SurvivorRatio等。

②.如果問題仍然存在，則增加JVM堆大小（即-Xmx）。

③.如果您無法增加堆大小，并且您注意到marking cycle沒有足夠早地開始回收老一代，那么請減少-XX：InitiatingHeapOccupancyPercent。默認值是45％。減小該值將提前開始marking cycle?。另一方面，如果marking cycle?提前開始并且未收回，請將-XX：InitiatingHeapOccupancyPercent閾值增加到默認值以上。

④.如果并發marking cycle準時開始，但需要很長時間才能完成，那么使用屬性'-XX：ConcGCThreads'增加并發標記線程數的數量。默認是GC Workers: 1 ，單線程執行。

⑤.如果有大量“空間耗盡（to-space exhausted）”或“空間溢出（to-space overflow）”GC事件，則增加-XX:G1ReservePercent。默認值是Java堆的10％。注意：G1 GC將此值限制在50％以內。

Humongous Allocation
???它是由'G1 Humongous Allocation'造成的。大型對象（Humongous?）是大于G1中region大小50％的對象。頻繁大型對象分配會導致性能問題。如果region里面包含大量的大型對象，則該region中最后一個具有巨型對象的區域與區域末端之間的空間將不會使用。如果有多個這樣的大型對象，這個未使用的空間可能導致堆碎片化。直到jdk1.8u40之前，這些巨型對象的回收只在full GC期間完成。在較新的JVM中，對這些對象的清理放在了清理階段。

解決方案：

①.可以加大region的大小，設置-XX:G1HeapRegionSize=n，但是這個參數需要設置為2的冪次方，最小值是1M，做大值是32M。

②.如果可以的話增加JVM堆大小（即-Xmx -Xms）。
---------------------?

總結

以上是生活随笔為你收集整理的G1 解决Evacuation Failure和Humongous Allocation的全部內容，希望文章能夠幫你解決所遇到的問題。

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