泰州网站制作计划,wordpress软件网站模板下载失败,用wordpress建站域名和空间哪里买比较好,广东建设行业招聘 什么网站等于和哈希码是每个Java对象的基本元素。 它们的正确性和性能对于您的应用程序至关重要。 但是#xff0c;我们经常看到甚至有经验的程序员也忽略了类开发的这一部分。 在本文中#xff0c;我将介绍一些与这两种非常基本的方法有关的常见错误和问题。 合同 提到的方法至关重… 等于和哈希码是每个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(emaillcustomer.com)HashMap customerToCart new HashMap()when:customerToCart.put(sampleCustomer, sampleCart)then:customerToCart.get(sampleCustomer) sampleCartand:sampleCustomer.setEmail(emailcustomer.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 {IdGeneratedValueprivate Long id;private UUID uuid UUID.randomUUID();// all other fields with getters and setters if you needOverridepublic 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:BiasedLockingStartupDelay0 -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
