我们通常在实体中有两个id:

仅用于持久化层(以便持久化提供程序和数据库能够找出对象之间的关系)。 是为了我们的应用程序需要(特别是equals()和hashCode())

来看看:

@Entity
public class User {

    @Id
    private int id;  // Persistence ID
    private UUID uuid; // Business ID

    // assuming all fields are subject to change
    // If we forbid users change their email or screenName we can use these
    // fields for business ID instead, but generally that's not the case
    private String screenName;
    private String email;

    // I don't put UUID generation in constructor for performance reasons. 
    // I call setUuid() when I create a new entity
    public User() {
    }

    // This method is only called when a brand new entity is added to 
    // persistence context - I add it as a safety net only but it might work 
    // for you. In some cases (say, when I add this entity to some set before 
    // calling em.persist()) setting a UUID might be too late. If I get a log 
    // output it means that I forgot to call setUuid() somewhere.
    @PrePersist
    public void ensureUuid() {
        if (getUuid() == null) {
            log.warn(format("User's UUID wasn't set on time. " 
                + "uuid: %s, name: %s, email: %s",
                getUuid(), getScreenName(), getEmail()));
            setUuid(UUID.randomUUID());
        }
    }

    // equals() and hashCode() rely on non-changing data only. Thus we 
    // guarantee that no matter how field values are changed we won't 
    // lose our entity in hash-based Sets.
    @Override
    public int hashCode() {
        return getUuid().hashCode();
    }

    // Note that I don't use direct field access inside my entity classes and
    // call getters instead. That's because Persistence provider (PP) might
    // want to load entity data lazily. And I don't use 
    //    this.getClass() == other.getClass() 
    // for the same reason. In order to support laziness PP might need to wrap
    // my entity object in some kind of proxy, i.e. subclassing it.
    @Override
    public boolean equals(final Object obj) {
        if (this == obj)
            return true;
        if (!(obj instanceof User))
            return false;
        return getUuid().equals(((User) obj).getUuid());
    }

    // Getters and setters follow
}

编辑:澄清我关于调用setUuid()方法的观点。下面是一个典型的场景:

User user = new User();
// user.setUuid(UUID.randomUUID()); // I should have called it here
user.setName("Master Yoda");
user.setEmail("yoda@jedicouncil.org");

jediSet.add(user); // here's bug - we forgot to set UUID and 
                   //we won't find Yoda in Jedi set

em.persist(user); // ensureUuid() was called and printed the log for me.

jediCouncilSet.add(user); // Ok, we got a UUID now

当我运行测试并看到日志输出时，我解决了这个问题:

User user = new User();
user.setUuid(UUID.randomUUID());

或者，也可以提供一个单独的构造函数:

@Entity
public class User {

    @Id
    private int id;  // Persistence ID
    private UUID uuid; // Business ID

    ... // fields

    // Constructor for Persistence provider to use
    public User() {
    }

    // Constructor I use when creating new entities
    public User(UUID uuid) {
        setUuid(uuid);
    }

    ... // rest of the entity.
}

我的例子是这样的:

User user = new User(UUID.randomUUID());
...
jediSet.add(user); // no bug this time

em.persist(user); // and no log output

我使用默认构造函数和setter，但您可能会发现双构造函数方法更适合您。

在我看来，你有3个实现equals/hashCode的选项

使用应用程序生成的标识，即UUID 基于业务键实现它 基于主键实现它

使用应用程序生成的标识是最简单的方法，但也有一些缺点

当使用它作为PK时，连接速度较慢，因为128位比32或64位大 “调试更困难”，因为用自己的眼睛检查某些数据是否正确是相当困难的

如果你能克服这些缺点，那就使用这种方法。

为了克服连接问题，可以使用UUID作为自然键，使用序列值作为主键，但是在具有嵌入id的组合子实体中，仍然可能遇到equals/hashCode实现问题，因为您希望基于主键进行连接。在子实体id中使用自然键，而在引用父实体时使用主键是一种很好的折衷方法。

