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

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

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

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

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

场景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!!

持久化和合并是为了两个不同的目的(它们根本不是替代方案)。

(编辑以扩大差异信息)

坚持:

向数据库中插入一个新的寄存器 将对象附加到实体管理器。

走：

找到具有相同id的附加对象并更新它。 如果存在，则更新并返回已附加的对象。 如果不存在，则将新寄存器插入数据库。

persist()效率:

在向数据库插入新寄存器时，它可能比merge()更有效。 它不会复制原始对象。

persist()的语义:

它确保您是在插入而不是错误地更新。

例子:

{
    AnyEntity newEntity;
    AnyEntity nonAttachedEntity;
    AnyEntity attachedEntity;

    // Create a new entity and persist it        
    newEntity = new AnyEntity();
    em.persist(newEntity);

    // Save 1 to the database at next flush
    newEntity.setValue(1);

    // Create a new entity with the same Id than the persisted one.
    AnyEntity nonAttachedEntity = new AnyEntity();
    nonAttachedEntity.setId(newEntity.getId());

    // Save 2 to the database at next flush instead of 1!!!
    nonAttachedEntity.setValue(2);
    attachedEntity = em.merge(nonAttachedEntity);

    // This condition returns true
    // merge has found the already attached object (newEntity) and returns it.
    if(attachedEntity==newEntity) {
            System.out.print("They are the same object!");
    }

    // Set 3 to value
    attachedEntity.setValue(3);
    // Really, now both are the same object. Prints 3
    System.out.println(newEntity.getValue());

    // Modify the un attached object has no effect to the entity manager
    // nor to the other objects
    nonAttachedEntity.setValue(42);
}

这种方法对于实体管理器中的任何寄存器只存在一个附加对象。

对于带id的实体，Merge()是这样的:

AnyEntity myMerge(AnyEntity entityToSave) {
    AnyEntity attached = em.find(AnyEntity.class, entityToSave.getId());
    if(attached==null) {
            attached = new AnyEntity();
            em.persist(attached);
    }
    BeanUtils.copyProperties(attached, entityToSave);

    return attached;
}

虽然如果连接到MySQL merge()可以像persist()一样有效，使用一个调用INSERT和ON DUPLICATE KEY UPDATE选项，JPA是一个非常高级的编程，你不能假设这将是任何地方的情况。

persist(entity)应该与全新的实体一起使用，将它们添加到DB(如果实体已经存在于DB中，则会抛出EntityExistsException)。

应该使用Merge(实体)，如果实体被分离并被更改，则将实体放回持久性上下文中。

可能持久是生成INSERT sql语句和合并UPDATE sql语句(但我不确定)。

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