Java理论与实践:哈希

每个Java对象都有hashCode()和 equals()方法。许多类忽略(Override)这 些方法的缺省实施,以在对象实例之间提供更深层次的语义可比性。在Java理念 和实践这一部分,Java开发人员Brian Goetz向您介绍在创建Java类以有效和准 确定义hashCode()和equals()时应遵循的规则和指南。您可以在讨论论坛与作者 和其它读者一同探讨您对本文的看法。(您还可以点击本文顶部或底部的讨论进 入论坛。)

虽然Java语言不直接支持关联数组 -- 可以使用任何对象作为一个索引的数 组 -- 但在根Object类中使用hashCode()方法明确表示期望广泛使用HashMap(及 其前辈Hashtable)。理想情况下基于散列的容器提供有效插入和有效检索;直接 在对象模式中支持散列可以促进基于散列的容器的开发和使用。

定义对象的相等性

Object类有两种方法来推断对象的标识:equals()和hashCode()。一般来说 ,如果您忽略了其中一种,您必须同时忽略这两种,因为两者之间有必须维持的 至关重要的关系。特殊情况是根据equals() 方法,如果两个对象是相等的,它 们必须有相同的hashCode()值(尽管这通常不是真的)。

特定类的equals()的语义在Implementer的左侧定义;定义对特定类来说 equals()意味着什么是其设计工作的一部分。Object提供的缺省实施简单引用下 面等式:

public boolean equals(Object obj) { return (this == obj); }

在这种缺省实施情况下,只有它们引用真正同一个对象时这两个引用才是相 等的。同样,Object提供的hashCode()的缺省实施通过将对象的内存地址对映于 一个整数值来生成。由于在某些架构上,地址空间大于int值的范围,两个不同 的对象有相同的hashCode()是可能的。如果您忽略了hashCode(),您仍旧可以使 用System.identityHashCode()方法来接入这类缺省值。

忽略 equals() -- 简单实例

缺省情况下,equals()和hashCode()基于标识的实施是合理的,但对于某些 类来说,它们希望放宽等式的定义。例如,Integer类定义equals() 与下面类似 :

public boolean equals(Object obj) {
return (obj instanceof Integer
&& intvalue() == ((Integer) obj).intvalue());
}

在这个定义中,只有在包含相同的整数值的情况下这两个Integer对象是相等 的。结合将不可修改的Integer,这使得使用Integer作为HashMap中的关键字是 切实可行的。这种基于值的Equal方法可以由Java类库中的所有原始封装类使用 ,如Integer、Float、Character和Boolean以及String(如果两个String对象包 含相同顺序的字符,那它们是相等的)。由于这些类都是不可修改的并且可以实 施hashCode()和equals(),它们都可以做为很好的散列关键字。

为什么忽略 equals()和hashCode()?

如果Integer不忽略equals() 和 hashCode()情况又将如何?如果我们从未在 HashMap或其它基于散列的集合中使用Integer作为关键字的话,什么也不会发生 。但是,如果我们在HashMap中使用这类Integer对象作为关键字,我们将不能够 可靠地检索相关的值,除非我们在get()调用中使用与put()调用中极其类似的 Integer实例。这要求确保在我们的整个程序中,只能使用对应于特定整数值的 Integer对象的一个实例。不用说,这种方法极不方便而且错误频频。

Object的interface contract要求如果根据 equals()两个对象是相等的,那 么它们必须有相同的hashCode()值。当其识别能力整个包含在equals()中时,为 什么我们的根对象类需要hashCode()?hashCode()方法纯粹用于提高效率。Java 平台设计人员预计到了典型Java应用程序中基于散列的集合类(Collection Class)的重要性--如Hashtable、HashMap和HashSet,并且使用equals()与许多 对象进行比较在计算方面非常昂贵。使所有Java对象都能够支持 hashCode()并 结合使用基于散列的集合,可以实现有效的存储和检索。

实施equals()和hashCode()的需求

实施equals()和 hashCode()有一些限制,Object文件中列举出了这些限制。 特别是equals()方法必须显示以下属性:

Symmetry:两个引用,a和 b,a.equals(b) if and only if b.equals(a)

Reflexivity:所有非空引用, a.equals(a)

Transitivity:If a.equals(b) and b.equals(c), then a.equals(c)

Consistency with hashCode():两个相等的对象必须有相同的hashCode()值

Object的规范中并没有明确要求equals()和 hashCode() 必须一致 -- 它们 的结果在随后的调用中将是相同的,假设“不改变对象相等性比较中使用的任何 信息。”这听起来象“计算的结果将不改变,除非实际情况如此。”这一模糊声 明通常解释为相等性和散列值计算应是对象的可确定性功能,而不是其它。

时间: 2024-09-17 23:04:02

Java理论与实践:哈希的相关文章

Java理论与实践: 消除bug

很多有关编程风格的建议都是为了创建高质量.可维护的代码,这很合理, 因为最容易修复 bug 的时间就是在产生 bug 之前(少量的预防措施--).遗 憾的是,只预防往往是不够的,虽然有一些精巧的工具可以帮助您创建好的代码 ,但是很少有工具可以帮助您分析.维护或提高现有代码的质量. 写线程安全的类很难,而分析现有类的线程安全性更难,增强类使其仍然保 持线程安全也很难.以隐含假定.不变式以及预期用例(虽然在开发人员的头脑 中很清晰,但是没有以设计笔记.注释或者文档的方式记录下来)的方式编写完 类之后

