Why are immutable objects ideal as keys in a HashMap or HashSet, and what breaks if you use a mutable key?

## How a hash-based collection finds things A `HashMap` is an array of **buckets**. To store key `k`, it computes `k.hashCode()`, spreads the bits, and reduces that to a bucket index. To look up `k` later (`get`, `containsKey`, `remove`), it does the **same** computation to pick a bucket, then walks that bucket comparing candidates with `k.equals(candidate)`. So retrieval depends on two things being **stable while the key is in the map**: 1. the key's `hashCode()` value, and 2. the result of `equals()` on the fields it compares. ## Why immutability makes a perfect key An immutable object's fields never change, so `hashCode()` and `equals()` are **constant for the object's lifetime**. The bucket you computed at insert time is the same bucket you'll compute at lookup time. Lookups therefore always land in the right place. The JDK's canonical keys - `String`, `Integer`, `Long`, `UUID`, `LocalDate`, enums - are all immutable for exactly this reason. ## What breaks with a mutable key Suppose `Point` is mutable with `x`, `y` used in `hashCode`/`equals`: ``` Point p = new Point(1, 2); map.put(p, "a"); // stored in bucket for hash(1,2) p.setX(99); // hashCode now reflects (99,2) map.get(p); // computes hash(99,2) -> different bucket -> MISS (null) ``` The entry still physically exists (iterating the map's entrySet finds it), but `get`/`containsKey`/`remove` all look in the wrong bucket and fail. You now have a key you **cannot retrieve or delete by lookup** - a silent, hard-to-debug leak/corruption. The collection's contract ('if you put it, you can get it') is violated, and it's entirely your fault for mutating a live key. ## The contract, stated precisely The `equals`/`hashCode` contract says equal objects must have equal hash codes, and `hashCode` must be **consistent** - return the same value on repeated calls *provided no information used in equals is modified*. A mutable key that changes such a field after insertion breaks the 'no information modified' precondition **relative to the collection's expectations**, which is what corrupts lookup. ## Safe options if you must key on mutable data - **Use an immutable snapshot as the key** (copy the relevant fields into an immutable value or a record) so later mutation of the original doesn't affect the stored key. - **Don't mutate the key while it's in the map**: remove it, mutate, re-insert. - **Use `IdentityHashMap`** if identity (not value equality) is the intended key semantics - it keys on `==` and the default identity hash, which doesn't depend on mutable fields. ## Tie to the broader topic This is one of the headline **benefits** of immutability: stable hash/equality makes immutable objects trouble-free keys and set members. The corresponding **trade-off** elsewhere (allocation per change) doesn't apply here because keys are typically created once and never modified - so for keys, immutability is almost pure upside.