Java 理论与实践:哈希

原创 2004年08月18日 21:46:00
Java 理论与实践:哈希
 

有效和正确定义hashCode()和equals()

级别:入门级


Brian Goetz 

Quiotix Corp首席顾问

2003年 8 月


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


对象相等性意味着什么?

人们很容易满足Object类规范对equals() 和 hashCode() 的要求。决定是否和如何忽略equals()除了判断以外,还要求其它。在简单的不可修值类中,如Integer(事实上是几乎所有不可修改的类),选择相当明显 -- 相等性应基于基本对象状态的相等性。在Integer情况下,对象的唯一状态是基本的整数值。 


对于可修改对象来说,答案并不总是如此清楚。equals() 和hashCode() 是否应基于对象的标识(象缺省实施)或对象的状态(象Integer和String)?没有简单的答案 -- 它取决于类的计划使用。对于象List和Map这样的容器来说,人们对此争论不已。Java类库中的大多数类,包括容器类,错误出现在根据对象状态来提供equals()和hashCode()实施。 


如果对象的hashCode()值可以基于其状态进行更改,那么当使用这类对象作为基于散列的集合中的关键字时我们必须注意,确保当它们用于作为散列关键字时,我们并不允许更改它们的状态。所有基于散列的集合假设,当对象的散列值用于作为集合中的关键字时它不会改变。如果当关键字在集合中时它的散列代码被更改,那么将产生一些不可预测和容易混淆的结果。实践过程中这通常不是问题 -- 我们并不经常使用象List这样的可修改对象做为HashMap中的关键字。 


一个简单的可修改类的例子是Point,它根据状态来定义equals()和hashCode()。如果两个Point 对象引用相同的(x, y)座标,Point的散列值来源于x和y座标值的IEEE 754-bit表示,那么它们是相等的。 


对于比较复杂的类来说,equals()和hashCode()的行为可能甚至受到superclass或interface的影响。例如,List接口要求如果并且只有另一个对象是List,而且它们有相同顺序的相同的Elements(由Element上的Object.equals() 定义),List对象等于另一个对象。hashCode()的需求更特殊--list的hashCode()值必须符合以下计算: 



hashCode = 1;

Iterator i = list.iterator();

while (i.hasNext()) {

Object obj = i.next();

hashCode = 31*hashCode + (obj==null ? 0 : obj.hashCode());

}




不仅仅散列值取决于list的内容,而且还规定了结合各个Element的散列值的特殊算法。(String类规定类似的算法用于计算String的散列值。) 


编写自己的equals()和hashCode()方法

忽略缺省的equals()方法比较简单,但如果不违反对称(Symmetry)或传递性(Transitivity)需求,忽略已经忽略的equals() 方法极其棘手。当忽略equals()时,您应该总是在equals()中包括一些Javadoc注释,以帮助那些希望能够正确扩展您的类的用户。 


作为一个简单的例子,考虑以下类: 



class A {

final B someNonNullField;

C someOtherField;

int someNonStateField;

}




我们应如何编写该类的equals()的方法?这种方法适用于许多情况: 



public boolean equals(Object other) {

// Not strictly necessary, but often a good optimization

if (this == other)

return true;

if (!(other instanceof A))

return false;

A otherA = (A) other;

return 

(someNonNullField.equals(otherA.someNonNullField))

&& ((someOtherField == null) 

? otherA.someOtherField == null 

: someOtherField.equals(otherA.someOtherField)));

}




现在我们定义了equals(),我们必须以统一的方法来定义hashCode()。一种统一但并不总是有效的定义hashCode()的方法如下: 



public int hashCode() { return 0; }




这种方法将生成大量的条目并显著降低HashMaps的性能,但它符合规范。一个更合理的hashCode()实施应该是这样: 



public int hashCode() { 

int hash = 1;

hash = hash * 31 + someNonNullField.hashCode();

hash = hash * 31 

+ (someOtherField == null ? 0 : someOtherField.hashCode());

return hash;

}




注意:这两种实施都降低了类状态字段的equals()或hashCode()方法一定比例的计算能力。根据您使用的类,您可能希望降低superclass的equals()或hashCode()功能一部分计算能力。对于原始字段来说,在相关的封装类中有helper功能,可以帮助创建散列值,如Float.floatToIntBits。 


编写一个完美的equals()方法是不现实的。通常,当扩展一个自身忽略了equals()的instantiable类时,忽略equals()是不切实际的,而且编写将被忽略的equals()方法(如在抽象类中)不同于为具体类编写equals()方法。关于实例以及说明的更详细信息请参阅Effective Java Programming Language Guide, Item 7 (参考资料) 。 


有待改进?

将散列法构建到Java类库的根对象类中是一种非常明智的设计折衷方法 -- 它使使用基于散列的容器变得如此简单和高效。但是,人们对Java类库中的散列算法和对象相等性的方法和实施提出了许多批评。java.util中基于散列的容器非常方便和简便易用,但可能不适用于需要非常高性能的应用程序。虽然其中大部分将不会改变,但当您设计严重依赖于基于散列的容器效率的应用程序时必须考虑这些因素,它们包括: 


太小的散列范围。使用int而不是long作为hashCode()的返回类型增加了散列冲突的几率。



