Forem: JillThornhill

The Finalizer Problem: A Deeper Look into OutOfMemoryError Due to Unclosed Resources

JillThornhill — Fri, 23 Jan 2026 08:00:36 +0000

The finalize() method of the Java class object, which can be overridden by any Java class, was deprecated as of Java 9. It will eventually be discontinued. Why?

This article takes a look at exactly how the finalize() method works, when it’s run, and how badly things can go wrong. Using this method can result in unclosed resources, wasted Java heap space, and ultimately to OutOfMemoryErrors.

Let’s see how this can happen, how to diagnose finalize() problems, and what we should do instead of using finalize().

Troubleshooting OutOfMemoryError: Java Heap Space

Before we start, if you’re not familiar with troubleshooting OutOfMemoryErrors, you may like to read this article: Java OutOfMemoryError: Heap Space. It gives some background into how to understand, find and fix memory issues.

Another useful article on this topic deals with the 9 different types of java.lang.OutOfMemoryError.

Unclosed Resources

Let’s now take a look at what we mean by unclosed resources.

Examples of resources include:

Heap and native memory;
File Descriptors;
Operating system handles;
Network sockets;
Database connections.

Many classes that manage these resources, such as the Stream classes, have a close() method. This releases any associated resources. It’s important to call this method when the resources are no longer needed. If they don’t have one, we must ensure the objects are released for garbage collection in a timely manner.

During the early years of Java, we were told that it was good practice to include these cleanup operations in a finalize() method, which would ensure all resources were released when the object was garbage collected.

Fairly soon, this was found to be unreliable, as we’ll see in the next section.

When is finalize() Executed?

To keep redundant memory from building up, a JVM process known as the garbage collector (GC) runs in the background. On each cycle, it:

Works from GC roots to identify and mark all memory items that still have live references;
For each unmarked item, the GC marks it as finalizable. If it has a finalize method, it’s added to the finalize queue; if not, GC marks it as eligible for deletion.;
Removes all objects eligible for deletion.

The JVM has a single finalize queue, which is not multi-threaded. It works sequentially through the queue, running the finalize() method of each object. Once the finalize() method has completed, the object is marked as eligible for deletion, and it will be removed on the next GC cycle.

At best, an object that has a finalize() method, and all its children, remain in memory for two GC cycles instead of just one. If it has a large retained memory, this can be significant.

It’s highly possible it will remain in memory for much longer. If a lot of objects are waiting to be finalized, it may be a while before they get to the front of the queue, and for all this time, they are retaining unneeded memory. This becomes more serious if a queued object is holding locks that may be needed by other processes, or unclosed resources.

At worst, a single object in the queue may have a slow finalize() method, and the entire queue is held up until it completes. If it hangs waiting for a resource or a lock to be available, it can result in a memory leak and, eventually, an OutOfMemoryError.

The other danger with using the finalize() method is that it may, in fact, never be executed at all. The object may still be in the queue when the program exits. If finalize() was used for important actions, such as database commits, this could result in data loss.

The bottom line is: the developers of the JVM cannot guarantee when, or even if, the finalize() method will be run. It’s therefore been recognized as dangerous, and that’s why it has been deprecated.

How To Diagnose Finalizer Problems

Let’s take a small sample program that demonstrates the effect of slow finalizers. This application creates several instances from a class, BuggyClass, that deliberately has a hanging finalizer.

// This demonstrates a hanging finalizer, and how it causes memory to be retained
// even though a weak reference is used.
// ==============================================================================
import java.lang.ref.WeakReference;

public class BuggyProg {
// Public class creates an object from TestClass
// =============================================
    public static void main(String[] args) {
    TestClass a = new TestClass();
    }
}

// Test class creates a number of instances of BuggyClass using weak references


class TestClass {

   public TestClass() {
       WeakReference<BuggyClass> a=null;
       WeakReference<BuggyClass> b=null;
       WeakReference<BuggyClass> c=null;
       WeakReference<BuggyClass> d=null;
       WeakReference<BuggyClass> e=null;
       WeakReference<BuggyClass> f=null;
       WeakReference<BuggyClass> g=null;
       WeakReference<BuggyClass> h=null;
       WeakReference<BuggyClass> i=null;

       methodA(a);
       methodA(b);
       methodA(c);
       methodA(d);
       methodA(e);
       methodA(f);
       methodA(g);
       methodA(h);
       methodA(i);
       try 
              {Thread.sleep(150000);}
       catch (Exception ex){}
    }
    public void methodA(WeakReference a) {
         a = new WeakReference<BuggyClass>(new BuggyClass());
    }
}

// BuggyClass creates a large array, and has a hanging finalizer
// It prints a message to indicate when the finalize method is run
// ===============================================================
class BuggyClass {
   int[] a = new int[2000000];
   public BuggyClass() {
   }

   public void finalize() {
     System.out.println("Finalizing");
     while(true)  
        a[1]=100;
   }
}

This program creates several instances of the class BuggyClass, which is released very quickly for garbage collection. This is because they’re created with weak references.

