分析java.lang.OutOfMemoryError: PermGen space

貌似我也碰到过这个，开几天tomcat就outofmemery了

换用Jrockit，不会有这样的问题

谢谢qieqie，我也找到了inside jvm里的相关描述：
方法区的大小不必是固定的，虚拟机可以根据应用的需要动态调整。同样，方法区也不必是连续的，方法区可以在一个堆（甚至是虚拟机自己的堆）中自由分配。另外，虚拟机也可以允许用户或者程序员指定方法区的初始大小以及最小和最大尺寸等


但是即使手动增大方法区大小也只不过是权益之计，因为sun的jvm的gc还是不能正确回收它呀。

对方法区中的Class类型的垃圾回收和内存堆中的GC机制是类似的。
不明白为什么动态加载类会无法被回收

是的，但是在运行的时候他们使用了不同的回收机制。可以在启动java的时候配置Perg空间的回收机制。

谢谢提醒，确实没有注意排版，下次注意：）

不是GC对permanent generation不能正常工作，而是permanent generation里的数据压根就不能被GC，也就是说permanent generation是GC不能触及的HEAP空间。字面意思也表达的很清楚了，permanent就是永久的意思。
解决办法也就只能通过设置-XX:PermSize和-XX:MaxPermSize，还有就是少用reflection。

不同意， 在某些jvm实现中，方法区中的类数据本身可能被存放在使用垃圾搜集器的堆中，以便使用和释放对象同样的垃圾收集算法来检测和卸载不再被引用的类。这里指的某些估计就包括jrokit

而且这个貌似和reflection的使用没有什么关系吧，out of memory主要是字节码增强类大量充斥了方法区，而且不能被sun的jvm回收造成的。

sun jvm有个好处是,比jrockit remote debug速度快很多.
jrockit只适合当作生产环境服务器,测试功能时,建议还是使用sun jvm

是我理解错了，一般GC算法也是会照顾permanent generation的，每次permanent generation满了要做扩展前都会触发一次FULL GC，除非设置了-Xnoclassgc。

另外如果使用CMS（ConcMarkSweep GC）算法的话，开了-XX:+UseConcMarkSweepGC标志，默认情况下就是不会扫描permanent generation的，需要同时打开下面两个标志位才能让CMS GC扫描permanent generation。
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled

P.S. 只针对SUN的JVM有效。