Strong References

## What a reference is In Java you almost never touch objects directly. An object lives in a region of memory called the **heap**. A **reference** is a value (think of it as a typed pointer / handle) that lets your code reach that heap object. When you write: ```java String s = new String("hi"); ``` `new String("hi")` allocates a `String` object on the heap, and `s` is a variable holding a **reference** to it. `s` is not the object; it points to the object. ## What 'strong' means A **strong reference** is just the ordinary, default kind of reference — the one you get from a normal assignment. The word 'strong' only matters by contrast: the `java.lang.ref` package adds three *weaker* reference types (`SoftReference`, `WeakReference`, `PhantomReference`) that give the garbage collector permission to reclaim the object earlier. A strong reference gives no such permission. It is the strongest claim you can stake on an object's survival. ## Garbage collection and reachability Java is a **managed** language: you do not free memory manually. A background process, the **garbage collector (GC)**, periodically reclaims objects you can no longer use, so their memory can be reused. How does the GC decide what is 'no longer used'? It uses **reachability**. The GC starts from a set of trusted always-live roots, called **GC roots** — for example: local variables and parameters on the call stack of every live thread, `static` fields of loaded classes, JNI references, and a few others. From those roots it follows references object-to-object, marking everything it can reach. Anything it can reach is **live**; anything it cannot reach is **unreachable** and may be collected. The key rule for this topic: > **An object is kept alive as long as it is reachable from a GC root through a chain of strong references.** While such a chain exists, the GC will never collect the object. So a strong reference does not by *itself* pin an object — it pins the object only when the reference is part of a chain that starts at a GC root. (A strong reference that is itself unreachable cannot save anything; e.g. two unreachable objects pointing at each other are both collectible — this is why Java does not leak on reference cycles.) ## Making an object collectible To let the GC reclaim an object you must drop every strong reference that reaches it from a root. Two common ways: 1. **Let the variable go out of scope** — when a method returns, its local variables disappear, so the references they held no longer count. 2. **Reassign or null it** — `s = null;` or `s = somethingElse;` removes that particular strong reference. ```java byte[] big = new byte[100_000_000]; // strong reference -> array is pinned big = null; // last strong ref dropped -> array now collectible ``` Note: setting to `null` matters mostly for **long-lived** references (fields, static collections). For ordinary short-lived locals, scope exit handles it and explicit nulling is unnecessary noise. ## Why this is the baseline Every weaker reference type is *defined* relative to this rule. A `WeakReference`'s target is collected at the next GC once only weak references remain; a `SoftReference`'s target survives until the JVM is under memory pressure. But the moment you keep even one **strong** reference to those same targets, the weaker reference's special behavior is overridden and the object stays alive — because reachability through a strong reference always wins. Understanding strong references is therefore the foundation for understanding caches, `WeakHashMap`, listeners, and most Java memory leaks (which are simply unintended strong reachability). ## Reachability vs. the platform notion 'Reachability' and 'GC roots' are really properties of the **JVM platform** (the runtime that runs all JVM languages), not of Java the language. The *strong reference* is the Java-language-level handle; *reachability from a GC root* is the platform mechanism that decides survival. They work together: the reference is what you write, reachability is how the runtime interprets it.