Java对象相等判断方法详解

Java中对象相等性远不止表面看起来那么简单：默认的equals()仅作引用比较，导致字段完全相同的对象也被判为不等；正确实现需同时重写equals()与hashCode()并保持逻辑一致，而Lombok虽能自动生成却暗藏继承遗漏、集合顺序敏感等陷阱；Objects.equals提供null安全的统一入口，record虽开箱即用但严重依赖字段类型自身equals()的正确性，且不可变性无法阻止内部可变对象引发的哈希码漂移风险——理解这些细节，才能避免在集合操作、缓存键值、数据比对等关键场景中掉入“看似相等实则失效”的深坑。

为什么 equals() 返回 false，即使两个对象字段一模一样？

因为默认的 equals() 继承自 Object，只做引用比较（==），不是内容比较。哪怕两个 User 实例的 id、name 完全相同，只要不是同一个对象，equals() 就返回 false。

解决办法是重写 equals() ——但必须同时重写 hashCode()，否则放进 HashSet 或用作 HashMap 的 key 时行为异常（比如找不到已存在的 key）。

• 重写 equals() 前先判 null 和类型：if (obj == null || getClass() != obj.getClass()) return false;
• 用 Objects.equals(a, b) 比较字段，它会自动处理 null 安全
• hashCode() 必须用 equals() 中参与比较的**相同字段**计算，推荐用 Objects.hash(f1, f2, ...)

用 Lombok 的 @EqualsAndHashCode 真的省心吗？

它能自动生成逻辑正确的 equals() 和 hashCode()，但有隐含约束：默认只包含非静态、非瞬态（non-transient）字段，且忽略父类字段（除非显式加 callSuper = true）。

常见翻车点：

• 实体类用了继承（比如 BaseEntity 含 createTime），但没写 @EqualsAndHashCode(callSuper = true) → 父类字段不参与比较
• 字段含集合（如 List），Lombok 默认调用其 equals()，但若集合里元素顺序不同，结果就不同 —— 这有时不符合业务预期（比如认为无序集合应等价）
• 用了 @Data 却在子类里新增字段，又没重写 equals() → 子类实例和父类实例永远不等，哪怕字段值全一样

==、equals()、Objects.equals() 到底该用哪个？

== 只用于基本类型或确认要判断是否为同一对象（比如单例校验、枚举比较）；普通对象一律避免直接用 == 比内容。

equals() 必须确保调用方对象非 null，否则空指针；而 Objects.equals(a, b) 是安全封装：任一参数为 null 都返回 false（两个都 null 才返回 true）。

• 比较两个可能为 null 的字符串：Objects.equals(str1, str2) ✅；str1.equals(str2) ❌（str1 为 null 就崩）
• 比较自己创建的对象实例（已重写 equals()）：obj1.equals(obj2) 可以，但更推荐统一用 Objects.equals(obj1, obj2)，写法一致、防错
• 比较数组内容相等？equals() 不行（数组是对象，还是引用比较），得用 Arrays.equals(arr1, arr2)

用 record 就不用操心 equals() 了吗？

Java 14+ 的 record 确实自动生成基于所有组件字段的 equals() 和 hashCode()，且不可变，天然适合做数据载体。

但要注意边界情况：

• 字段类型本身没正确实现 equals()（比如某个字段是自定义类但没重写 equals()）→ 整个 record 的相等性会出错
• record 不能继承（extends 关键字非法），所以无法复用父类逻辑；想共享字段和行为，只能靠组合
• 如果字段含可变对象（如 ArrayList），record 虽不可变（引用不变），但内部状态仍可变 → hashCode() 在生命周期中可能变化，**绝不能用作 HashMap 的 key**

真正省心的前提是：所有字段类型都“守规矩”，且你接受 record 的语义限制 —— 它不是万能替代品，而是特定场景下的精准工具。

理论要掌握，实操不能落！以上关于《Java对象相等判断方法详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！