BuggyClass deliberately has a finalizer that hangs. It displays a message ‘Finalizing’ when the finalizer runs.

Let’s see what happens when we run the program.

c:\javadev\articles\demos>java BuggyProg
Finalizing

c:\javadev\articles\demos>

Despite the fact that we created multiple instances of BuggyClass, and made them available for GC, only ONE of these finalize() methods has been initiated. This is because the other instances were still waiting in the finalizer queue when the program completed. They will never be run at all.

So how can we tell if we have objects waiting in the finalizer queue?

The easiest way is to take a heap dump, and run the HeapHero tool. This produces a comprehensive heap analysis report, including an interactive section that lists the finalizer queue. We can drill down from this section to see the actual classes of objects awaiting finalization, as per the image below.

Fig: Finalizer Report by HeapHero

What Should We Use Instead of finalize()?

When we create our own classes, we should use a close() method instead of finalize() for any cleanup operations. Of course, we need to document the fact that any application using this class must use this method to release resources.

When we use other classes, we should always check if they have a close() method, and call it when the task is completed.

Alternatively, we can use the try-with-resources construct to automatically release resources when the block completes.

Conclusion

The finalize() method has been deprecated with good reason. It can cause hard-to-find problems with Java heap space, as well as other issues such as running out of available file descriptors. Instead, we should put any cleanup code into a close() method.

We also need to be meticulous about calling the close() method of resource-hungry classes such as streams, and ensure all our objects are released for garbage collection as soon as we’ve finished with them.

The HeapHero tool is ideal for diagnosing finalizer problems, since it contains an explicit list of any objects in the finalizer queue.

Avoiding "Out of Memory" Errors: Strategies for Efficient Heap Dump Analysis

JillThornhill — Wed, 10 Dec 2025 16:26:11 +0000

Most of us have seen this unwelcome exception in Java: java.lang.OutOfMemoryError. In testing, this is annoying. In production, it can be disastrous.

In live systems, we’re likely to see degraded performance followed by an OutOfMemory crash. The repercussions can include unhappy customers, overwhelmed support staff, loss of revenue and shouting managers. This is not anyone’s idea of a happy day.
Can OutOfMemoryErrors be avoided? How?

This article answers those questions.

Too many administrators just increase the heap size haphazardly. Instead, we’ll look at how to use a memory analyzer throughout the project lifecycle to make informed decisions.

Why Shouldn’t We Just Increase Heap Size?

Here are a few good reasons why simply increasing the heap size is not a good idea.

If we have a memory leak, increasing the size will be at best a very temporary solution, since memory usage will eventually exceed the new limit.
Not all memory problems relate to the heap.
Increasing the heap size may result in depriving other areas of the JVM, or even the device as a whole, of memory.
Several other factors, such as the choice of garbage collection algorithms, could be the root cause of the problem. Increasing the heap size would not solve these problems.

So, what’s the solution?

Firstly, if the heap runs out of memory, we need to use a heap dump analyzer such as HeapHero or Eclipse MAT to examine the heap and discover the cause of the problem. Only then can we figure out how to solve the real problem and prevent it from recurring.

But more importantly, we need to proactively prevent memory problems by making performance analysis an integral part of each phase of the software lifecycle.

Using Memory Analyzers Throughout the Project Lifecycle.

Don’t wait until it breaks.

Let’s see how we can use memory analyzers, and other diagnostic tools, to make sure we never encounter another java.lang.OutOfMemoryError in production.

1. The Planning Stage

Innovative ideas are great. However, all great inventors build prototypes, because it’s seldom possible to predict how things will actually work in real life.

It’s good to get into the habit of building a small trial program to see how much memory we might need to implement our designs. This is especially important if we’re designing for small devices, or for containers. Also, if we’re designing for the cloud, memory usage has a direct impact on monthly running costs.

This is where tools like HeapHero come in. While the program is running, we would dump the heap, as described in these articles:

We can then explore the heap using a heap dump analyzer. You may like to watch this video to see a demonstration of how to analyze a dump with HeapHero.

This takes the guesswork out of design, and lets us evaluate different strategies and make trade-offs as needed. It also gives us a good idea of how much memory the final solution may require, so we can accurately specify the hardware and carry out a cost-benefit analysis.

2. The Development Stage

At the development stage, we can use a memory analyzer in many ways.

Comparing different coding techniques for efficiency.
Checking for memory wastage.
Confirming that actual memory requirements match the original hardware specifications.
Providing memory usage statistics in order to accurately configure the heap size at the testing stage.

3. The Testing Stage

At each phase of testing, we should use a memory analyzer to confirm that memory usage is reasonable, that we have no memory leaks, and obtain more accurate memory usage statistics.

When we come to testing the system as a whole, and particularly in performance labs and stress tests, we should also look at monitoring garbage collection (GC) behavior.

Efficient GC is critical for preventing memory problems. We can use a GC log analysis tool such as GCeasy to make sure the GC is doing its job, and that memory is staying well within configuration limits.

