两个对象的 hashCode（）相同，则 equals（）也一定为 true，对吗？

两个对象的hashcode()相同，equals()方法不一定返回true。这是因为hashcode()的返回值有限，不同对象可能产生相同的哈希值（即哈希碰撞），而equals()才是判断对象是否相等的最终依据；因此当hashcode()相同时，仍需通过equals()进一步确认对象是否真正相等。

不是的，两个对象的 hashCode() 相同，它们的 equals() 方法不一定返回 true。这是一个常见的误区，理解 hashCode() 和 equals() 的契约非常重要。简单来说，hashCode() 相同只是一个初步的筛选，表明它们“可能”是相等的，但最终的、权威的判断始终由 equals() 方法来完成。

解决方案

当我们谈论Java（或者其他面向对象语言中类似的概念）里两个对象的“相等性”时，equals() 和 hashCode() 是两把非常关键的尺子。它们的职责不同，但又紧密关联，构成了一套判断对象逻辑相等性的机制。

hashCode() 方法返回一个整数值，这个值的主要作用是为基于哈希的集合（比如 HashMap、HashSet）提供快速查找的依据。你可以把它想象成一个对象的“指纹”或者“桶号”。当你想在一个 HashSet 中查找一个对象，或者在 HashMap 中查找一个键对应的值时，系统会先计算对象的 hashCode()，然后直接去对应的哈希桶里找。这比遍历整个集合要快得多。

而 equals() 方法，它的职责是定义两个对象在逻辑上是否相等。这才是真正判断“是不是同一个东西”的标准。例如，两个 Person 对象，如果它们的 id 和 name 都一样，我们可能就认为它们是相等的，即使它们在内存中的地址不同。

这里的核心契约是：

• 如果两个对象通过 equals() 方法判断为相等（即 a.equals(b) 返回 true），那么它们的 hashCode() 值必须相同。这是强制性的。
• 反过来，如果两个对象的 hashCode() 值相同，它们通过 equals() 方法判断不一定相等。这就是我们标题问题的答案。

为什么会有这种不对称性呢？因为 hashCode() 的返回值是一个 int 类型，它的取值范围有限（大约20亿）。而我们程序中可能存在的对象数量，或者说对象能够表示的不同状态数量，是远超这个范围的。这就导致了“哈希碰撞”——不同的对象可能会计算出相同的 hashCode 值。这就像把很多不同形状的积木放进有限数量的箱子里，不同的积木可能会被分到同一个箱子。当哈希值相同，系统会进一步调用 equals() 来确认这两个对象是否真的相等。如果 equals() 返回 false，那么即使 hashCode() 相同，它们也不是同一个对象。

为什么两个对象的 hashCode() 相同，equals() 却可能不同？

这其实是哈希函数设计本身的特性所决定的。hashCode() 的目标是尽可能地将不同的对象映射到不同的哈希值，但由于哈希值的空间是有限的，而对象的状态空间是无限的（或者说远大于哈希值空间），所以哈希碰撞是不可避免的。

打个比方，你有一本字典，每个词都有一个页码。hashCode() 就像是根据词的开头字母给你一个大致的页码范围，比如所有A开头的词都在第1页。但第1页上肯定有不止一个A开头的词，要找到具体的“Apple”这个词，你还需要在第1页里一个一个地看，这个“一个一个地看”的过程，就是 equals() 在做的事情。

在实际编程中，我们可能会遇到这样的情况：你自定义了一个类，但没有正确地重写 hashCode() 方法，或者只重写了 hashCode() 而没有重写 equals()。默认情况下，Object 类的 hashCode() 返回的是对象的内存地址相关的哈希值，而 equals() 比较的是两个对象的内存地址（即 == 运算符）。如果你只重写了 hashCode()，使得两个逻辑上相等的对象返回了相同的哈希值，但 equals() 仍然比较内存地址，那么它们当然不相等。更常见的是，即使 hashCode() 实现得很好，不同的对象也可能偶然地产生相同的哈希值。这种情况下，equals() 就会发挥它作为最终仲裁者的作用。

正确重写 hashCode() 和 equals() 方法的关键原则是什么？

正确重写这两个方法是Java编程中的一项基本功，尤其当你的对象需要作为 HashMap 的键或 HashSet 的元素时。遵循以下原则至关重要：

Midjourney

当前最火的AI绘图生成工具，可以根据文本提示生成华丽的视觉图片。

下载

1. 自反性 (Reflexive): 对于任何非 null 的引用值 x，x.equals(x) 必须返回 true。这很直观，自己肯定等于自己。
2. 对称性 (Symmetric): 对于任何非 null 的引用值 x 和 y，如果 x.equals(y) 返回 true，那么 y.equals(x) 也必须返回 true。这是一个常见的陷阱，尤其是在处理不同类型但逻辑上可能相等的对象时。
3. 传递性 (Transitive): 对于任何非 null 的引用值 x、y 和 z，如果 x.equals(y) 返回 true 且 y.equals(z) 返回 true，那么 x.equals(z) 也必须返回 true。
4. 一致性 (Consistent): 对于任何非 null 的引用值 x 和 y，只要 equals 比较中使用的信息没有被修改，多次调用 x.equals(y) 都会返回相同的结果。这意味着 equals 方法不应该依赖于随机数或外部可变状态。
5. 与 null 的比较 (Nullity): 对于任何非 null 的引用值 x，x.equals(null) 必须返回 false。

hashCode() 的额外原则：

