Java 如何优化JVM 8 G1参数以避免完全GC（分配失败）

在XMX为8gb的服务器中使用g1gc时，运行几天后会发生完全GC故障

尝试调整jvmgc参数，打印出所有GC细节，但仍然无法确定根本原因

JVM参数：

java -Xms8g -Xmx8g 
-XX:+CrashOnOutOfMemoryError 
-XX:+AlwaysPreTouch 
-XX:-UseBiasedLocking 
-XX:MaxTenuringThreshold=15 
-Xss256k 
-XX:SurvivorRatio=6 
-XX:+UseTLAB 
-XX:GCTimeRatio=4 
-XX:+ScavengeBeforeFullGC 
-XX:G1HeapRegionSize=8M 
-XX:ConcGCThreads=8 
-XX:G1HeapWastePercent=10 
-XX:+AggressiveOpts 
-XX:MaxMetaspaceSize=256m 
-XX:+UseG1GC 
-XX:InitiatingHeapOccupancyPercent=35 
-XX:+DisableExplicitGC 
-Xloggc:/var/tmp/prod/query/Portfolio/PORTFOLIO-QRY-A-Instance1/query-gc.log
-verbose:gc 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+PrintGCTimeStamps 
-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=10 
-XX:GCLogFileSize=100M 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/var/tmp/prod/query/xxx.log-XX:NewSize=3g 
-XX:MaxNewSize=5g 
-server

最后的GC详细信息：

2019-01-25T00:25:28.998+0800:399236.910:[GC暂停（G1疏散 暂停）（年轻）（初始标记）（到空间耗尽），0.3400461秒]
[伊甸园：1080.0M（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆： 8144.0M（8192.0M）->7936.0M（8192.0M）【时间：用户=2.22系统=0.01，实际=0.34秒】2019-01-25T00:25:29.338+0800:399237.251:[GC 并发根区域扫描开始]2019-01-25T00:25:29.338+0800: 399237.251:[GC并发根区域扫描结束，0.0000869秒]2019-01-25T00:25:29.338+0800:399237.251:[GC并发标记开始] 2019-01-25T00:25:29.419+0800:399237.332:[GC暂停（G1疏散 暂停）（年轻）（到空间耗尽），0.2033834秒][伊甸园： 208.0M（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->8144.0M（8192.0M）][时间：用户=0.67 sys=0.02，实数=0.21秒]2019-01-25T00:25:29.624+0800:399237.537:[GC暂停 （G1疏散暂停）（年轻），0.0076649秒][伊甸园： 0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->8144.0M（8192.0M）][次数：用户=0.07系统=0.00，实数=0.01秒]2019-01-25T00:25:29.632+0800:399237.545:[GC暂停 （G1疏散暂停）（年轻），0.0072213秒][伊甸园： 0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->8144.0M（8192.0M）][次数：用户=0.06系统=0.00，实数=0.01秒]2019-01-25T00:25:29.640+0800:399237.553:[GC暂停 （G1疏散暂停）（年轻），0.0032099秒][伊甸园： 0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->8144.0M（8192.0M）][次数：用户=0.02系统=0.01，实值=0.00秒]2019-01-25T00:25:29.645+0800:399237.557:[GC暂停 （G1疏散暂停）（年轻），0.0041076秒][伊甸园： 0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->8144.0M（8192.0M）][时间：用户=0.03系统=0.00秒，实数=0.00秒]2019-01-25T00:25:29.649+0800:399237.562:[GC暂停 （G1疏散暂停）（年轻），0.0027963秒][伊甸园： 0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->8144.0M（8192.0M）][次数：用户=0.01系统=0.00，实数=0.01秒]2019-01-25T00:25:29.653+0800:399237.566:[GC暂停 （G1疏散暂停）（年轻），0.0027614秒][伊甸园： 0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->8144.0M（8192.0M）][时间：用户=0.02系统=0.00秒，实数=0.00秒]2019-01-25T00:25:29.656+0800:399237.569:[完整GC （分配失败）8144M->4016M（8192M），10.6192450秒][伊甸园： 0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->4016.1M（8192.0M）]，[元空间：83995K->83979K（1126400K）][次数：用户=15.73系统=0.00，真实=10.62 秘书]2019-01-25T00:25:40.277+0800:399248.190:[GC] 并发标记中止]堆垃圾第一堆总计8388608K，已使用 4268154K[0x00000005c0000000，0x00000005c0802000，0x00000007c0000000） 区域大小8192K，20个年轻人（163840K），0个幸存者（0K）元空间
使用84034K，容量85146K，承诺86732K，预留1126400K
已使用的类空间8833K，容量9090K，已提交9420K，保留 1048576K

---

我们的服务器是32G 16核心，任何建议都将不胜感激！

这很复杂

在日志中，我发现由于旧一代而导致的完整GC太小

“分配失败”表明直接分配给老一代失败

但是，从日志中，我还发现完整GC之前的次要GC过于频繁，并且释放了一点空间。在25:29.338 25:29.653之间有7个次要GC。只有第一个次要GC释放了一些空间

最糟糕的问题是“[Eden:0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B”。似乎所有对象都是在旧一代中分配的。从日志中”[Eden:0.0B（3072.0M）->0.0B幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->4016.1M（8192.0M）]”，我认为这个完整的GC释放了4000M+的旧代空间。这很奇怪。你的应用程序需要至少4G的旧代，并且旧代中几乎所有的对象都被回收。这意味着旧对象还不够老。它们中的大多数都是提前升级的。或者它们中的大部分都是巨大的对象

我试着给你一些建议

-XX:InitiatingHeapOccupencyPercent=35太小。这会使次要GC更频繁，对象可能会提前升级。因此旧一代很快就会满。您可以将XX:InitiatingHeapOccupencyPercent设置得更大。或者您可以考虑自适应IHOP

老一代太小了。有些应用程序需要比年轻一代多得多的老一代空间。有人说年轻一代空间的两倍或三倍大小比较好

MaxTenuringThreshold=15可以设置为大于20的值。

这很复杂

在日志中，我发现由于旧一代而导致的完整GC太小

“分配失败”表明直接分配给老一代失败

但是，从日志中，我还发现完整GC之前的次要GC过于频繁，并且释放了一点空间。在25:29.338 25:29.653之间有7个次要GC。只有第一个次要GC释放了一些空间

最糟糕的问题是“[Eden:0.0B（3072.0M）->0.0B（3072.0M）幸存者：0.0B->0.0B”。似乎所有对象都是在旧一代中分配的。从日志中”[Eden:0.0B（3072.0M）->0.0B幸存者：0.0B->0.0B堆：8144.0M（8192.0M）->4016.1M（8192.0M）]”，我认为这个完整的GC释放了4000M+的旧代空间。这很奇怪。你的应用程序至少需要4G