We can also recognize memory leaks and other potential memory issues by analyzing GC patterns. For example, the image below compares the pattern of a healthy application to one with a memory leak. In the memory leak pattern, although GC is clearing some memory on each cycle, it never manages to fully clear it back to the same level. If the memory leak is not resolved, usage will keep growing until we run out of heap memory.

Fig: Memory Usage Graphs from GCeasy: Healthy Application vs Memory Leak

Before we begin performance lab testing, we should think about automating some aspects of memory monitoring, and setting alerts if any problems are detected. There are two ways we can do this:

Both HeapHero and GCeasy offer REST APIs that can be included in testing scripts to automatically analyze the heap dump and the GC logs. They return key information that can be used to flag any issues found.
We can use a monitoring and analysis system such as yCrash. This tool samples the JVM regularly to analyze micrometrics that predict any developing performance issues.

By including performance analysis in our testing, we can identify and fix any bottlenecks, and also provide detailed statistics that can be used for accurate configuration in the live system.

4. Preparing to Go Live

At this stage, we should use memory statistics produced during testing to accurately configure the heap.

We should also set in place monitoring procedures for the live system, so that we will be alerted if performance indicators begin to drop.

5. In Production

Monitoring heap dump usage and GC logs regularly can prevent problems escalating to the point where performance is affected. System usage is likely to grow with time. If we see memory usage increasing, we can alter the JVM configuration to cater for growth.

GC logging should always be enabled in production, as it uses very little overhead. We can then periodically submit logs to a GC log analyzer.

We could set up heap dump extract and analysis as a CRON job that runs periodically. This shouldn’t happen too often, because dumping the heap can take time and reduce performance. It should be scheduled off-peak.

Alternatively, we can set up the yCrash monitor to continuously sample performance, and raise alerts as needed.

6. In CI/CD Pipelines

Incorporating HeapHero and GCeasy REST APIs into the build pipeline is an effective way to prevent new versions introducing memory issues.

We can use them to automatically compare performance indicators with previous builds, and fail the build if we detect unacceptable changes.

The indicators we can monitor include:

Object Creation Rate;
Heap size;
Class Count;
Object count;
Throughput;
Latency;
Memory Wastage Percentage.

Conclusion

We’ve looked at incorporating memory analyzers in all stages of the project lifecycle.

Using this strategy, we can either increase the heap size or optimize the code long before issues result in an OutOfMemoryError. Even if we haven’t done this with existing systems, it’s never too late to start. Including memory monitoring, both in production and in future development cycles, saves a lot of heartache.

Prevention is definitely better than cure.

Don't Just Find the Leak, Fix the Root Cause: A Modern Approach to Memory Analysis

JillThornhill — Tue, 16 Sep 2025 08:10:18 +0000

Your Java application has memory issues: maybe it’s throwing OutOfMemoryErrors, or maybe you’re experiencing degraded performance or frequent timeouts. You suspect a memory leak, and your heap dump analyzer has identified a few leak suspects in the Java heap space.
What next?

In this article we’ll look at some typical coding issues that result in memory leaks, and how to find and fix the problem.

What is a Memory Leak?

A memory leak occurs when a program unnecessarily allocates more and more memory over time. Eventually, the program slows down and finally throws an OutOfMemoryError.

Not all memory problems are leaks: they could be caused by either wasted memory, under-configuring the heap or other memory pools, or lack of RAM in the device or container. The best way to tell if the problem is a memory leak is to analyze the behavior of the garbage collector (GC).

The graphs below were produced by GCeasy, a GC log analyzer, showing heap usage over time. The red triangles indicate full GC events. The first graph shows a healthy GC pattern, whereas the second indicates a memory leak.

Fig: Healthy Memory Pattern vs Memory Leak Pattern

Notice that, although the GC is freeing memory, heap usage continues to increase over time, and the GC runs more and more frequently. As time goes on, GC events run back-to-back in an attempt to clear memory, and performance degrades drastically.

Do All Memory Leaks Occur in the Java Heap Space?

The majority of leaks affect the heap. For a debugging guide for heap memory issues, see this article: Java OutOfMemoryError: Heap Space.

It’s also possible for other areas, such as the metaspace or the direct buffer space, to suffer from memory leaks. In fact, there are nine different types of OutOfMemoryErrors in Java. We can distinguish the type of error by examining the error message.

How Do We Troubleshoot OutOfMemoryErrors?

To effectively find memory leaks we need to examine:

The error message, to determine the error type;
Garbage Collection logs, which can be analyzed by a tool such as GCeasy;
A heap dump, which can be analyzed by a dump analyzer such as HeapHero or Eclipse MAT;
The stack trace, which is displayed after the error message. This shows the line at which the error occurred, followed by the path the program took to reach that point.

The error message tells us which area of the JVM memory has run out of space. The GC logs indicate whether the issue is a memory leak, or just excess memory usage. If the problem lies with the Java heap space, we can use a heap dump analyzer to find and trace the ownership of the largest objects in memory.