糟糕的散列值分配。短strings和小型integers的散列值是它们自己的小整数,接近于其它“邻近”对象的散列值。一个循规导矩(Well-behaved)的散列函数将在该散列范围内更均匀地分配散列值。



无定义的散列操作。虽然某些类,如String和List,定义了将其Element的散列值结合到一个散列值中使用的散列算法,但语言规范不定义将多个对象的散列值结合到新散列值中的任何批准的方法。我们在前面编写自己的equals()和hashCode()方法中讨论的List、String或实例类A使用的诀窍都很简单,但算术上还远远不够完美。类库不提供任何散列算法的方便实施,它可以简化更先进的hashCode()实施的创建。



当扩展已经忽略了equals()的 instantiable类时很难编写equals()。当扩展已经忽略了equals()的 instantiable类时,定义equals()的“显而易见的”方式都不能满足equals()方法的对称或传递性需求。这意味着当忽略equals()时,您必须了解您正在扩展的类的结构和实施详细信息,甚至需要暴露基本类中的机密字段,它违反了面向对象的设计的原则。 

结束语

通过统一定义equals()和hashCode(),您可以提升类作为基于散列的集合中的关键字的使用性。有两种方法来定义对象的相等性和散列值:基于标识,它是Object提供的缺省方法;基于状态,它要求忽略equals()和hashCode()。当对象的状态更改时如果对象的散列值发生变化,确信当状态作为散列关键字使用时您不允许更更改其状态。 

Java 理论与实践: 正确使用 Volatile 变量

转载于:http://www.ibm.com/developerworks/cn/java/j-jtp06197.html Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的...
  • zgmzyr
  • zgmzyr
  • 2013年06月22日 11:48
  • 4387

Java 理论与实践: 哈希

Java 理论与实践: 哈希 有效和正确定义hashCode()和equals() 每个Java对象都有 hashCode() 和 equals() 方法。许多类 Override 这些方...
  • hlp_127
  • hlp_127
  • 2014年03月21日 09:56
  • 448

语音增强-理论与实践----笔记-谱减法

谱减法降噪 1: ref the 语音增强-理论与实践 语音增强-理论与实践----笔记-谱减法 关于谱减法降噪,在噪声为加性噪声的前提下,区分出带噪语音帧与噪声帧,通过带噪语音帧的幅度谱...
  • yahoochemical
  • yahoochemical
  • 2017年07月28日 21:54
  • 461

由学习理论谈学习中的实践

意在增加个体经验的实践学习,在古今中外的学习思想中均有体现,并且颇受重视。增长知识与亲身体验,是学习的两个方面,是不可分割的。正是这两方面的不断交互和相互促进,才形成一种有效的学习,实现人的内在发展和...
  • sxhelijian
  • sxhelijian
  • 2013年09月29日 21:47
  • 2805

raytrace 算法理论与实践

光线追踪(RayTracing)算法理论与实践(三)光照 分类: 计算机图形学2012-12-05 00:09 2360人阅读 评论(0) 收藏 举报 目录(?)[+] ...
  • xuexiaokkk
  • xuexiaokkk
  • 2015年09月17日 16:02
  • 498

感知哈希算法原理与实现

今天忽然想做一个图像识别的APP,但是在两张图片相似度的问题上产生了问题,感知哈希算法并不能解决这个问题,只是我在试着解决问题的过程中学到的一点知识。这里的关键技术叫做”感知哈希算法”(Percept...
  • whuhan2013
  • whuhan2013
  • 2016年03月27日 19:11
  • 2337

调试寄存器(DRx)理论与实践

调试寄存器(DRx)理论与实践By Hume/冷雨飘心前言+牢骚:生活的苦痛就象烈火,时时煎熬着伤痕累累疲惫不堪的那颗心。我拼力挣扎,然而却无济于事……太残酷了….上帝也在苦笑。           ...
  • zhaofuguang
  • zhaofuguang
  • 2013年10月18日 14:55
  • 642

java泛型学习和实践(1)

JDK1.5之后引入了泛型,泛型刚开始接触时比较难理解,经过慢慢学习,有一些收获,现总结下,既可以加深自身理解,也可以帮助他人。 在开源项目源代码中,会经常出现泛型。学习和使用泛型,是java程序员的...
  • tang9140
  • tang9140
  • 2014年12月25日 16:32
  • 1790

最小哈希和局部性哈希理论

最近在看《大数据-互联网大规模数据挖掘与分布式处理》这本书,觉得里面有些内容还是值得学习的,对于超大规模的文档集合,文档长度很长,文档的个数也很多,这么个情况下,如果寻找相似性比较高的文档对,会有一些...
  • u012303532
  • u012303532
  • 2015年08月11日 19:29
  • 690

哈希表、Java中HashMap

hash就是把剁碎的意思。说的好听点叫“散列”- 散开列出来。 意思是: 把任意长度的输入,通过某个hash算法,变换成固定长度的输出。该值就是hash值。 你看,这其实是一种固定长度的...
  • u010297957
  • u010297957
  • 2016年08月05日 01:24
  • 6423
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Java 理论与实践:哈希
举报原因:
原因补充:

(最多只允许输入30个字)