如何解釋導致OutOfMemoryError的G1 GC日志？

Question

我想知道是否有人能夠向我解釋如何解釋一些導致OutOfMemoryError的G1 GC日志？

我知道堆轉儲是查找實際使用堆的最佳選擇，但我無法得到它，因為它包含無法離開客戶端站點的受保護信息。 我所擁有的只是應用程序日志（包括來自OOME的堆棧）和G1 GC日志。

完整的G1 GC日志有很多細節，所以我不會把它們放在這里，除非有人特別需要看到它們。

這些來自的特定Java版本是：

> java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

我用來創建GC日志的GC選項是：

-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xloggc:log/gc.log

以下是在OOME前30分鍾內每個年輕和完整GC的所有內存統計數據：

INFO   | jvm 1    | 2015/05/28 04:29:34 | [Eden: 1290M(1290M)->0B(1290M) Survivors: 20M->20M Heap: 2445M(3932M)->1155M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:33:21 | [Eden: 1290M(1290M)->0B(1290M) Survivors: 20M->20M Heap: 2445M(3932M)->1155M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:37:09 | [Eden: 1290M(1290M)->0B(1290M) Survivors: 20M->20M Heap: 2445M(3932M)->1155M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:40:58 | [Eden: 1290M(1290M)->0B(1290M) Survivors: 20M->20M Heap: 2445M(3932M)->1155M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:44:44 | [Eden: 1290M(1290M)->0B(1290M) Survivors: 20M->20M Heap: 2445M(3932M)->1155M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:48:30 | [Eden: 1290M(1290M)->0B(1290M) Survivors: 20M->20M Heap: 2445M(3932M)->1155M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:52:17 | [Eden: 1290M(1290M)->0B(1290M) Survivors: 20M->20M Heap: 2445M(3932M)->1155M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:52:58 | [Eden: 639M(1290M)->0B(1295M) Survivors: 20M->15M Heap: 2278M(3932M)->1635M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:52:59 | [Eden: 51M(1295M)->0B(1300M) Survivors: 15M->10M Heap: 2561M(3932M)->2505M(3932M)]
INFO   | jvm 1    | 2015/05/28 04:52:59 | [Full GC 2505M->1170M(3901M), 1.9469560 secs]
INFO   | jvm 1    | 2015/05/28 04:53:01 | [Eden: 44M(1300M)->0B(1299M) Survivors: 0B->1024K Heap: 1653M(3901M)->1610M(3901M)]
INFO   | jvm 1    | 2015/05/28 04:53:01 | [Eden: 1024K(1299M)->0B(1299M) Survivors: 1024K->1024K Heap: 1610M(3901M)->1610M(3901M)]
INFO   | jvm 1    | 2015/05/28 04:53:02 | [Full GC 1610M->1158M(3891M), 1.4317370 secs]
INFO   | jvm 1    | 2015/05/28 04:53:03 | [Eden: 112M(1299M)->0B(1296M) Survivors: 0B->1024K Heap: 1758M(3891M)->1647M(3891M)]
INFO   | jvm 1    | 2015/05/28 04:53:06 | [Eden: 49M(1296M)->0B(1360M) Survivors: 1024K->1024K Heap: 2776M(4084M)->2728M(4084M)]
INFO   | jvm 1    | 2015/05/28 04:53:06 | [Eden: 0B(1360M)->0B(1360M) Survivors: 1024K->1024K Heap: 2837M(4084M)->2836M(4084M)]
INFO   | jvm 1    | 2015/05/28 04:53:06 | [Full GC 2836M->1158M(3891M), 1.4847750 secs]
INFO   | jvm 1    | 2015/05/28 04:53:08 | [Full GC 1158M->1158M(3891M), 1.5313770 secs]

*這是原始日志的不同格式，我刪除了時間細節，使其更短更容易閱讀。

我還在GCViewer中繪制了原始GC日志：

到目前為止，似乎一切順利：

• 使用的tenured是恆定的（圖表底部的深品紅線）。
• 每隔幾分鍾就會發生年輕的GC暫停，清理所有年輕物體（圖表頂部的灰線）。
• 每一代的分配大小是不變的。
• 年輕的GC之后的堆使用量約為1155M。

然后在2015/05/28 04:52:59事情變成了梨形：

• 終身突然開始成長。
• 當年輕的GC運行時，伊甸園空間只有51M。
• 完整的GC開始發生。
• 前3個完整的GC似乎沒問題，他們將堆使用量減少到1158M-1170M（非常接近正常的1155M）。
• 最終完整的GC開始使用1158M，之后仍然是1158M。

屏幕截圖中的Memory選項卡顯示：

Tenured heap (usage / alloc. max)    2,836 (104.1%) / 2,723M
Total promotion                                       2,048K

現在簡要解釋2015/05/28 04:52:59發生的2015/05/28 04:52:59 。 此時，使用StringBuilder將一大堆配置對象序列化為自定義格式。 這導致了一堆數組副本，最終在2015/05/28 04:53:09導致以下異常：

java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:2367)
    at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130)
    at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:587)
    at java.lang.StringBuilder.append(StringBuilder.java:214)
    ...

我無法解釋一些事情：

1. 在GC日志中，您會找到使用過的終身內存嗎？
2. 什么會導致使用的終身內存中出現如此顯着的峰值導致GC？ 只有2000萬的幸存者，所以在最壞的情況下，這些都不會終身而已？
3. 這可能是通過大量的對象分配來解釋的嗎？
4. 為什么最后一個完整的GC被觸發時（顯然）有那么少的堆使用，之后它什么都沒清理？
5. 如果分配了3891M堆並且只使用了1158M，那么為什么會有OOME呢？

Answer 1

你的內存不足發生在StringBuilder.append期間 - 請記住，每次你追加一個字符串並且StringBuilder中的緩沖區太小以至於擴展容量時，它會嘗試將緩沖區分配為當前長度的兩倍。構建器中的字符串加2或新的長度（如果更大）。 （參見AbstractStringBuilder.java的源代碼）

例如，如果您的字符串構建器已經有100個字符並且已滿，那么您將另外添加10個字符，它將擴展為：

100 * 2 + 2 = 202，超過10。

因此，如果您已經擁有一個非常長的字符串（10MB），它將嘗試創建一個20MB的緩沖區，依此類推。

檢查代碼並確保您沒有在構建器中創建大字符串。