Spring 事务失效的原因及解决方案全解析，来复习了

原创已于 2025-04-14 02:51:55 修改 · 2.3k 阅读 ·

大模型引用 5 次

本内容遵循CC 4.0 BY-SA版权协议

熬夜的猪

关注

标签

#数据库 #java #spring #spring事务 #讲义

分类后端开发

代码可运行

于 2025-04-14 02:46:22 首次发布

Spring 专栏收录该内容

1 篇文章

订阅专栏

Spring 事务失效是指在使用 Spring 声明式事务管理时，预期的事务行为（如事务的开启、提交、回滚等）未按预期执行，导致数据操作未满足 ACID 特性（原子性、一致性、隔离性、持久性），从而引发数据不一致问题。

失效的原因及解决方案

1. 方法访问权限问题

原因分析

Spring 事务基于动态代理（JDK 或 CGLIB）实现，仅拦截 public 方法。若方法为 private、protected 或包级可见，代理类无法增强该方法，事务失效。

示例场景

@Service
public class UserService {
    @Transactional
    void createUser() {  // 包级可见方法
        // 数据库操作
    }
}

调用 createUser() 时，事务未生效。

解决方案

强制要求：将事务方法声明为 public。
Spring 限制：Spring 原生机制不支持非 public 方法的事务代理，需严格遵守规范。

2. 自调用问题（内部方法调用）

原因分析

在同一个类中，非事务方法调用事务方法时，实际通过 this 实例调用，而非代理对象，导致事务拦截失效。

示例场景

@Service
public class OrderService {
    public void placeOrder() {
        this.deductStock();  // 自调用事务方法
    }

    @Transactional
    public void deductStock() {
        // 扣减库存（事务失效）
    }
}

解决方案

拆分到不同 Bean（Spring 推荐方案）

@Service
public class StockService {
    @Transactional
    public void deductStock() { ... }
}

@Service
public class OrderService {
    @Autowired
    private StockService stockService;

    public void placeOrder() {
        stockService.deductStock();  // 通过代理对象调用
    }
}

使用 Spring 的 AopContext ：

@Service
public class OrderService {
    public void placeOrder() {
        ((OrderService) AopContext.currentProxy()).deductStock();
    }
}

需开启代理暴露：在配置类添加 @EnableAspectJAutoProxy(exposeProxy = true)。

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

原因分析

如 MySQL 的 MyISAM 引擎不支持事务，仅 InnoDB 支持。

验证方法

SHOW TABLE STATUS LIKE 'your_table';

解决方案

修改表引擎为 InnoDB：
```
ALTER TABLE your_table ENGINE = InnoDB;
```

4. 配置错误

原因分析

未启用事务管理：未添加 @EnableTransactionManagement 或 XML 中未配置 <tx:annotation-driven/>，导致事务注解未被解析。
多数据源未指定事务管理器：多数据源场景需为每个数据源配置独立的 DataSourceTransactionManager，并在 @Transactional 中通过 transactionManager 属性指定。

示例场景

