如何解释导致OutOfMemoryError的G1 GC日志?

时间:2015-06-04 04:50:04

标签: java garbage-collection jvm g1gc

我想知道是否有人能够向我解释如何解释一些导致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日志:

enter image description here

到目前为止,似乎一切顺利:

  • 使用的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发生的事情。此时,使用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?

1 个答案:

答案 0 :(得分:1)

你的内存不足发生在StringBuilder.append期间 - 请记住,每次你追加一个字符串并且StringBuilder中的缓冲区太小以至于它扩展了容量时,它会尝试将缓冲区的dobule分配为double构建器中String的当前长度加2或新长度(如果更大)。 (参见AbstractStringBuilder.java)的源代码

例如,如果您的字符串构建器已经有100个字符且已满,那么您将另外添加10个字符,它将扩展为:

100 * 2 + 2 = 202,超过10。

因此,如果您已经拥有一个非常长的字符串(10MB),它将尝试创建一个20MB的缓冲区,依此类推。

检查代码并确保您没有在构建器中创建大字符串。