等于和哈希码是每个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