PermGen space issue with Glassfish/Hibernate

Question

I'm running a GWT+Hibernate app on Glassfish 3.1. After a few hours, I run out of Permgen space. This is without any webapp reloads. I'm running with –XX:MaxPermSize=256m –XmX1024m .

I took the advice from this page , and found that I'm leaking tons of classes- all of my Hibernate models and all of my GWT RequestFactory proxies.

The guide referenced above says to "inspect the chains, locate the accidental reference, and fix the code". Easier said than done.

The classloader always points back to an instance of org.glassfish.web.loader.WebappClassLoader . Digging further, I find lots of references from $Proxy135 and similar-named objects. But I don't know how else to follow through.

Answer 1

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.

Answer 2

我通过迁移到Tomcat来“解决”这个问题。

Answer 3

There are some OK tools to help with this, though you'd never know it. The JDK (1.6 u1 and above) ships with jhat and jmap. These tools will help significantly, especially if you use the jhat JavaScript query support.

See:

http://blog.ringerc.id.au/2011/06/java-ee-application-servers-learning.html

http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java

http://www.mhaller.de/archives/140-Memory-leaks-et-alii.html

http://blogs.oracle.com/sundararajan/entry/jhat_s_javascript_interface

Answer 4

(I can't view the link you provided as it's blocked by websense so if I'm restating anything I apologize)

It sounds like you have a class loader leak. These are difficult to track down, add these options to the JVM Options in your instance configuration

-XX:+PrintGCDetails
-XX:+TraceClassUnloading
-XX:+TraceClassLoading

Now when you run your app, you can look at the jvm.log located in your domain/logs folder and see what's loading and unloading. Mostly likely, you'll see the same class(es) loading over and over again.

A good culprit is JAXB, especially if you're creating a new JAXBContext over and over again.