@Configuration
@EnableTransactionManagement // 必须启用，相当于<tx:annotation-driven/>启用基于注解的事务管理
public class AppConfig {
    @Bean
    public PlatformTransactionManager txManager(DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}

解决方案

检查配置类是否启用事务管理。

多数据源时明确指定事务管理器：

@Transactional(transactionManager = "orderTxManager")
public void createOrder() { ... }

5. Bean 未被 Spring 管理

根本原因

未标记为 Spring Bean
类未使用以下任一注解标记，导致 Spring 容器无法扫描和管理：
- @Component（通用注解）
- @Service（服务层）
- @Repository（数据层）
- @Controller/@RestController（Web 层）
- @Configuration（配置类中的 @Bean 方法）
直接通过 new 实例化对象
即使类上有 @Component 等注解，直接 new 出的对象不受 Spring 管理。
包未被 Spring 扫描
类所在的包未在 @ComponentScan 或启动类扫描范围内。

Bean 未被管理的典型表现

依赖注入失效
- @Autowired、@Resource、@Value 等注解无效，注入字段为 null。
- 示例：userService.save() 抛出 NullPointerException。
事务和 AOP 失效
- @Transactional 不生效，数据库操作无法回滚。
- @Aspect、@Cacheable 等注解逻辑不执行。
生命周期回调失效
- @PostConstruct（初始化方法）和 @PreDestroy（销毁方法）不触发。

解决方案

标记类为 Spring Bean

@Service // 使用任意 Bean 注解（如 @Component, @Service）
public class UserService {
    // 类内注解（@Autowired、@Transactional 等）才会生效
}

通过 Spring 容器获取 Bean
- 使用依赖注入（@Autowired 或构造函数注入），避免直接 new。
- 示例：
```
@Autowired 
private UserService userService; // 正确：由 Spring 注入代理对象
```
检查包扫描配置
- 确保类所在的包在 @ComponentScan 范围内（Spring Boot 默认扫描启动类所在包及其子包）。

6. 多线程调用导致事务上下文丢失

原因分析

事务上下文存储在 ThreadLocal 中，子线程无法继承父线程的事务。在异步方法中操作数据库时，事务独立于主线程。

示例场景

@Transactional
public void processBatch() {
    new Thread(() -> userDao.insert(user)).start();  // 子线程操作无事务
}

解决方案

避免跨线程操作：确保事务方法内所有数据库操作在同一线程。

编程式事务管理：

@Autowired
private TransactionTemplate transactionTemplate;

public void processBatch() {
    transactionTemplate.execute(status -> {
        userDao.insert(user);
        return null;
    });
}

7. 方法被 `final` 或 `static` 修饰

在Spring框架中，使用动态代理（如CGLIB）实现AOP（面向切面编程）增强时，final或static修饰的方法会导致事务等增强逻辑失效。以下是具体原因和场景说明：

动态代理的工作原理

动态代理通过生成目标类的子类来实现方法增强。CGLIB（Code Generation Library）是Spring中常用的动态代理技术，它在运行时动态生成目标类的子类，并重写目标类的方法。生成的子类会在方法执行前后插入增强逻辑（如事务管理、日志记录等）。

`final`方法的影响

final方法不能被子类重写。
动态代理依赖于子类覆盖父类方法来实现增强。若目标方法是final的，生成的代理类无法重写该方法，导致增强逻辑（如事务管理）无法生效。

`static`方法的影响

static方法属于类本身，不依赖于实例调用。
动态代理基于对象实例的继承或接口实现，无法拦截静态方法的调用。因此，静态方法无法被代理类增强，事务管理等逻辑失效。

示例场景

1. final方法导致事务失效

@Service
public class ReportService {
    @Transactional
    public final void generateReport() {  // final方法无法被CGLIB代理覆盖
        // 数据库操作（无事务管理）
    }
}

问题：generateReport是final方法，代理类无法重写它，@Transactional失效。

2. static方法导致事务失效

@Service
public class UtilityService {
    @Transactional
    public static void performCleanup() {  // static方法无法被代理拦截
        // 数据库操作（无事务管理）
    }
}

问题：performCleanup是静态方法，代理类无法覆盖它，事务逻辑未触发。
Java语法特性
通过实例调用static方法是一种语法糖，本质仍是对类方法的调用。例如：
```
MyClass instance = new MyClass();  
instance.staticMethod();  // 等价于 MyClass.staticMethod();  
```
编译器会自动将其转换为类名调用。

解决方案

避免使用final或static修饰需增强的方法
确保需要事务管理的方法是非final且非static的。
重构代码
将静态方法转换为实例方法，并通过依赖注入调用，确保代理逻辑可应用。

8. 循环依赖导致事务失效

原因分析

代理生成时机：Spring通过动态代理（JDK或CGLIB）实现事务管理。当存在循环依赖时，Bean可能在完全初始化前被注入到其他Bean中，导致注入的是原始对象而非代理对象。
三级缓存机制：Spring使用三级缓存解决循环依赖，但若代理在对象初始化后才生成，早期引用的Bean可能无法获得代理，从而绕过事务拦截。

示例场景

@Service
public class ServiceA {
    @Autowired
    private ServiceB serviceB;

    @Transactional
    public void methodA() {
        // 假设操作数据库
        serviceB.methodB();
    }
}

@Service
public class ServiceB {
    @Autowired
    private ServiceA serviceA;

