你为什么要关心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;
 }

 @Override
 public 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);
 }

 @Override
 public 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) == sampleCart
 and:
  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:20
 2016-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 Set

 addresses = 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
 @GeneratedValue
 private Long id;
 
 private UUID uuid = UUID.randomUUID();

 // all other fields with getters and setters if you need

 @Override
 public 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);
 }

 @Override
 public 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
  }

  @Override
  public 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审阅了这篇文章并指出了一些错误。

翻译自: https://www.javacodegeeks.com/2016/12/care-equals-hashcode.html