java - JVM内存足够但频率full gc

Question

JVM 选项: -Xms512M -Xmx512M -XX:PermSize=70M -XX:MaxPermSize=70M

jstat -gc 8260 5000

S0C:512.0 S1C:512.0 S0U:0.0 S1U:0.0 EC:174080.0 EU:0.0 OC:349696.0 OU:45191.1 PC:71680.0 PU:34882.2 YGC:2216225 YGCT:6754.909 FGC:2216144 F GCT:160651.466 GCT:167406.375

S0C:512.0 S1C:512.0 S0U:0.0 S1U:64.0 EC:174080.0 EU:0.0 OC:349696.0 OU:45187.3 PC:71680.0 PU:34882.2 YGC:2216253 YGCT:6755.047 FGC:2216172 FGCT:160653.488 GCT:167408.535

S0C:512.0 S1C:512.0 S0U:0.0 S1U:128.0 EC:174080.0 EU:0.0 OC:349696.0 OU:45189.6 PC:71680.0 PU:34882.2 YGC:2216281 YGCT:6755.180 FGC:221620 0 FGCT:160655.542 GCT:167410.721

S0C:512.0 S1C:512.0 S0U:0.0 S1U:0.0 EC:174080.0 EU:1775.6 OC:349696.0 OU:45187.3 PC:71680.0 PU:34882.2 YGC:2216308 YGCT:6755.309 FGC:22162 27 FGCT:160657.627 GCT:167412.936

S0C:512.0 S1C:512.0 S0U:128.0 S1U:0.0 EC:174080.0 EU:0.0 OC:349696.0 OU:45187.3 PC:71680.0 PU:34882.2 YGC:2216336 YGCT:6755.444 FGC:221625 5 FGCT:160659.701 GCT:167415.146

为什么会发生JVM频率full gc？

Answer 1

这很难说，但一种可能的解释是您重复分配和丢弃非常大的数组。

如果我正确解释统计数据，Eden 空间为 174MB，Survivor 空间为 0.5MB，Old 空间为 349MB。如果您分配的数组太大而无法放入 Eden 空间，它将直接分配到 Old 空间。如果 Old 空间被填满，可能会触发 Full GC。

“大”有多大？嗯，这很复杂，因为还存在 TLAB 及其大小、-XX:PretenureSizeThreshold 选项以及不同类型 GC 之间的差异的问题。阅读 "Java Garbage Collection Distilled"作者:Martin Thompson，帮助您开始解决这些问题。

<小时/>

如果这不是问题，那么您需要对堆中发生的情况进行更深入的调查。弄清楚对象的组合是什么、它们的比率和分配/处置模式等，以尝试找出为什么这么多对象最终进入旧空间。

After 3-5 days works fine, this happens

这往往表明在三到五天的操作中，应用程序的内存数据结构中正在积累一些东西。调查该场景。