I have a perm gen memory leak, that I know. Profiling using jvisualvm shows that when doing hot deployment (e.g. stop and start an application without killing the JVM, in tomcat, WebSphere, WebLogic etc) - the PermGen space is constantly increasing.
After reading, using jhat, and other advanced tools I realized that I probably have a reference to the WebAppClassLoader from a class somewhere in its parent class loaders.
I couldn't pin it down even though I did some massive JavaScript based queries on jhat
Isn't there a simple utility that finds out who is responsible for you class loader to not be garbage collected (thus allowing garbage collection of classes loaded by it)?
I tried JProfiler, jvisualvm, jhat, and a lot of Google
to all the LMGTFY friends - I've spent about a day and a half reading forums with step by steps instructions, no luck. I'm looking for a utility or code that outputs:
Object X of class Y is the sole GC root that keeps your classes from being removed.
There is an unsatisfiying but easy solution: Don't hotdeploy in production environments. You could setup a cluster of two servlet containers and them update one at a time with a restart.
The realities of frequent redeployments... Best you can do is increase the size of perm gen using -XX:MaxPermSize=256m. This may buy you some redeployments more per jvm restart. Or read on at http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back
Beware that if the classloaders can't be gc-ed at all, fiddling with the jvm won't help at all. You'd better forget about frequent deployments, especially in production, for dev it's handy, nevertheless.
I used the method from this site and it helped. http://www.mkyong.com/tomcat/tomcat-javalangoutofmemoryerror-permgen-space/
Few pointers here as well, http://minmaxmim.blogspot.com/2010/01/javalangoutofmemoryerror-java-heap.html
also check the javalangoutofmemoryerror-permgen-space article.
来源：https://stackoverflow.com/questions/1996088/java-class-permgen-memory-leak-web-applications-generic-solution