When the Java VM runs low on memory, you should see two behaviors:

To confirm the presence of a memory leak, add -verbose:gc to your JAVA_ARGS and monitor the number of sessions on your site (see the Garbage Collection section for details). If you see free memory decrease over time as your site has a constant number of sessions, you may have a memory leak. Before deciding that you have a memory leak, make sure you have given the system enough time to fill all caches and reach a stable state after startup.

Memory leaks in Java are caused by data structures that hold onto objects that are no longer needed. This is often due to a Collection (such as a Vector or Hashtable) that is not coded correctly. For example, if you store objects in a Hashtable using a session ID as a key, but you do not remove these objects when the session expires, this Hashtable will grow without bounds.

You can use memory profilers to help find these errors. Another way to detect when a Hashtable or Vector is growing without bounds is to use a modified version of the standard Hashtable and Vector that is instrumented to print a message each time the 10000th, 20000th, etc. element is added. Of course, if you use a different Collection class, this will not find that problem.

One frequent cause of Java memory leaks is the use of an addXXXListener() method without a corresponding removeXXXListener() method. Review your code to make sure you have not made this mistake.