So if you were familiar with PermGen then all you need to know as background is that – whatever was in PermGen before Java 8 (name and fields of the class, methods of a class with the bytecode of the methods, constant pool, JIT optimizations etc) – is now located in Metaspace.
As you can see, Metaspace size requirements depend both upon the number of classes loaded as well as the size of such class declarations. So it is easy to see the main cause for the java.lang.OutOfMemoryError: Metaspace is: either too many classes or too big classes being loaded to the Metaspace.
Classloader Leak
A classloader leak happens when an application is redeployed, but there are lingering instances of the previous deployment’s classes left. These lingering instances prevent their Classes from being garbage collected, which, in turn, prevent the classloaders and all the classes held therein from being collected, too. Here’s an example of that situation:
Apparently, the application starts a thread that cleans up connections. As noble of a goal as it is, the application does not stop the thread on un-deploy, so it keeps hold of the classloader. Cleanup threads and Timer threads are by far the most common reason for the leaks. A simple way of fixing this issue would be to add a shutdown hook by implementing a ServletContextListener:
public class CleanupCleanup implements ServletContextListener {
@Override
public void contextDestroyed(ServletContextEvent sce) {
// Stop the cleanup thread
}
//...
}