默认的hashCode可以作为熵源吗？

Question

一个非常奇怪的问题：如果我只需要一个对象的一个​​随机数，我们可以使用hashCode作为熵源而不是创建新的Java.util.Random对象，然后调用nextInr() ？

Answer 1

hashCode()的默认实现是返回由JVM提供的对象的标识哈希值，可能不是那么随机。如果hashCode()被覆盖（通常是这种情况），则返回值甚至更不随机，并且任何返回hashCode()的随机数的实现（即使它对于每个调用都是相同的）实例）很可能会违反为equals()和hashCode();

定义的合同

来自JavaDoc：

  

请注意，通常需要在重写此方法时覆盖hashCode方法，以便维护hashCode方法的常规协定，该方法声明相等的对象必须具有相同的哈希代码。

所以我建议继续使用java.util.Random（您可以使用单个实例）或其他不同的内容，但不 hashCode()。

Answer 2

理想哈希码应该

• 对于相等的实例是相等的
对于不平等的实例，
• 不同（在尽可能多的情况下）

请注意，第二个条件与随机性相矛盾。让我们想象一下 我们有10个物体。最佳hashCode实现返回

  0, 1, 2, 3, 4, 5, 6, 7, 8, 9

表示实例，因此hashCode没有冲突。但是，随机 数字将是这样的：

  5, 3, 7, 0, 5, 4, 2, 8, 1, 7

注意碰撞（两个5和两个7＆＃39; s）。所以应该是一个好的hashCode 不可思议地偏见（为了防止/最小化冲突）以及不应该被用作作为与之相关的随机数的原因实例。如果你覆盖 hashCode使得它将关联随机值作为哈希码返回，你实际上会通过添加潜在的冲突来破坏 hashCode。

因此，对于哈希码使用hashCode，对随机数使用Java.util.Random。

Answer 3

defaultTables通常会给你一个非常糟糕的随机数（如果你通过通常的统计测试）。

如果它仍然可以，它实际上取决于你的应用程序。