I constantly detect OOM in PermGen for my environment:
- java 6
- jboss-4.2.3
- Not a big web-application
I know about String.intern() problem - but I don't have enough valuable usage of it. Increasing of MaxPermGen size didn't take a force (from 128 Mb to 256 Mb).
What other reasons could invoke OOM for PermGen? What scenario of investigation is the best in such situation (strategy, tools and etc.)?
Thanks for any help
- Put JDBC driver in common/lib (as tomcat documentation says) and not in WEB-INF/lib
- Don't put commons-logging into WEB-INF/lib since tomcat already bootstraps it
new class objects get placed into the PermGen and thus occupy an ever increasing amount of space. Regardless of how large you make the PermGen space, it will inevitably top out after enough deployments. What you need to do is take measures to flush the PermGen so that you can stabilize its size. There are two JVM flags which handle this cleaning:
-XX:+CMSPermGenSweepingEnabled
This setting includes the PermGen in a garbage collection run. By default, the PermGen space is never included in garbage collection (and thus grows without bounds).
-XX:+CMSClassUnloadingEnabled
This setting tells the PermGen garbage collection sweep to take action on class objects. By default, class objects get an exemption, even when the PermGen space is being visited during a garabage collection.
You typically get this error when redeploying an application while having a classloader leak, because it means all your classes are loaded again while the old versions stay around.
There are two solutions:
- Restart the app server instead of redeploying the application - easy, but annoying
- Investigate and fix the leak using a profiler. Unfortunately, classloader leaks can be very hard to pinpoint.
来源：https://stackoverflow.com/questions/5635255/permgen-out-of-memory-reasons