• 一致性： 在应用程序执行期间，只要对象的 equals 比较中使用的信息没有被修改，对同一个对象多次调用 hashCode() 方法必须始终返回相同的整数。
• 与 equals() 的关联： 如果两个对象根据 equals(Object) 方法是相等的，那么对这两个对象中的每一个调用 hashCode() 方法都必须产生相同的整数结果。这是最关键的一点，也是我们文章开头问题的反面。

实践建议：

• 永远同时重写 equals() 和 hashCode()。 如果只重写一个，几乎必然会导致问题。
• 使用IDE生成： 现代IDE（如IntelliJ IDEA, Eclipse）通常能自动生成符合这些契约的 equals() 和 hashCode() 方法，这能大大减少出错的几率。
• 选择参与比较的字段： 只有那些在 equals() 方法中用来判断对象相等性的字段，才应该被用来计算 hashCode()。通常是那些能唯一标识对象或者构成其逻辑同一性的字段。
• 考虑性能： hashCode() 的实现应该尽可能高效，因为它会被频繁调用。
• 不可变对象： 对于不可变对象（Immutable Objects），hashCode() 可以缓存起来，因为它永远不会改变，下次直接返回缓存值即可，进一步提升性能。

这里是一个简单的Java类，展示了如何正确重写这两个方法：

import java.util.Objects;

public class User {
    private final Long id;
    private final String name;
    private final int age;

    public User(Long id, String name, int age) {
        this.id = id;
        this.name = name;
        this.age = age;
    }

    // Getters...

    @Override
    public boolean equals(Object o) {
        if (this == o) return true; // 相同引用
        if (o == null || getClass() != o.getClass()) return false; // null或不同类型
        User user = (User) o; // 类型转换
        // 比较所有参与逻辑相等判断的字段
        return age == user.age &&
               Objects.equals(id, user.id) &&
               Objects.equals(name, user.name);
    }

    @Override
    public int hashCode() {
        // 使用所有参与 equals 比较的字段来计算哈希值
        return Objects.hash(id, name, age);
    }

    @Override
    public String toString() {
        return "User{" +
               "id=" + id +
               ", name='" + name + '\'' +
               ", age=" + age +
               '}';
    }
}

在这个 User 类中，equals 方法判断 id、name 和 age 都相同时才认为是相等。相应的，hashCode 方法也使用了这三个字段来计算哈希值，确保了契约的遵守。Objects.hash() 是一个方便的工具方法，能帮助我们避免手动处理 null 和复杂的哈希计算。

不正确重写 hashCode() 和 equals() 会导致哪些常见问题？

我个人在工作中，遇到过太多因为这两个方法没写对而引发的“奇葩”问题，有时候能让你抓耳挠腮好几天。这些问题往往非常隐蔽，因为代码本身可能不会直接报错，但程序的行为就是不对劲。

1. 集合类行为异常：

   • HashSet / HashMap 无法正确查找或存储元素： 这是最常见也是最直接的问题。如果你重写了 equals() 但没有重写 hashCode()，或者 hashCode() 的实现与 equals() 不一致，那么当你把对象放到 HashSet 中，或者作为 HashMap 的键时，后面再尝试用一个逻辑上相等的对象去 contains() 或 get()，很可能返回 false 或 null。因为 hashCode() 可能会把这个“相等”的对象放到了不同的哈希桶里，或者 equals() 在哈希桶内找不到它。
     • 举个例子，你有一个 User 对象 u1，把它放进 HashSet。然后你创建了一个新的 User 对象 u2，它的字段和 u1 完全一样（逻辑相等）。如果你 set.contains(u2)，很可能得到 false，因为 u2 的默认 hashCode()（基于内存地址）和 u1 不同，它被放到了另一个哈希桶里，或者根本就没去 u1 所在的桶里找。
   • 集合中出现重复元素： 如果你只重写了 hashCode() 但没有重写 equals()，或者 equals() 判断逻辑有问题，即使 hashCode() 相同，equals() 也可能返回 false。这样，逻辑上相同的两个对象，在 HashSet 中会被视为两个不同的元素存储起来，违背了 Set 的“不重复”特性。

2. 性能急剧下降：

   • 如果 hashCode() 方法总是返回一个常量（比如 return 1;），那么所有的对象都会被映射到同一个哈希桶。这会导致 HashMap 或 HashSet 的查找性能从预期的 O(1) 退化到 O(n)，因为每次查找都需要遍历这个巨大的“桶”里的所有元素，实际上就退化成了 ArrayList 或 LinkedList 的性能。对于数据量大的应用，这简直是灾难性的。

3. 框架和库的误用：

   • 许多Java框架（如Spring Data JPA、Hibernate等ORM框架、各种测试框架、序列化库等）在内部处理对象时，都会依赖 equals() 和 hashCode() 来判断对象的同一性或进行比较。如果这些方法实现有误，可能会导致数据持久化出现问题、缓存失效、测试用例失败、或者在集合操作中出现预期之外的行为。比如，ORM框架在管理实体生命周期时，可能会因为 equals() 错误而认为两个逻辑上相同的对象是不同的，从而导致重复插入或更新失败。

4. 调试困难：

   • 这类问题通常不会在编译时报错，也不会立即抛出运行时异常，而是表现为程序逻辑上的错误，比如“数据不对”、“某个功能不生效”。追踪这类问题往往需要花费大量时间，因为你需要从业务逻辑层层深入，最终才能定位到是某个POJO（Plain Old Java Object）的 equals() 或 hashCode() 方法出了问题。我见过太多次，一个看似简单的bug，追溯到最后发现，竟然是某个数据传输对象（DTO）忘记重写或者重写错了 equals 和 hashCode。

所以，对待 equals() 和 hashCode()，一定要像对待你的核心业务逻辑一样认真。它们是构建健壮、高效Java应用的基础。