你为什么要关心equals和hashcode

等于和哈希码是每个Java对象的基本元素。它们的正确性和性能对于您的应用程序至关重要。但是，我们经常看到甚至有经验的程序员都忽略了类开发的这一部分。在本文中，我将介绍一些与这两种非常基本的方法有关的常见错误和问题。

合同

提到的方法至关重要的是所谓的“合同”。有大约的hashCode三个规则和五个约等于（你可以找到他们在Java文档的Object类），但我们将讨论三个重要的。让我们从hashCode（）开始：

“只要在Java应用程序执行期间在同一个对象上多次调用它， hashCode方法就必须一致地返回相同的整数，只要没有 修改该对象的equals比较中使用的 信息即可 。”
这意味着对象的哈希码不必是不变的。因此，让我们看一下真正简单的Java对象的代码：

public class Customer {private UUID id;private String email;public UUID getId() {return id;}public void setId(final UUID id) {this.id = id;}public String getEmail() {return email;}public void setEmail(final String email) {this.email = email;}@Overridepublic boolean equals(final Object o) {if (this == o) return true;if (o == null || getClass() != o.getClass()) return false;final Customer customer = (Customer) o;return Objects.equals(id, customer.id) &&Objects.equals(email, customer.email);}@Overridepublic int hashCode() {return Objects.hash(id, email);}
}

您可能已经注意到， equals和hashCode是由我们的IDE自动生成的。我们确信这些方法不是一成不变的，并且肯定会广泛使用此类。也许这样的类太常见了，这样的实现没有错吗？因此，让我们看一个简单的用法示例：

def "should find cart for given customer after correcting email address"() {given:Cart sampleCart = new Cart()Customer sampleCustomer = new Customer()sampleCustomer.setId(UUID.randomUUID())sampleCustomer.setEmail("emaill@customer.com")HashMap customerToCart = new HashMap<>()when:customerToCart.put(sampleCustomer, sampleCart)then:customerToCart.get(sampleCustomer) == sampleCartand:sampleCustomer.setEmail("email@customer.com")customerToCart.get(sampleCustomer) == sampleCart
}

在上述测试中，我们希望确保在更改示例客户的电子邮件后，我们仍然能够找到其购物车。不幸的是，该测试失败。为什么？因为HashMap将密钥存储在“存储桶”中。每个存储桶都具有特定范围的哈希。由于这个想法，哈希映射非常快。但是，如果我们将密钥存储在第一个存储桶中（负责1到10之间的散列），然后hashCode方法的值返回11而不是5（因为它是可变的），会发生什么？哈希图尝试查找密钥，但是它检查第二个存储桶（保留哈希11到20）。它是空的。因此，对于给定的客户根本没有购物车。这就是为什么拥有不可更改的哈希码如此重要的原因！

实现它的最简单方法是使用不可变对象。如果由于某种原因在您的实现中不可能，那么请记住将hashCode方法限制为仅使用对象的不可变元素。
第二个hashCode规则告诉我们，如果两个对象相等（根据equals方法），则哈希值必须相同。这意味着我必须将这两种方法相关联，这可以通过基于相同的信息（基本上是字段）来实现。

最后但并非最不重要的一点是，它告诉我们有关等式的传递性。它看起来很琐碎，但事实并非如此-至少在您考虑继承时。想象我们有一个扩展了日期时间对象的日期对象。为一个日期实现equals方法很容易–当两个日期相同时，我们返回true。日期时间也一样。但是，当我想将日期与日期时间进行比较时会发生什么？他们有相同的日期，月份和年份是否足够？是否可以比较小时和分钟，因为日期上没有此信息？如果我们决定使用这种方法，那我们就搞砸了。请分析以下示例：

2016-11-28 == 2016-11-28 12:202016-11-28 == 2016-11-28 15:52

由于equals的传递性，我们可以说2016-11-28 12:20等于2016-11-28 15:52这当然是愚蠢的。但是，当您考虑平等合同时是正确的。

JPA用例

不让我们谈论JPA。看起来在这里实现equals和hashCode方法非常简单。我们对每个实体都有唯一的主键，因此基于此信息的实现是正确的。但是，何时分配了该唯一ID？在对象创建期间还是在刷新更改到数据库之后？如果您是手动分配ID，则可以，但是如果您依赖底层引擎，则可能会陷入陷阱。想象这样的情况：

