Modern Classloaders and Classloader Leaks, Page 2

Modern Classloaders

Having a hierarchy of classloaders is not always enough; modern classloaders, including OSGi, take the approach of having one classloader per module. All classloaders may refer to each other and share a central repository, and each module declares the packages it imports and exports. Given a package name, the common repository is able to find relevant classloaders.

Troubleshooting issues with modern classloaders is similar to troubleshooting issues with a classloader hierarchy, except a developer must think in terms of export/import as well as the classpath.

Here are the problems with the modern approach:

Import is a one-way street: if you want to use Hibernate, you import it but it cannot access your classes.

Leaking is perhaps even more problematic: the more classloaders, the more references between them, the easier leaking becomes.

Deadlocks may happen as the JVM enforces a global lock on loadClass( ).

How Can We Fix Classloader Leaks?

Isolating modules or applications through classloaders is an illusion: leaks can and will happen. The natural abstraction for isolation is a process -- this is understood widely outside of Java: .NET, dynamic languages and even browsers use processes for isolation.

A separate process for each application is the only approach to isolation that supports leakless updates.

The best possible solution for Java EE production applications is running one Web application per application container and using rolling restarts with session draining to ensure the new version will start without any side effects from the previous one. This Continuous Delivery approach is found in tools that automatically run no downtime rolling restarts for Web applications.