能否将Employee类用作HashMap中的键？

当然可以，但如果不遵循HashMap键的核心规则，大概率会遇到各种不符合预期的问题。下面结合具体场景拆解关键注意点：

1. 必须同时重写equals()和hashCode() #

HashMap的核心逻辑是：先通过hashCode()计算键的存储桶位置，再通过equals()在桶内匹配具体元素。这两个方法必须配套实现，否则会彻底打乱HashMap的工作机制：

• hashCode()规则：逻辑相等的对象必须返回相同的哈希值；逻辑不等的对象尽量返回不同哈希值（减少哈希碰撞，提升性能）。比如Employee类可以用唯一标识id来计算哈希值，示例：return Objects.hash(id);。
• equals()规则：要满足等价关系——自反、对称、传递、一致。比如比较两个Employee的id是否相等，同时处理null和类型判断，示例：

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Employee employee = (Employee) o;
    return id == employee.id;
}

2. 仅重写equals()未重写hashCode()的坑 #

假设两个Employee对象emp1和emp2的id相同，equals()返回true，但默认的hashCode()基于对象内存地址生成，两者哈希值不同。此时把emp1放入HashMap后，用emp2去get会返回null——因为HashMap会先根据emp2的哈希值找到另一个桶，桶里根本没有这个键；甚至重复putemp1和emp2，会被当成两个不同的键存入，造成数据冗余。

3. 仅重写hashCode()未重写equals()的问题 #

如果两个逻辑上相等的Employee对象（比如id相同），hashCode()返回相同值，但equals()默认比较对象引用，HashMap会认为它们是不同的键。这会导致同一个桶里存入多个逻辑相同的键，后续get时无法匹配到正确的元素，因为即使哈希值相同，equals()也不认可。

4. hashCode()返回常量的性能灾难 #

如果hashCode()固定返回同一个值（比如return 1;），所有键都会被塞进同一个桶里。此时HashMap退化为链表（元素超过8个会转红黑树），put和get操作的时间复杂度从理想的O(1)暴跌到O(n)（链表）或O(logn)（红黑树），完全失去HashMap的性能优势，数据量大的时候会严重拖慢程序。

5. 将Employee设为不可变是最佳实践 #

如果作为键的Employee对象是可变的（比如提供了setId()方法），放入HashMap后修改id会导致其哈希值变化——之后再用这个对象get时，会找不到原来的桶，无法获取对应的值；甚至原来的键会留在旧桶里，无法被访问，造成内存泄漏。

所以最佳实践是把Employee的字段设为final，不提供修改方法，确保对象一旦创建就不可变，从根源避免这类问题。

内容的提问来源于stack exchange，提问作者Pooja Sawant