When does an object become eligible for garbage collection in Java, and what makes it eligible?

## What garbage collection is **Garbage collection (GC)** is the JVM's automatic memory management: it finds objects the program can no longer use and reclaims their heap memory so it can be reused. You never call `free`/`delete` in Java; the GC does it for you. The key question is: *which objects can be reclaimed?* The answer is **unreachable** objects. ## Reachability and GC roots The collector starts from a set of **GC roots** — references that are definitely "live": - **Local variables** in the stack frames of currently executing methods (and method parameters). - **Static fields** of loaded classes. - **Active threads** and thread-local references. - **JNI** (native code) references. From these roots, the collector follows every reference, then every reference from those objects, and so on — transitively marking everything it can reach. Any object **not** reached by this traversal is **unreachable** and therefore **eligible for garbage collection**. So: *an object is eligible for GC exactly when no chain of references leads to it from any GC root.* ## How objects become unreachable ```java Dog d = new Dog(); // reachable via local var d d = null; // the Dog is now unreachable (if no other ref) -> eligible ``` ```java void f() { Dog d = new Dog(); } // when f() returns, d's frame is gone -> Dog eligible ``` ```java Dog a = new Dog(); Dog b = new Dog(); a = b; // the first Dog is now unreachable -> eligible ``` Three triggers, all the same underlying cause — **the last reference disappears**: going out of scope, reassignment, or explicit `null`. ## Eligibility vs. actual collection Becoming *eligible* does **not** mean the memory is freed *now*. The JVM frees eligible objects at an unspecified later time, when a collection cycle runs (driven by allocation pressure and the chosen collector). `System.gc()` is only a *hint* and may be ignored. So you can never rely on an object being collected at a precise moment. ## Cycles: why reachability beats reference counting ```java a.next = b; b.next = a; // a and b reference each other a = null; b = null; // nothing reachable points into the pair ``` Even though `a` and `b` still reference each other, the whole **island** is unreachable from any root, so both are eligible. A naive **reference-counting** scheme would wrongly keep them (each has count 1). Java uses **tracing/reachability** collection, which correctly reclaims cycles. ## Memory leaks in Java GC eliminates dangling pointers and most leaks, but not all. A **leak** in Java means *unintended reachability*: an object you're done with is still reachable, so it's never eligible. Classic causes: a `static` collection or cache that keeps growing, listeners never unregistered, `ThreadLocal`s on pooled threads. The fix is to drop references (remove from the collection, null it out, deregister). ## finalize / Cleaner (brief) Don't rely on `finalize()` (deprecated) or `Cleaner` for timely cleanup — they run, if ever, at GC's discretion. Use `try-with-resources`/`AutoCloseable` for deterministic release of external resources (files, sockets).