@Entity class Parent {
  @Id @GeneratedValue Long id;
  @NaturalId UUID uuid;
  @OneToMany(mappedBy = "parent") Set<Child> children;
  // equals/hashCode based on uuid
}

@Entity class Child {
  @EmbeddedId ChildId id;
  @ManyToOne Parent parent;

  @Embeddable class ChildId {
    UUID parentUuid;
    UUID childUuid;
    // equals/hashCode based on parentUuid and childUuid
  }
  // equals/hashCode based on id
}

在我看来，这是最干净的方法，因为它将避免所有的缺点，同时为您提供一个值(UUID)，您可以与外部系统共享，而不暴露系统内部。

基于业务键来实现它(如果你能从用户那里得到的话)是个好主意，但也有一些缺点

大多数情况下，这个业务键是用户提供的某种代码，很少是多个属性的组合。

连接速度较慢，因为基于可变长度文本的连接速度很慢。如果键超过一定长度，一些DBMS甚至可能在创建索引时遇到问题。 根据我的经验，业务键往往会发生变化，这就需要对引用它的对象进行级联更新。如果外部系统引用它，这是不可能的

在我看来，你不应该专门实现或使用业务键。这是一个很好的附加功能，用户可以通过业务键快速搜索，但系统不应该依赖它来运行。

基于主键实现它有它的问题，但也许这不是什么大问题

如果需要向外部系统公开id，请使用我建议的UUID方法。如果您不这样做，您仍然可以使用UUID方法，但不必这样做。 在equals/hashCode中使用DBMS生成的id的问题源于这样一个事实，即对象可能在分配id之前已被添加到基于哈希的集合中。

解决这个问题的明显方法是在分配id之前不将对象添加到基于哈希的集合中。我知道这并不总是可行的，因为您可能需要在分配id之前进行重复数据删除。要仍然能够使用基于散列的集合，您只需在分配id后重新构建集合。

你可以这样做:

@Entity class Parent {
  @Id @GeneratedValue Long id;
  @OneToMany(mappedBy = "parent") Set<Child> children;
  // equals/hashCode based on id
}

@Entity class Child {
  @EmbeddedId ChildId id;
  @ManyToOne Parent parent;

  @PrePersist void postPersist() {
    parent.children.remove(this);
  }
  @PostPersist void postPersist() {
    parent.children.add(this);
  }

  @Embeddable class ChildId {
    Long parentId;
    @GeneratedValue Long childId;
    // equals/hashCode based on parentId and childId
  }
  // equals/hashCode based on id
}

我自己还没有测试过确切的方法，所以我不确定在持久化事件之前和之后更改集合是如何工作的，但这个想法是:

临时从基于散列的集合中移除对象 坚持它 将对象重新添加到基于散列的集合中

解决这个问题的另一种方法是在更新/持久化之后重新构建所有基于哈希的模型。

最后，决定权在你。我个人大部分时间使用基于序列的方法，只有在需要向外部系统公开标识符时才使用UUID方法。

Jakarta Persistence 3.0，第4.12节写道:

相同抽象模式类型的两个实体当且仅当它们具有相同的主键值时相等。

我看不出为什么Java代码的行为应该有所不同。

If the entity class is in a so called "transient" state, i.e. it's not yet persisted and it has no identifier, then the hashCode/equals methods can not return a value, they ought to blow up, ideally implicitly with a NullPointerException when the method attempts to traverse the ID. Either way, this will effectively stop application code from putting a non-managed entity into a hash-based data structure. In fact, why not go one step further and blow up if the class and identifier are equal, but other important attributes such as the version are unequal (IllegalStateException)! Fail-fast in a deterministic way is always the preferred option.

警告:也要记录下爆发行为。文档本身很重要，但它也希望能够阻止初级开发人员在未来对您的代码做一些愚蠢的事情(他们倾向于压制发生NullPointerException的地方，他们最不关心的是副作用，lol)。

哦，总是使用getClass()而不是instanceof。equals方法要求对称性。如果b等于a，那么a必须等于b。对于子类，instanceof打破了这种关系(a不是b的实例)。