    @Transactional
    public void methodB() {
        // 调用ServiceA的方法，可能未经过代理
        serviceA.methodA();
    }
}

问题：当ServiceA注入到ServiceB时，可能注入的是原始对象，而非事务代理。此时调用methodA()不会触发事务，导致事务失效。

验证方法

日志调试
```
logging.level.org.springframework.transaction=DEBUG
```
观察TransactionInterceptor.invoke()是否有日志，若无则事务未拦截。
检查连接事务状态：
在DataSourceUtils.getConnection()中，若Connection的autoCommit为true，说明未开启事务。

解决方案

一、详细分析与推荐理由

1. 重构代码（提取公共逻辑到第三个Service）

推荐度：⭐️⭐️⭐️⭐️⭐️
核心思想：通过职责分离，直接消除循环依赖，从根源解决问题。

示例：

@Service
public class ServiceC {  // 提取公共逻辑
    @Transactional
    public void commonMethod() {
        // 公共事务逻辑
    }
}

@Service
public class ServiceA {
    @Autowired
    private ServiceC serviceC;  // 依赖ServiceC
}

@Service
public class ServiceB {
    @Autowired
    private ServiceC serviceC;  // 依赖ServiceC
}

优势：
- 代码清晰：消除循环依赖，提升可维护性。
- 符合设计原则：遵循单一职责原则（SRP）和接口隔离原则（ISP）。
适用场景：
- 长期维护的中大型项目。
- 需要高代码质量和可扩展性的场景。

2. 使用构造器注入

推荐度：⭐️⭐️⭐️⭐️
核心思想：通过构造器强制声明依赖，提前暴露循环依赖问题，迫使开发者重构。

示例：

@Service
public class ServiceA {
    private final ServiceB serviceB;

    // 构造器注入
    public ServiceA(ServiceB serviceB) {
        this.serviceB = serviceB;
    }
}

@Service
public class ServiceB {
    private final ServiceA serviceA;

    // 构造器注入（若存在循环依赖，Spring会直接报错）
    public ServiceB(ServiceA serviceA) {
        this.serviceA = serviceA;
    }
}

优势：
- 依赖明确：所有必需依赖在实例化时明确传入。
- 不可变性：依赖字段可设为final，避免意外修改。
适用场景：
- 需要严格依赖管理的项目。
- 适合大多数Spring Boot应用（官方推荐方式）。

3. 使用Setter注入 + `@Lazy`

推荐度：⭐️⭐️⭐️
核心思想：通过延迟注入代理对象，绕开循环依赖导致的代理生成问题。

示例：

@Service
public class ServiceB {
    private ServiceA serviceA;

