WeakHashMap, IdentityHashMap and EnumMap

For this lesson, we'll focus on how WeakHashMap uses WeakReference and ReferenceQueue, why it is not a general cache, when reference equality makes IdentityHashMap the right answer, why EnumMap is the best default for enum keys, and how to build maps with case-insensitive String keys. Interviewers ask these because they look like trivia until you hit the edge cases. Then the answer tells me whether you understand object lifetime, equality and the real contract of Map.

01Picture it first: luggage tags, mirror IDs and mail slots

Think of these maps as three different reception desks. WeakHashMap keeps a luggage tag that falls off when the suitcase is gone. IdentityHashMap checks the physical badge, not the name printed on it. EnumMap has one fixed mail slot per enum constant, so MONDAY always goes to slot 0 if it was declared first.

Let's get the WeakHashMap picture right first. The key is weak; the value is not.

Fig. 1

A WeakHashMap entry holds its key through a WeakReference registered with a ReferenceQueue; when the application drops the last strong reference, GC clears the weak key and the next map operation removes the stale entry while the value was always strongly held

Notice the shape. The map does not remove the entry at the exact instant the key becomes unreachable. The GC clears the weak reference and enqueues it, then a later map operation drains the queue and unlinks the stale entry.

02WeakHashMap under the hood

WeakHashMap<K,V> is a hash table whose entry extends WeakReference<Object>. The referent is the key. The entry also stores the value, the cached hash and the next pointer in the bucket chain.

import java.util.Map;
import java.util.WeakHashMap;

public class WeakKeysDemo {
    public static void main(String[] args) throws Exception {
        Map<Object, String> metadata = new WeakHashMap<>();

        Object request = new Object();
        String literal = "tenant-a";
        Integer small = Integer.valueOf(42);

        metadata.put(request, "request metadata");
        metadata.put(literal, "literal metadata");
        metadata.put(small, "small integer metadata");

        request = null;
        System.gc();
        Thread.sleep(100);

        metadata.size(); // touches the map and gives it a chance to expunge stale entries
        System.out.println(metadata);
    }
}

The request entry is the one that can disappear, because after request = null nothing else strongly refers to that object. The string literal is held by the class's constant data for as long as the class is loaded. The small Integer comes from IntegerCache for values from -128 to 127, so the cached object is strongly reachable through the JDK cache.

Notice three things:

• WeakHashMap calls an internal expungeStaleEntries while serving normal operations such as get, put, remove, size and table access. Cleanup is lazy from your point of view.
• The value is a strong reference. If the value points back to the key, directly or through a graph, the key is still reachable and the entry does not disappear.
• GC timing is not a business rule. You cannot write correctness logic that depends on an entry vanishing right after System.gc().

A real stale entry goes through four steps. The application drops its last strong reference to the key. The GC discovers that only weak references point at the key, clears the weak reference, and enqueues the entry's reference on the map's queue. A later map operation drains that queue, finds the original entry and removes it from the bucket.

That makes WeakHashMap useful for metadata keyed by object lifetime. For example, a framework might attach analysis data to AST nodes, parsed templates or connection wrapper objects without wanting a side table to keep those objects alive. For class-specific metadata, ClassValue<T> is often the cleaner API because the JVM owns the class-lifetime association.

03IdentityHashMap: reference equality on purpose