Java GC(分配失败)

use*_*708 112 java garbage-collection

为什么总是"GC(分配失败)"?

用于linux-amd64 JRE(1.8.0_25 -b17)的Java HotSpot(TM)64位服务器VM(25.25- b02),

CommandLine flags: 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:GCLogFileSize=10485760 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:InitialHeapSize=32212254720 
-XX:MaxHeapSize=32212254720 
-XX:NewRatio=10 
-XX:OldPLABSize=16 
-XX:ParallelGCThreads=4 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintStringTableStatistics 
-XX:+PrintTenuringDistribution 
-XX:StringTableSize=1000003 
-XX:SurvivorRatio=4 
-XX:TargetSurvivorRatio=50 
-XX:+UseCompressedClassPointers 
-XX:+UseCompressedOops
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC
Run Code Online (Sandbox Code Playgroud)
27.329: [GC (Allocation Failure) 27.329: [ParNew
Desired survivor size 44728320 bytes, new threshold 15 (max 15)
- age   1:   16885304 bytes,   16885304 total
: 349568K->16618K(436928K), 0.2069129 secs] 349568K->16618K(31369920K), 0.2070712 secs] [Times: user=0.78 sys=0.04, real=0.21 secs]


28.210: [GC (Allocation Failure) 28.210: [ParNew
Desired survivor size 44728320 bytes, new threshold 15 (max 15)
- age   1:   28866504 bytes,   28866504 total
- age   2:   12582536 bytes,   41449040 total
: 366186K->47987K(436928K), 0.2144807 secs] 366186K->47987K(31369920K), 0.2146024 secs] [Times: user=0.84 sys=0.01, real=0.22 secs]


29.037: [GC (Allocation Failure) 29.038: [ParNew
Desired survivor size 44728320 bytes, new threshold 2 (max 15)
- age   1:   28443488 bytes,   28443488 total
- age   2:   28386624 bytes,   56830112 total
- age   3:   12579928 bytes,   69410040 total
: 397555K->76018K(436928K), 0.2357352 secs] 397555K->76018K(31369920K), 0.2358535 secs] [Times: user=0.93 sys=0.01, real=0.23 secs]
Run Code Online (Sandbox Code Playgroud)

Ale*_*zin 186

"分配失败"是导致GC循环的原因.

"分配失败"意味着Eden中没有剩余空间来分配对象.因此,这是年轻GC的正常原因.

较旧的JVM没有打印GC导致较小的GC循环.

"分配失败"几乎只是导致次要GC的可能原因.轻微GC启动的另一个原因可能是CMS备注阶段(如果+XX:+ScavengeBeforeRemark已启用).

  • 对于每天通常会发生多次的事件,GC(分配失败)是一个糟糕的单词选择.那些JVM工程师应该更频繁地出去,并尝试在现实世界中进行社交,这样他们就可以学到更多人们理解的友好术语. (156认同)
  • @SalvadorValencia没关系,定期阅读GC日志的人也不是"正常".:) (66认同)
  • 是的,这是正常行为 (6认同)
  • @SalvadorValencia,不管你信不信。如果他们能够社交,他们就永远不会接触 GC。 (3认同)
  • 我没有完全得到这个答案,所以是否应该避免?"这是年轻GC的正常原因".那么年轻的GC是错误的选择吗? (2认同)

小智 7

“分配失败”是GC踢不正确的原因。这是GC操作的结果。

当没有空间可分配时,GC将启动(取决于执行次要或主要GC的区域)。一旦执行了GC,如果释放的空间足够好,但是如果空间不足,那么它将失败。分配失败就是这样的失败之一。下面的文件有很好的解释 https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html

  • “(...) 然后发生分配失败(因为没有空间从被疏散的区域分配活动对象)并且停止世界(STW)完整收集完成。” - 在 java 1.8 服务器模式下,我复制了一个短暂的停顿,并将这两个跟踪打印在一起:[GC (Allocation Failure) 2287742K->1148645K(2633216K), 0.4571912 secs] [Full GC (Ergonomics) 15K-4116K (3184128K),2.8563984 秒]。所以我赞成你的回答;-) (2认同)