关于 Object.hashcode() 和冲突
About Object.hashcode() and collisions
我正在阅读 JavaDoc 的 Object.hashCode 方法，它说
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer [...])
但是无论它的实现是什么，hashCode 方法总是 returns 一个（假设为正）整数，所以给定 Integer.MAX+1 个不同的对象，其中两个将具有相同的哈希码。
为什么此处的 JavaDoc "denying" 冲突？考虑到使用了内部地址并且“拜托，你永远不会在内存中同时拥有 Integer.MAX+1 个对象，这是一个实际的结论吗，所以我们可以说它实际上总是唯一的"?
编辑
这个 bug entry (thank you ) 给出了我的意思的确切概念（这似乎是一个超过 10 年的讨论）：
appears that many, perhaps majority, of programmers take this to mean that the default implementation, and hence System.identityHashCode, will produce unique hashcodes.
The qualification "As much as is reasonably practical," is, in practice, insufficient to make clear that hashcodes are not, in practice, distinct.
该文档确实具有误导性，很久以前就有一个 bug 打开说该文档具有误导性，尤其是该实现是 JVM 依赖的，并且在实践中尤其是对于大量堆将对象标识映射到 32 位整数时很可能发生冲突的大小
这里有一个关于哈希码冲突的有趣讨论：
http://eclipsesource.com/blogs/2012/09/04/the-3-things-you-should-know-about-hashcode/
特别强调，由于 birthday paradox。
，您的实际结论 "you're never going to have Integer.MAX+1 objects in memory at once, so we can say it's practically always unique" 远非准确
link 的结论是，假设 hashCode 随机分布，我们只需要 77,163 个对象就会有 50/50 的 hashCode 冲突机会。
当您仔细阅读本文时，您会注意到这仅意味着对象应尽量避免冲突 ('as much as reasonably practical')，而且不保证不相等的对象具有不同的哈希码。
所以promise不是很强，但是还是很有用的。例如，在进行全面检查之前使用哈希码作为相等性的快速指示。
例如ConcurrentHashMap，它将使用（执行的函数）哈希码将位置分配给地图中的对象。实际上，hashcode 用于查找对象的大致位置，而 equals 用于查找精确位置。
如果对象不尝试尽可能多地传播其哈希码，则哈希图无法使用此优化。
我正在阅读 JavaDoc 的 Object.hashCode 方法，它说
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer [...])
但是无论它的实现是什么，hashCode 方法总是 returns 一个（假设为正）整数，所以给定 Integer.MAX+1 个不同的对象，其中两个将具有相同的哈希码。
为什么此处的 JavaDoc "denying" 冲突？考虑到使用了内部地址并且“拜托，你永远不会在内存中同时拥有 Integer.MAX+1 个对象，这是一个实际的结论吗，所以我们可以说它实际上总是唯一的"?
编辑
这个 bug entry (thank you
appears that many, perhaps majority, of programmers take this to mean that the default implementation, and hence System.identityHashCode, will produce unique hashcodes.
The qualification "As much as is reasonably practical," is, in practice, insufficient to make clear that hashcodes are not, in practice, distinct.
该文档确实具有误导性，很久以前就有一个 bug 打开说该文档具有误导性，尤其是该实现是 JVM 依赖的，并且在实践中尤其是对于大量堆将对象标识映射到 32 位整数时很可能发生冲突的大小
这里有一个关于哈希码冲突的有趣讨论：
http://eclipsesource.com/blogs/2012/09/04/the-3-things-you-should-know-about-hashcode/
特别强调，由于 birthday paradox。
，您的实际结论 "you're never going to have Integer.MAX+1 objects in memory at once, so we can say it's practically always unique" 远非准确link 的结论是，假设 hashCode 随机分布，我们只需要 77,163 个对象就会有 50/50 的 hashCode 冲突机会。
当您仔细阅读本文时，您会注意到这仅意味着对象应尽量避免冲突 ('as much as reasonably practical')，而且不保证不相等的对象具有不同的哈希码。
所以promise不是很强，但是还是很有用的。例如，在进行全面检查之前使用哈希码作为相等性的快速指示。
例如ConcurrentHashMap，它将使用（执行的函数）哈希码将位置分配给地图中的对象。实际上，hashcode 用于查找对象的大致位置，而 equals 用于查找精确位置。
如果对象不尝试尽可能多地传播其哈希码，则哈希图无法使用此优化。