For a demonstration of how to do this, it’s worth watching this video: How to Analyze a Heap Dump Fast.

Finally, working back through the stack trace helps us locate the offending code.

Typical Causes of Memory Leaks and How to Fix Them

In this section, we’ll look at a few of the causes of memory leaks, with hints on how to fix the code. Most, though not all, leaks will fit into these categories.

1. Forever-growing Object

This is one of the two most common symptoms of memory leaks. A collection or cache continues to grow over time, until it causes memory problems. Causes include:

The program is not preventing duplicates from being stored. Make sure a proper policy is in place to prevent duplicates.
The program doesn’t have a policy to evict older records from a cache, so the cache continually grows over time.
A program loop is not terminating when it should, and contains code to add to a collection or cache. Use the stack trace to identify the loop, and ensure proper conditions are in place to make sure it terminates, even under unexpected conditions.

2. Proliferation of Same Type of Objects

This is the second most common symptom of leaks. The heap dump analysis will show a very large number of the same class of object. The causes can include:

Objects are not being released to the garbage collector when they’re no longer needed. This may be because they’re defined in the wrong scope, because they are not set to null after use, or because the program fails to call the close() method on objects that have one.
The program is creating a large number of threads that don’t terminate;
Objects aren’t being re-used;
The program uses a large number of string concatenations. This creates new strings each time. It’s better to use the StringBuffer() class, which allows strings to be edited within a single object.
The program is looping without a proper termination condition.

3. Slow finalize() Methods

This is a less common cause of memory leaks. In fact, the finalize() method has been deprecated in later versions of Java, because it’s unreliable.

If you’re analyzing the dump with HeapHero, it includes a list of objects awaiting finalization.

When an object that has a finalize() method is eligible for garbage collection, the method is placed in the finalizer queue. This queue is single-threaded, so if this method is slow or hangs, none of the objects behind it in the queue can be garbage collected until it completes. This could be because it’s waiting for I/O or some other resource. To solve this issue, include a close() method in classes rather than a finalize() method.

4. Mutated keys in collections.

This is an obscure and hard-to-debug cause of memory leaks. Collections such as HashMaps use the key to determine the bucket where an entry is stored, and if the key is changed, the map is unable to find the entry. It therefore doesn’t protect against duplicates, and doesn’t successfully delete entries. To prevent this, always use the final modifier on variables used as keys so they can’t be changed.

5. Uncleared ThreadLocal Variables

This is another unusual and difficult-to-find error. ThreadLocal variables are used to associate a state with a thread. If they’re not cleared, and the thread doesn’t terminate for some time, these variables can build up in memory.

This is particularly likely to happen when we're using thread pools.

To fix this, either ensure threads terminate as they should, or use the remove() method of the variable to free it.

Here are blogs that highlight the Common Memory Leaks and Not-So-Common Memory Leaks in Java that can be used in debugging and fixing memory leaks.

Conclusion

In this article, we’ve looked at how to find memory leaks, examined some of the common causes and included hints on how to fix them.

If you’ve experienced different causes of memory leaks, it would be great if you’d share them in the comments section, so we can pool our knowledge.

Thank you.

Solving OutOfMemoryError: Native Method Stack Trace Analysis

JillThornhill — Mon, 15 Sep 2025 17:51:28 +0000

Beyond Leak Suspects: Advanced Techniques for Deep Dive Memory Leak Analysis

JillThornhill — Mon, 02 Jun 2025 14:16:17 +0000

Memory leaks can cause havoc in production. If they don’t actually make the program crash, they can degrade response times and performance drastically.

Most memory leaks can be found fairly easily with a good heap dump analyzer, since the tool instantly highlights memory leak suspects. This is a great starting point, but to troubleshoot elusive issues, we need to go a little deeper.

This article discusses what we can do if the leak suspect chart doesn’t give us the answers we need.

What is a Memory Leak, and What is a Heap Dump?

A memory leak occurs when unnecessary objects remain in memory, in spite of the best efforts of the garbage collector (GC). The diagram below shows the difference between a healthy GC memory pattern, and a pattern indicating a memory leak.

Fig: Healthy GC vs Memory Leak Pattern

In the first chart, GC is consistently bringing down memory usage. In the second, although GC temporarily reduces memory congestion, memory usage is building up over time, until the system becomes unresponsive and may finally crash.

A memory dump is a snapshot of memory at a given moment. Since it’s a very large binary file, we need tools to analyze it for memory leaks. In this article, we’ll be using the popular HeapHero to illustrate this.

The Object Reference Tree

The best tools identify the largest objects in memory as leak suspects. This is because we’ll almost always find the cause of the leak by examining the top three or four biggest objects. Unfortunately, this may not instantly let us identify the actual cause of the leak.

An object reference tree is a tree structure that records the parent and child objects of each item in the heap, as illustrated in the diagram below.

Fig: Object Reference Tree

We can see that Object A created Objects B, C and D; Object B created Objects E and F; and Object D created Object G.

The Retained Heap is the total heap space occupied by an object and its children. The Shallow Heap is the space occupied by the object on its own.

