Prevent memory leaks with @Configuration beans [SPR-9851]

[spring-projects-issues]

Juraj Misur opened SPR-9851 and commented

I have an app where I create many spring contexts for 3rd party classes, so they can autowire some resources, work in restricted environment, basically some "plugin system". These contexts are created and destroyed dynamically, sometimes in rapid pace.

Since I added support for custom javaconfig style context configuration, app started to produce PermGen errors. I traced it to the root of the problem, shown in this simple test:

package springctx;

import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class SpringCtxTest {

	public static void main(String[] args) {
		while (true) {
			AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(MyConfigClass.class);
			ctx.destroy();
		}
	}

}

Config class:

package springctx;

import org.springframework.context.annotation.Configuration;

@Configuration
public class MyConfigClass {

}

When I run this, I can see clearly in VisualVM that PermGen is heading to the sky. Heapdump revealed gazillion of springctx.MyConfigClass$$EnhancerByCGLIB$$5d91109e entries in CachedIntrospectionResults

When I run it without @Configuration annotation, everything is OK.

---

Affects: 3.1.1

Sub-tasks:

• Backport "Prevent memory leaks with @Configuration beans" [SPR-9902] #14535 Backport "Prevent memory leaks with @Configuration beans"

Issue Links:

• MemoryLeak in Cglib2AopProxy.ProxyCallbackFilter [SPR-8008] #12663 MemoryLeak in Cglib2AopProxy.ProxyCallbackFilter
• Concurrent creation of the same Configuration class in different contexts is not thread-safe [SPR-10307] #14941 Concurrent creation of the same Configuration class in different contexts is not thread-safe

Referenced from: commits 27c8371, ced6bb4, c806139

[spring-projects-issues]

Juraj Misur commented

I forgot to mention: using cglib-nodep 2.2.2

[spring-projects-issues]

Juergen Hoeller commented

Chris, could you please have a look at this? It's not the first CGLIB memory leak issue to come up this year, and we might have a better chance of dealing with it now that we upgraded to CGLIB 3.0...

[spring-projects-issues]

Chris Beams commented

Sure. Thanks, Juraj for the report.

[spring-projects-issues]

Chris Beams commented

Juraj Misur, this is now fixed in the latest 3.2.0.BUILD-SNAPSHOT. Thanks again for the report!

commit c8061393fbe3aa20bb51606c60d01a772d3df536
Author: Phillip Webb <pwebb@vmware.com>
Commit: Chris Beams <cbeams@vmware.com>

    Prevent memory leaks with @Configuration beans
    
    Refactor ConfigurationClassEnhancer to allow cglib caching of
    generated classes.  Prior to this commit each enhanced @Configuration
    class would consume permgen space when created.
    
    The CallbackFilter and Callback Types are now defined as static final
    members so that they can be shared by all enhancers.  Only the
    callbackInstances remain specific to a @Configuration class and
    these are not used by cglib as part of the cache key.
    
    Issue: SPR-9851

[spring-projects-issues]

Juraj Misur commented

No PermGen errors in today's build 3.2.0.BUILD-20121016.200757-324. Thanks a lot!

[spring-projects-issues]

Chris Beams commented

Now backported to 3.1.x:

commit ced6bb4569af81ea86850a4d028d11088488ef1e
Author: Phillip Webb <pwebb@vmware.com>
Commit: Chris Beams <cbeams@vmware.com>

    Prevent memory leaks with @Configuration beans
    
    Refactor ConfigurationClassEnhancer to allow cglib caching of
    generated classes.  Prior to this commit each enhanced @Configuration
    class would consume permgen space when created.
    
    The CallbackFilter and Callback Types are now defined as static final
    members so that they can be shared by all enhancers.  Only the
    callbackInstances remain specific to a @Configuration class and
    these are not used by cglib as part of the cache key.
    
    Issue: SPR-9851
    Backport-Commit: c8061393fbe3aa20bb51606c60d01a772d3df536