SoftReference vs WeakReference vs PhantomReference.

Signed-off-by: https://github.com/Someshdiwan <[email protected]>

Author: Someshdiwan

Section 25 Collections Frameworks/Map Interface/Garbage Collection/SoftReference vs WeakReference vs PhantomReference/src/SoftReference vs WeakReference vs PhantomReference.txt

@@ -0,0 +1,86 @@
+SoftReference vs WeakReference vs PhantomReference:
+
+1. Background:
+- In Java, garbage collection (GC) automatically reclaims memory of objects that are no longer reachable.
+- Normally, objects are referenced via **strong references**, meaning they will never be collected as long as a
+  strong reference exists.
+- To give more flexibility in memory-sensitive or resource-sensitive applications, Java provides special reference
+  types:
+  • SoftReference
+  • WeakReference
+  • PhantomReference
+
+These references help developers influence GC behavior in specific scenarios such as caching, memory management, or
+native resource cleanup.
+
+2. SoftReference
+- Definition:
+  A SoftReference keeps an object reachable *until memory pressure occurs*.
+  The GC will clear softly reachable objects **only when JVM needs memory**.
+
+- Why use:
+  Useful for implementing memory-sensitive caches (e.g., image cache, large data cache).
+  The cached objects stay in memory as long as possible but are discarded automatically when JVM runs low on memory.
+
+- Application examples:
+  • Web browsers caching images or pages.
+  • Large in-memory caches that should shrink automatically under memory pressure.
+  • Situations where data can be recomputed or re-fetched if evicted.
+
+----------------------------------------
+3. WeakReference
+----------------------------------------
+- Definition:
+  A WeakReference does not prevent its referent from being collected.
+  Once no strong (or soft) references exist, the object becomes weakly reachable and GC will reclaim it eagerly.
+
+- Why use:
+  Ideal when you want to associate metadata with an object **without preventing it from being collected**.
+  For example, a map where keys should disappear once the actual object is gone.
+
+- Application examples:
+  • WeakHashMap (commonly used for caches of metadata).
+  • Listener or callback registries, where you don’t want listeners to keep objects alive.
+  • Interning or canonicalizing maps where duplicate objects should be merged but freed if unused.
+
+4. PhantomReference
+- Definition:
+  PhantomReferences are enqueued **after the object has been finalized** but before its memory is reclaimed.
+  They always return null from `get()`, and must be used with a ReferenceQueue.
+
+- Why use:
+  They give you a reliable hook to perform cleanup actions after the object is no longer reachable.
+  This is safer and more flexible than finalizers (which are deprecated).
+
+- Application examples:
+  • Releasing native resources (file handles, sockets, direct memory).
+  • Implementing custom memory managers or resource pools.
+  • Framework-level cleanup tasks (like advanced caching libraries).
+
+5. ASCII Summary of Reachability
+Strong Ref → Object (alive, never GC)
+Soft Ref   → Object (collected under memory pressure)
+Weak Ref   → Object (collected eagerly when no strong refs)
+Phantom Ref→ (no access; only cleanup notification before GC frees memory)
+
+6. When to Use What?
+- SoftReference:
+  Use for caches that can be recomputed/reloaded. Survive GC until memory is tight.
+- WeakReference:
+  Use for mappings/registries where you do not want the reference to keep objects alive.
+- PhantomReference:
+  Use for advanced cleanup of external resources (native memory, sockets, files). Provides exact point of reclamation.
+
+7. Real-world Usage Scenarios
+✔ Android image loading libraries (Glide, Picasso) use SoftReference/WeakReference for memory-sensitive caches.
+✔ WeakHashMap internally uses WeakReference for keys, letting them vanish once not strongly referenced.
+✔ JVM internals and frameworks sometimes use PhantomReference for resource cleanup instead of finalizers.
+✔ Database connection pools or large native buffers can be tracked via PhantomReference to ensure they are released properly.
+
+8. Key Takeaway
+These references exist to provide finer control over how objects are treated by GC:
+- Soft → "Keep as long as possible but discard under pressure."
+- Weak → "Don’t keep alive; free as soon as no one else needs it."
+- Phantom → "I don’t need the object, just notify me when it’s gone so I can clean resources."
+
+They help balance performance, memory efficiency, and safe cleanup in complex applications.