If Object B is identified as a leak suspect, the problem may actually be found amongst its children, E and F. We can determine whether the problem is likely to be found in the object itself, or in its children, by comparing the size of the shallow heap to the retained heap.

The problem could also be that its parent, Object A, is not releasing it once it’s no longer needed. To find the leak, we need to browse up and down the object reference tree. Fortunately, with HeapHero, this is simple.

For a demonstration, see the video Finding Memory Leaks with HeapHero. We can move up and down the object tree by requesting either incoming or outgoing references, as shown in the screenshot below.

Fig: Scrolling Through the Object Reference Tree

Analyzing a Heap Dump for Memory Leaks: Other Considerations

We need to bear in mind that the memory leak may be outside of heap memory. For example, if a bug in the program causes a loop in a method that creates classes dynamically, we could cause an Out of Memory error in the Metaspace.

The HeapHero report contains a class histogram, listing the number of instances of each class, as shown in the screenshot below.

Fig: Class Histogram

In this histogram, the class jdk.internal.ref.Cleaner has nearly four thousand instances, which could well be the symptom of a leak.

Memory problems may not be an actual leak, but may simply be caused by inefficient code. Duplicate strings, poorly-planned collections and boxed numbers can all cause performance problems. The HeapHero tool reports on any inefficiencies it detects. In the report below, the program had an excessive number of duplicate strings.

Fig: Duplicate Strings

Finally, the problem may simply be that either the heap or the GC may be incorrectly configured. If we’re satisfied that the program code is not the cause of the problem, we can consider increasing the heap size, or using a different GC algorithm.

Conclusion

When analyzing a heap dump for memory leaks, HeapHero offers so much more than just identifying leak suspects. We can interactively browse the object reference tree, see ML suggestions for improvement, investigate the class histogram and check for wasted memory.

Troubleshooting obscure memory leaks need no longer be a frustrating, time-consuming chore.

Analyzing OutOfMemoryError: GC Overhead Limit Exceeded

JillThornhill — Thu, 24 Apr 2025 14:47:37 +0000

In this article, we’ll be taking a look at the Java runtime error: java.lang.outofmemoryerror: gc overhead limit exceeded. It’s a fairly common error, but it can be confusing, because the same program can throw either java.lang.outofmemoryerror: gc overhead limit exceeded, or java.lang.outofmemoryerror: java heap space. This can even happen when the program is running with exactly the same data.

What causes the error? How can we fix it, and why does the same program sometimes alternate between two different error messages? Let’s look for some answers.

What is GC, and What Causes a Program to Crash With java.lang.outofmemoryerror: gc overhead limit exceeded?

Garbage Collection (GC) is a process that runs periodically within the JVM to clean up items in memory that are no longer needed. For a full description of GC, and how to tune it, read this article: What is Java Garbage Collection?

The error java.lang.outofmemoryerror: gc overhead limit exceeded occurs when:

GC is using 98% or more of the available CPU time, preventing the application from doing any actual work AND
GC is releasing less that 2% of memory on each cycle AND
This has happened consistently for the last 5 GC cycles.

In simple terms, this means GC is continually running, but not freeing a significant amount of memory. Application performance degrades dramatically, and the JVM aborts the program to prevent it hogging CPU time to no purpose.

The reason it may alternate with throwing java.lang.outofmemoryerror: java heap space is that in both cases, available memory is dangerously low. Depending on what else is happening on the machine, it’s a matter of chance which error is thrown first.

Causes

A few different issues may cause this error, including:

The application has a memory leak. Either unused memory is not released in a timely manner, or the program is looping on a method that uses a lot of memory;
Traffic has spiked;
The application has been moved to the production environment without carrying out adequate load testing;
The heap has not been configured large enough for the application’s needs.

Troubleshooting Out of Memory Errors Affecting the Heap

For these errors, we need to analyze:

GC efficiency;
Heap contents.

It’s worth obtaining and analyzing a GC log. A good tool for this is GCeasy. It helps determine whether the problem is likely to be caused by a memory leak, and whether GC is working correctly.

Looking at graphs of memory freed on each GC cycle, we can see a definite pattern that indicates a memory leak.

Fig: Comparing a healthy GC pattern with a memory leak pattern using GCeasy

The diagram at the top shows a graph of GC functioning efficiently. Memory increases, but decreases back to the same level after each GC cycle.

The bottom diagram shows a typical memory leak pattern. The GC is releasing some memory, but overall, memory usage keeps increasing with time.

Next, we need to take a heap dump. A heap dump is a snapshot of heap memory, holding details of each item. It includes both the parents and children of each object in the heap. We can analyze it to determine:

What objects are occupying the most space?
What parts of the source code reference those objects?

The easiest way to do this is to use the HeapHero tool. This article, Java OutOfMemoryError: GC Overhead Limit Exceeded, contains a sample program that throws the error, and a detailed explanation of how to trace the problem using HeapHero.

Solutions

Once we’ve identified the problem, we can decide on a solution. This may be one of the following:

