JPA规范说明了关于persist()的以下内容。

如果X是一个分离对象，则在持久化时可能会抛出EntityExistsException 操作被调用，或者EntityExistsException或另一个PersistenceException可能在刷新或提交时抛出。

因此，当对象不应该是分离对象时，使用persist()是合适的。您可能更喜欢让代码抛出PersistenceException，以便快速失败。

尽管规范不清楚，persist()可能会为对象设置@GeneratedValue @Id。但是merge()必须有一个已经生成的@Id对象。

JPA is indisputably a great simplification in the domain of enterprise applications built on the Java platform. As a developer who had to cope up with the intricacies of the old entity beans in J2EE I see the inclusion of JPA among the Java EE specifications as a big leap forward. However, while delving deeper into the JPA details I find things that are not so easy. In this article I deal with comparison of the EntityManager’s merge and persist methods whose overlapping behavior may cause confusion not only to a newbie. Furthermore I propose a generalization that sees both methods as special cases of a more general method combine.

持久化实体

与merge方法相比，persist方法非常简单直观。使用persist方法最常见的场景可以总结如下:

一个新创建的实体类实例被传递给持久化方法。该方法返回后，将管理实体并计划将其插入到数据库中。它可能发生在事务提交时或提交之前，也可能发生在调用flush方法时。如果实体通过标记为PERSIST级联策略的关系引用另一个实体，则此过程也应用于它。”

规范中有更多的细节，然而，记住它们并不重要，因为这些细节只涵盖了或多或少的奇异情况。

合并实体

In comparison to persist, the description of the merge's behavior is not so simple. There is no main scenario, as it is in the case of persist, and a programmer must remember all scenarios in order to write a correct code. It seems to me that the JPA designers wanted to have some method whose primary concern would be handling detached entities (as the opposite to the persist method that deals with newly created entities primarily.) The merge method's major task is to transfer the state from an unmanaged entity (passed as the argument) to its managed counterpart within the persistence context. This task, however, divides further into several scenarios which worsen the intelligibility of the overall method's behavior.

我没有从JPA规范中重复段落，而是准备了一个流程图，概要地描述了合并方法的行为:

什么时候使用持久化，什么时候使用归并?

坚持

您希望该方法总是创建一个新实体，而从不更新实体。否则，该方法将因违反主键惟一性而引发异常。 批处理流程，以有状态的方式处理实体(参见网关模式)。 性能优化

走

您希望该方法插入或更新数据库中的实体。 您希望以无状态的方式处理实体(服务中的数据传输对象) 您希望插入一个新实体，该实体可能对另一个实体有引用，但可能尚未创建(关系必须标记为MERGE)。例如，插入带有新相册或已有相册引用的新照片。

关于merge的更多细节将帮助你使用merge over persist:

Returning a managed instance other than the original entity is a critical part of the merge process. If an entity instance with the same identifier already exists in the persistence context, the provider will overwrite its state with the state of the entity that is being merged, but the managed version that existed already must be returned to the client so that it can be used. If the provider did not update the Employee instance in the persistence context, any references to that instance will become inconsistent with the new state being merged in. When merge() is invoked on a new entity, it behaves similarly to the persist() operation. It adds the entity to the persistence context, but instead of adding the original entity instance, it creates a new copy and manages that instance instead. The copy that is created by the merge() operation is persisted as if the persist() method were invoked on it. In the presence of relationships, the merge() operation will attempt to update the managed entity to point to managed versions of the entities referenced by the detached entity. If the entity has a relationship to an object that has no persistent identity, the outcome of the merge operation is undefined. Some providers might allow the managed copy to point to the non-persistent object, whereas others might throw an exception immediately. The merge() operation can be optionally cascaded in these cases to prevent an exception from occurring. We will cover cascading of the merge() operation later in this section. If an entity being merged points to a removed entity, an IllegalArgumentException exception will be thrown. Lazy-loading relationships are a special case in the merge operation. If a lazy-loading relationship was not triggered on an entity before it became detached, that relationship will be ignored when the entity is merged. If the relationship was triggered while managed and then set to null while the entity was detached, the managed version of the entity will likewise have the relationship cleared during the merge."

