服务Perm Gen OOM了
jmap -heap 20598 发现 Perm Generation 使用量持续增长

翻看过相关资料，标记为dead后将被GC回收，但是我触发Full GC后，jmap -permstat 20598 的输出片段中，仍然有大量DelegatingClassLoader标记为dead

0x00000000ea6fe628      2       3472    0x00000000e94c1370      dead    sun/reflect/DelegatingClassLoader@0x00000000f0067700
0x00000000ea3981a0      1       3088    0x00000000ea398088      dead    sun/reflect/DelegatingClassLoader@0x00000000f0067700
0x00000000e9eb7d28      1       3088    0x00000000e9ead9a8      dead    sun/reflect/DelegatingClassLoader@0x00000000f0067700
0x00000000ea60acf0      1       3088    0x00000000ea616ea8      dead    sun/reflect/DelegatingClassLoader@0x00000000f0067700
0x00000000e985a3e8      2       3488    0x00000000e94c1370      dead    sun/reflect/DelegatingClassLoader@0x00000000f0067700
0x00000000e97e1870      1       3088    0x00000000e94c1370      dead    sun/reflect/DelegatingClassLoader@0x00000000f0067700
0x00000000ea6141e0      1       3088    0x00000000ea614138      dead    sun/reflect/DelegatingClassLoader@0x00000000f0067700
0x00000000e99110e8      2       3488    0x00000000e94c1370      dead    sun/reflect/DelegatingClassLoader@0x00000000f0067700

比较困惑 Perm Generation 中的对象回收策略具体是什么

谁来解答下啊.我也遇到了相同的问题,头疼啊.
查看dump信息.10万多的DelegatingClassLoader.FGC也不回收怎么办?

查到个连接,有需要的自己看下把
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4957990
JDK的一个bug

您说的JDK-4957990是个非常老的bug了。相信只要您在用最新的JDK6或者JDK7都不会碰到它。
而如果您以及是在用最新的JDK6/7但还是遇到这种问题，那多半就不是这个bug。这个bug的成因是HotSpot VM在运行时收集的profile信息（称为methodDataOop或者MDO）有可能持有对klassOop，而之前某些老版本里MDO被当作强引用的根，所以出现了内存泄漏的问题。那个bug已经修好了。


jmap -permstat功能由Serviceability Agent（SA）的PermStat类实现，源码可以参考这里：
（JDK7u版）
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/tip/agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java
可见标记ClassLoader的死活用的是RevPtrs。而SA的RevPtrs其实并不保证覆盖所有引用，所以它说是dead其实不一定真的是dead（虽然真的是dead的可能性很高）。这个得具体情况具体分析。关于RevPtrs的使用例子，可以参考我之前的一篇笔记：http://rednaxelafx.iteye.com/blog/1847971
还是得先问您用的JDK版本是什么，启动参数是什么。


PermGen通常随着Full GC回收。使用CMS（-XX:+UseConcMarkSweepGC）时，如果打开了-XX:+CMSClassUnloadingEnabled，那么在CMS并发收集周期中也会有一个阶段收集PermGen。跟普通Java对象一样，PermGen里的对象也是要在没有活的强引用、足够强度的弱引用所引用的时候才可以回收。
类对象比较特别，一个ClassLoader实例加载的所有类都死掉的时候，这个ClassLoader及其加载的所有类才可以一起死掉。所以说一个类要死掉的话，必须有：
1、这个类已经没有任何活的实例；
2、这个类自身没有被别的地方引用（主要是指这个类对应的java.lang.Class对象不能被别的活引用所引用）；
3、这个类的ClassLoader及其所加载的所有其它类都没有被活引用所引用（注意这里对同一ClassLoader加载的其它所有类都要满足上面两条）
条件还挺苛刻的嗯。


出现大量DelegatingClassLoader意味着您在大量使用反射调用不同的方法。请参考我之前写的关于JDK反射调用的笔记：http://rednaxelafx.iteye.com/blog/548536


如果接连触发两次full GC都啥也回收不掉的话那问题是比较严重。
要从外部连续触发两次full GC的话，可以从外部执行两次jmap -histo:live。

多谢 RednaxelaFX 的恢复，已经被这个问题折腾的死去活来了。

JDK版本：Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
启动参数：-Xms4069m -Xmx8192m  -XX:PermSize=512m -XX:MaxPermSize=1024m -XX:NewSize=128m -Xss256k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xdebug
使用Tomcat5.5作为服务容器，有JSP也有FLEX
运行状况，在服务启动的前几天PermSize空间在200M~350M之间波动，FGC有效，但时间长了以后发现PermSize一直增长FGC无法回收。

请把PermSize和MaxPermSize设到同一个值。CMS有个bug在OpenJDK里还没修好，在PermSize和MaxPermSize不一样的时候会出问题。

之前就是设置-XX:PermSize=512m -XX:MaxPermSize=512m 的因为Perm发生OOM才将 Max调大的。
之前JDK没贴全
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
使用的是sun的jdk

此问题已解决,问题的现象是YGC过于频繁,导致无法进入Perm空间的回收事件.原来系统YGC的频率为1.5一次.
调整年轻代空间后,YGC的频率达到30秒一次,Perm空间的回收也变正常了.