Documentation Contents
Java Platform, Standard Edition Troubleshooting Guide
Contents Previous Next

# 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.

Exception in thread thread_name: java.lang.OutOfMemoryError: Java heap space
  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.

Exception in thread thread_name: java.lang.OutOfMemoryError: GC Overhead limit exceeded
  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`.

Exception in thread thread_name: Requested array size exceeds VM limit
  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.

Exception in thread thread_name: java.lang.OutOfMemoryError: Metaspace
  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.

Exception in thread thread_name: java.lang.OutOfMemoryError: request size bytes for reason. Out of swap space?
  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.

Exception in thread thread_name: java.lang.OutOfMemoryError: Compressed class space
  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`.

Exception in thread thread_name: java.lang.OutOfMemoryError: reason stack_trace_with_native_method
  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.

Contents Previous Next

Copyright © 1993, 2026, Oracle and/or its affiliates. All rights reserved.
Contact Us