Java PermGen Memory Leak when Redeploying a Web Application
April 29, 2010 | Development, Java by Chris |
As I suspect may typically be the case, it started with java.lang.OutOfMemoryError: PermGen space after restarting/redeploying one of my web applications several times. It ended with my moving application libraries from the deployed web application library folder to the web server’s shared library folder. I learned a lot, but it would have been nice to see this suggestion much sooner.
Research and Initial Attempts
I started with a little background provided by Frank Kieviet. I played around with jhat and jmap for a while, but noticed that the problem was too extensive for me to find a reasonable solution simply by pruning references. I did some more searching and came across solutions like adjusting the JVM garbage collection behavior, using another JVM, increasing the available PermGen space, pruning references that can typically cause problems when redeploying web applications by way of the servlet destroy method, and even that there was no solution and web server restarts were the only solution! I either tried these solutions or disregarded them based on their evaluation of what the problem really was.
None of this seemed to have any impact, so I decided to dive into pruning all unnecessary references when the servlet was destroyed. It slowly became clear that links from my application libraries were part of the problem. These were either all or mostly static links from enums. These were references to my application that I couldn’t seem to control. I thought that there might be some problem with enums in Java, or some special solution to break those references, but nothing seemed to be mentioned. Even Sun’s own troubleshooting guide only has a very simple approach to PermGen memory leaks, which only accounts for legitimate shortages of PermGen space.
My options were to:
- imagine that Java was seriously flawed,
- the immensely popular implementations of it were seriously flawed,
- my application was seriously flawed beyond my own current or near-future understanding of Java
- or there was some very simple solution that people were dancing around.
Despite being new to Java and Linux with my share of problem-induced, multi-day solution-searching sessions, I have almost only found solutions that are surprisingly simple and elegant.
The Solution
My faith was rewarded when I came to the idea of moving my application libraries to a shared location. I can’t really–nor do I think it’s necessary to–explain the feeling when I restarted my web application 20 times and saw no increase in memory utilization. That reward continues to pay as I haven’t had to restart my web server since, and have restarted my web applications at least 100 times.
Background Information
To provide a little background information, I have been using Java seriously for only a few months, and am using IcedTea6, and Glassfish v3. I am still fairly certain that this solution will be applicable in many JVMs and web servers. Especially, since it is often the default to package libraries with compiled applications.
