为什么我们需要在java中重写equals和hashcode，为什么我们不能使用Object类实现 [英] why we need to override equals and hashcode in java and why cannot we use Object class implementation

问题描述

伙计们请告诉我，在现实世界中我们为什么需要覆盖equals和hashcode，并且我们不能使用Object的等号和哈希码。

guys please let me know, in real world why we need to override equals and hashcode and cant we use Object's equals and hashcode.

推荐答案

对象的equals / hashcode实现很好 - 如果你想要引用标识作为你的相等。换句话说，on对象将始终与其自身相等，但与另一个对象不同。

Object's equals/hashcode implementation is fine - if you want "reference identity" as your equality. In other words, on object will always compare as equal to itself, but different to another object.

但是，如果您希望两个不同的对象相等，那么''必须覆盖方法，说明如何它们应该相等（然后覆盖哈希码与之一致）。

If, however, you want two distinct objects to be equal, you've got to override the method to say how they should be equal (and then override hashcode to be consistent with that).

最简单的例子可能是String。两个具有相同字符的不同字符串是相同的，并且它们非常有用它们是相等的：

The simplest example is probably String. Two different strings with the same characters are equal, and it's very useful for them to be equal:

String x = new String(new char[]{'a', 'b', 'c'});
String y = new String(new char[]{'a', 'b', 'c'});
System.out.println(x.equals(y)); // Prints true

现在将其与 FileInputStream进行比较 - 什么会使两个FileInputStreams相等？如果他们正在阅读同一个文件？文件中的位置怎么样？两个流到具有相同内容的不同文件怎么样？提问IMO并没有多大意义。

Now compare that to FileInputStream - what would make two FileInputStreams equal? If they're reading the same file? What about the position within the file? What about two streams to different files with the same content? It doesn't really make a lot of sense to ask the question, IMO.

现在，对象怎么可能实现知道 FileInputStream 和 String 的所需行为之间的区别？ 可以注意添加到字段，属性和类型本身的注释，可能会自动生成适当的字节码，然后可以进行JIT编译......但当然Java在注释可用之前很久就出现了。当前的方法非常简单 - 但它确实意味着如果你想要不同对象的值相等，你需要自己编写代码。

Now, how could the Object implementation know the difference between the desired behaviour of FileInputStream and String? It could potentially take note of annotations added to fields, properties and the type itself, possibly autogenerating appropriate bytecode which could then get JIT-compiled... but of course Java came out long before annotations were available. The current approach is very simple - but it does mean if you want value equality for distinct objects, you need to code it yourself.

需要注意的一点是，相等是通常更容易考虑不可变类型 - 如果两个对象在一个时间点相等然后在之后不相等则很奇怪。这也可能严重搞乱哈希表 - 哈希码基本上应该依赖于被认为是相等的对象的方面，并且当密钥首次被添加到哈希表时记录哈希码;如果你然后更改密钥的内容，它的哈希码会改变，但哈希表不会知道它。

One point to note is that equality is usually easier to think about for immutable types - it is odd if two objects are equal at one point in time and then non-equal later on. This can also seriously mess up hashtables - the hashcode should basically depend on the aspects of the object which are considered for equality, and the hashcode is recorded when a key is first added to a hashtable; if you then change the contents of the key, its hashcode would change, but the hashtable wouldn't know about it.

这篇关于为什么我们需要在java中重写equals和hashcode，为什么我们不能使用Object类实现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！