If you want to avoid the dreaded java.lang.OutOfMemoryError: Metaspace
/ PermGen space
,
just include this library into your Java EE application and it should take care of the rest!
To learn more about classloader leaks, their causes, types, ways to find them and known offenders, see blog series here: http://java.jiderhamn.se/category/classloader-leaks/
In a Servlet 3.0+ environment, all you need to do is include this Maven
dependency in your .war
:
<dependency>
<groupId>se.jiderhamn.classloader-leak-prevention</groupId>
<artifactId>classloader-leak-prevention-servlet3</artifactId>
<version>2.7.0</version>
</dependency>
If you run into problems with the Servlet 3.0 module, try the Servlet 2.5 alternative below.
Since the Servlet spec does not guarantee the order of ServletContainerInitializer
s,
it means this library may not initialize first and clean up last in case you have other Servlet 3.0 dependencies, which
could lead to unexpected behaviour.
For Servlet 2.5 (and earlier) environments, you need to use a different
Maven dependency (notice the difference in artifactId
):
<dependency>
<groupId>se.jiderhamn.classloader-leak-prevention</groupId>
<artifactId>classloader-leak-prevention-servlet</artifactId>
<version>2.7.0</version>
</dependency>
You also have to add this to your web.xml
:
<listener>
<listener-class>se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventorListener</listener-class>
</listener>
Note that the name of the listener class has changed since 1.x!
It makes sense to keep this listener "outermost" (initializing first,
destroying last), so you should normally declare it before any other
listeners in web.xml
.
The context listener used in both cases has a number of settings that can be configured with context parameters in web.xml
:
<context-param>
<param-name>ClassLoaderLeakPreventor.stopThreads</param-name>
<param-value>false</param-value>
</context-param>
The available settings are
Parameter name | Default value | Description |
---|---|---|
ClassLoaderLeakPreventor.stopThreads |
true |
Should threads tied to the web app classloader be forced to stop at application shutdown? |
ClassLoaderLeakPreventor.stopTimerThreads |
true |
Should Timer threads tied to the web app classloader be forced to stop at application shutdown? |
ClassLoaderLeakPreventor.executeShutdownHooks |
true |
Should shutdown hooks registered from the application be executed at application shutdown? |
ClassLoaderLeakPreventor.startOracleTimeoutThread |
true |
Should the oracle.jdbc.driver.OracleTimeoutPollingThread thread be forced to start with system ClassLoader,
in case Oracle JDBC driver is present? This is normally a good idea, but can be disabled in case the Oracle JDBC
driver is not used even though it is on the classpath.
|
ClassLoaderLeakPreventor.threadWaitMs |
5000 (5 seconds) |
No of milliseconds to wait for threads to finish execution, before stopping them. |
ClassLoaderLeakPreventor.shutdownHookWaitMs |
10000 (10 seconds) |
No of milliseconds to wait for shutdown hooks to finish execution, before stopping them. If set to -1 there will be no waiting at all, but Thread is allowed to run until finished. |
The test framework has its own Maven module and its own documentation, see classloader-leak-test-framework.
For non-servlet environments, please see the documentation for the core module.
This project is licensed under the Apache 2 license, which allows you to include modified versions of the code in your distributed software, without having to release your source code.