Java Memory APIs & Diagnostics

A heap dump is a snapshot of all objects in the JVM heap at one moment, saved to a file. You can trigger it on demand with jmap, or have the JVM write one automatically when it runs out of memory using the -XX:+HeapDumpOnOutOfMemoryError flag.

The garbage collector only frees objects nothing else points to. If your code keeps a reference to an object you no longer use, the collector cannot free it. The memory is still 'reachable', just wasted. That is a Java memory leak.

OutOfMemoryError means the JVM ran out of memory and could not get more, so it can't keep running normally. It's an Error, not a regular Exception, because it signals a serious problem you usually can't recover from. Don't catch it to keep going; fix the root cause instead.

A SoftReference is a special wrapper around an object that lets the garbage collector throw that object away, but only when the JVM is running low on memory. Until then, the object stays alive.

It is an error thrown when a thread runs out of stack space. The usual cause is recursion that never stops because it is missing a base case, so methods keep calling themselves until the stack fills up.

A strong reference is an ordinary variable that points to an object, like String s = new String(). As long as such a reference exists and can be reached by the program, the garbage collector will never delete that object.

An object is garbage when it can no longer be reached by following references from "GC roots" (like local variables and static fields). The collector keeps reachable objects and frees the rest. It is not based on reference counting.

A static collection lives for the whole program and is a GC root, so anything you put in it stays in memory forever unless you remove it. If you keep adding and never evicting, the heap grows without bound. Fix it by bounding the size or evicting old entries.

Read the text right after 'OutOfMemoryError:'. 'Java heap space' means object memory is full — take a heap dump and check for a leak vs. a too-small heap. 'Metaspace' means too many classes are loaded — look for a classloader leak or raise MaxMetaspaceSize. 'GC overhead limit exceeded' means the collector is thrashing — treat it like a heap problem. The message names the region; that tells you where to look.

It means the heap — the area where Java objects live — is full and the garbage collector can't free enough room for a new object. Common causes are a memory leak, a heap that's simply too small for the workload, or trying to load too much data at once. First step: capture a heap dump and check whether it's a leak or just under-sizing.

A weak reference is thrown away as soon as the next garbage collection runs once nothing else points to the object. A soft reference is kept longer — the collector only clears it when memory is running low. So soft is for caches you want to keep; weak is for cleanup that should happen quickly.

StackOverflowError means one thread ran out of stack space, usually from deep recursion. OutOfMemoryError means the heap (or metaspace) is full, usually from too many or too-large objects. Different memory areas, different causes.

A strong reference keeps an object alive as long as it is reachable. Soft references are cleared only under memory pressure, weak references at the next GC once no strong refs remain, and phantom references are used only for post-cleanup notification.

Weak references are dropped at the next garbage collection as soon as nothing else needs the object. Soft references are kept as long as possible and only dropped when the JVM is running out of memory. For a cache that should survive until memory is tight, use soft references.

Every object points to its Class, every Class points to the classloader that loaded it, and the classloader points to all the classes it loaded. So holding one live object keeps the loader and every class it loaded alive in metaspace — you can't lose just part of it.

Shallow size is the memory one object uses by itself. Retained size is all the memory that would be freed if that object were removed — the object plus everything only it keeps alive. A dominator tree shows which objects hold the most memory, so you look at the biggest retained sizes to find the leak.

Strong references are normal references and stop collection. Soft references are cleared only when memory is low (caches). Weak references are cleared as soon as nothing strong points to the object (canonical maps). Phantom references are the weakest and only signal that the object was already collected (cleanup).

Most objects die young, so the heap is split into a young generation (new objects) and an old generation (survivors). A minor GC collects only the young area (fast, frequent); a major/full GC handles the old area (slower, rarer). Objects that survive get promoted to the old generation.

Watch metaspace climb with each redeploy and never fall, ending in OutOfMemoryError: Metaspace. Then take a heap dump, find the classloaders that should be dead, and use the tool's 'path to GC roots' to see which reference is keeping each one alive.

It happens when something keeps a reference to a class (or its instance/static field) loaded by a custom classloader, so the JVM can never unload that classloader. Its classes pile up in metaspace, eventually causing OutOfMemoryError: Metaspace.

jstat prints live GC and memory stats from the command line. VisualVM is a GUI that shows memory, threads, and lets you take dumps. Java Flight Recorder records detailed events with very low overhead for later analysis. async-profiler is a low-overhead sampling profiler great for CPU and allocation flame graphs.

A PhantomReference is the weakest reference type. Its get() always returns null on purpose, so you can never resurrect the object. It only exists to tell you, via a ReferenceQueue, that the object has already been collected so you can run cleanup.

A WeakReference holds an object without keeping it alive. Once nothing else strongly points to that object, the garbage collector can reclaim it at the next collection, and the weak reference's get() then returns null.

Cleaner runs a cleanup action after an object becomes unreachable, using phantom references and a background thread. It replaces finalize(), which was unreliable and is deprecated. The key rule: the cleanup action must not reference the object it cleans up.

Read the OutOfMemoryError message — it tells you which kind: heap space, Metaspace, GC overhead limit, or unable to create native thread. Capture a heap dump (-XX:+HeapDumpOnOutOfMemoryError), open it in a tool like Eclipse MAT, and find what's holding the most memory.

A normal (strong) reference keeps an object alive. SoftReference lets the GC drop the object only when memory is low (good for caches). WeakReference lets it be collected as soon as nothing strong points to it (good for canonicalizing maps). PhantomReference signals after collection, for cleanup.

Pooled threads (like a server's thread pool) outlive your app. If a request sets a ThreadLocal to an app object and never removes it, that value stays attached to the long-lived thread, keeping your app's classloader alive. Always remove() ThreadLocals in a finally block.

Confirm the leak by watching memory climb over time and never fully recover after GC. Enable an automatic heap dump on OutOfMemoryError, or take dumps at intervals and compare. Open the dump in a tool like Eclipse MAT, sort by retained size, find the object retaining the most, and trace its path to GC roots to see what code keeps it alive.

Watch the heap after garbage collection: if the live (post-GC) size keeps trending up over time instead of returning to a baseline, that's a leak, not just busy memory. Then take a heap dump, find the objects with the largest retained size, and trace what GC root is keeping them alive — that points at the offending reference.