How do you diagnose OutOfMemoryError?

OutOfMemoryError (OOM) is thrown when the JVM cannot allocate memory and the garbage collector cannot free enough to satisfy the request. The first diagnostic step is reading the error's message to learn which region ran out, because each points to a different cause: "Java heap space" means the heap is exhausted, "Metaspace" means class metadata exhausted, "unable to create new native thread" means the OS could not create another thread, and "GC overhead limit exceeded" means GC is running constantly while freeing almost nothing. You then capture a heap dump and analyze it in Eclipse MAT for large object retention or a leak.

OutOfMemoryError: Java heap space

This is the most common variant. It means the heap is full of live objects. The cause is either a genuine need for more memory (undersized -Xmx), a memory leak where objects stay reachable forever, or a spike like loading a huge result set into memory at once. You diagnose it with a heap dump: the Dominator Tree in Eclipse MAT shows which objects retain the most heap, and the path to GC roots shows what holds them.

package com.bank.report;

import java.util.ArrayList;
import java.util.List;

public class StatementGenerator {
    // BAD: loads all transactions into memory at once
    public void generateYearlyStatement(String accountId) {
        List<Transaction> allTxns = repo.findAllByAccountId(accountId);
        // For an active account, this could be millions of rows → OOM!
    }

    // GOOD: stream and process in pages
    public void generateYearlyStatementPaged(String accountId) {
        int page = 0;
        List<Transaction> batch;
        do {
            batch = repo.findByAccountId(accountId, page, 1000);
            processBatch(batch);
            page++;
        } while (!batch.isEmpty());
    }
}

OutOfMemoryError: Metaspace

This means class metadata has filled Metaspace. Since Metaspace holds loaded classes, this usually indicates a class-loading leak: frameworks that generate proxy classes endlessly, repeated redeployments in an app server that leak old class loaders, or dynamic scripting that keeps defining classes.

# Monitor loaded class count over time
jcmd <pid> VM.classloader_stats

# If loaded classes climb indefinitely, you have a class-loader leak
# Bound Metaspace so it fails fast instead of consuming all native memory
java -XX:MaxMetaspaceSize=256m -jar bank-api.jar

You diagnose it by watching loaded-class count climbing over time and by capturing a dump to see which class loaders are retained.

OutOfMemoryError: unable to create new native thread

This is not about the heap at all. It means the operating system refused to create another thread, usually because the process hit a thread-count or memory limit. Each thread needs a native stack (default around 1 MB, set by -Xss), so thousands of threads consume real memory outside the heap.

package com.bank.service;

public class BadBatchProcessor {
    // BAD: creates a new thread per account – thousands of threads
    public void processAllAccounts(List<String> accountIds) {
        for (String id : accountIds) {
            new Thread(() -> processAccount(id)).start();  // unbounded!
        }
    }

    // GOOD: use a bounded thread pool
    public void processAllAccountsCorrectly(List<String> accountIds) {
        ExecutorService pool = Executors.newFixedThreadPool(16);
        for (String id : accountIds) {
            pool.submit(() -> processAccount(id));
        }
        pool.shutdown();
    }
}

The cause is often a thread leak – creating threads without a bounded pool – and the fix is to use a bounded thread pool and check OS ulimits.

OutOfMemoryError: GC overhead limit exceeded

This means the JVM spent over 98 percent of time in GC while recovering less than 2 percent of the heap. It is an early warning of a heap-space problem, treated the same way with a heap dump.

Diagnostic workflow

  Step 1: Read the OOM message → identifies which memory region
  Step 2: Capture heap dump (auto or manual)
  Step 3: Open in Eclipse MAT → Dominator Tree + Leak Suspects
  Step 4: Trace path to GC roots → find the retaining reference
  Step 5: Correlate with GC logs → leak (drift up) vs spike (sudden)
  Step 6: Fix in code, verify with load test

What should a senior engineer know?

• Always run production with -XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath so the dump is captured automatically.
• Correlate the OOM with GC logs to see whether the heap baseline was drifting up (leak) or spiked suddenly (bad request).
• Never just raise -Xmx to fix a leak. That only delays the crash. Find and fix the root cause.
• In Kubernetes, set the JVM heap smaller than the container memory limit to leave room for Metaspace, thread stacks, and native memory. A common formula: -Xmx = container limit minus 500 MB.
• In banking at National Bank of India, Rajesh always sets up OOM heap dumps and GC log alerts on every production service, so the team never has to guess when a memory issue occurs.