Java 理论与实践: 非阻塞算法简介

[本文转载自Java 理论与实践: 非阻塞算法简介]Java 5.0 第一次让使用 Java 语言开发非阻塞算法成为可能,java.util.concurrent 包充分地利用了这个功能.非阻塞算法属于并发算法,它们可以安全地派生它们的线程,不通过锁定派生,而是通过低级的原子性的硬件原生形式 -- 例如比较和交换.非阻塞算法的设计与实现极为困难,但是它们能够提供更好的吞吐率,对生存问题(例如死锁和优先级反转)也能提供更好的防御.在这期的 Java 理论与实践 中,并发性大师 Brian Goet

Java 理论与实践:变还是不变?

不变对象具有许多能更方便地使用它们的特性,包括不严格的同步需求和不必考虑数据讹误就能自由地共享和高速缓存对象引用.尽管不变性可能未必对于所有类都有意义,但大多数程序中至少有一些类将受益于不可变.在本月的 Java 理论与实践中,Brian Goetz 说明了不变性的一些长处和构造不变类的一些准则.请在附带的论坛中与作者和其他读者分享您关于本文的心得.(也可以单击文章顶部或底部的"讨论"来访问论坛.) 不变对象是指在实例化后其外部可见状态无法更改的对象.Java 类库中的 String.

Java 理论与实践: JDK 5.0 中更灵活、更具可伸缩性的锁定机制

伸缩 内容: synchronized 快速回顾 对 synchronized 的改进 比较 ReentrantLock 和 synchronized 的可伸缩性 条件变量 这不公平 结束语 参考资料 关于作者 对本文的评价 相关内容: Java 理论与实践 系列 Synchronization is not the enemy Reducing contention IBM developer kits for the Java platform (downloads) 订阅: develop

Java理论与实践: 您的小数点到哪里去了?

许多程序员在其整个开发生涯中都不曾使用定点或浮点数,可能的例外是, 偶尔在计时测试或基准测试程序中会用到.Java语言和类库支持两类非整数类型 ― IEEE 754 浮点( float 和 double ,包装类(wrapper class)为 Float 和 Double ),以及任意精度的小数( java.math.BigDecimal ).在本月的 Java 理论和实践中,Brian Goetz 探讨了在 Java 程序中使用非整数类型时一 些常碰到的陷阱和"gotcha". 虽

Java理论与实践: 垃圾收集简史

Java 语言可能是使用最广泛的依赖于垃圾收集的编程语言,但是它并不是第 一个.垃圾收集已经成为了包括 Lisp.Smalltalk.Eiffel.Haskell.ML. Scheme和 Modula-3 在内的许多编程语言的一个集成部分,并且从 20 世纪 60 年代早期就开始使用了.在 Java 理论与实践的本篇文章中,Brian Goetz 描述 了垃圾收集最常用的技术. 垃圾收集的好处是无可争辩的 ―― 可靠性提高.使内存管理与类接口设计 分离,并使开发者减少了跟踪内存管理错误的时间.著

Java理论与实践: 构建一个更好的HashMap

ConcurrentHashMap 是 Doug Lea的 util.concurrent 包的一部分,它提供 比Hashtable 或者 synchronizedMap 更高程度的并发性.而且,对于大多数成 功的 get() 操作它会设法避免完全锁定,其结果就是使得并发应用程序有着非 常好的吞吐量.这个月,BrianGoetz 仔细分析了 ConcurrentHashMap的代码, 并探讨 Doug Lea 是如何在不损失线程安全的情况下取得这么骄人成绩的. 在7月份的那期 Java理论与实践

Java理论与实践: 修复Java内存模型,第1部分

活跃了将近三年的 JSR 133,近期发布了关于如何修复 Java 内存模型 (Java Memory Model, JMM)的公开建议.原始 JMM 中有几个严重缺陷,这导 致了一些难度高得惊人的概念语义,这些概念原来被认为很简单,如 volatile .final 以及 synchronized.在这一期的 Java 理论与实践 中,Brian Goetz 展示了如何加强 volatile 和 final 的语义,以修复 JMM.这些更改有些已经 集成在 JDK 1.4 中:而另一些将会包含

Java理论与实践:做个好的(事件)侦听器

观察者模式在 Swing 开发中很常见,在 GUI 应用程序以外的场景中,它对 于消除组件的耦合性也非常有用.但是,仍然存在一些侦听器登记和调用方面的 常见缺陷.在 Java 理论与实践 的这一期中,Java 专家 Brian Goetz 就如何 做一个好的侦听器,以及如何对您的侦听器也友好,提供了一些感觉很好的建议 .请在相应的 讨论论坛 上与作者和其他读者分享您对这篇文章的想法.(您也 可以单击本文顶部或底部的 讨论 访问论坛.) Swing 框架以事件侦听器的形式广泛利用了观察者模式(也称

Java理论与实践专题

Java理论与实践: JDK 5.0中更灵活.更具可伸缩性的锁定机制 Java理论和实践: 一个有缺陷的微基准的剖析 Java理论和实践: 理解JTS ― 平衡安全性和性能 Java理论和实践: 理解JTS ― 幕后魔术 Java理论和实践: 安全构造技术 Java理论与实践: 平衡测试,第3部分:用方面检验设计约束 Java理论与实践:平衡测试,第2部分:编写和优化bug检测器 Java理论与实践:平衡测试,第1部分:不要仅编写测试,还要编写bu Java理论与实践: 您的小数点到哪里去了?