Fix memory leaks;
Increase the heap size using the JVM switches -Xms (Initial size) and -Xmx (Maximum size);
Upgrade to a newer version of Java. GC is progressively more efficient in each new release;
Tune GC.

Conclusion

The error java.lang.outofmemoryerror: gc overhead limit exceeded occurs when the heap is short of space, and may alternate with the error java.lang.outofmemoryerror: java heap space.

To solve it, we need to analyze the heap, as well as looking at GC efficiency. We can then either fix the application, or increase memory limits.

Tuning OutOfMemoryError: Metaspace Size Problems

JillThornhill — Thu, 24 Apr 2025 09:12:14 +0000

When it comes to tuning and troubleshooting memory issues in Java, many people think only of the Java heap. However, the metaspace is also an important consideration. Metaspace memory is managed separately from the heap. Issues in this area can lead to performance problems and even system crashes, such as java.lang.outofmemoryerror: metaspace.

What is the metaspace? How do we troubleshoot and tune it? In this article, we’ll answer those questions.

What is the Metaspace?

First let’s review the JVM memory model. The diagram below shows the various memory pools. Some of these are managed by the JVM, whereas others are stored in native memory managed by the operating system.

Fig: JVM Memory Model Showing the Metaspace

The metaspace is marked in red. It was introduced in Java 8 to replace the JVM-managed permanent generation (permgen) space. The metaspace is held in native memory allocated by the operating system as needed. It’s held as a collection of metaspace chunks, which are contiguous sections of memory.

The metaspace stores class definitions, including:

Name;
Byte code for each method;
Constants.

It may also hold other information, such as string pools.

Causes of the Error: java.lang.outofmemoryerror: metaspace

If the metaspace exceeds its size limit, the application will crash with the error: java.lang.outofmemoryerror: metaspace. This is likely to be caused by either too many classes being created, or, in rare cases, by using too many class loaders.

Why is an application likely to have too many classes? The reasons include:

Dynamic class loading, typically when using either Java Reflection or Groovy Scripting;
Extensive use of large 3rd-party libraries;
Memory leaks, which happen either because classes are not dereferenced when no longer in use, or because a method that creates classes is repeated without a valid termination condition.

Troubleshooting `java.lang.outofmemoryerror: metaspace`

There are many ways of troubleshooting and monitoring metaspace usage. This article, How to Inspect the Contents of the Java Metaspace Region, covers several tools that provide useful information.

From JDK 11 onwards, the following JDK command is a quick way to summarize metaspace usage:

jcmd <PID> VM.metaspace

It gives details of class usage, non-class usage and totals.

For a worked example, including a sample program and a step-by-step guide to troubleshooting with the HeapHero tool, read: Java Out of Memory: Metaspace.

Tuning the Metaspace

When we experience the error: java.lang.outofmemoryerror: metaspace, the first step is to ensure there are no memory leaks. As shown in the article linked above, HeapHero is an excellent tool for identifying application errors that affect memory.

If the program is running as it should, the next step is to make the metaspace bigger.

The following JVM switches can be used to adjust the size:

-XX:MetaspaceSize=<size>: Sets the initial size of the metaspace;
-XX:MaxMetaspaceSize<size>: Sets the maximum size to which the metaspace is allowed to grow.

The metaspace is cleaned by the JVM’s garbage collector, but only during full GC events. When using dynamic classes, it may not be cleared quickly enough to avoid Out of Memory errors. We can tune the garbage collection by setting the maximum and minimum fill percentages at which GC is triggered:

-XX:MaxMetaspaceFreeRatio=<percentage>
-XX:MinMetaspaceFreeRatio=<percentage>

A good tool for analyzing the efficiency of the garbage collector is GCeasy.

Conclusion

Never leave the metaspace out of account when tuning and
troubleshooting Java applications. You could find yourself experiencing poor
performance in production, and application failures such as java.lang.outofmemoryerror:metaspace.

In summary, the metaspace is a pool held in native memory.
It’s primarily used for class definitions. You can tune its size and garbage
collection policy using JVM runtime switches.

HeapHero and GCeasy are great tools for troubleshooting
issues in the metaspace.

Emerging Trends in Java Garbage Collection

JillThornhill — Sun, 30 Mar 2025 16:17:09 +0000

Efficient garbage collection is essential to Java application performance. What worked well in 1995, when Java was first released, won’t cope with the high demands of modern computing. To stay ahead of the game, you need to make sure you’re using the best GC algorithm for your application.

In this article, we’ll look at evolving trends in Java garbage collection, and take a quick look at what’s planned for the future.

Computing Trends

Any software that stands the test of time must evolve to keep up with technology. To understand how and why GC has changed over the years, we must look at overall trends in IT.

Hardware has progressively trended towards becoming smaller, cheaper, faster and more powerful. Multi-core CPUs have become the norm, and GPUs have taken over the load of graphics processing. In 1995, a typical PC had around 8MB of memory. Most laptops now have at least 8GB. Faster networks have enabled larger numbers of users to access IT systems directly.

