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 FGCT：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：2216200 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：2216227 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：2216255 FGCT：160659.701 GCT：167415.146
为什么JVM频率满gc发生了？
答案 0 :(得分：1)
很难说，但一种可能的解释是你反复分配和丢弃非常大的数组。
如果我正确解释统计数据，伊甸园空间为174MB，幸存者空间为0.5MB，旧空间为349MB。如果分配的数组太大而无法放入Eden空间，它将直接分配到旧空间。如果旧空间填满，则可能触发完整的GC。
有多大＆＃34;大＆＃34;？这很复杂，因为还有TLAB及其大小的问题，-XX:PretenureSizeThreshold选项以及不同类型的GC之间的差异。请阅读Martin Thompson的"Java Garbage Collection Distilled"，以帮助您解决问题。
如果这不是问题，那么您需要对堆中发生的事情进行更深入的调查。弄清楚对象的混合，它们的速率和分配/处置模式等，试图弄清楚为什么这么多的东西最终会进入旧空间。
3-5天工作正常后，会发生这种情况
这往往表明，在运行三到五天的时间内，应用程序的内存数据结构中正在积累某些东西。调查那种情况。
答案 1 :(得分：0)
你的幸存者空间非常小。只需512KB。如果幸存者空间填满清理伊甸园空间，则会触发Full GC。
当您的伊甸园空间大约300倍时，如果它们没有填满，我会感到惊讶。
我会检查你是不是在创建很多非常短暂的对象，这就是为什么JVM认为几乎没有任何东西存在的原因。
例如，看看您是否可以在不创建对象的情况下解析/处理UDP数据包。
答案 2 :(得分：0)
当堆和堆栈内存看起来不错时，尝试查找有关“直接内存”的内存泄漏。就我而言，部分Netty5-ByteBuf没有发布。