Java Reference
In-Depth Information
need to look into whatever native memory issue is mentioned in the error. For example, the
following message tells you that the native memory for thread stacks is exhausted:
Exception in thread "main" java.lang.OutOfMemoryError:
unable to create new native thread
Out of permgen or metaspace memory
This memory error is also not associated with the heap—it occurs because the permgen (in
Java 7) or the metaspace native memory (in Java 8) is full. The root cause can be two things:
the first is simply that the application uses more classes than can fit in the default perm
space; the solution to that is to increase the size of permgen (see Sizing Permgen and
Metaspace ). (As in Chapter 5 , the discussion in this section refers to permgen for simplicity;
the same issues can occur with the Java 8 class metaspace if its maximum size is set.)
The second case is trickier: it involves a classloader memory leak. This occurs most fre-
quently in a Java EE application server. Each application that is deployed to an app server
runs in its own classloader (that provides isolation, so that classes from one application are
not shared with—and do not interfere with—classes from another application). In develop-
ment, each time the application is changed, it must be redeployed: a new classloader is cre-
ated to load the new classes, and the old classloader is allowed to go out of scope. Once the
classloader goes out of scope, the class metadata can be collected.
If the old classloader does not go out of scope, then the class metadata cannot be freed, and
eventually permgen will fill up and throw an out of memory error. In this case, increasing the
size of permgen will help, but ultimately that will simply postpone the error.
If this situation occurs in an app server environment, there is little to do but contact the app
server vendor and get them to fix the leak. If you are writing your own application that cre-
ates and discards lots of classloaders, then take care to make sure the class loaders them-
selves are discarded correctly (in particular, make sure that no thread sets its context class-
loader to one of the temporary classloaders). To debug this situation, the heap dump analysis
just described is quite helpful: in the histogram, find all the instances of the ClassLoader
class, and trace their GC roots to see what is holding onto them.
The key to recognizing this situation is again the full-text output of the out of memory error.
In Java 8, if the metaspace is full the error text will appear like this:
Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
Search WWH ::




Custom Search