[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-2481) Big memory leak in the use of CGLIB

Paul Malolepsy (JIRA) noreply at atlassian.com
Mon Mar 12 03:34:10 EDT 2007


     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481?page=all ]

Paul Malolepsy updated HHH-2481:
--------------------------------

    Attachment: fix.diff

Here is a diff of the fix for this issue as well as a test case.

Just to give an idea of how potentially bad this leak was, making this change had a dramatic impact on the the memory use and performance of our servlet based web application.  Before, we had to max out the Xmx of our servlets at 2gb, and even still we'd get OOM errors after about 6 hours under heavy stress testing.  Now they run fine at 500mb.  This has also translated to some astonishing performance gains in the overall performance of our app.   I'd be very interested to see if other people have a similar experience.


> Big memory leak in the use of CGLIB
> -----------------------------------
>
>          Key: HHH-2481
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2481
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.2
>  Environment: Hibernate 3.2.2
> MySQL 5.1
>     Reporter: Paul Malolepsy
>     Priority: Critical
>  Attachments: fix.diff
>
> Original Estimate: 5 minutes
>         Remaining: 5 minutes
>
> The way CGLIBLazyInitializer is creating proxies is resulting in a potentially massive memory leak.
> In CGLIBLazyInitializer.getProxy() just before the proxy is instantiated, a call is made to Enhancer.registerCallbacks() passing in the instance of CGLIBLazyInitializer that will manage the proxy.  This variable is stored in a static ThreadLocal on the CGLIB created persistentClass so that any subsequent objects instantiated will get this callback class.  
> The problem is that once this ThreadLocal is set, it is never cleared, so it will stay around (together with the object it's managing, and whatever object graph it may be connected to) until the next time a proxy is created for that type on that thread.  
> For our application we have about 150 different proxy types, and our app can have over 100 threads.  This results in potentially 15,000 proxy objects and their graphs stuck in memory.
> The fix for this is simple.  Just make another call the Enhancer.registerCallbacks() with a null callback arg, right after the proxy class is instantiated:
> Enhancer.registerCallbacks(factory, null);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira




More information about the hibernate-issues mailing list