如何处理 丢失更新​（不可重复读​）

默认隔离级别​

Spring中@Transactional的默认隔离级别是Isolation.DEFAULT，这通常意味着使用数据库的默认级别（MySQL为可重复读(REPEATABLE_READ)，Oracle为读已提交(READ_COMMITTED)）。

在读已提交级别下，会发生不可重复读；在可重复读级别下，虽然能避免不可重复读，但仍可能发生幻读，并且如果更新逻辑设计不当，依然可能导致数据覆盖。

核心问题​

您描述的场景关键在于：事务A读取数据后，事务B修改并提交了该数据。此时，事务A持有的数据副本已是过时版本。当事务A基于此旧数据计算并进行更新时，就会覆盖事务B已提交的更改，造成数据丢失。

丢失更新​ 。

1. 提高事务隔离级别​

将方法的事务隔离级别设置为Isolation.SERIALIZABLE（最高级别）。这会强制事务串行执行，彻底解决并发问题，但性能开销最大，一般不推荐。

对数据一致性要求极高，且并发量不大的场景。

2. 使用悲观锁​

在查询数据的SQL语句后添加FOR UPDATE（如：SELECT * FROM table WHERE ... FOR UPDATE）。这会直接锁定目标行，阻止其他事务修改，直到当前事务结束。

并发冲突频繁，且事务执行时间较短的场景。这是一种“先锁后改”的策略。

3. 使用乐观锁（推荐）​

在数据库表中增加一个version（版本号）字段。更新时，在SQL语句中同时检查版本号是否未变，并将版本号+1。例如：UPDATE table SET ..., version = version + 1 WHERE id = ? AND version = ?。如果版本号不匹配，则更新失败。

并发冲突不频繁的大多数场景。性能最好，是一种“先改再看”的策略。

4. 使用分布式锁​

对于分布式系统，可以使用如Redisson等工具，在业务层对关键资源（如订单ID）加锁，确保同一时间只有一个线程能执行“查询-计算-更新”的完整流程。

分布式应用环境，需要跨JVM保证资源独占。