java humongous_G1 解决Evacuation Failure和Humongous Allocation

希望您对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)。