Java 可扩展类的哈希代码（未来证明）

因为我在数学方面没有什么好的技能，我问你是否有任何算法我应该用于一个将来可能会改变的类

考虑以下场景：

类“角色”具有以下字段：

private boolean admin;
private boolean printer;

几周后，我决定添加一个角色“来宾”：

几周后，我决定删除“打印机”这个角色

因为我将在数据库中持久化hashcode，所以我必须100%确保该类的所有版本都生成唯一的hashcode

也许这不是问题，我一直使用EclispeIDE源代码生成器中提供的源代码

您能告诉我使用EclipseIDE（Indigo）Java version>=6方法是否安全，或者就这个主题给我一些其他建议吗。我相信这是一件很平常的事

提前谢谢

因为我将在数据库中持久化哈希代码

不要那样做。

hashCode

的结果不能持久化。特别是，从文档中：

从应用程序的一次执行到同一应用程序的另一次执行，该整数不必保持一致

下一步：

我必须100%确定这个类的所有版本都会生成唯一的哈希代码

哈希代码也不是唯一的。。。他们通常不会。好的，你的案例中只有5位数据，但一般情况下不是这样的

---

听起来您对

Object.hashCode（）

的需求与普通的需求不同，因此您不应该期望任何自动生成的实现了解您的特殊需求。我建议您确切地说明您的需求是什么，然后我们可以确定该怎么做…

为了了解32位哈希代码和UUID之间的区别，以及每个的冲突可能性，这是您需要生成多少ID才能获得其中两个具有相同值（冲突）的50%几率：

32位哈希代码-77000

128位UUID-22000000000000000000

哈希代码不保证唯一性，在正常使用中会发生冲突。UUID承诺了实际的唯一性，在实践中碰撞不太可能发生

---

请参阅和

听起来像GUID/UUID或其他唯一标识符生成比哈希代码更适合您的需要。GUID通常不保证唯一。碰撞的可能性很低，但不是零。但它们实际上是独一无二的。在接下来的100年中，每秒生成10亿个UUID后，仅创建一个副本的概率约为50%。你的数据中心被陨石击中的几率要高得多。你的散列码是用来描述数据格式的，比如a，对吗？您对向前或向后兼容性有任何要求吗？你用什么来保存东西？正如其他评论所指出的，没有任何散列在数学上会给你“100%的肯定”，但是碰撞的几率会变得非常小。从理论上说，绝对肯定的是，你必须维护一个分配的数字列表，并检查是否不再使用一个。我只知道一个哈希代码，它的性质不适合这个问题。更改*UID的hashcode会使这个问题不那么令人困惑。我相信这个“hashcode”只是用来描述内部数据布局的。可能我们这里谈论的不是Object.hashCode（），而是的

serialVersionUID

或类似的东西。将其存储为格式版本id非常有意义。@MvG:我怀疑没有，因为OP谈到了“EclipseIDE源代码生成器中提供的一个”。如果OP真的意味着serialVersionUID，我会很惊讶他没有提到它…谢谢你，你能看一下吗？我想你明白我想要实现什么。

private boolean admin;
private boolean printer;
private boolean guest;

private boolean admin;
private boolean guest;