Error java.lang.OutOfMemoryError: GC overhead limit exceeded – Dev

The best answers to the question “Error java.lang.OutOfMemoryError: GC overhead limit exceeded” in the category Dev.


I get this error message as I execute my JUnit tests:

java.lang.OutOfMemoryError: GC overhead limit exceeded

I know what an OutOfMemoryError is, but what does GC overhead limit mean? How can I solve this?


Quoting from Oracle’s article “Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning”:

Excessive GC Time and OutOfMemoryError

The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.

EDIT: looks like someone can type faster than me 🙂


This message means that for some reason the garbage collector is taking an excessive amount of time (by default 98% of all CPU time of the process) and recovers very little memory in each run (by default 2% of the heap).

This effectively means that your program stops doing any progress and is busy running only the garbage collection at all time.

To prevent your application from soaking up CPU time without getting anything done, the JVM throws this Error so that you have a chance of diagnosing the problem.

The rare cases where I’ve seen this happen is where some code was creating tons of temporary objects and tons of weakly-referenced objects in an already very memory-constrained environment.

Check out the Java GC tuning guide, which is available for various Java versions and contains sections about this specific problem:

  • Java 11 tuning guide has dedicated sections on excessive GC for different garbage collectors:
    • for the Parallel Collector
    • for the Concurrent Mark Sweep (CMS) Collector
    • there is no mention of this specific error condition for the Garbage First (G1) collector.
  • Java 8 tuning guide and its Excessive GC section
  • Java 6 tuning guide and its Excessive GC section.


It’s usually the code. Here’s a simple example:

import java.util.*;

public class GarbageCollector {

    public static void main(String... args) {

        List<Double> list = new ArrayList<Double>();
        for (int outer = 0; outer < 10000; outer++) {

            // list = new ArrayList<Double>(10000); // BAD
            // list = new ArrayList<Double>(); // WORSE
            list.clear(); // BETTER

            for (int inner = 0; inner < 10000; inner++) {

            if (outer % 1000 == 0) {
                System.out.printf("Outer loop at %d%n", outer);


Using Java 1.6.0_24-b07 on a Windows 7 32 bit.

java -Xloggc:gc.log GarbageCollector

Then look at gc.log

  • Triggered 444 times using BAD method
  • Triggered 666 times using WORSE method
  • Triggered 354 times using BETTER method

Now granted, this is not the best test or the best design but when faced with a situation where you have no choice but implementing such a loop or when dealing with existing code that behaves badly, choosing to reuse objects instead of creating new ones can reduce the number of times the garbage collector gets in the way…


If you are sure there are no memory leaks in your program, try to:

  1. Increase the heap size, for example -Xmx1g.
  2. Enable the concurrent low pause collector -XX:+UseConcMarkSweepGC.
  3. Reuse existing objects when possible to save some memory.

If necessary, the limit check can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.