Java Memory and Garbage Collection: Stack, Heap and Common Errors

Java frees memory for you, so interviewers ask a different question: do you know where your objects live and when they die? This article covers the memory areas, how garbage collection (GC) decides what to free, and the two errors every developer eventually sees.

The JVM memory areas

In Person p = new Person("Asha"); the reference p lives on the stack (as a local variable) and the Person object lives on the heap. Primitive locals live in the stack frame itself. A reference stored in a field lives inside its object on the heap. Strings in the string pool also live on the heap.

When is an object eligible for garbage collection?

An object can be collected when it is unreachable from every GC root. The roots are local variables on live thread stacks, static fields, active threads and JNI references. Reference counting is not used, so two objects that point at each other but are otherwise unreachable are still collected.

// Illustrative: Person stands for any class
Person a = new Person("Asha");      // reachable through a
Person b = a;                       // still one object, two references
a = null;                           // the object is still reachable through b
b = null;                           // now it is eligible for collection

"Eligible" does not mean "collected right now". System.gc() is only a hint, and you should never depend on it.

Generational garbage collection

Most objects die young, so the heap is divided by age:

• Young generation: new objects are allocated in Eden. A minor GC copies the survivors into one of two survivor spaces, and objects that survive several cycles move on.
• Old generation (tenured): long-lived objects. Cleaning it (a major or mixed collection) takes longer.

A stop-the-world pause is when the application threads are halted so the collector can work. Modern collectors keep these pauses short.

StackOverflowError

Each method call pushes a frame onto the thread's stack, and the stack has a fixed size (about 512 KB to 1 MB by default, set with ). Endless or very deep recursion fills it:

The fix is a correct base case, or converting the recursion into a loop. Catching is for demonstrations only.

OutOfMemoryError

This means the heap cannot supply enough room even after a full collection. The usual causes are loading too much data at once (for example into a list), a cache without a size limit, or a genuine leak.

With this prints .

Memory leaks in a garbage-collected language

A leak in Java is an object that is still reachable but no longer needed. The collector cannot free what you still point at. The usual suspects:

• a static collection (a cache or registry) that only ever grows,
• listeners and callbacks that are registered but never removed,
• values on pooled threads that are never cleared,
• unclosed resources (connections, streams),
• keys whose or changed after they were put in a map.

Use a bounded cache (an LRU cache built on LinkedHashMap, or a library such as Caffeine) or / when entries should vanish if nothing else needs them.

Reference types

is deprecated (for removal since Java 18). For cleanup, use and , or .

JVM flags worth knowing

To diagnose a problem: look at output (are collections frequent, is the old generation always full?), take a heap dump () and open it in Eclipse MAT or VisualVM, and take thread dumps with .

Interview answers in one line each

• Stack versus heap: the stack holds method frames and local variables for each thread; the heap holds all objects and is shared.
• Can you force garbage collection? No. is only a request.
• Can a Java program leak memory? Yes, by keeping unneeded objects reachable.
• StackOverflowError versus OutOfMemoryError: the first means a thread's stack is full (deep recursion); the second means the heap (or Metaspace) is full.

Practise

1. Run with and compare the depth to a run with .
2. Run with and , then open the dump.
3. Continue with JDBC and SQL injection.