为什么JVM做这么多的垃圾收集

下面是一个JVM一个jstat输出具有下列参数为什么JVM做这么多的垃圾收集

-Xmx10240m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

的jstat输出与参数运行

jstat -gcutil <pid> 10s

的部分是片段在80秒的时间内，根据统计近70秒这是花在GC上。他们都是正在触发的完整GC。

Timestamp S0 S1 E  O  P  YGC  YGCT  FGC  FGCT  GCT   Diff 
1040430.2 0 0 23.69 24.58 95.03 168048 22187.057 3672 4483.931 26670.988 8.175 
1040440.2 0 0 0.1  24.58 95.02 168048 22187.057 3674 4495.551 26682.608 11.62 
1040450.2 0 0 4.19 24.59 95.03 168048 22187.057 3677 4506.731 26693.788 11.18 
1040460.2 0 0 0.01 24.45 95.02 168048 22187.057 3679 4517.391 26704.448 10.66 
1040470.2 0 0 0.33 24.45 95.03 168048 22187.057 3681 4522.213 26709.27 4.822 
1040480.2 0 0 0  24.43 95.02 168048 22187.057 3684 4534.816 26721.874 12.604

PermGen的空间运行在几乎满，但我没想到的是，太阳GC机制将尝试在这里收集和我可以看到所收集的基础上，伊甸或旧空间的理由。

任何能给我指点的人都是可能发生的事情？

来源

2011-07-11 bstick12

为什么JVM做了很多垃圾回收。

这很可能是因为永久代的入住率相当高。当使用CMS算法时，只有当旧的或永久的世代占用率超过定义的阈值时，主要收集才会启动。除非我错了，否则旧一代的默认占用率阈值为68％，可以使用-XX:CMSInitiatingOccupancyFraction=n flag更改此默认占用率阈值。然而，就所提供的数据而言，这个数值似乎并不重要，因为统计数据显示老一代的入住率似乎低于25％（这并不意味着老一代没有填补过渡期，但永久代自身展现更高的入住率不太可能）。

请注意，CMS收集器默认情况下不会声明永久生成的对象。这将需要切换CMSClassUnloading标志。如果行为没有得到改善，那么永久性世代的大小可能不是正确的，并且必须给予更多的记忆，因为永久性世代中只有少数目标有资格收集每个主要收集周期。

来源

2011-07-11 09:26:49

您能否指出一个说明PermGen将由CMS算法收集的文档？我一直无法看到没有明确设置标志CMSPermGenSweepingEnabled的情况。 – bstick12

'CMSPermGenSweepingEnabled'在Java 6中似乎已被弃用。然而，大多数人使用'CMSClassUnloadingEnabled'和'CMSPermGenSweepingEnabled'来启用集合中的permgen Java 6.最接近我可以找到这种行为的文档是[OpenJDK邮件列表]（http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-October/000522.html）和在Sun bug数据库中[对于错误5037027]（http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5037027）和[6250214]（http://bugs.sun.com/bugdatabase/view_bug）。 do？bug_id = 6250214） –

接受答案似乎是最合乎逻辑的解释。文件是这方面非常差。 – bstick12

为什么JVM做这么多的垃圾收集

回答

相关问题