这里有一些关于JPA实体的讨论，以及应该为JPA实体类使用哪些hashCode()/equals()实现。它们中的大多数(如果不是全部)依赖于Hibernate，但是我想中立地讨论它们的jpa实现(顺便说一下，我使用的是EclipseLink)。
所有可能的实现都有其自身的优点和缺点:
hashCode()/equals()契约一致性(不可变性)用于列表/集操作
是否可以检测到相同的对象(例如来自不同会话的对象，来自惰性加载数据结构的动态代理)
实体在分离(或非持久化)状态下是否正确运行
在我看来，有三种选择:
Do not override them; rely on Object.equals() and Object.hashCode()
hashCode()/equals() work
cannot identify identical objects, problems with dynamic proxies
no problems with detached entities
Override them, based on the primary key
hashCode()/equals() are broken
correct identity (for all managed entities)
problems with detached entities
Override them, based on the Business-Id (non-primary key fields; what about foreign keys?)
hashCode()/equals() are broken
correct identity (for all managed entities)
no problems with detached entities
我的问题是:
我是否错过了一个选择和/或赞成/反对的观点?
你选择了什么，为什么?
更新1:
通过“hashCode()/equals()是坏的”，我的意思是连续的hashCode()调用可能返回不同的值，这(当正确实现时)在对象API文档的意义上不是坏的，但是当试图从Map、Set或其他基于哈希的集合中检索更改的实体时，会导致问题。因此，JPA实现(至少是EclipseLink)在某些情况下不能正确工作。
更新2:
谢谢你的回答——大部分问题都很有质量。
不幸的是，我仍然不确定哪种方法最适合实际应用程序，或者如何确定最适合我的应用程序的方法。所以，我将保持这个问题的开放性，希望有更多的讨论和/或意见。
实际上，似乎Option 2(主键)是最常用的。
自然的和不可变的业务密钥是很少的事情，创建和支持合成密钥对于解决情况来说太沉重了，这可能从来没有发生过。
看一下spring-data-jpa AbstractPersistable实现(唯一需要注意的是:对于Hibernate实现使用Hibernate. getclass)。
public boolean equals(Object obj) {
if (null == obj) {
return false;
}
if (this == obj) {
return true;
}
if (!getClass().equals(ClassUtils.getUserClass(obj))) {
return false;
}
AbstractPersistable<?> that = (AbstractPersistable<?>) obj;
return null == this.getId() ? false : this.getId().equals(that.getId());
}
@Override
public int hashCode() {
int hashCode = 17;
hashCode += null == getId() ? 0 : getId().hashCode() * 31;
return hashCode;
}
注意在HashSet/HashMap中操作新对象。
相反，选项1(保留对象实现)在合并后被破坏，这是非常常见的情况。
如果你没有业务键，并且需要在哈希结构中操作新实体，则将hashCode重写为常量，如下所示Vlad Mihalcea的建议。
我总是重写equals/hashcode，并基于业务id实现它。对我来说这是最合理的解决办法。请看下面的链接。
总而言之，这里列出了处理equals/hashCode的不同方法中哪些是有效的，哪些是无效的:
编辑:
为了解释为什么这对我有用:
I don't usually use hashed-based collection (HashMap/HashSet) in my JPA application. If I must, I prefer to create UniqueList solution.
I think changing business id on runtime is not a best practice for any database application. On rare cases where there is no other solution, I'd do special treatment like remove the element and put it back to the hashed-based collection.
For my model, I set the business id on constructor and doesn't provide setters for it. I let JPA implementation to change the field instead of the property.
UUID solution seems to be overkill. Why UUID if you have natural business id? I would after all set the uniqueness of the business id in the database. Why having THREE indexes for each table in the database then?
我个人已经在不同的项目中使用了这三种策略。我必须说，选项1在我看来是现实应用中最可行的。以我的经验来看，打破hashCode()/equals()一致性会导致许多疯狂的错误，因为你每次都会遇到这样的情况:在一个实体被添加到一个集合后，相等的结果发生了变化。
但也有更多的选择(也有它们的优点和缺点):
a) hashCode/equals基于一组不可变的、非空的、构造函数赋值的字段
(+)三个标准都有保证
(-)字段值必须可用以创建新实例
(-)如果你必须改变其中一个，处理起来会很复杂
b) hashCode/equals基于应用程序(在构造函数中)分配的主键，而不是JPA
(+)三个标准都有保证
(-)您不能利用简单可靠的ID生成策略，如DB序列
(-)如果在分布式环境(客户端/服务器)或应用服务器集群中创建新实体会很复杂
c) hashCode/equals基于实体的构造函数分配的UUID
(+)三个标准都有保证
(-)生成UUID的开销
(-)可能会有使用两次相同UUID的风险，这取决于所使用的算法(可能由DB上的唯一索引检测到)
