JVM memory and garbage collection

Where things live

void placeOrder() {
    int qty = 2;                          // on this thread's stack
    Order order = new Order("Asha", qty); // reference on the stack, Order object on the heap
}                                          // frame popped; the Order is unreachable unless stored elsewhere

Garbage collection

The garbage collector (GC) finds objects that cannot be reached from any "root" (local variables of running threads, static fields, and so on) and reclaims their memory. Most objects die young (temporary strings, DTOs for one request), so collectors split the heap into a young generation (collected often and quickly) and an old generation (for long-lived objects, collected less often). This is called generational collection.

• G1 (Garbage-First): the default collector since Java 9; balances throughput and pause times for most server apps.
• ZGC and Shenandoah: low-pause collectors for very large heaps and latency-sensitive services.
• Parallel GC: maximum throughput for batch jobs that can tolerate longer pauses.

Sizing the heap

java -Xms512m -Xmx2g -jar app.jar          # start with 512 MB, allow up to 2 GB of heap
java -XX:+UseZGC -Xmx8g -jar app.jar        # choose a collector
java -Xlog:gc -jar app.jar                  # log GC activity
jcmd <pid> GC.heap_info                     # inspect a running JVM

Memory leaks in Java

The GC frees only UNREACHABLE objects. A leak in Java means something still references objects you no longer need, so they can never be collected. Common causes: static collections that only grow (a static Map used as a cache with no limit), listeners or callbacks registered and never removed, ThreadLocal values not cleaned up in thread pools, and unclosed resources.

class SessionCache {
    private static final Map<String, Session> SESSIONS = new HashMap<>();   // grows forever
    static void add(Session s) { SESSIONS.put(s.id(), s); }                 // never removed → leak
}
// Fix: remove on logout, add expiry, or use a bounded cache (Caffeine) / a WeakHashMap where suitable.

Errors to recognise

• java.lang.OutOfMemoryError: Java heap space → the heap is full of live objects: a leak, or genuinely too little -Xmx.
• java.lang.StackOverflowError → usually unbounded recursion.
• GC overhead limit exceeded → the JVM spends almost all its time collecting and freeing almost nothing.