When coding with Java, the developers typically do not manage the memory usage themselves; JVM manages the memory on its own. This is a concept that was non-existent in C/C++ and brought a lot of excitement among developers, playing an critical role in Java language’s rising popularity all over the world. But despite its revolutionary concept, memory problems still occur in Java. Though not as frequently as C/C++, OutOfMemoryError is occasionally encountered, causing headaches for many administrators and developers.

Java OutOfMemoryError Types

Cause of OutOfMemoryError can be broken down into 3 major categories :(1)when there is not enough memory allocated, (2)when a heavy service is executed, (3) or when there is a memory leak. In case of reason (1), the memory shortage is not due to any program error or bug, but the allocated memory is simply not enough to handle the task at hand, thus in this case increasing the –Xmx parameter usually solves the memory shortage issue. Sometimes the developer or administrator would forget to include the memory allocation parameter (ex: -Xmx512m) or miss type the parameter, and other times the allocation may have been set too low despite the high volume of Service Arrival Rate simply because the administrator just didn’t know about it. Reason (2) is due to applicable program/service using too much memory at once. Loading too much data from the database or running inefficient searches are some of the examples. Other frequently encountered examples include setting the byte[] buffer size too big in upload/download program, or multiple requests arriving at the same time, causing more burden on the memory in than it can handle. In case of latter, determining whether application is simply using a lot of memory due to its load or if there is a bug in the program can be a difficult task. Finally, (3) reason is due to MEMORY LEAK. Memory leak is when the GC fails to recover the used memory due to strong reference, thus the memory usage continues to increase. A prime example can be when the JDBC class does not call on close(). Another cause of memory leak is when the cache logic is not designed correctly. When unnecessary data in cache is not cleared due to poorly designed GC, OutOfmemoryError may occur.

OutOfMemoryError Cause Analysis

When OutOfMemoryError is encountered on the screen or in the log, an accurate cause analysis must be performed. If the root cause is simply miss-configured JVM memory setting, the error will show up during startup or a short time after the startup. Thus if you see the error during startup, check the memory option parameter first. In case of PERM area, it may take a little more time after startup for the error message to appear. If OutOfMemoryError occurs while there is plenty of HEAP memory and SUN/HP JVM is used, check the PERM area memory setting to make sure enough memory is allocated there.

If (2) heavy load application is executed, what kind of phenomenon can be observed? Look at the HEAP Memory graph on Jennifer Dashboard; the memory usage typically increases and the GC becomes more frequent. If the memory usage does not increase gradually but suddenly along with increased frequency in GC, over-usage of specific application memory usage can be speculated. Incase of IBM JVM, if there is plenty of HEAP memory available and GC is not running frequently, then OutOfMemoryError suddenly occurs, investigate the fragmentation in the continuity space(?).

Lastly, when memory leak occurs, Heap Memory Usage graph may indicate increasing memory usage over time. Memory leak require long observation time, it can be a few hours or months until the leak occurs after the server is started.

Jennifer and OutOfMemoryError.

If the error occurs because of simple miss-configuration, correcting the setting will fix the problem, but if the error is due to specific application, a more scientific approach is necessary.

First task is to determine which application is causing the error. If the application’s function is uploading/downloading, check the buffer size it uses first and if it interfaces with database, check the DB access data quantity first. Jennifer collects and saves the error information when OutOfMemoryError occurs. When observed through X-View, the application with highest response time or CPU usage is the culprit.

Memory Leak is the most difficult type of memory problem to solve. It requires a long time to find and it’s difficult to reproduce it in a development/test environment. In order to confirm memory leak, gradual memory usage increase over time must be observed. Thus a display that allows user to monitors heap memory usage throughout the day is necessary. Jennifer provides such feature.

System that uses IBM JVM can find memory leak problem via HEAP DUMP, but it’s a different story with SUN/HP. To trouble shoot, specific application is called multiple times and the memory usage change observed but doing this in a production environment is next to impossible. HEAP analysis through -Xrunhprof:heap option is also available but this method is not practical in a production environment also. Thus the memory leak problem must be analyzed and resolved by an APM solution.

Jennifer has several features prepared just for this kind of situation. Jennifer detects JDBC resource status perfectly. When Memory Leak occurs, correcting unreturned JDBC Resource is recommended.

Also Jennifer provides Collection/Map class size monitoring capability; this unique capability is only available in Jennifer. While performing IBM JVM/HEAP DUMP analysis, I found that majority of Memory LEAK occurs in Collection/MAP type class. Error occurring while storing Collection/Map data in Cache/Pool component was the most frequent cause of memory leak. This means that if the Collection/Map count can be monitored over time, memory leak can easily detected. Jennifer has this capability.

Another feature in Jennifer 3.2 and above is that it can monitor static Collection/Map data in specified jar files. Element count trace is also possible.

Jennifer is a practical solution that can be readily used with ease in production environment.