Java GC (échec d'allocation)

Pourquoi toujours "GC (Allocation Failure)"?

VM serveur 64 bits Java HotSpot (TM) (25.25-b02) pour linux-amd64 JRE ( 1.8.0_25 -b17),

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

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]

«L'échec d'allocation» est une cause de démarrage du cycle GC.

«Échec d'allocation» signifie qu'il ne reste plus d'espace dans Eden pour allouer l'objet. Donc, c'est une cause normale de jeune GC.

Les JVM plus anciens n'imprimaient pas la cause GC pour les cycles GC mineurs.

«Échec d'allocation» est presque uniquement la cause possible d'un GC mineur. Une autre raison pour laquelle le GC mineur se déclenche pourrait être la phase de remarque du CMS (si elle +XX:+ScavengeBeforeRemarkest activée).

«Échec d'allocation» est la cause du coup de pied du GC n'est pas correct. C'est le résultat du fonctionnement du GC.

Le GC entre en jeu lorsqu'il n'y a pas d'espace à allouer (selon la région, le GC mineur ou majeur est effectué). Une fois que GC est effectué si l'espace est suffisamment libéré, mais s'il n'y a pas assez de taille, il échoue. L'échec d'allocation est l'un de ces échecs. Le document ci-dessous a une bonne explication https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html

Lorsque l'utilisation de CMS GC dans jdk1.8 apparaîtra cette erreur, je change le G1 Gc pour résoudre ce problème.

 -Xss512k -Xms6g -Xmx6g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=70 -XX:NewRatio=1 -XX:SurvivorRatio=6 -XX:G1ReservePercent=10 -XX:G1HeapRegionSize=32m -XX:ConcGCThreads=6 -Xloggc:gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps