3.2 Understand the OutOfMemoryError Exception
One common indication of a memory leak is the java.lang.OutOfMemoryError exception. Usually, this error is thrown when there is insufficient space to allocate an object in the Java heap. In this case, The garbage collector cannot make space available to accommodate a new object, and the heap cannot be expanded further. Also, this error may be thrown when there is insufficient native memory to support the loading of a Java class. In a rare instance, a java.lang.OutOfMemoryError may be thrown when an excessive amount of time is being spent doing garbage collection and little memory is being freed.
When a java.lang.OutOfMemoryError exception is thrown, a stack trace is also printed.
The java.lang.OutOfMemoryError exception can also be thrown by native library code when a native allocation cannot be satisfied (for example, if swap space is low).
An early step to diagnose an OutOfMemoryError exception is to determine the cause of the exception. Was it thrown because the Java heap is full, or because the native heap is full? To help you find the cause, the text of the exception includes a detail message at the end, as shown in the following exceptions.
Cause: The detail message Java heap space indicates object could not be allocated in the Java heap. This error does not necessarily imply a memory leak. The problem can be as simple as a configuration issue, where the specified heap size (or the default size, if it is not specified) is insufficient for the application.
In other cases, and in particular for a long-lived application, the message might be an indication that the application is unintentionally holding references to objects, and this prevents the objects from being garbage collected. This is the Java language equivalent of a memory leak. Note: The APIs that are called by an application could also be unintentionally holding object references.
One other potential source of this error arises with applications that make excessive use of finalizers. If a class has a finalize method, then objects of that type do not have their space reclaimed at garbage collection time. Instead, after garbage collection, the objects are queued for finalization, which occurs at a later time. In the Oracle Sun implementation, finalizers are executed by a daemon thread that services the finalization queue. If the finalizer thread cannot keep up, with the finalization queue, then the Java heap could fill up and this type of OutOfMemoryError exception would be thrown. One scenario that can cause this situation is when an application creates high-priority threads that cause the finalization queue to increase at a rate that is faster than the rate at which the finalizer thread is servicing that queue.
Action: You can find more information about how to monitor objects for which finalization is pending in Monitor the Objects Pending Finalization. See Finalization and Weak, Soft, and Phantom References in Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide for information about detecting and migrating from finalization.
Cause: The detail message «GC overhead limit exceeded» indicates that the garbage collector is running all the time and Java program is making very slow progress. After a garbage collection, if the Java process is spending more than approximately 98% of its time doing garbage collection and if it is recovering less than 2% of the heap and has been doing so far the last 5 (compile time constant) consecutive garbage collections, then a java.lang.OutOfMemoryError is thrown. This exception is typically thrown because the amount of live data barely fits into the Java heap having little free space for new allocations.
Action: Increase the heap size. The java.lang.OutOfMemoryError exception for GC Overhead limit exceeded can be turned off with the command line flag -XX:-UseGCOverheadLimit .
Cause: The detail message «Requested array size exceeds VM limit» indicates that the application (or APIs used by that application) attempted to allocate an array with a size larger than the VM implementation limit, irrespective of how much heap size is available.
Action: Ensure that your application (or APIs used by that application) allocates an array with a size less than the VM implementation limit.
Cause: Java class metadata (the virtual machines internal presentation of Java class) is allocated in native memory (referred to here as metaspace). If metaspace for class metadata is exhausted, a java.lang.OutOfMemoryError exception with a detail MetaSpace is thrown. The amount of metaspace that can be used for class metadata is limited by the parameter MaxMetaSpaceSize , which is specified on the command line. When the amount of native memory needed for a class metadata exceeds MaxMetaSpaceSize , a java.lang.OutOfMemoryError exception with a detail MetaSpace is thrown.
Action: If MaxMetaSpaceSize , has been set on the command-line, increase its value. MetaSpace is allocated from the same address spaces as the Java heap. Reducing the size of the Java heap will make more space available for MetaSpace . This is only a correct trade-off if there is an excess of free space in the Java heap. See the following action for Out of swap space detailed message.
Cause: The detail message «request size bytes for reason . Out of swap space?» appears to be an OutOfMemoryError exception. However, the Java HotSpot VM code reports this apparent exception when an allocation from the native heap failed and the native heap might be close to exhaustion. The message indicates the size (in bytes) of the request that failed and the reason for the memory request. Usually the reason is the name of the source module reporting the allocation failure, although sometimes it is the actual reason.
Action: When this error message is thrown, the VM invokes the fatal error handling mechanism (that is, it generates a fatal error log file, which contains useful information about the thread, process, and system at the time of the crash). In the case of native heap exhaustion, the heap memory and memory map information in the log can be useful. For more information about understanding the fatal error log file, see Appendix A.
If this type of the OutOfMemoryError exception is thrown, you might need to use troubleshooting utilities on the operating system to diagnose the issue further. For more information about tools available for various operating systems, see Native Operating System Tools.
Cause: On 64-bit platforms a pointer to class metadata can be represented by a 32-bit offset (with UseCompressedOops ). This is controlled by the command line flag UseCompressedClassPointers (on by default). If the UseCompressedClassPointers is used, the amount of space available for class metadata is fixed at the amount CompressedClassSpaceSize . If the space needed for UseCompressedClassPointers exceeds CompressedClassSpaceSize , a java.lang.OutOfMemoryError with detail Compressed class space is thrown.
Action: Increase CompressedClassSpaceSize to turn off UseCompressedClassPointers . Note: There are bounds on the acceptable size of CompressedClassSpaceSize . For example -XX: CompressedClassSpaceSize=4g , exceeds acceptable bounds will result in a message such as
CompressedClassSpaceSize of 4294967296 is invalid; must be between 1048576 and 3221225472.
Note: There is more than one kind of class metadata — klass metadata and other metadata. Only klass metadata is stored in the space bounded by CompressedClassSpaceSize . The other metadata is stored in Metaspace .
Cause: If the detail part of the error message is » reason stack_trace_with_native_method » and a stack trace is printed in which the top frame is a native method, then this is an indication that a native method has encountered an allocation failure. The difference between this and the previous message is that the allocation failure was detected in a Java Native Interface (JNI) or native method rather than in the JVM code.
Action: If this type of the OutOfMemoryError exception is thrown, you might need to use native utilities of the OS to further diagnose the issue. For more information about tools available for various operating systems, see Native Operating System Tools.
Symptoms
You found «java.lang.OutOfMemoryError: Java heap space» in std_server.out.
Description
This error indicates that an object failed to be allocated in Java heap.
This may indicate inappropriate VM configuration (compared to actual workload), or a memory leak.
Solution
First the Java system administrator should make sure the VM memory parameter is carefully set.
Step 2 Check defaultTrace file.
Find the entry on corresponding time point:
java.lang.OutOfMemoryError: Java heap space (failed to allocate XXXXX bytes)
If the size of bytes (XXXX) is more than 200 million (200MB), the coming request might not be reasonable.
Check the call stack, to see who’s generating such request.
Heap dump will tell us what was occupying the VM memory.
Step 4 Check ../work/std_server.out file and locate the OutOfMemoryError event and determine which part of the heap size is filled. You will see something like this:
J Tue Oct 18 21:11:01 2016 J : [140657363408640] 21:11:01 ***ERROR (:0): OutOfMemoryError: Could not allocate 104 bytes J 2668659.725: [GC 2668659.725: [GC 2668659.725: [ParNew: 356809K->356809K(1222144K), 0.0000283 secs] 3150281K->3150281K(4015616K), 0.0000866 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] J [1 CMS-initial-mark: 2793471K(2793472K)] 3150281K(4015616K), 0.2217318 secs] [Times: user=0.21 sys=0.00, real=0.22 secs]
In this example the old generation of the heap memory is filled ( 2793471K while the total size is 2793472K ). So the conclusion is that the total heap size is far from being full, still an OutOfMemoryError occured. It is possible that other areas of the heap gets filled as well.
A possible solution is to increase the heap size (-Xms and -Xmx parameters) to prepare the system for higher load. We have to note here, increasing the heap size is not always a solution. If the root cause is a bug that causes memory leak, all the memory will be filled over time, so obviously increasing the heap will not help in these cases.
Step 5 If the previous steps do not solve the problem, report it :
-
- Attach work folder *
- Attach defaultTrace *
- Attach heap dump analysis report
* The work folder and defaultTrace file should cover the time point / time period when issue occurred.