A `HashMap` doubles its table when the load factor is exceeded. Someone assumes that means every key gets rehashed — `hashCode()` called again for each one — during a resize. Is that true, and if not, what does a resize actually do, and why does it matter for a key whose `hashCode()` is expensive to compute?

No — a resize does not call hashCode() again on any key. Each HashMap node stores the key's already-computed hash value (after the internal spread step) right alongside the key and value, precisely so it never has to be recomputed. A resize doubles the table's length, and because that new length is a power of two with exactly one more bit than before, every existing node's new bucket index is determined by that single new bit of its already-stored hash — it either stays at its old index, or moves to old-index-plus-old-length, and nothing else about where it lands needs deciding. The HashMap walks each old bucket once, splits its nodes into a "stays" list and a "moves" list using that one bit, and relinks them into the new table — no hash computed, no equals() called, just pointer relinking. It's still an O(n) operation because every node in the table gets touched once, but the expensive part (whatever hashCode() does) never runs again after the key's first insertion.