Java GC (błąd alokacji)

136

Dlaczego zawsze „GC (Błąd alokacji)”?

Java HotSpot (TM) 64-bitowa maszyna wirtualna serwera (25.25-b02) dla środowiska 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]
user3644708
źródło

Odpowiedzi:

208

„Błąd alokacji” jest przyczyną rozpoczęcia cyklu GC.

„Błąd alokacji” oznacza, że ​​w Edenie nie ma już miejsca na przydzielenie obiektu. Jest to więc normalna przyczyna młodego GC.

Starsze JVM nie drukowały przyczyny GC dla mniejszych cykli GC.

„Błąd alokacji” jest prawie jedyną możliwą przyczyną pomniejszego GC. Innym powodem do +XX:+ScavengeBeforeRemarkuruchomienia pomniejszego GC może być faza uwag CMS (jeśli jest włączona).

Alexey Ragozin
źródło
1
Dzięki. Po prostu znajdź, że stara maszyna JVM nie drukuje błędu alokacji.
user3644708
3
Nie rozumiem w pełni tej odpowiedzi, więc należy tego unikać, czy nie? „jest to normalna przyczyna młodego GC”. Czy młody GC jest więc złym wyborem?
Thomas
8
Tak, to normalne zachowanie
Alexey Ragozin
193
GC (Błąd alokacji) to zły dobór słów na określenie zdarzenia, które normalnie będzie występować wiele razy dziennie. Ci inżynierowie JVM powinni częściej wychodzić z domu i próbować nawiązywać kontakty w prawdziwym świecie, aby mogli nauczyć się bardziej przyjaznych terminów, które ludzie rozumieją.
Salvador Valencia
87
@SalvadorValencia W porządku, ludzie, którzy czytają dzienniki GC regularnie, też nie są „normalni”. :)
biziclop
8

„Błąd alokacji” jest przyczyną uruchomienia GC nie jest poprawna. Jest wynikiem operacji GC.

GC uruchamia się, gdy nie ma miejsca do przydzielenia (w zależności od regionu mniejszego lub większego GC jest wykonywane). Po wykonaniu GC, jeśli miejsce jest wystarczająco dobrze zwolnione, ale jeśli nie ma wystarczającego rozmiaru, kończy się niepowodzeniem. Błąd alokacji jest jedną z takich awarii. Poniższy dokument ma dobre wyjaśnienie https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html

Kamal Rathod
źródło
1
„(...) następuje awaria alokacji (ponieważ nie ma miejsca na przydzielenie żywych obiektów z ewakuowanego regionu) i kompletne gromadzenie danych typu Stop-the-World (STW) jest wykonywane”. - W java 1.8, tryb serwera, odtworzyłem krótką przerwę i oba te ślady są drukowane razem: [GC (Błąd alokacji) 2287742K-> 1148645K (2633216K), 0,4571912 s] [Pełna GC (Ergonomia) 1148645K-> 1112141K (3184128K), 2,8563984 s]. Głosuję więc za twoją odpowiedź ;-)
Jose Manuel Gomez Alvarez
-10

Podczas korzystania z CMS GC w jdk1.8 pojawi się ten błąd, zmieniam G1 Gc rozwiązuje ten problem.

 -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 
Hatter Bush
źródło
1
Dlaczego głosowanie to było odrzucane tyle razy? Przydałoby się wyjaśnienie.
Mike Stoddart
2
Bo to tak, jakby powiedzieć, że przepisałeś swój program w Rust i teraz nie masz takich komunikatów?
simplylizz