以上所有信息都摘自Mike Keith和Merrick Schnicariol的“Pro JPA 2掌握Java™Persistence API”。第六章。分段分离与合并。这本书实际上是作者专门介绍JPA的第二本书。这本新书比前一本有许多新信息。我非常推荐那些将认真参与JPA的人阅读这本书。我很抱歉匿名发布了我的第一个答案。

我注意到，当我使用em.merge时，每个INSERT都有一个SELECT语句，即使JPA没有为我生成字段——主键字段是我自己设置的UUID。我切换到em.persist(myEntityObject)，然后只得到INSERT语句。

场景X:

表:spititter(1)，表:Spittles(许多)(Spittles是与FK:spitter_id关系的所有者)

这个场景的结果是节省:喷壶和两个喷壶就像被同一个喷壶拥有一样。

        Spitter spitter=new Spitter();  
    Spittle spittle3=new Spittle();     
    spitter.setUsername("George");
    spitter.setPassword("test1234");
    spittle3.setSpittle("I love java 2");       
    spittle3.setSpitter(spitter);               
    dao.addSpittle(spittle3); // <--persist     
    Spittle spittle=new Spittle();
    spittle.setSpittle("I love java");
    spittle.setSpitter(spitter);        
    dao.saveSpittle(spittle); //<-- merge!!

场景Y:

这将拯救喷壶，将拯救2喷壶，但他们不会引用同一喷壶!

        Spitter spitter=new Spitter();  
    Spittle spittle3=new Spittle();     
    spitter.setUsername("George");
    spitter.setPassword("test1234");
    spittle3.setSpittle("I love java 2");       
    spittle3.setSpitter(spitter);               
    dao.save(spittle3); // <--merge!!       
    Spittle spittle=new Spittle();
    spittle.setSpittle("I love java");
    spittle.setSpitter(spitter);        
    dao.saveSpittle(spittle); //<-- merge!!

如果您正在使用分配的生成器，使用merge而不是持久化可能会导致冗余SQL语句，从而影响性能。

另外，对托管实体调用merge也是一个错误，因为托管实体是由Hibernate自动管理的，并且它们的状态在刷新持久性上下文时通过脏检查机制与数据库记录同步。

要理解这一切是如何工作的，首先应该知道Hibernate将开发人员的思维模式从SQL语句转换为实体状态转换。

一旦一个实体被Hibernate主动管理，所有的更改都将自动传播到数据库中。

Hibernate监视当前附加的实体。但是要使实体受到管理，它必须处于正确的实体状态。

为了更好地理解JPA状态转换，您可以将下面的图可视化:

或者如果你使用Hibernate特定的API:

如上图所示，一个实体可以处于以下四种状态之一:

新(瞬态)

如果一个新创建的对象从未与Hibernate会话(也就是持久化上下文)关联过，也没有映射到任何数据库表行，则认为该对象处于New (Transient)状态。

要成为持久化，我们需要显式地调用EntityManager#persist方法，或者使用传递持久化机制。

Persistent (Managed) A persistent entity has been associated with a database table row and it’s being managed by the currently running Persistence Context. Any change made to such an entity is going to be detected and propagated to the database (during the Session flush-time). With Hibernate, we no longer have to execute INSERT/UPDATE/DELETE statements. Hibernate employs a transactional write-behind working style and changes are synchronized at the very last responsible moment, during the current Session flush-time. Detached

一旦当前运行的持久性上下文被关闭，所有以前管理的实体将被分离。连续的更改将不再被跟踪，也不会发生自动的数据库同步。

要将分离实体关联到活动Hibernate会话，您可以选择以下选项之一:

Reattaching Hibernate (but not JPA 2.1) supports reattaching through the Session#update method. A Hibernate Session can only associate one Entity object for a given database row. This is because the Persistence Context acts as an in-memory cache (first level cache) and only one value (entity) is associated with a given key (entity type and database identifier). An entity can be reattached only if there is no other JVM object (matching the same database row) already associated with the current Hibernate Session. Merging The merge is going to copy the detached entity state (source) to a managed entity instance (destination). If the merging entity has no equivalent in the current Session, one will be fetched from the database. The detached object instance will continue to remain detached even after the merge operation. Remove Although JPA demands that managed entities only are allowed to be removed, Hibernate can also delete detached entities (but only through a Session#delete method call). A removed entity is only scheduled for deletion and the actual database DELETE statement will be executed during Session flush-time.