Object类中的Hash Code方法

Question

我在想为什么哈希码是在Object类中实现的，只是在使用像HashMap这样的集合时才提供它。所以不应该在实现Maps的接口中实现哈希码。

Answer 1

  

说使用哈希码实现并不是一个好主意   仅限收藏。

在Java API文档中，hashCode的常规协定如下：

1. 每当在同一个对象上多次调用它时 执行Java应用程序时，hashCode方法必须 如果没有使用任何信息，则始终返回相同的整数 in equals比较对象被修改。这个整数需要 从一次执行申请到保持不一致 另一个执行相同的应用程序。
2. 如果两个对象根据equals（Object）方法相等， 然后必须在两个对象中的每一个上调用hashCode方法 产生相同的整数结果。
3. 如果两个物体不相等，则不需要 equals（java.lang.Object）方法，然后调用hashCode方法 两个对象中的每一个都必须产生不同的整数结果。 但是，程序员应该意识到产生了不同的 不等对象的整数结果可以提高性能 哈希表。

  

所以hashcode只能用Object做。收藏只是获得好处   来自该特征的用于它们自己的用例，例如检查具有相同散列码的对象，基于散列码存储对象   等

Note:- Collections doesn't use hashcode value to sort the objects.

Answer 2

hashcode（）方法主要用于基于哈希的集合，如HashMap和HashSet。此方法返回的哈希码用于计算哈希索引或桶索引。

HashCode函数是我们需要比较或检查相等性的所有类或POJO或Bean的必要条件。

假设我们需要比较两个对象而不管Collection API，那么应该有一种方法来实现它。 如果HashCode不是Object Class的一部分，那么每次都很难计算哈希值并且是一个负担过重。

Answer 3

这是一个务实的设计决定，但问题基本上是正确的。纯粹分析会说它是Interface Bloat或Fat Interface的一个例子。 Java java.lang.Object拥有的方法多于所有对象严格要求的方法（甚至有意义）。它不仅仅是hashCode()。

Object唯一对所有对象都有意义的方法是getClass()，这是有争议的。

并非所有应用程序都是并发的，更不用说需要自己的监视器。因此，纯粹对象模型会将notify()，notifyAll()和3个版本的wait()删除到名为（例如）Monitored的接口，然后只允许synchronized用于实现该目标的对象。

它对于clone()个对象来说无效或不必要是非常常见的 - 尽管幸运的是这个方法protected。再一次在界面中最好说interface Cloneable<T>。

对象标识比较（这些对同一对象的引用）已作为内在运算符==提供，因此equals(Object)应该（仍然是纯粹主义者）位于ValueComparable<T>接口中对于具有该语义的对象（很多不是）。 即使这样，你也可以将hashCode()推入另一个界面（比如说）HashCodable。

finalize()也可以放在接口HasFinalize中。事实上，这可以使垃圾收集器的生活更加轻松，特别是考虑到它的使用如此罕见和专业化。

然而，在Java中有一个明确的设计决策来简化事情，设计师决定在Object中放置一些显然经常使用的方法＆＃39;或有用的而不是严格的一部分作为一个对象的最小性质＆＃39;这是（至少在Java模型中）＆＃39;是某类对象的实例（具有通用方法，接口和语义）＆＃39;。

恕我直言hashCode()可能最少不合适！ 完全没有必要在每个对象上提供一个监视器，并且让实现者头疼地支持每个对象上的方法，知道它们将被调用它们的数量非常少。不要估计可能导致的开销，因为可能有必要将互斥体这样的东西分配给整个缓存行（通常是几十个字节）到数百万个对象的每一个，并且没有任何理智的方式。用过的。

我没有建议第二次“Java被破坏”＃39;或者＆＃39;设计糟糕＆＃39;。我不是来敲Java。这是一门很棒的语言。与泛型设计一样，它总是选择简化并且愿意在性能方面做出一些妥协以简化，因此产生了一种非常强大且易于使用的语言，通过很好的实现，这些性能开销只会偶尔产生。

但重申这一点，我认为我们应该认识到这些方法不属于所有对象的内在本质。