Java 为什么对象#hashCode（）返回int而不是long

为什么不：

public native long hashCode();

而不是：

public native int hashCode();

---

为了获得更高的唯一哈希代码的可能性？

无论如何，哈希代码值将用于确定表中相对较小的行数

例如，在

HashMap

中，默认表包含256行，只有16行（Sun JDK 1.6.0_17）。这意味着行号的确定方式如下：

int rowNumber = obj.hashCode() % rowsCount;

因此，实际分布是从0到

rowsCount

UPD：我记得

ConcurrentHashMap

的实现。简而言之，

ConcurrentHashMap

包含许多相对较小的表。首先使用

hashCode

函数确定表号，然后使用相同的函数确定所选表中的行

这种方法消除了数组大小的限制（甚至允许构建分布式哈希表）

---

因此，我倾向于得出结论，

hashCode

返回

int

，因为它涵盖了绝大多数用例。

我假设这是计算成本与哈希范围的平衡。hash码经常被引用，每次需要散列时推高大约两倍的数据将是昂贵的，特别是如果你考虑更常见的用例-

例如，如果您创建一个包含10、100或1000个值的小散列，那么您将看到的散列冲突数量的差异将是极其微不足道的。对于较大的散列。。。好吧，想想10**32值需要多大的散列才能开始频繁发生冲突，考虑到您需要的内存量，在JVM中是否可以这样做。

因为是

整数。最大值

---

由于

hashCode（）

的主要用途是确定在

HashMap

/

Hashtable

的备份数组中插入对象的插槽，因此hashCode>

整数.MAX\u值将无法存储在数组中。
这不太准确，由于表的大小可能不同于默认值，无论是随着表的增长还是
initialCapacity
的不同参数被传递给
HashMap
构造函数。还有什么不准确的地方吗？：）没有人认为表的默认大小可以更大。您需要删除最大的位（现在行数可以是负数）
（obj.hashCode&0x7fffffff）%rowCount
。由于mod操作类似于30个cpu时钟（按位和为1），因此条目数保持为2的幂次方，并且操作仅为
（obj.hashCode&（array.length-1））
有效点。我不确定它是否在规范中有文档记录，但Sun JDK的
HashMap
表不能大于
1-1：备份数组几乎总是小得多，因此无论如何都需要缩小。从64位向下扩展并不是一个真正的问题。此外，hashCode（）允许返回负值……为什么不在数组中也使用long？@Nikolas我们不能使用long作为数组索引，试想一下，对于第1个索引，您可以存储多少子索引，1.1、1.2、1.3、1.1.1.1等等；这样做会产生比您需要的解决方案更多的开销！对于64位JDK来说，这可能更有意义，但是即使在今天，一个长的哈希代码也不会有什么不同。Hashcode不必是唯一的，如果您的条目明显少于40亿条，则32位int也可以。@PeterLawrey我原则上同意您的观点，但它表明，由于这个问题的性质，即使您的哈希表只有77163条条目，也有50%的几率发生冲突@KedarMhaswade具有78K条目的哈希映射可能具有128k的容量，因此仅使用17位搅动哈希代码。