深入分析Spring的事务隔离级别及实现原理

知其然要知其所以然，探索每一个知识点背后的意义，你知道的越多，你不知道的越多，一起学习，一起进步，如果文章感觉对您有用的话，关注、收藏、点赞，有困惑的地方请评论，我们一起交流！

深入分析Spring的事务隔离级别及实现原理

1. 事务隔离级别的定义与问题

事务隔离级别旨在解决数据库并发操作中的以下问题：

脏读（Dirty Read）：读取到其他事务未提交的数据。
不可重复读（Non-Repeatable Read）：同一事务中多次读取同一数据，结果不一致。
幻读（Phantom Read）：同一查询条件返回的行数因其他事务的插入或删除操作而发生变化。

标准隔离级别（由ANSI SQL定义）：

READ_UNCOMMITTED：允许脏读、不可重复读、幻读。
READ_COMMITTED：避免脏读，但允许不可重复读和幻读。
REPEATABLE_READ：避免脏读和不可重复读，但允许幻读。
SERIALIZABLE：完全串行化，避免所有问题，但性能最低。

2. Spring如何实现事务隔离级别

Spring本身并不直接实现事务隔离，而是通过以下方式与底层数据库交互：

依赖数据库的隔离机制

Spring通过设置数据库连接的隔离级别来控制事务行为。例如，当使用@Transactional(isolation = Isolation.READ_COMMITTED)时，Spring会在事务开始时调用java.sql.Connection#setTransactionIsolation()方法，将数据库连接的隔离级别设置为READ_COMMITTED。
- @Transactional 的作用范围：
  - 方法：推荐将注解使用于方法上，不过需要注意的是：该注解只能应用到 public 方法上，否则不生效，因为底层基于AOP，AOP底层基于动态代理，非pubilc方法，是直接调用该方法，没有经过代理
  - 类：如果这个注解使用在类上的话，表明该注解对该类中所有的 public 方法都生效
  - @Transactional 的工作机制是基于 AOP 实现的，AOP 又是使用动态代理实现的。如果目标对象实现了接口，默认情况下会采用 JDK 的动态代理，如果目标对象没有实现了接口,会使用 CGLIB 动态代理
  - DefaultAopProxyFactory.createAopProxy() 方法决定了是使用 JDK 还是 Cglib 来做动态代理，Cglib和JDK最大的区别在于Cglib实现的动态代理并没有被代理类的实例对象，所有的方法调用都是通过代理类来实现的。
事务管理器（PlatformTransactionManager）

Spring通过事务管理器与具体的数据访问技术（如JDBC、Hibernate）集成。不同的事务管理器实现类（如DataSourceTransactionManager、HibernateTransactionManager）负责将隔离级别配置传递给底层数据库。接口中定义了三个方法：获得事务、提交事务、回滚事务。
事物传播行为

PROPAGATION_REQUIRED：默认，如果当前没有事务，则创建一个新事务；如果已有事务，则加入该事务。
PROPAGATION_REQUIRES_NEW：创建一个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部方法是否开启事务
PROPAGATION_NESTED：如果当前存在事务，就在嵌套事务内执行；如果当前没有事务，就执行与TransactionDefinition.PROPAGATION_REQUIRED类似的操作。
- 嵌套事务的特性：
  - 嵌套事务的提交和回滚是相对独立的。外部事务的提交不会自动提交内部事务。
  - 内部事务的回滚会导致外部事务的回滚，前提是外部事务还在进行中
PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。（mandatory：强制性）
PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行
PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
PROPAGATION_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。

AOP代理与事务拦截器
Spring通过AOP动态生成代理对象，在目标方法执行前后插入事务管理逻辑（如开启事务、提交/回滚）。隔离级别在事务启动时生效。

3. 数据库兼容性与Spring的适配

数据库支持的隔离级别差异

不同数据库对隔离级别的支持存在差异。例如：
- MySQL ：默认REPEATABLE_READ，支持所有四种级别。
- Oracle ：默认READ_COMMITTED，不支持READ_UNCOMMITTED和REPEATABLE_READ。
- PostgreSQL ：默认READ_COMMITTED，支持所有级别。
Spring的处理策略
- 兼容性检查 ：Spring不会自动降级隔离级别。如果指定了数据库不支持的隔离级别，会在运行时抛出异常（如InvalidIsolationLevelException）。
- 开发者责任 ：需根据数据库特性选择合适的隔离级别。例如，在Oracle中使用SERIALIZABLE可能导致性能问题。

