OutOfmemoryErrors
using JMC. OutOfmemoryErrors
may be seen. However, memory leaks can be detected early, even before such problems occur, by analyzing Java Flight recordings. GarbageCollectorAggregator
MBean under com.sun.management
. .jfr
) opens in JMC. Look at the Automated Analysis Results page. To detect a memory leak focus on the Live Objects section of the page. Here is a sample figure of a recording, which shows heap size issue: Leak$DemoThread
, which in turn holds on to a leaked char[]
class. For further analysis, see the Old Object Sample
event in the Results tab that contains sampling of the objects that have survived. This event contains the time of allocation, the allocation stack trace, the path back to the GC root. OutOfMemoryErrors
may be seen. java
command as shown in the following example: OutMemoryError
, a recording with the prefix hs_oom_pid
is often, but not always, written to the directory in which the JVM was started. An alternative way to get a recording is to dump it before the application runs out of memory using the jcmd
tool, as shown in the following example: jfr
tool located in the java-home/bin
directory to print Old Object Sample events that contain information about potential memory leaks. The following example shows the command and an example of the output from a recording for an application with the pid 16276: lastKnownHeapUsage
element in the Old Object Sample events is increasing over time, from 63.9 MB in the first event in the example to 121.7 MB in the last event. This increase is an indication that there is a memory leak. Most applications allocate objects during startup and then allocate temporary objects that are periodically garbage collected. Objects that are not garbage collected, for whatever reason, accumulate over time and increases the value of lastKnownHeapUsage
. allocationTime
element to see when the object was allocated. Objects that are allocated during startup are typically not memory leaks, neither are objects allocated close to when the dump was taken. The objectAge
element shows for how long the object has been alive. The startTime
and duration
elements are not related to when the memory leak occurred, but when the OldObject
event was emitted and how long it took to gather data for it. This information can be ignored. object
element to see the memory leak candidate; in this example, an object of type java.util.HashMap$Node. It is held by the table
field in the java.util.HashMap class, which is held by java.util.HashSet, which in turn is held by the users
field of the Application class. root
element contains information about the GC root. In this example, the Application class is held by a stack variable in the main thread. The eventThread
element provides information about the thread that allocated the object. -XX:StartFlightRecording:settings=profile
option, then the recording also contains the stack trace from where the object was allocated, as shown in the following example: HashSet
when the storeUser(String, String)
method was called. This suggests that the cause of the memory leak might be objects that were not removed from the HashSet
when the user logged out. -XX:StartFlightRecording:settings=profile
option due to overhead in certain allocation-intensive applications, but is typically OK when debugging. Overhead is usually less than 2%. path-to-gc-roots=true
creates overhead, similar to a full garbage collection, but also provides reference chains back to the GC root, which is usually sufficient information to find the cause of a memory leak. java.lang.OutOfMemoryError
error is thrown when there is insufficient space to allocate an object in the Java heap. java.lang.OutOfMemoryError
exception. 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
can be thrown when an excessive amount of time is being spent doing garbage collection, and little memory is being freed. java.lang.OutOfMemoryError
exception is thrown, a stack trace is also printed. 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). 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: 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. 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. java.lang.OutOfMemoryError
exception for GC Overhead limit exceeded can be turned off with the command-line flag -XX:-UseGCOverheadLimit
. OutOfMemoryError
will be thrown with the reason “Requested array size exceeds VM limit.' 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. 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. 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. OutOfMemoryError
exception is thrown, you might need to use troubleshooting utilities on the operating system to diagnose the issue further. See Native Operating System Tools. 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. 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. –klass
metadata, and other metadata. Only klass
metadata is stored in the space bounded by CompressedClassSpaceSize
. The other metadata is stored in Metaspace
. OutOfMemoryError
exception is thrown, you might need to use native utilities of the OS to further diagnose the issue. See Native Operating System Tools. malloc
system call returns null
if there is no memory available. If the return from malloc
is not checked, then the application might crash when it attempts to access an invalid memory location. Depending on the circumstances, this type of issue can be difficult to locate. -XX:+PrintClassHistogram
command-line option, then the Control+Break handler will produce a heap histogram.jmap
utility to get a heap histogram from a running process:jcmd
, instead of jmap
utility for enhanced diagnostics and reduced performance overhead. See Useful Commands for the jcmd Utility.The command in the following example creates a heap histogram for a running process using jcmd
and results similar to the following jmap
command. jhsdb jmap
utility to get a heap histogram from a core file, as shown in the following example.-XX:+CrashOnOutOfMemoryError
command-line option while running your application, then when an OutOfMemoryError
exception is thrown, the JVM will generate a core dump. You can then execute jhsdb jmap
on the core file to get a histogram, as shown in the following example. OutOfMemoryError
exception was caused by the number of byte
arrays (2108 instances in the heap). Without further analysis it is not clear where the byte arrays are allocated. However, the information is still useful. OutOfMemoryError
exception is thrown with the 'Java heap space' detail message, the cause can be excessive use of finalizers. To diagnose this, you have several options for monitoring the number of objects that are pending finalization: jmap
utility can be used with the -finalizerinfo
option to print information about objects awaiting finalization.getObjectPendingFinalizationCount
method of the java.lang.management.MemoryMXBean
class. Links to the API documentation and example code can be found in Custom Diagnostic Tools. The example code can easily be extended to include the reporting of the pending finalization count.total_allocated
variable to verify that it made sense. The preceding code could also be expanded to save in a linked list the allocations that remained, and report where the leaked memory was allocated. This is a localized and portable way to track memory allocations in a single set of sources. You would need to ensure that debug_free() was called only with the pointer that came from debug_malloc(), and you would also need to create similar functions for realloc(), calloc(), strdup(), and so forth, if they were used. /Md
and /Mdd
compiler options that will automatically include extra support for tracking memory allocation.mtrace
and libnjamd
to help in dealing with allocation tracking.