title: ClassLoader Leak - Are they worth solving?
body: <p><code>ClassLoader</code> leaks usually result in <em>java.lang.OutOfMemoryError: PermGen</em>.  In the instance of working on application servers you may see this as a result of many redeploys of a common application.  The explanation and possible resolutions to this problem can be seen on these two links. (among others)</p>
  <p><a href="http://frankkieviet.blogspot.com/2006/10/classloader-leaks-dreaded-permgen-space.html" rel="nofollow noreferrer">http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java</a>
  <a href="http://web.archive.org/web/20100223084225/http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/" rel="nofollow noreferrer">http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/</a></p>
  <p>Now for the most part they are easy to get around.  Simply increase the -XX:MaxPermSize and when the inevitable happens, restart the JVM completely.  The problem with trying to solve this is that in large applications many classes can cause the classloader to leak and thus the classes to stay within the permgen.</p>
  <p>Two questions arise from this:</p>
  <p>Is it reasonable to say that an issue like this is better to just increase the max perm size and restart where necessary or should finding a resolution be a higher priority?</p>
  <p>Are there easier ways to resolve a classloader leak?</p>