merge和persist之间还有一些区别(我将再次列举已经在这里发布的区别):

D1。Merge不会使传递的实体受管理，而是返回另一个受管理的实例。在另一边持久化将使传递的实体被管理:

//MERGE: passedEntity remains unmanaged, but newEntity will be managed
Entity newEntity = em.merge(passedEntity);

//PERSIST: passedEntity will be managed after this
em.persist(passedEntity);

D2。如果你删除了一个实体，然后决定持久化该实体，你只能使用persist()来做，因为merge会抛出一个IllegalArgumentException。

D3。如果您决定手动处理您的id(例如通过使用uuid)，则合并 operation将触发后续的SELECT查询，以查找具有该ID的存在实体，而persist可能不需要这些查询。

D4。有些情况下，您只是不相信调用您的代码的代码，为了确保没有数据被更新，而是被插入，您必须使用持久化。

这两种方法都会将实体添加到PersistenceContext中，区别在于之后如何处理实体。

Persist获取一个实体实例，将其添加到上下文中，并使该实例被管理(即将跟踪实体的未来更新)。

Merge返回与状态合并的托管实例。它确实返回存在于PersistenceContext中的内容或创建实体的新实例。在任何情况下，它都会从提供的实体复制状态，并返回一个托管副本。传入的实例不会被管理(你所做的任何更改都不会成为事务的一部分——除非你再次调用merge)。不过您可以使用返回的实例(托管实例)。

也许一个代码示例会有所帮助。

MyEntity e = new MyEntity();

// scenario 1
// tran starts
em.persist(e); 
e.setSomeField(someValue); 
// tran ends, and the row for someField is updated in the database

// scenario 2
// tran starts
e = new MyEntity();
em.merge(e);
e.setSomeField(anotherValue); 
// tran ends but the row for someField is not updated in the database
// (you made the changes *after* merging)
      
// scenario 3
// tran starts
e = new MyEntity();
MyEntity e2 = em.merge(e);
e2.setSomeField(anotherValue); 
// tran ends and the row for someField is updated
// (the changes were made to e2, not e)

场景1和3大致相同，但在某些情况下，您可能希望使用场景2。

我发现Hibernate文档中的解释很有启发性，因为它们包含了一个用例:

The usage and semantics of merge() seems to be confusing for new users. Firstly, as long as you are not trying to use object state loaded in one entity manager in another new entity manager, you should not need to use merge() at all. Some whole applications will never use this method. Usually merge() is used in the following scenario: The application loads an object in the first entity manager the object is passed up to the presentation layer some modifications are made to the object the object is passed back down to the business logic layer the application persists these modifications by calling merge() in a second entity manager Here is the exact semantic of merge(): if there is a managed instance with the same identifier currently associated with the persistence context, copy the state of the given object onto the managed instance if there is no managed instance currently associated with the persistence context, try to load it from the database, or create a new managed instance the managed instance is returned the given instance does not become associated with the persistence context, it remains detached and is usually discarded

来自:http://docs.jboss.org/hibernate/entitymanager/3.6/reference/en/html/objectstate.html

如果您正在使用分配的生成器，使用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.

另一个观察:

merge()只关心自动生成的id(在IDENTITY和SEQUENCE上测试)，当表中已经存在这样一个id的记录时。在这种情况下，merge()将尝试更新记录。 然而，如果一个id不存在或者不匹配任何现有的记录，merge()将完全忽略它，并要求db分配一个新的。这有时是许多bug的来源。不要使用merge()强制新记录的id。

另一方面，Persist()甚至不允许将id传递给它。它会立即失效。在我的例子中，它是:

原因:org.hibernate.PersistentObjectException:分离实体 传递到持久化

Hibernate-jpa javadoc有一个提示:

抛出:javax.persistence.EntityExistsException——如果实体 已经存在。(如果实体已经存在，则 当持久化操作时，可能会抛出EntityExistsException 或者EntityExistsException或另一个PersistenceException 可能在同花顺或提交时抛出。)

我在我的实体上得到了lazyLoading异常，因为我试图访问一个会话中的惰性加载集合。

我要做的是在一个单独的请求中，从会话检索实体，然后尝试访问我的jsp页面中的一个集合，这是有问题的。

为了缓解这个问题，我在控制器中更新了相同的实体，并将其传递给我的jsp，尽管我想象当我在会话中重新保存时，它也可以通过SessionScope访问，而不会抛出一个LazyLoadingException，这是示例2的修改:

以下是我行之有效的方法:

// scenario 2 MY WAY
// tran starts
e = new MyEntity();
e = em.merge(e); // re-assign to the same entity "e"

//access e from jsp and it will work dandy!!