If you put an object into a HashSet (or as a HashMap key) and then mutate a field that its hashCode depends on, what happens when you later try to look it up or remove it, and why?

## The setup: what a hash collection actually does A **hash collection** (`HashMap`, `HashSet`, which is backed by a `HashMap`) stores entries in an array of **buckets**. To decide which bucket an object goes into, it calls the object's **`hashCode()`** method — a method every Java object has that returns an `int`. The collection takes that int, spreads/mixes it, and reduces it modulo the array length to get a bucket index. Two objects with the same hashCode land in the same bucket (a **collision**); within a bucket the collection uses **`equals()`** to tell entries apart. So a hash collection relies on a simple but strict assumption: **an object's hashCode does not change while it is stored.** The collection records *where* it put the object exactly once — at insertion time — and never re-checks. ## What goes wrong when you mutate a hashCode field Suppose `hashCode()` is computed from a field `name`. You insert the object; the collection computes `hashCode()` = (say) 42, reduces it to bucket 7, and stores the object in bucket 7. Now you call `obj.setName(...)`, changing a field that `hashCode()` reads. The object's `hashCode()` is now (say) 99, which would reduce to bucket 3. But the collection **did not move the object** — it is still sitting in bucket 7. Nothing notified the collection of the change; there is no mechanism for that. Now you do `set.contains(obj)` (or `map.get(obj)`, or `set.remove(obj)`): 1. The collection computes the object's *current* hashCode → 99 → bucket 3. 2. It looks in bucket 3 and finds nothing matching. 3. It returns `false` / `null` — even though the very same object is physically still in the collection (in bucket 7). The entry is now **stranded**: you can't find it, can't `get` it, can't `remove(key)` it. Iterating the whole collection still visits it (iteration walks every bucket), but key-based access is broken. In a long-lived map this is a genuine **memory leak**: the entry stays reachable from the map but is unretrievable, so it's never removed and never collected. ## Why even `remove` fails People expect at least `remove` to clean up. It doesn't: `remove` also hashes the key to find the bucket, so it goes to bucket 3 and finds nothing. The only ways to get rid of a stranded entry are to mutate the field *back* to its original value (restoring the old hashCode), iterate-and-`Iterator.remove`, or clear the whole collection. ## The rules that follow 1. **Don't include mutable fields in `hashCode()` (and `equals`).** Base identity on fields that never change after construction — ideally a stable id assigned at creation. 2. **Prefer immutable keys.** Strings, boxed primitives, `record`s with immutable components, enums — these are the safest hash keys because their hashCode can never change. 3. **If you truly must mutate a key**, follow the remove → mutate → re-insert dance so the collection re-buckets it. ## Note on equals The same hazard applies to `equals` if `equals` and `hashCode` use the same fields (as the contract requires). But hashCode is the field that controls *bucketing*, so it's the one that determines whether the entry can be found at all. `TreeMap`/`TreeSet` (sorted, comparison-based — not hash-based) have an analogous but separate hazard: mutating a field used by `compareTo`/`Comparator` corrupts the tree ordering.