Java 为什么在内存耗尽之前会发生完全GC？

在JVM 8中使用G1GC时，在内存耗尽之前会发生完全GC（分配失败）。它每30分钟出现一次，每次它停止应用程序6-10秒，大约300-500个请求超时失败，这对我来说很糟糕

我不明白为什么会发生

[完全GC（分配失败）16G->13G（20G），8.9794231秒]

<代码>分配请求：304字节，但堆实际上还有4G空间，为什么不能分配

我怀疑这是一个碎片问题，但我不知道如何验证。欢迎使用任何验证方法

最后一个完整的GC详细信息是：

2019-12-11T18:42:12.687+0800: 1312029.392: [GC pause (G1 Evacuation Pause) (young) (initial-mark)
Desired survivor size 67108864 bytes, new threshold 3 (max 3)
 1312029.393: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 37379, predicted base time: 20.39 ms, remaining time: 69.61 ms, target pause time: 90.00 ms]
 1312029.393: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 0 regions, survivors: 0 regions, predicted young region time: 0.00 ms]
 1312029.393: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 0 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 20.39 ms, target pause time: 90.00 ms]
, 0.0180293 secs]
   [Parallel Time: 12.8 ms, GC Workers: 16]
      [GC Worker Start (ms): Min: 1312029393.4, Avg: 1312029393.5, Max: 1312029393.6, Diff: 0.2]
      [Ext Root Scanning (ms): Min: 3.1, Avg: 3.9, Max: 11.9, Diff: 8.8, Sum: 62.0]
      [Update RS (ms): Min: 0.0, Avg: 5.0, Max: 6.1, Diff: 6.1, Sum: 80.2]
         [Processed Buffers: Min: 0, Avg: 9.2, Max: 14, Diff: 14, Sum: 148]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 0.2, Avg: 0.3, Max: 0.5, Diff: 0.3, Sum: 5.0]
      [Termination (ms): Min: 0.0, Avg: 3.3, Max: 3.8, Diff: 3.8, Sum: 52.4]
         [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 16]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.2]
      [GC Worker Total (ms): Min: 12.4, Avg: 12.5, Max: 12.6, Diff: 0.2, Sum: 199.9]
      [GC Worker End (ms): Min: 1312029406.0, Avg: 1312029406.0, Max: 1312029406.0, Diff: 0.0]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.2 ms]
   [Other: 5.0 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 2.4 ms]
      [Ref Enq: 0.2 ms]
      [Redirty Cards: 0.2 ms]
      [Humongous Register: 0.4 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.0 ms]
   [Eden: 0.0B(1024.0M)->0.0B(1024.0M) Survivors: 0.0B->0.0B Heap: 16.4G(20.0G)->16.4G(20.0G)]
Heap after GC invocations=452782 (full 1):
 garbage-first heap   total 20971520K, used 17217092K [0x00000002c0000000, 0x00000002c2001400, 0x00000007c0000000)
  region size 32768K, 0 young (0K), 0 survivors (0K)
 Metaspace       used 60984K, capacity 61408K, committed 62156K, reserved 1105920K
  class space    used 6123K, capacity 6258K, committed 6400K, reserved 1048576K
}
 [Times: user=0.00 sys=0.00, real=0.01 secs]
