JPA的merge与persist方法内部执行机制是怎样的？

persist() 方法执行顺序 #

• 方法调用后首先执行的动作是将传入的瞬态实体加入当前持久化上下文，直接标记为托管状态，这一步纯是内存层面的操作，不会触发任何JDBC数据库请求。
• 实体进入托管状态后，所有字段修改都会被持久化上下文自动跟踪，变更会被暂存，不需要重复调用persist方法。
• 真正的数据库INSERT操作，只会在持久化上下文触发刷盘（flush）时执行，常见刷盘触发场景包括：事务提交、手动调用entityManager.flush()、执行查询前JPA判断需要先同步待持久化数据避免查询结果脏读。
• 不存在「先写库再托管」的逻辑：如果persist调用后事务回滚，数据最终不会落库，但实体确实已经在方法调用瞬间进入过托管状态，仅在事务回滚后转为脱管状态。

典型验证场景：新建一个瞬态实体调用persist后，立刻修改实体字段值，最终事务提交时数据库存储的是修改后的值，正是因为实体提前进入托管状态被跟踪，字段变更已经被记录到待执行SQL中。

merge() 方法执行顺序 #

首先需要明确一个极易踩坑的规则：传入merge()方法的原对象，永远不会被直接转为托管状态。

• 第一步：JPA根据传入实体的主键（标注@Id的字段），在当前持久化上下文查找是否存在同ID的托管实例：
  • 如果存在匹配的托管实例，直接将传入对象的所有字段值拷贝到这个已有的托管实例上；
  • 如果上下文内没有匹配实例，JPA会先发起SELECT查询从数据库拉取对应ID的记录，构造一个全新的托管实例，再把传入对象的字段值拷贝到这个新实例上；如果传入的是无主键的瞬态实体，JPA会直接新建一个托管的实体副本，完成字段拷贝。
• 第二步：方法直接返回这个持有拷贝值的托管副本实例，到这一步为止，全程不会触发INSERT/UPDATE类的数据库写操作。
• 第三步：等到持久化上下文刷盘时，才会根据托管副本上的字段变更，生成对应SQL同步到数据库。

踩坑提示：调用merge后如果继续修改传入的原对象，变更不会被同步到数据库，只有操作merge返回的托管实例，修改才会被持久化上下文跟踪。

核心规则澄清 #

• JPA标准流程下，所有会被自动同步到数据库的实体变更，必须绑定在持久化上下文内的托管实例上，不存在「先执行数据库写操作，再将对应实例转为托管状态」的逻辑。
• JPA本身基于工作单元模式设计，持久化上下文本质是内存中的一级缓存与操作缓冲区，所有实体变更先在内存的托管实例上记录，攒到刷盘节点再一次性和数据库交互，减少不必要的数据库IO。
• 如果你绕过JPA直接执行JDBC写操作，这类动作JPA完全无感知，也不会对应生成托管实例，属于脱离JPA持久化流程的特殊场景，不在规范定义的标准行为范围内。

内容的提问来源于stack exchange，提问作者Yuri Bittencourt