On the one hand, cloud computing, BigData and AI require huge memory and CPU capacities. On the other, smart devices and the IoT require small, ultra-efficient systems. Robotics, virtual reality and other real time processes need fast and consistent response times.

Evolution of Java Garbage Collection

If you’re not yet familiar with how GC works, I recommend this article: Java Garbage Collection.

Initially, Java had a single, simple GC algorithm, suitable for the small memory sizes and single-core processors of that era. With today’s wide divergence in IT requirements, from the very large to the very small, it’s no longer one-size-fits-all. Java now has six different GC algorithms (or seven, if you count Epsilon, used only for benchmarking).

Each was written with a particular purpose in mind, and most of them still have a place today. Let’s have a brief look at them.

Serial: The original algorithm. It’s single-threaded, and all GC is stop-the-world, resulting in high latency. You may still use it where the heap size is very small, or you’re running in a small container or small device where multi-cores are not available.
Parallel: Added to take advantage of multi-cored CPUs in Java 5. It has much better throughput, but latency is high. It’s used in processes where latency is not important. Large batch processes may perform well with this algorithm.
CMS (Concurrent Mark Sweep): Released in Java 4, it reduced latency by doing much of the work concurrently. It didn’t deal well with compaction, and was later discontinued.
G1: Released in Java 7 to provide a good balance between latency and throughput. The heap is divided into equal-sized regions, each collected separately. Most of the work is done concurrently. You can configure pause time goals, making it simple to tune. It has been the default since Java 8, and is usually the best choice if the heap size is less than 32GB.
Z: Introduced in Java 11, it aimed to provide low latency and good scalability. Almost all the work is done concurrently, and it can scale for heap sizes in terabytes. It’s ideal for cloud computing and BigData. Originally non-generational, it has had the option of generational GC since Java 21. This resulted in a huge improvement in performance, at the expense of a larger memory footprint.
Shenandoah: Developed by Red Hat, it had much the same objectives as Z. It’s also good for very large heap sizes and applications requiring low latency.

Future Planned Developments

Developers are currently working on:

More features for Z GC;
Throughput improvements for G1 GC;
Footprint reduction in all algorithms;
A new algorithm, N2GC, which is an extension of G1. Suitable for BigData and other large caches, it aims to reduce latency and fragmentation.

Monitoring and Tuning

It’s a good idea to evaluate and compare at least two algorithms for high-performance applications. A great tool for evaluating GC efficiency is GCeasy, which instantly provides a range of analytical data.

Conclusion

Java GC must follow general trends in computing to remain competitive. Coping with large heap sizes, and delivering low latency, are the key requirements today.

The development team works continually to improve performance and cater for new trends. GC efficiency has improved enormously since Java 8. Upgrading to the latest version of Java gives significant performance gains.

Advanced Garbage Collection Techniques and Best Practices

JillThornhill — Tue, 25 Mar 2025 14:13:15 +0000

Cranky users, critical processes failing, robots going haywire: all these are typical of application performance issues. Performance monitoring and tuning are vital for smooth-running systems.

In Java, garbage collection (GC) can often be the culprit if systems aren’t performing as they should. Even if GC is not to blame, GC logs can provide vital information about how systems are performing, and identify present and future bottlenecks.

Advanced Java GC Techniques

GC monitoring and tuning isn’t difficult, but you need to have a good understanding of how GC works and the JVM memory model.

You’ll need to know how to obtain GC logs, analyze them and use the information to tune your JVM settings.

You should also have a good understanding of the different GC algorithms available in Java. Each has its own strengths and weaknesses, and you need to choose the right algorithm for your application.

Briefly, the GC algorithms are:

Serial: This was the original GC algorithm, and up until Java 4, it was the only one available. It used single-threading, and all other threads were paused during GC.
Parallel: Introduced in Java 5, it used multithreading. Some tasks were performed concurrently with user threads.
CMS (Concurrent Mark Sweep): This was experimental in Java 4, and performed many of the GC tasks concurrently with application threads. It was sometimes problematic, because it didn’t deal well with defragmentation. It was later deprecated and then discontinued.
G1: This is the default algorithm in later versions of Java. Much of the work is done concurrently, and it’s efficient in most cases.
Z: This is refined from G1 to deal better with larger heap sizes.
Shenandoah: Also similar to G1, with improvements for working with large heaps.
Epsilon: This is a do-nothing algorithm used purely for benchmarking other algorithms.

Obtaining GC Logs

You can request GC logs by using arguments on the command line when invoking your Java program. These arguments changed with Java 9.

For Java 8 and below, the arguments are:

-XX:+PrintGCDetails -Xloggc:<gc-log-file-path>

For Java 9 and above, the argument is:

-Xlog:gc*:file=<gc-log-file-path>

Analyzing GC Logs

GC logs are produced in text format, so it’s possible to read the file manually. However, they are usually very long, and it would be a time-consuming and difficult task.

JDK tools such as jstat and jcmd are useful in analyzing logs. However, one of the best tools is GCeasy. This produces useful stats, graphs and charts within minutes, and also gives performance tuning recommendations.

