The various options for solving PermGen problems

 

I am looking into the various options around garbage collection on a Java 6 18 VM and would like some pointers.

We run our application on JBoss, and occasionally there are the infamous PermGen errors during redeploys. There is a lot of conflicting and obsolete information on the internet about the best way to solve or mitigate this problem.

From what I can see, the following is correct:

  • VM options on their own will not resolve this issue, only postpone it.
  • The only reliable way to fix this problem is to fix coding errors either in the Application Server itself (unlikely) or the code (our code or third-party libraries) that is running in the Application Server (more likely). The filling of Permgen is often the result of references from objects loaded by the application classloader to objects loaded by the Application Server classloader, thus preventing garbage collection of the application's classloader.

    • I have two questions resulting from this:

  • Is the above correct?
  • Where do the VM options CMSClassUnloadingEnabled and CMSPermGenSweepingEnabled come into this? From what I can see CMSClassUnloadingEnabled supercedes or implicitly enables CMSPermGenSweepingEnabled . Do either of them help with the above problem?

    • Unfortunately, the answers are:

  • Yes
  • Those VM options will only postpone the problem.

    • The basic problem is that the GC will not garbage collect a strongly reachable object. You need to figure out why those old application class loaders are still reachable after a redeploy ... and fix the leak.

    Alternatively, give up on hot redeployment on your production servers, or restart the web container (eg JBoss) more often.

    Long but good reading: http://victor-jan.blogspot.com/2010/05/classloader-leaks-dreaded.html In short, it is solvable. Not easy, but solvable.

    链接地址: http://www.djcxy.com/p/82384.html

    上一篇: XX：MaxPermSize呢？

    下一篇: 解决PermGen问题的各种选项