HashMap 优化的影响，该优化将与每个条目关联的哈希码缓存到其 get 方法

摘自第 46 页“有效的 Java”Joshua Bloch。第 9 项：当你重写 equals 时，一定要重写 hashCode

• 某些类 PhoneNumber 重写 equals() 但不重写 hashCode()
• “涉及两个实例：一个用于插入 HashMap，第二个相同的实例用于（尝试）检索。” ... “...即使两个实例碰巧散列到同一个存储桶，get方法几乎肯定会返回null，因为 HashMap 进行了优化，可以缓存与每个条目关联的哈希代码，并且如果哈希代码不匹配，则不会检查对象相等性。”

问题是 - 如果“两个实例碰巧散列到同一个存储桶”，为什么“get”将返回“null”？

• HashMap 优化“兑现......”的作用是什么（在没有获得正确的实例时）？

• 仅针对这种情况 - “两个实例碰巧散列到同一个存储桶” - 如果 HashMap 担心“如果散列码不匹配则对象相等”怎么办？

如果“两个实例恰好散列到同一个存储桶”，为什么“get”将返回“null”？ HashMap 优化“兑现......”的作用是什么（在没有获得正确实例的情况下）？

关键的一句话是

[...] 如果哈希码不匹配，则不会检查对象相等性。

所以即使键散列到同一个桶，.equals可能不会为相关元素调用（由于缓存优化）（因为甚至哈希码都不匹配）。因此，即使相关元素位于同一个桶中，也可能永远不会通过以下方式进行比较：.equals，因此没有“找到”。

仅针对这种情况 - “两个实例碰巧散列到同一个存储桶” - 如果 HashMap 担心“如果散列码不匹配则对象相等”怎么办？

If it didn't有这个优化，实际上did check .equals对应桶中的所有元素and如果两个散列碰巧散列到同一个桶，那么 get 方法将返回正确的元素。 （但这纯粹是运气，因为如果对象不相等，则不能保证两个哈希值首先会映射到同一个存储桶。）