为何Spring Data JPA设置事务隔离级别仍无法解决丢失更新问题

你给出的业务代码如下：

@Override
@Transactional
public boolean removeAvailableStock(Long itemId, Long quantity) {
    ItemEntity itemEntity = itemRepository.findById(itemId).orElseThrow(NoSuchItemException::new);
    itemEntity.removeAvailableStock(quantity);
    return true;
}

1. 为何该场景下隔离级别无法解决丢失更新问题？ #

你遇到的是第二类丢失更新（提交覆盖），这一问题无法通过H2等主流数据库的MVCC实现的隔离级别解决，核心原因如下：

• H2的Repeatable Read、Serializable隔离级别默认基于MVCC快照读实现：普通SELECT查询时会读取事务启动时刻的快照数据，不会对数据行加锁。两个并发事务会同时读到相同版本的库存数据，各自在内存中修改后提交，后提交的事务会直接覆盖先提交事务的修改，全程不会触发冲突检测。
• 你给findById指定LockMode本质是将快照读改为当前读，对数据行加排他锁，后续并发事务查询时必须等待前序事务提交释放锁才能读取数据，自然避免了写覆盖问题。

2. 很多文档中提到的可解决丢失更新的隔离级别具体指代什么？ #

这类文档的表述通常基于两种前提：

• 指代解决第一类丢失更新（回滚覆盖）：所有高于读未提交的隔离级别，都已经解决了事务异常回滚时覆盖其他事务已提交更新的问题，这是隔离级别最基础的能力。
• 基于传统锁实现的隔离级别理论模型：早期数据库隔离级别的理论定义是基于锁实现的，在该模型下Repeatable Read级别会给查询的数据加共享锁直到事务结束，此时两个事务同时读取同一条数据后尝试修改，会触发锁升级冲突，避免丢失更新。但现在主流数据库（MySQL、H2、PostgreSQL等）都采用MVCC实现提升读性能，和传统锁模型的行为存在差异，才会出现你遇到的情况。
• 少部分文档提到的是真正完全串行执行的Serializable隔离级别：部分数据库的最高隔离级别会强制所有事务串行执行，自然不会有并发写冲突，但性能极低，几乎不会在生产环境使用。

3. 若隔离级别无法解决这类并发问题，其实际作用是什么？ #

隔离级别核心解决的是事务内读操作的一致性问题，对应SQL标准定义的四类异常场景：

• 读未提交：防止脏读（读取到其他事务未提交的回滚数据）
• 读已提交：解决脏读问题
• 可重复读：解决脏读、不可重复读（同一事务内多次读取同一条数据结果不一致）问题
• 串行化：解决脏读、不可重复读、幻读（同一事务内多次查询匹配的行数不一致）问题

它的设计目标是保证单个事务的读操作符合预期，而写-写冲突的并发控制，属于业务层的并发安全范畴，需要通过悲观锁（指定LockMode）、乐观锁（JPA的@Version字段）、分布式锁等方案解决，不属于隔离级别的责任范围。

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