2019-12-11T18:42:12.705+0800: 1312029.411: [GC concurrent-root-region-scan-start]
2019-12-11T18:42:12.705+0800: 1312029.411: [GC concurrent-root-region-scan-end, 0.0000510 secs]
2019-12-11T18:42:12.705+0800: 1312029.411: [GC concurrent-mark-start]
2019-12-11T18:42:12.705+0800: 1312029.411: Total time for which application threads were stopped: 0.0282629 seconds, Stopping threads took: 0.0003029 seconds
2019-12-11T18:42:12.706+0800: 1312029.412: Application time: 0.0009042 seconds
 1312029.419: [G1Ergonomics (Heap Sizing) attempt heap expansion, reason: allocation request failed, allocation request: 304 bytes]
 1312029.419: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 33554432 bytes, attempted expansion amount: 33554432 bytes]
 1312029.419: [G1Ergonomics (Heap Sizing) did not expand the heap, reason: heap already fully expanded]
{Heap before GC invocations=452782 (full 1):
 garbage-first heap   total 20971520K, used 17217092K [0x00000002c0000000, 0x00000002c2001400, 0x00000007c0000000)
  region size 32768K, 0 young (0K), 0 survivors (0K)
 Metaspace       used 60984K, capacity 61408K, committed 62156K, reserved 1105920K
  class space    used 6123K, capacity 6258K, committed 6400K, reserved 1048576K
2019-12-11T18:42:12.714+0800: 1312029.420: [Full GC (Allocation Failure)  16G->13G(20G), 8.9794231 secs]
   [Eden: 0.0B(1024.0M)->0.0B(1248.0M) Survivors: 0.0B->0.0B Heap: 16.4G(20.0G)->13.1G(20.0G)], [Metaspace: 60984K->60984K(1105920K)]
Heap after GC invocations=452783 (full 2):
 garbage-first heap   total 20971520K, used 13750684K [0x00000002c0000000, 0x00000002c2001400, 0x00000007c0000000)
  region size 32768K, 0 young (0K), 0 survivors (0K)
 Metaspace       used 60984K, capacity 61408K, committed 62156K, reserved 1105920K
  class space    used 6123K, capacity 6258K, committed 6400K, reserved 1048576K
}
 [Times: user=6.25 sys=2.34, real=8.98 secs]
2019-12-11T18:42:21.694+0800: 1312038.400: Total time for which application threads were stopped: 8.9877650 seconds, Stopping threads took: 0.0001943 seconds
2019-12-11T18:42:21.695+0800: 1312038.400: [GC concurrent-mark-abort]
2019-12-11T18:42:21.931+0800: 1312038.637: Application time: 0.2366224 seconds
{Heap before GC invocations=452783 (full 2):
 garbage-first heap   total 20971520K, used 15028636K [0x00000002c0000000, 0x00000002c2001400, 0x00000007c0000000)
  region size 32768K, 39 young (1277952K), 0 survivors (0K)
 Metaspace       used 60984K, capacity 61408K, committed 62156K, reserved 1105920K
  class space    used 6123K, capacity 6258K, committed 6400K, reserved 1048576K

JVM GC参数：

     -XX:+UseG1GC
     -Xmx20480m
     -XX:+UnlockExperimentalVMOptions

     -XX:MaxGCPauseMillis=90
     -XX:ConcGCThreads=4
     -XX:ParallelGCThreads=16
     -XX:MaxTenuringThreshold=3
     -XX:G1HeapRegionSize=32m
     -XX:InitiatingHeapOccupancyPercent=70
     -XX:G1NewSizePercent=5
     -XX:G1MaxNewSizePercent=30
     -XX:G1MixedGCCountTarget=16
     -XX:G1OldCSetRegionThresholdPercent=3
     -XX:G1HeapWastePercent=15

设置此参数的原因：
1.IHOP是70%，因为我的程序中有很多缓存和请求（大约65%）
2.MaxNewSizePercent可以更小，但不应导致完全gc
3. -XX:G1MixedAccountTarget和-XX:G1OldCsetRegionsHoldPercent的组合效应是，在一个混合GC中发生16个集合，每次600M，考虑到驻留内存为13G，每次9.6G是一个可接受的数字
4.和-XX:G1HeapWastePercent是15%，实际上这也让我感到困扰，在我的过程中有许多大型对象（超过16M），所以我设置它的唯一原因是避免过于频繁地混合gc

---

但我无法从上面的论证中找到这个完整gc发生的原因。任何意见或建议将不胜感激

您希望它只是抛出一个

OutOfMemoryError

吗？垃圾收集器收集垃圾，它就是这样做的。我不明白在这种情况下，这是一个为什么或如何的问题。你认为它的行为应该有所不同吗？如果是这样的话：您希望它表现如何？既然您说过“任何建议或建议都将非常感谢”，那么我的建议是：删除所有您不了解的JVM选项。@JoachimSauer我的意思是堆实际上仍然有4G空间，为什么不能分配它？在我的理解中，由于G1中的内存碎片，没有完整的GC，所以我不知道为什么。事实上，我有5台机器运行相同的进程，它们的写流量（50MB/s）大致相同，但其中只有一台有这个问题，可能是QPS造成的王: 所有这些都是很好的细节，你可能应该把它们放在问题中，以便人们理解上下文。就目前而言，它看起来像“它正在进行垃圾收集，我该如何阻止它”（这是一个没有必要上下文的愚蠢问题）。