G1年轻的GC没有释放内存 - 空间耗尽

Question

我正在使用G1GC,jdk 1.7

Java HotSpot(TM) 64-Bit Server VM (24.79-b02) for linux-amd64 JRE (1.7.0_79-b15), built on Apr 10 2015 11:34:48 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 32826020k(12590436k free), swap 33431548k(33358800k free)

CommandLine flags: -XX:AutoBoxCacheMax=3000000 -XX:+DisableExplicitGC 
-XX:G1NewSizePercent=20 -XX:+HeapDumpOnOutOfMemoryError -XX:InitialHeapSize=10737418240 
-XX:InitiatingHeapOccupancyPercent=70 -XX:MaxDirectMemorySize=1073741824 -XX:MaxGCPauseMillis=1000 
-XX:MaxHeapSize=10737418240 
-XX:-OmitStackTraceInFastThrow -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps -XX:+UnlockExperimentalVMOptions 
-XX:+UseCompressedOops -XX:+UseG1GC

大多数小型GC工作正常,但它仍然开始异常的fullGC,一小时大约一到两次.

这是年轻GC日志的正常情况

3443.100: [GC pause (young), 0.3021260 secs]
  [Parallel Time: 277.6 ms, GC Workers: 4]
  [GC Worker Start (ms): Min: 3443100.5, Avg: 3443100.6, Max: 3443100.6, Diff: 0.1]
  [Ext Root Scanning (ms): Min: 2.9, Avg: 3.0, Max: 3.1, Diff: 0.2, Sum: 11.9]
  [Update RS (ms): Min: 33.5, Avg: 33.6, Max: 33.9, Diff: 0.4, Sum: 134.5]
     [Processed Buffers: Min: 180, Avg: 204.8, Max: 227, Diff: 47, Sum: 819]
  [Scan RS (ms): Min: 76.0, Avg: 76.2, Max: 76.3, Diff: 0.3, Sum: 304.9]
  [Code Root Scanning (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 0.3]
  [Object Copy (ms): Min: 164.4, Avg: 164.4, Max: 164.5, Diff: 0.1, Sum: 657.7]
  [Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
  [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.0, Sum: 0.2]
  [GC Worker Total (ms): Min: 277.3, Avg: 277.4, Max: 277.4, Diff: 0.1, Sum: 1109.5]
  [GC Worker End (ms): Min: 3443377.9, Avg: 3443378.0, Max: 3443378.0, Diff: 0.0]
  [Code Root Fixup: 0.2 ms]
  [Code Root Migration: 0.3 ms]
  [Clear CT: 2.0 ms]
  [Other: 22.1 ms]
  [Choose CSet: 0.0 ms]
  [Ref Proc: 15.7 ms]
  [Ref Enq: 0.5 ms]
  [Free CSet: 3.2 ms]
  [Eden: 5996.0M(5996.0M)->0.0B(5648.0M) Survivors: 148.0M->196.0M Heap: 8934.5M(10.0G)->2997.2M(10.0G)]
  [Times: user=1.13 sys=0.00, real=0.30 secs]

这是在fullGC之前的一个不寻常的GC日志.它重复了两到三次,并没有清理任何记忆.

3482.422: [GC pause (young) (to-space exhausted), 3.4878580 secs]
[Parallel Time: 1640.5 ms, GC Workers: 4]
  [GC Worker Start (ms): Min: 3482421.8, Avg: 3482422.4, Max: 3482424.0, Diff: 2.2]
  [Ext Root Scanning (ms): Min: 2.1, Avg: 3.2, Max: 3.8, Diff: 1.7, Sum: 12.6]
  [Update RS (ms): Min: 104.8, Avg: 105.2, Max: 105.6, Diff: 0.8, Sum: 421.0]
     [Processed Buffers: Min: 201, Avg: 221.2, Max: 236, Diff: 35, Sum: 885]
  [Scan RS (ms): Min: 75.1, Avg: 75.2, Max: 75.3, Diff: 0.1, Sum: 300.8]
  [Code Root Scanning (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 0.2]
  [Object Copy (ms): Min: 1455.9, Avg: 1456.1, Max: 1456.2, Diff: 0.3, Sum: 5824.2]
  [Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.4]
  [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
  [GC Worker Total (ms): Min: 1638.2, Avg: 1639.8, Max: 1640.4, Diff: 2.2, Sum: 6559.3]
  [GC Worker End (ms): Min: 3484062.2, Avg: 3484062.2, Max: 3484062.2, Diff: 0.0]
[Code Root Fixup: 0.2 ms]
[Code Root Migration: 0.5 ms]
[Clear CT: 2.0 ms]
[Other: 1844.7 ms]
  [Choose CSet: 0.0 ms]
  [Ref Proc: 60.1 ms]
  [Ref Enq: 0.5 ms]
  [Free CSet: 1.2 ms]
[Eden: 5648.0M(5648.0M)->0.0B(1876.0M) Survivors: 196.0M->172.0M Heap: 9441.9M(10.0G)->9352.3M(10.0G)]
[Times: user=9.29 sys=0.05, real=3.49 secs]

然后它启动了一个fullGC

3490.812: [Full GC 9626M->1879M(10G), 7.6059670 secs]
[Eden: 0.0B(2048.0M)->0.0B(6144.0M) Survivors: 0.0B->0.0B Heap: 9626.3M(10.0G)->1879.5M(10.0G)], [Perm: 33901K->33901K(36864K)]
[Times: user=10.24 sys=0.00, real=7.61 secs]

为什么最后一个youngGC没有清理任何内存？

Answer 1

您正遇到疏散失败,可以从to-space exhausted集合的开始消息部分看出.

当堆上没有足够的可用空间来提升幸存或升级的对象(或两者)并且无法扩展堆时,就会发生这种情况.

Monica Beckwith在调整垃圾第一垃圾收集器的技巧中写了以下内容

对于G1 GC,疏散失败非常昂贵 -

• 对于成功复制的对象,G1需要更新引用,并且区域必须是终结的.
• 对于未成功复制的对象,G1将自行转发它们并使区域保持在适当位置.

当被迫执行这些操作时,G1通常无法跟上分配率,并且由于分配失败,最终将被强制为完整的GC.这可能是您在几次疏散失败后看到完整GC的原因.

Monica Beckwith还撰写了关于Garbage First Garbage Collector Tuning的可能解决方案

• 增加-XX:G1ReservePercent选项的值(以及相应的总堆)以增加"to-space"的保留内存量.

• 通过减少-XX:InitiatingHeapOccupancyPercent来提前开始标记周期.

• 您还可以增加-XX:ConcGCThreads选项的值以增加并行标记线程的数量.

此外,增加堆是另一种选择,可以减少疏散失败的可能性.