Java Interview Guide: How to Build Confidence With a Solid Understanding of Core Java Principles pdfdrive com

Memory Leaks
Memory leaks are possible despite Java’s automatic memory management.
For example, imagine hosting the world’s largest star database. In order
to improve performance we could use a ConcurrentMap to cache a Star
object, using its name as a key. However, as more and more users looked
up stars, our Star cache would grow like a black hole until it eventually
consumed all of the available heap space. Fortunately, Java provides different
Reference
objects to prevent this problem.
Memory leaks are often difficult to locate, since the resulting
OutOfMemoryError
could be thrown from any part of the application.
Debugging a memory leak usually requires the help of a profiler. A profiler can
analyze the heap dump created when the JVM crashes and recreate the reference
hierarchy to pinpoint where the majority of memory is being retained.

---

Soft References
A soft reference is an object that can only be retrieved by invoking the get()
method on a SoftReference container. Softly reachable objects will not
be eagerly garbage collected, making them ideal for caches. For example, if we
stored SoftReference values inside of our map, our cache could
grow until it filled the heap, at which point the get() method would start
returning null for stars that were garbage collected. We could then treat these
values as if they were expired cache entries.

---

Weak References
A weak reference is an object that can only be retrieved by invoking the get()
method on a WeakReference container. Weakly reachable objects will
be eagerly garbage collected, making them ideal for short-lived object
associations. For example, if we allowed our users to edit stars, we could use
a ConcurrentMap to synchronize access to a star by associating its name
to a User. However, if the user closed their browser prematurely the star would
remain locked in the map. Assuming that the User was also stored as a strong
reference in a session object, we could use a WeakReference
to determine when that session expired because the get() method would return
null
soon after the session was garbage collected.

---

Reference Queue
In both of our examples, there is a subtle problem.
Our SoftReference cache automatically removes Star objects,
but we could still fill up the map with keys and empty SoftReference
containers. Fortunately, Java provides us with an elegant solution in the form
of a ReferenceQueue.
A ReferenceQueue is a queue that can be passed into the constructor
of Reference objects. When an object wrapped by a Reference becomes
garbage collected, the Reference is enqueued onto the ReferenceQueue.
This queue can then be polled for cleanup operations. If we were to subclass the
SoftReference
and WeakReference classes to store the name of a star,
we would then have a convenient callback for removing expired map entries.

---