尽管我个人总是使用getClass()，即使在实现非实体类(类型是状态，所以子类添加状态，即使子类是空的或只包含行为)，只有当类是final时，instanceof才会很好。但实体类必须不是最终的(§2.1)，所以我们真的别无选择。

Some folks may not like getClass(), because of the persistence provider's proxy wrapping the object. This might have been a problem in the past, but it really shouldn't be. A provider not returning different proxy classes for different entities, well, I'd say that's not a very smart provider lol. Generally, we shouldn't solve a problem until there is a problem. And, it seems like Hibernate's own documentation doesn't even see it worthwhile mentioning. In fact, they elegantly use getClass() in their own examples (see this).

Lastly, if one has an entity subclass that is an entity, and the inheritance mapping strategy used is not the default ("single table"), but configured to be a "joined subtype", then the primary key in that subclass table will be the same as the superclass table. If the mapping strategy is "table per concrete class", then the primary key may be the same as in the superclass. An entity subclass is very likely to be adding state and therefore just as likely to be logically a different thing. But an equals implementation using instanceof can not necessarily and secondarily rely on the ID only, as we saw may be the same for different entities.

在我看来，instanceof在非final Java类中根本没有位置。对于持久实体来说尤其如此。

我个人已经在不同的项目中使用了这三种策略。我必须说，选项1在我看来是现实应用中最可行的。以我的经验来看，打破hashCode()/equals()一致性会导致许多疯狂的错误，因为你每次都会遇到这样的情况:在一个实体被添加到一个集合后，相等的结果发生了变化。

但也有更多的选择(也有它们的优点和缺点):

a) hashCode/equals基于一组不可变的、非空的、构造函数赋值的字段

(+)三个标准都有保证

(-)字段值必须可用以创建新实例

(-)如果你必须改变其中一个，处理起来会很复杂

b) hashCode/equals基于应用程序(在构造函数中)分配的主键，而不是JPA

(+)三个标准都有保证

(-)您不能利用简单可靠的ID生成策略，如DB序列

(-)如果在分布式环境(客户端/服务器)或应用服务器集群中创建新实体会很复杂

c) hashCode/equals基于实体的构造函数分配的UUID

(+)三个标准都有保证

(-)生成UUID的开销

(-)可能会有使用两次相同UUID的风险，这取决于所使用的算法(可能由DB上的唯一索引检测到)

实际上，似乎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的建议。

业务密钥方法不适合我们。我们使用DB生成的ID、临时临时tempId和重写equal()/hashcode()来解决这个困境。所有实体都是Entity的后代。优点:

DB中没有额外字段 在后代实体中没有额外的编码，一种方法适用于所有的实体 没有性能问题(如UUID)， DB Id生成 使用hashmap没有问题(不需要记住equal & etc的使用)。 新实体的Hashcode即使在持久化后也不会及时更改

缺点:

序列化和反序列化非持久化实体可能会出现问题 从DB重新加载后，保存的实体的Hashcode可能会改变 非持久化对象被认为总是不同的(也许这是对的?) 还有什么?

看看我们的代码:

@MappedSuperclass
abstract public class Entity implements Serializable {

    @Id
    @GeneratedValue
    @Column(nullable = false, updatable = false)
    protected Long id;

    @Transient
    private Long tempId;

    public void setId(Long id) {
        this.id = id;
    }

    public Long getId() {
        return id;
    }

    private void setTempId(Long tempId) {
        this.tempId = tempId;
    }

    // Fix Id on first call from equal() or hashCode()
    private Long getTempId() {
        if (tempId == null)
            // if we have id already, use it, else use 0
            setTempId(getId() == null ? 0 : getId());
        return tempId;
    }

    @Override
    public boolean equals(Object obj) {
        if (super.equals(obj))
            return true;
        // take proxied object into account
        if (obj == null || !Hibernate.getClass(obj).equals(this.getClass()))
            return false;
        Entity o = (Entity) obj;
        return getTempId() != 0 && o.getTempId() != 0 && getTempId().equals(o.getTempId());
    }

    // hash doesn't change in time
    @Override
    public int hashCode() {
        return getTempId() == 0 ? super.hashCode() : getTempId().hashCode();
    }
}