高并发时Hibernate保存实体触发StaleObjectStateException咨询

问题本质是代码的锁逻辑、事务边界设计完全偏离预期，和并发量大小没有直接关系，只是高并发把隐藏的设计问题触发了：

• 锁的作用时机完全失效：给save()方法配置的@Lock(PESSIMISTIC_WRITE)，只会在save触发的UPDATE语句执行时才尝试申请行锁，根本覆盖不了之前的实体查询、属性修改阶段。加上你配置的锁超时参数javax.persistence.lock.timeout = -2（即锁不可用直接跳过），完全起不到串行化并发操作的作用。
• 事务边界被错误拆分：Repository层给两个方法分别配置了独立的事务：findById走只读事务，查询完成就提交、释放数据库连接和持有锁；save走独立的可写事务。这意味着哪怕你在查询阶段拿到了行锁，锁也会在find方法执行完、只读事务提交的瞬间释放，等到save执行时，内存中的实体已经是脱离事务上下文的游离状态，根本没法和后续修改绑定在同一个锁范围内。
• 乐观锁校验和现有逻辑天然冲突：你的实体类必然配置了@Version乐观锁字段，Hibernate执行UPDATE时会自动校验内存中实体的版本号和数据库当前版本号是否一致。多个并发事务同时执行findById时，因为是只读查询没有行锁，大家都会拿到同一条记录的相同版本快照；后续执行save时，第一个抢到行锁的事务会正常更新版本号提交，剩下的事务拿到锁后发现版本号不匹配，就会抛出StaleObjectStateException。
• 你观察到两条日志时间戳完全一致，只是高并发下两个操作间隔极短（毫秒级）的正常现象，不是异常的触发原因。
• 并发15个任务时只出现1次失败，本质是这些任务里只有2个刚好操作了同一条存在并发冲突的记录，剩下13个操作的都是无冲突的独立记录，所以只抛出1次异常。

• @Lock注解的使用位置错误：JPA规范中，@Lock注解只有作用于查询方法时，才会在执行SELECT语句时同步申请行锁；作用于save、delete等写方法时注解完全不生效，锁的获取时机远晚于业务预期。
• 锁超时参数配置错误：javax.persistence.lock.timeout = -2（SKIP LOCKED）是为消息队列抢占场景设计的配置，和你当前需要串行化更新同一条记录的业务场景完全不匹配。
• 事务下放到Repository方法层配置，导致跨方法的业务流程被拆分成多个独立事务，无法实现长流程的锁持有。

根据业务场景二选一即可：

1. 适配现有乐观锁逻辑，改动最小
   • 删掉Repository方法上单独配置的@Transactional和@Lock注解，把事务边界上移到核心业务方法myConcurrentRnnningJob()上，添加@Transactional注解，保证从实体查询、属性修改到保存的全流程运行在同一个事务上下文里，实体始终处于受管状态。
   • 保留实体类上的@Version乐观锁字段，这是应对并发修改的标准设计。
   • 针对抛出的StaleObjectStateException增加轻量重试逻辑：捕获该异常后，重新从数据库查询最新版本的实体，重新执行属性修改和保存操作，一般重试2-3次即可解决偶发的并发冲突。
2. 切换为悲观锁逻辑，适合强一致性要求场景
   • 去掉实体类上的@Version乐观锁字段，避免双重版本校验导致的不必要冲突。
   • 把@Lock(PESSIMISTIC_WRITE)注解从save方法挪到findById方法上，同时删掉锁超时参数-2的配置，保证拿不到锁的事务会排队等待，而不是直接跳过。
   • 同样将事务边界上移到核心业务方法层，保证从查询阶段（此时通过SELECT ... FOR UPDATE拿到行排他锁）、属性修改到保存的全流程持锁，其他并发事务查询同一条记录时会阻塞排队，完全避免版本号校验失败的问题。

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