    @Autowired
    public void setServiceA(@Lazy ServiceA serviceA) {
        this.serviceA = serviceA;  // 延迟注入代理
    }
}

优势：
- 快速修复：无需改动现有代码结构，适合紧急修复。
劣势：
- 掩盖设计缺陷：循环依赖依然存在，可能引发其他隐患。
- 可维护性差：依赖关系不够清晰。
适用场景：
- 短期过渡方案或遗留代码维护。
- 小型项目或原型开发。

二、决策树：如何选择方案？

场景	推荐方案
代码可维护性优先	重构代码 + 构造器注入
紧急修复生产问题	Setter注入 + `@Lazy`
新项目或严格遵循Spring规范	构造器注入
依赖复杂且难以重构	结合`@Lazy`与部分重构

三、总结

终极方案：重构代码提取公共逻辑，彻底消除循环依赖。
推荐实践：在新项目中优先使用构造器注入，避免循环依赖。
临时方案：使用@Lazy+Setter注入作为短期过渡，但需尽快重构。

其他注意事项：

1. 异常处理不当（事务未失效，但回滚规则配置错误）

原因分析

默认回滚规则：仅 RuntimeException 和 Error 触发回滚，受检异常（如 IOException）需手动配置。
异常被吞没：捕获异常后未重新抛出，事务管理器无法感知异常。

示例场景

@Transactional
public void updateUser() {
    try {
        userDao.update(user);
    } catch (SQLException e) {
        // 捕获异常但未抛出，事务不回滚
    }
}

解决方案

抛出运行时异常：

catch (SQLException e) {
    throw new DataAccessException("更新失败", e);
}

显式配置回滚异常：

@Transactional(rollbackFor = Exception.class)
public void updateUser() { ... }

手动回滚事务：

catch (SQLException e) {
    TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}

2. 事务的传播行为不正确

传播行为	作用	典型使用场景	关键特点	注意事项
REQUIRED	加入当前事务，不存在则新建	90% 的增删改操作（默认选项）	事务合并，任一失败全部回滚	默认选择，适合绝大多数场景
REQUIRES_NEW	新建独立事务，挂起当前事务	日志记录、异步任务、外部不可逆操作	完全独立提交，外层事务回滚不影响内层	慎用！可能导致锁竞争或性能问题
NOT_SUPPORTED	非事务执行，挂起当前事务	大数据量只读查询、性能敏感操作	强制非事务运行，避免事务开销	确保操作无需事务一致性
NEVER	非事务执行，若当前存在事务则抛异常	防御性非事务场景	严格校验环境，防止误用事务	确保调用链中无事务
SUPPORTS	有事务则加入，无事务则以非事务运行	兼容性操作（如根据调用方决定事务）	灵活适配，不主动控制事务	需明确业务是否需要事务支持
MANDATORY	必须存在事务，否则抛异常	公共服务被事务方法调用	强制依赖外部事务	确保调用方已开启事务
NESTED	嵌套事务（基于保存点，子事务回滚不影响父事务）	复杂业务流程分层（如订单与子步骤）	父事务回滚导致子事务回滚，子事务可独立回滚	依赖数据库支持（如 Oracle/PostgreSQL 支持，MySQL InnoDB 不支持）

附加说明

优先级建议：
- 首选 REQUIRED：除非有明确需求，否则默认使用。
- 慎用 REQUIRES_NEW：独立事务可能导致死锁或长事务问题。
非事务场景：
- NOT_SUPPORTED：用于明确无需事务且需提升性能的场景。
- NEVER：防御性设计，防止事务误用。
特殊场景：
- NESTED：仅适用于支持保存点的数据库，复杂业务中可替代部分 REQUIRES_NEW 需求。
性能影响：
- REQUIRES_NEW 和 NESTED 会占用更多数据库连接资源，高并发时需谨慎。

快速决策流程图

是否需要独立提交？ → YES → REQUIRES_NEW
是否强制非事务？ → YES → NEVER/NOT_SUPPORTED
是否依赖外部事务？ → YES → MANDATORY
默认 → REQUIRED

通过此表格和说明，可快速匹配业务场景与传播行为，平衡一致性与性能。

以下是一个典型场景：

在同一个类中调用带有 `REQUIRES_NEW` 传播行为的方法，由于自调用导致事务传播未生效，但事务本身仍然存在。

示例代码

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    // 外部方法：使用默认的 REQUIRED 传播行为
    @Transactional
    public void createUserAndLogIncorrect() {
        userRepository.save(new User("Alice"));  // 保存用户
        
        // 自调用内部方法（期望开启新事务，但实际未生效）
        logOperation();
    }

    // 内部方法：期望开启独立事务（但实际未生效）
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void logOperation() {
        logRepository.save(new LogEntry("User created"));  // 记录日志
        throw new RuntimeException("模拟日志失败");  // 强制抛出异常
    }
}

现象解释

预期行为：
- logOperation() 方法会开启一个新事务，即使日志保存失败（抛出异常），createUserAndLogIncorrect() 中的用户保存操作（主事务）应该正常提交。
实际行为：
- logOperation() 的事务传播行为 未生效，因为它被同一个类中的 createUserAndLogIncorrect() 直接调用。
- 由于自调用绕过 Spring AOP 代理，logOperation() 没有开启新事务，而是与 createUserAndLogIncorrect() 共享同一个事务。
- 当 logOperation() 抛出异常时，整个事务回滚，导致用户和日志均未保存。
事务未失效的表现：
- 事务仍然存在（如移除 @Transactional 注解，数据会直接提交到数据库，不会回滚）。
- 错误在于传播行为未按预期工作，但事务机制本身正常运行。

解决方案

拆分事务方法到独立Service

@Service
public class StockService {
    @Transactional
    public void deductStock() { ... }
}

@Service
public class OrderService {
    @Autowired
    private StockService stockService;

    public void placeOrder() {
        stockService.deductStock();  // 通过代理对象调用，事务生效
    }
}