4. 隔离级别与传播行为的区别

隔离级别（Isolation）：控制事务之间的可见性和影响。
传播行为（Propagation）：控制事务的边界（如是否加入已有事务、新建事务等）。

两者共同决定事务的行为，但关注点不同。例如：
java 复制代码
```
@Transactional(
    isolation = Isolation.READ_COMMITTED,
    propagation = Propagation.REQUIRES_NEW
)
public void doSomething() { ... }
```

5. 代码示例与测试验证

通过模拟并发操作，验证隔离级别的作用：

测试脏读
- 事务A修改数据但未提交。
- 事务B在READ_UNCOMMITTED级别下读取到未提交的数据（脏读），在READ_COMMITTED下读取不到。
测试不可重复读
- 事务A读取数据后，事务B修改并提交。
- 事务A再次读取同一数据，若隔离级别为READ_COMMITTED，则结果不一致；若为REPEATABLE_READ，则结果一致。
测试幻读
- 事务A根据条件查询数据，事务B插入符合条件的新数据并提交。
- 事务A再次查询，若隔离级别为REPEATABLE_READ，可能仍看不到新数据（取决于数据库实现）；若为SERIALIZABLE，则完全避免。

6. 事物实效的场景

1. 未启用事务管理

原因：未在Spring配置中启用事务管理。

解决方案 ：

java 复制代码

@Configuration
@EnableTransactionManagement // 必须启用事务管理
public class AppConfig {
    // 配置数据源和事务管理器
}

2. 方法非public或内部调用导致代理失效

场景：非public方法或类内部调用事务方法。

示例：

java 复制代码

public class UserService {
    public void methodA() {
        methodB(); // 内部调用，事务失效
    }
    
    @Transactional
    private void methodB() { // 非public方法，事务失效
        // 业务逻辑
    }
}

解决方案 ：

确保事务方法是public的。

通过代理对象调用事务方法（如注入自身Bean）：

java 复制代码

@Autowired
private UserService selfProxy; // 注入自身代理对象

public void methodA() {
    selfProxy.methodB(); // 通过代理调用
}

3. 异常处理不当

场景：
- 捕获异常未抛出。
- 抛出检查型异常（Checked Exception），但未指定rollbackFor。

示例：

java 复制代码

@Transactional
public void updateUser() {
    try {
        // 业务逻辑
    } catch (Exception e) {
        // 捕获异常未抛出，事务不回滚
    }
}

@Transactional
public void saveData() throws IOException { // 检查型异常
    // 业务逻辑
    throw new IOException(); // 默认不回滚
}

解决方案 ：

java 复制代码

@Transactional(rollbackFor = Exception.class) // 指定回滚所有异常
public void saveData() throws IOException {
    // 业务逻辑
}

4. 数据库引擎不支持事务

场景：使用不支持事务的数据库引擎（如MySQL的MyISAM）。
解决方案 ：将表引擎切换为InnoDB：
sql 复制代码
```
ALTER TABLE your_table ENGINE = InnoDB;
```

5. 事务传播行为配置不当

场景：传播行为设置为NOT_SUPPORTED或NEVER，导致事务不生效。

示例：

java 复制代码

@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void doSomething() {
    // 该方法不在事务中运行
}

解决方案 ：根据业务需求选择合适的传播行为（如REQUIRED）。

6. 多数据源环境下未指定事务管理器

场景：多数据源配置中未明确使用@Transactional的transactionManager属性。

示例：

java 复制代码

@Transactional("secondTxManager") // 指定事务管理器名称
public void multiDataSourceOperation() {
    // 操作第二个数据源
}

7. 事务超时或只读冲突

场景：
- 事务超时（timeout）设置过短，导致操作未完成即回滚。
- 方法标记为readOnly = true，但执行了写操作。

解决方案 ：

java 复制代码

@Transactional(timeout = 30, readOnly = false)
public void writeOperation() {
    // 写操作
}

7. 总结与最佳实践

选择隔离级别 ：根据业务需求平衡一致性与性能。例如：
- 高一致性场景：使用SERIALIZABLE。
- 高并发场景：使用READ_COMMITTED。
数据库适配：明确目标数据库支持的隔离级别，避免配置不支持的级别。
结合传播行为 ：合理使用传播行为（如REQUIRED、REQUIRES_NEW）以优化事务边界。