Java GC (Thất bại phân bổ)


129

Tại sao luôn luôn "GC (Phân bổ thất bại)"?

Máy chủ 64-bit Java HotSpot (TM) (25,25-b02) cho 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]

Câu trả lời:


202

"Thất bại phân bổ" là một nguyên nhân của chu kỳ GC khởi động.

"Thất bại phân bổ" có nghĩa là không còn chỗ trống trong Eden để phân bổ đối tượng. Vì vậy, nó là nguyên nhân bình thường của GC trẻ.

JVM cũ hơn không in nguyên nhân GC cho các chu kỳ GC nhỏ.

"Thất bại phân bổ" gần như chỉ có thể là nguyên nhân đối với GC nhỏ. Một lý do khác để GC nhỏ có thể đá là giai đoạn nhận xét CMS (nếu +XX:+ScavengeBeforeRemarkđược bật).


1
Cảm ơn. Chỉ cần thấy rằng JVM cũ không in Lỗi phân bổ.
dùng3644708

2
Tôi không nhận được câu trả lời này đầy đủ, vậy có nên tránh hay không? "Đó là nguyên nhân bình thường của GC trẻ". Có phải các bạn trẻ là sự lựa chọn sai lầm?
Thomas

7
Vâng, đây là hành vi bình thường
Alexey Ragozin

183
GC (Phân bổ thất bại) là một lựa chọn từ ngữ kém cho một sự kiện sẽ xảy ra bình thường nhiều lần trong ngày. Những kỹ sư JVM đó nên ra ngoài thường xuyên hơn và cố gắng giao tiếp trong thế giới thực để họ có thể học các thuật ngữ thân thiện hơn mà mọi người hiểu.
Salvador Valencia

79
@SalvadorValencia Không sao, những người đọc nhật ký GC một cách thường xuyên cũng không hoàn toàn "bình thường". :)
biziclop

8

"Thất bại phân bổ" là nguyên nhân khiến cho cú đá của GC không đúng. Đó là kết quả của hoạt động GC.

GC khởi động khi không có không gian để phân bổ (tùy thuộc vào khu vực phụ hoặc chính được thực hiện). Khi GC được thực hiện nếu không gian được giải phóng đủ tốt, nhưng nếu không đủ kích thước thì nó sẽ thất bại. Thất bại phân bổ là một thất bại như vậy. Dưới đây tài liệu có lời giải thích tốt https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html


1
"(...) sau đó xảy ra lỗi phân bổ (vì không có không gian để phân bổ các đối tượng sống từ khu vực đang được sơ tán) và bộ sưu tập đầy đủ thế giới (STW) đã được thực hiện." - Trong java 1.8, chế độ máy chủ, tôi đã tạo lại một khoảng dừng ngắn và cả hai dấu vết này được in cùng nhau: [GC (Thất bại phân bổ) 2287742K-> 1148645K (26.33216K), 0.4571912 giây] [Full GC (Ergonomics) 1148645K- 1112 (3184128K), 2.8563984 giây]. Vì vậy, tôi nêu lên câu trả lời của bạn ;-)
Jose Manuel Gomez Alvarez

-10

Khi sử dụng CMS GC trong jdk1.8 sẽ xuất hiện lỗi này, tôi thay đổi G1 Gc giải quyết vấn đề này.

 -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 

1
Tại sao điều này đã được bỏ phiếu rất nhiều lần? Một lời giải thích sẽ hữu ích.
Mike Stoddart

2
Bởi vì nó giống như nói rằng bạn viết lại chương trình của mình trong Rust và bây giờ bạn không có những tin nhắn như vậy?
Simplylizz
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.