public class Customer {@OneToMany(cascade = CascadeType.PERSIST)private Setaddresses = new HashSet<>();public void addAddress(Address newAddress) {addresses.add(newAddress);}public boolean containsAddress(Address address) {return addresses.contains(address);}
}

如果地址的hashCode基于ID，则在保存Customer实体之前，我们可以假定所有哈希码均等于零（因为还没有ID）。刷新更改后，将分配ID，这也会导致新的哈希码值。现在，您可以调用containsAddress方法，不幸的是，由于与在第一部分中讨论HashMap的相同原因，它将始终返回false。我们如何保护这种问题？据我所知，有一种有效的解决方案– UUID。

class Address {@Id@GeneratedValueprivate Long id;private UUID uuid = UUID.randomUUID();// all other fields with getters and setters if you need@Overridepublic boolean equals(final Object o) {if (this == o) return true;if (o == null || getClass() != o.getClass()) return false;final Address address = (Address) o;return Objects.equals(uuid, address.uuid);}@Overridepublic int hashCode() {return Objects.hash(uuid);}
}

uuid字段（可以是UUID或简单地为String）在对象创建期间分配，并在整个实体生命周期中保持不变。它存储在数据库中，并在查询该对象后立即加载到字段中。它或当然会增加一些开销和占用空间，但没有免费的东西。如果您想了解有关UUID方法的更多信息，可以查看有关此内容的两篇精彩文章：

https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
https://vladmihalcea.com/2014/07/01/hibernate-and-uuid-identifiers/

偏向锁定

十多年来，Java中的默认锁定实现使用一种称为“偏置锁定”的东西。可以在标志注释中找到有关此技术的简要信息（来源： Java Tuning White Paper ）：

-XX：+ UseBiasedLocking
启用一种用于提高无竞争同步性能的技术。一个对象被“偏向”线程，该线程首先通过Monitorenter字节码或同步方法调用来获取其监视器。在多处理器计算机上，该线程执行的后续与监视器相关的操作相对要快得多。在启用了此标志的情况下，某些具有大量无竞争同步的应用程序可能会实现明显的加速。尽管已尝试将负面影响降到最低，但某些具有某些锁定模式的应用程序可能会变慢。

对于我们而言，有关此帖子的有趣之处是内部如何实现偏置锁定。 Java使用对象标头存储持有锁的线程的ID。问题在于对象标头的布局定义明确（如果您有兴趣，请参阅OpenJDK源hotspot / src / share / vm / oops / markOop.hpp ），不能像这样“扩展”它。在64位中，JVM线程ID的长度为54位，因此我们必须决定是否要保留此ID或其他。不幸的是，“其他”意味着对象哈希码（实际上是身份哈希码，存储在对象头中）。

每当您对自Object类以来没有覆盖它的任何对象调用hashCode（）方法时，或者当您直接调用System.identityHashCode（）方法时，都将使用此值。这意味着当您检索任何对象的默认哈希码时；您禁用对此对象的偏向锁定支持。这很容易证明。看一下这样的代码：

class BiasedHashCode {public static void main(String[] args) {Locker locker = new Locker();locker.lockMe();locker.hashCode();}static class Locker {synchronized void lockMe() {// do nothing}@Overridepublic int hashCode() {return 1;}}
}

当您使用以下VM标志运行main方法时： -XX:BiasedLockingStartupDelay=0 -XX:+TraceBiasedLocking您会看到……没有什么有趣的事情：）

但是，从Locker类中删除hashCode实现后，情况将发生变化。现在我们可以在日志中找到这样的行：
Revoking bias of object 0x000000076d2ca7e0 , mark 0x00007ff83800a805 , type BiasedHashCode$Locker , prototype header 0x0000000000000005 , allow rebias 0 , requesting thread 0x00007ff83800a800

为什么会发生？因为我们要求提供身份哈希码。总结一下这一部分：类中没有hashCode意味着没有偏向锁定。

非常感谢https://www.sitepoint.com/java/的 Nicolai Parlog审阅了这篇文章并指出了一些错误。