重写hashCode()与equals()相关问题：链表形成及HashMap实现疑问

这两个问题问到了HashMap核心机制的关键点，我来逐一拆解清楚：

问题1：若同时重写hashCode()和equals()，是否会形成链表？ #

答案是：不一定，但实际场景中大概率会。

首先得明确：HashMap里链表（或链表长度达标后转成的红黑树）形成的核心原因是哈希冲突——也就是两个不同的对象，经过哈希计算后被分配到了同一个哈希桶位置。

重写hashCode()和equals()本身并不会直接生成链表，而是取决于你重写hashCode()的逻辑：

• 理论上，如果能写出一个“完美”的hashCode()，让每个业务意义上不同的对象都生成唯一的哈希值（但这几乎不可能，因为哈希值是有限的int类型，而业务对象的可能状态是无限的），那不会有哈希冲突，自然不会形成链表。
• 但现实中，绝大多数hashCode()实现都会存在不同对象生成相同哈希值的情况（比如两个不同的Employee对象，可能因hashCode计算逻辑的巧合导致哈希值相同），这时候就会产生哈希冲突，HashMap就会把这些对象放到同一个哈希桶的链表（或红黑树）里。

而重写equals()的作用，是当哈希冲突发生时，帮HashMap判断两个对象是否是同一个键——如果不重写equals()，就会用Object默认的引用比较，这通常不符合业务上“相同内容的对象视为同一个键”的需求。

问题2：仅重写hashCode()，不重写equals()是否可行？ #

绝对不可行，这会导致HashMap完全不符合你的业务预期，甚至出现诡异的逻辑错误。

咱们结合HashMap的核心工作流程来分析：
当你往HashMap里put键值对，或者用键get值的时候，流程是这样的：

1. 先通过键的hashCode()计算哈希桶位置；
2. 遍历该桶里的元素，用equals()方法逐一比较，找到匹配的键。

你现在只重写了hashCode()，保证相同业务意义的Employee对象（比如id相同的员工）能得到相同的哈希值，但equals()用的是Object类的默认实现——只比较对象的内存引用。这就会出现以下问题：

• 假设你创建了两个Employee对象：Employee e1 = new Employee(1, "Alice")和Employee e2 = new Employee(1, "Alice")，它们的hashCode()相同，但因为是两个不同的对象，e1.equals(e2)会返回false。
• 当你把e1put进HashMap后，再用e2去get，HashMap会找到对应的哈希桶，但遍历的时候发现e2和桶里的e1equals不匹配，就会返回null——明明业务上是同一个员工，却找不到对应的值。
• 更糟的是，你可以把e1和e2都put进HashMap，HashMap会把它们当成两个不同的键，存到同一个哈希桶的链表中，造成数据冗余和逻辑混乱。

另外，从Java的规范来看，hashCode()和equals()是强绑定的：如果两个对象通过equals()比较返回true，那么它们的hashCode()必须相等；反过来，如果两个对象的hashCode()相等，equals()可以返回false（也就是哈希冲突的情况）。但如果只重写hashCode()不重写equals()，就等于打破了这个约定，必然会导致依赖这两个方法的集合类（比如HashMap、HashSet）行为异常。

所以结论是：只要你需要把自定义类作为HashMap的键，就必须同时重写hashCode()和equals()，而且要保证两者的逻辑一致——比如都基于Employee的id字段来计算/比较。

内容的提问来源于stack exchange，提问作者Moulina Mary A