等于和哈希码是每个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审阅了这篇文章并指出了一些错误。
翻译自: https://www.javacodegeeks.com/2016/12/care-equals-hashcode.html
)
)
