首页教程行业资讯正文

自定义对象作为HashMap的key注意事项

uncle 行业资讯 2025年08月6日

0 收藏 0 点赞 676 浏览 2869 个字

摘要 :

文章目录 1. 键必须遵守hashCode()和equals()之间的契约 2. 如果允许更改键的hashCode会发生什么？ 3. 我们应该使HashMap的键不可变 4. 自定义键的HashMap示例 5. 示例 ……

文
章
目
录

1. 键必须遵守hashCode()和equals()之间的契约
2. 如果允许更改键的hashCode会发生什么？
3. 我们应该使HashMap的键不可变
4. 自定义键的HashMap示例
5. 示例
6. 结论

在Java中，我们可以使用对象作为HashMap的key，但在这样做时需要考虑重要的因素和准则。这的确是一个常见的面试问题，需要对HashMap的工作原理有很好的理解。以下是用户定义的类用作HashMap中的键时，需要考虑的几个重要因素：

1. 键必须遵守hashCode()和equals()之间的契约

为了设计一个良好的键，基本需求是“我们应该能够在不失败的情况下从map中检索值对象”，否则无论你构建多么复杂的数据结构，都将毫无用处。

为了决定我们是否已经创建了一个良好的键，我们必须了解“HashMap的工作原理”。“HashMap的工作原理”部分请自行阅读相关文章，但总结来说，它是基于哈希的原则工作的。

在HashMap中，键的hashCode()主要与equals()方法一起使用，用于将键放入map中，然后从map中获取它。因此，我们的唯一关注点是这两个方法。

equals() – 验证两个对象的相等性，这在我们的案例中是键。要重写以提供比较两个键的逻辑。
hashCode() – 在运行时返回键的唯一整数值。这个值用于查找map中的桶位置。

通常，如果重写equals()方法，则必须重写hashCode()方法，以保持hashCode()方法的一般合同，该合同规定相等的对象必须具有相等的哈希码。

2. 如果允许更改键的hashCode会发生什么？

如上所述，哈希码有助于计算存储键值对的map中的桶位置。不同的哈希码值可能指的是不同的桶位置。

如果不小心，在将键值对放入map后，更改了键对象的哈希码，那么几乎不可能从map中获取值对象，因为我们不知道在哪个桶中放入了键值对。旧的键值对是不可访问的，因此这是一种内存泄漏情况。

在运行时，JVM为每个对象计算哈希码并按需提供。当我们修改对象的状态时，JVM设置一个标志，表示对象已被修改，并且必须再次计算哈希码。所以，下一次调用对象的hashCode()方法时，JVM会重新计算该对象的哈希码。

3. 我们应该使HashMap的键不可变

对于上述基本推理，建议键对象是不可变的。不可变性确保我们每次都会得到相同的哈希码，用于键对象。因此，它实际上一次性解决了几乎所有问题。但是，再次强调，这种类必须遵守hashCode()和equals()方法的合同。

这也是为什么像String、Integer或其他包装类这样的不可变类是良好的键对象候选项的主要原因。这也回答了为什么字符串是Java中流行的HashMap键的问题。

但请记住，不可变性是建议而不是强制性的。如果你想将可变对象用作HashMap中的键，那么你必须确保键对象的状态更改不会更改对象的哈希码。这可以通过重写hashCode()方法来实现。但是，你必须确保你遵守equals()的合同。

4. 自定义键的HashMap示例

在下面的示例中，我创建了一个Account类，仅包含两个字段以简化。我已经重写了hashCode和equals方法，以便它只使用帐户号来验证Account对象的唯一性。帐户类的所有其他可能属性都可以在运行时更改。

public class Account
{
    private int accountNumber;
    private String holderName;
    public Account(int accountNumber) {
        this.accountNumber = accountNumber;
    }
    public String getHolderName() {
        return holderName;
    }
    public void setHolderName(String holderName) {
        this.holderName = holderName;
    }
    public int getAccountNumber() {
        return accountNumber;
    }
    //Depends only on account number
    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + accountNumber;
        return result;
    }
    //仅比较 account numbers
    @Override
    public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        Account other = (Account) obj;
        if (accountNumber != other.accountNumber)
            return false;
        return true;
    }
}

这是否会导致不良行为？

不会。原因是Account类的实现遵守了这样的合同：“只要它们相等，相等的对象必须产生相同的哈希码，但不相等的对象不需要产生不同的哈希码。”

5. 示例

让我们测试一下上述分析中的Account类。

//创建具有可变键的HashMap
HashMap<Account, String> map = new HashMap<Account, String>();
//创建 key 1
Account a1 = new Account(1);
a1.setHolderName(\"A_ONE\");
//创建 key 2
Account a2 = new Account(2);
a2.setHolderName(\"A_TWO\");
//在map中存入可变键和值
map.put(a1, a1.getHolderName());
map.put(a2, a2.getHolderName());
//更改key状态，哈希码便重新计算
a1.setHolderName(\"Defaulter\");
a2.setHolderName(\"Bankrupt\");
//成功！我们能够获取value
System.out.println(map.get(a1)); //打印 A_ONE
System.out.println(map.get(a2)); //打印 A_TWO
//尝试使用新创建的具有相同account number的key
Account a3 = new Account(1);
a3.setHolderName(\"A_THREE\");
//成功!我们仍然能够取回账号1的value
System.out.println(map.get(a3)); //打印  A_ONE