Spring事务隔离级别共5种：DEFAULT（使用数据库默认）、READ_UNCOMMITTED（允许脏读、不可重复读、幻读）、READ_COMMITTED（解决脏读，但存在不可重复读和幻读）、REPEATABLE_READ（解决脏读和不可重复读，MySQL通过间隙锁缓解幻读）、SERIALIZABLE（彻底避免三类问题，但性能最低）。
Spring 事务隔离级别共5种，对应标准SQL定义的并发控制策略，核心目标是解决脏读、不可重复读和幻读这三类并发读问题。选择哪一级别，取决于业务对数据一致性与性能的权衡。
五种隔离级别及其解决的读问题
每种级别在数据库层面通过锁或MVCC机制实现，Spring本身不直接处理隔离，而是通过Connection.setTransactionIsolation()将设置透传给底层数据库：
-
DEFAULT：不显式指定时使用，实际值由数据库决定（MySQL InnoDB 默认
REPEATABLE_READ，Oracle 默认READ_COMMITTED） - READ_UNCOMMITTED：允许读未提交数据 → 脏读、不可重复读、幻读都可能发生；极少用于生产
- READ_COMMITTED：只读已提交数据 → 解决脏读，但不可重复读和幻读仍存在；适合报表查询、日志类场景
- REPEATABLE_READ：同一事务内多次读同一行结果一致 → 解决脏读和不可重复读；MySQL通过间隙锁（Gap Lock）缓解幻读，但未完全杜绝
- SERIALIZABLE：强制串行执行 → 彻底避免脏读、不可重复读、幻读；以锁表或范围锁为代价，吞吐量显著下降，仅用于极敏感操作（如金融核心账务）
怎么配置隔离级别
通过 @Transactional 的 isolation 属性设置，必须作用于 public 方法，且需经 Spring 代理调用（避免 this. 直接调用）：
@Service
public class OrderService {
<pre class="brush:php;toolbar:false;">// 使用数据库默认（推荐多数场景）
@Transactional
public void placeOrder() { /* ... */ }
// 明确要求读已提交（如防止脏读的订单状态查询）
@Transactional(isolation = Isolation.READ_COMMITTED)
public OrderDTO findOrder(Long id) { /* ... */ }
// 需要事务内多次读取并比对（如库存扣减前校验）
@Transactional(isolation = Isolation.REPEATABLE_READ)
public void deductStock(Long productId, int count) { /* ... */ }}
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
如何针对性解决三类读问题
不是所有业务都需要最高隔离，应按问题类型匹配策略：
-
脏读：只要不选
READ_UNCOMMITTED就能避免；默认READ_COMMITTED或更高即可 -
不可重复读：升级到
REPEATABLE_READ或SERIALIZABLE；也可用应用层缓存+版本号（如@Version）替代强隔离 -
幻读：
REPEATABLE_READ在 MySQL 中靠间隙锁抑制部分幻读，但 insert/delete 仍可能触发；彻底解决需SERIALIZABLE，或改用 SELECT FOR UPDATE + 显式加锁，或从业务上规避（如用唯一约束代替条件插入）
实际选型建议
多数业务无需显式指定隔离级别。优先依赖数据库默认，并在出现具体并发异常时再针对性调整：
- 高并发读多写少（如商品详情页）→
READ_COMMITTED平衡一致性与性能 - 写操作含多次读-判-写逻辑（如下单扣库存）→
REPEATABLE_READ保证中间数据不被干扰 - 跨多表强一致性校验（如转账余额+流水双写）→ 可考虑
SERIALIZABLE，但更推荐拆分为幂等+补偿事务 - 避免盲目升级隔离级别：它不能替代正确的并发控制设计，比如缺少 where 条件的 update、未加索引导致锁升级等，都会放大问题