Key performance indicators that show whether garbage collection is working correctly include:

Throughput: The percentage of time spent on application tasks as opposed to GC tasks. For critical systems, you should aim at a throughput of at least 98%;
Latency: The time during which the application threads are paused waiting for GC events to complete. You should look at both maximum and average latency times.
Footprint: Resources used by GC.

GC Logging Best Practices

Here are a few tips for making good use of GC logs:

Monitor your logs regularly to pick up any problems that are developing before they become a major issue. This is where tools such as GCeasy are invaluable.
Always enable logs in production. If you have an issue, and logs aren’t enabled, it may be difficult to replicate the problem in order to solve it.
Always monitor over a 24-hour period, so you can assess what’s happening during low and high traffic times.
Use the right GC algorithm.
Avoid using excessive GC logging arguments on the command line: for most purposes, the arguments shown in the previous section are sufficient.
Avoid using log rotation. This can often result in losing the very log that you most need. Instead, suffix the GC log file name with %t, which adds a timestamp to the log name.
Use a suitable tool such as GCeasy to analyze the logs, and pay attention to the results.

Tuning the GC Algorithm

Java includes a wide range of command line arguments that you can use to tune your applications. Once you’ve made informed decisions based on the GC logs, you can tweak your JVM settings in various ways, including:

Adjusting the heap size;
Adjusting the size/ratio of spaces within the heap;
Controlling how quickly objects are promoted to the next heap space;
The percentage of used space at which GC is activated;
The number of concurrent and parallel GC threads;
Enabling or disabling string deduplication;
Changing the GC algorithm.

There may be occasions where resources such as CPU cores and memory are insufficient, and must be upgraded. If this is the case, regular monitoring of the GC logs helps you to plan ahead and put solutions in place before performance is dangerously downgraded.

You may also need to refactor your code to ensure memory is released in a timely manner.

Each of the GC algorithms requires a different tuning strategy. This article, What is Java Garbage Collection? contains links to specific tuning guides for each algorithm, as well as in-depth information on how garbage collection works.

Conclusion

A good understanding of Java garbage collection is essential for maintaining good performance, especially in critical systems.

Simple tweaks to the garbage collector can result in huge performance gains at very little cost. If your application is running in the cloud, you could be paying for CPU and memory resources you wouldn’t actually need if your GC worked correctly. Uber reduced their costs dramatically with a few changes to GC operations.

If you need to up your performance tuning skills, you may like to look at this Performance Tuning and Troubleshooting Masterclass.

Forem: JillThornhill

The Finalizer Problem: A Deeper Look into OutOfMemoryError Due to Unclosed Resources

Troubleshooting OutOfMemoryError: Java Heap Space

Unclosed Resources

When is finalize() Executed?

How To Diagnose Finalizer Problems

Conclusion

Avoiding "Out of Memory" Errors: Strategies for Efficient Heap Dump Analysis

Why Shouldn’t We Just Increase Heap Size?

1. The Planning Stage

2. The Development Stage

3. The Testing Stage

4. Preparing to Go Live

5. In Production

6. In CI/CD Pipelines

Conclusion

Don't Just Find the Leak, Fix the Root Cause: A Modern Approach to Memory Analysis

What is a Memory Leak?

Do All Memory Leaks Occur in the Java Heap Space?

How Do We Troubleshoot OutOfMemoryErrors?

Typical Causes of Memory Leaks and How to Fix Them

1. Forever-growing Object

2. Proliferation of Same Type of Objects

3. Slow finalize() Methods

4. Mutated keys in collections.

5. Uncleared ThreadLocal Variables

Conclusion

Solving OutOfMemoryError: Native Method Stack Trace Analysis

Beyond Leak Suspects: Advanced Techniques for Deep Dive Memory Leak Analysis

What is a Memory Leak, and What is a Heap Dump?

The Object Reference Tree

Analyzing a Heap Dump for Memory Leaks: Other Considerations

Conclusion

Analyzing OutOfMemoryError: GC Overhead Limit Exceeded

What is GC, and What Causes a Program to Crash With java.lang.outofmemoryerror: gc overhead limit exceeded?

Causes

Troubleshooting Out of Memory Errors Affecting the Heap

Solutions

Conclusion

Tuning OutOfMemoryError: Metaspace Size Problems

What is the Metaspace?

Causes of the Error: java.lang.outofmemoryerror: metaspace

Troubleshooting java.lang.outofmemoryerror: metaspace

Tuning the Metaspace

Conclusion

Emerging Trends in Java Garbage Collection

Computing Trends

Evolution of Java Garbage Collection

Future Planned Developments

Monitoring and Tuning

Conclusion

Advanced Garbage Collection Techniques and Best Practices

Advanced Java GC Techniques

Obtaining GC Logs

Analyzing GC Logs

GC Logging Best Practices

Tuning the GC Algorithm

Conclusion

Troubleshooting `java.lang.outofmemoryerror: metaspace`