java 95连续完整地面军事系统，但无OOM。怎么会这样？

Question

我正在对一个Java web应用程序进行故障排除，该应用程序运行了一段时间后，堆突然增加到100%，这导致连续的完整GCs，几乎没有清除旧的gen。但是，这不会导致OOM包含通常的java.lang.OutOfMemoryError: GC overhead limit exceeded消息。 这怎么可能

以下是6个完整的GC条目：

gc_20180423_1443.log.11.current:37491:2018-05-01T09:10:52.156+0000: 671212.664: [Full GC (Allocation Failure) 2018-05-01T09:10:52.156+0000: 671212.664: [CMS: 7077887K->7077887K(7077888K), 28.6425809 secs] 9043967K->9043787K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 28.6428227 secs] [Times: user=28.63 sys=0.00, real=28.64 secs]
gc_20180423_1443.log.11.current:37510:2018-05-01T09:11:20.803+0000: 671241.311: [Full GC (Allocation Failure) 2018-05-01T09:11:20.803+0000: 671241.311: [CMS: 7077887K->7077888K(7077888K), 42.8881300 secs] 9043964K->9043856K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 42.8883826 secs] [Times: user=42.85 sys=0.01, real=42.89 secs]
gc_20180423_1443.log.11.current:37529:2018-05-01T09:12:03.694+0000: 671284.201: [Full GC (Allocation Failure) 2018-05-01T09:12:03.694+0000: 671284.201: [CMS: 7077888K->7077888K(7077888K), 28.8305893 secs] 9043959K->9043845K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 28.8308264 secs] [Times: user=28.83 sys=0.01, real=28.83 secs]
gc_20180423_1443.log.11.current:37548:2018-05-01T09:12:32.527+0000: 671313.035: [Full GC (Allocation Failure) 2018-05-01T09:12:32.527+0000: 671313.035: [CMS: 7077888K->7077887K(7077888K), 34.2235811 secs] 9043967K->9043802K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 34.2238304 secs] [Times: user=34.22 sys=0.00, real=34.23 secs]
gc_20180423_1443.log.11.current:37567:2018-05-01T09:13:06.754+0000: 671347.261: [Full GC (Allocation Failure) 2018-05-01T09:13:06.754+0000: 671347.262: [CMS: 7077887K->7077887K(7077888K), 30.2722671 secs] 9043966K->9043854K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 30.2725042 secs] [Times: user=30.27 sys=0.00, real=30.27 secs]
gc_20180423_1443.log.11.current:37586:2018-05-01T09:13:37.028+0000: 671377.536: [Full GC (Allocation Failure) 2018-05-01T09:13:37.028+0000: 671377.536: [CMS: 7077887K->7077887K(7077888K), 35.6276778 secs] 9043955K->9043843K(9043968K), [Metaspace: 75140K->75140K(1118208K)], 35.6278998 secs] [Times: user=35.61 sys=0.01, real=35.63 secs]

根据我的计算，基于这6条记录的总持续时间为164.872秒，其中GC占164.8583663秒，相当于GC中99.99%的时间。 给定9043968K的总堆数，将2%的堆数增加到180879.36K

在这5次执行中，从日志中清除的总堆数为679K（跨调用），远低于2%，但没有抛出OOM

尚未使用-XX:-UseGCOverheadLimit标志

以下是GC参数的列表：

CommandLine flags: -XX:CICompilerCount=4 
-XX:CMSInitiatingOccupancyFraction=50 -XX:CMSMaxAbortablePrecleanTime=6000 
-XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark
-XX:ConcGCThreads=4 -XX:+CrashOnOutOfMemoryError -XX:GCLogFileSize=10485760 
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/WORK/log/solr/solr.hprof 
-XX:InitialHeapSize=9663676416 -XX:LogFile=/WORK/log/solr/vm.log -XX:+LogVMOutput 
-XX:MaxHeapSize=9663676416 -XX:MaxNewSize=2415919104 -XX:MaxTenuringThreshold=8 
-XX:MinHeapDeltaBytes=196608 -XX:NewRatio=3 -XX:NewSize=2415919104
-XX:NumberOfGCLogFiles=20 -XX:OldPLABSize=16 -XX:OldSize=7247757312
-XX:OnOutOfMemoryError=/WORK/bin/oom.sh solr -XX:ParallelGCThreads=4
-XX:+ParallelRefProcEnabled -XX:PretenureSizeThreshold=67108864 -XX:+PrintGC 
-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1 -XX:+PrintTenuringDistribution
-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=500 -XX:SurvivorRatio=4
-XX:TargetSurvivorRatio=90 -XX:ThreadStackSize=256 
-XX:+UnlockDiagnosticVMOptions -XX:-UseBiasedLocking 
-XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedClassPointers
-XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseGCLogFileRotation
-XX:+UseParNewGC 

JDK版本是openjdk-1.8.0_151

如果您在我的计算或我对java.lang.OutOfMemoryError: GC overhead limit exceeded规则的理解中发现错误，请告诉我，当超过98%的总时间用于垃圾收集，而堆的恢复率低于2%时，会抛出错误

非常感谢任何指点。谢谢