Spring事务传播行为与失效场景分析：从源码到实战的全面解密

引言

在微服务架构盛行的今天，分布式事务框架（如Seata、TCC）层出不穷，但绝大多数业务场景下的数据一致性保障，依然要回归到本地事务这个最基础的单元。而Spring事务管理，作为Java后端开发者绕不开的核心技能，其传播行为和失效场景的掌握程度，往往直接决定了一个系统的数据可靠性。

想象这样一个场景：你的系统收到一笔订单请求，需要同时扣减库存、增加积分、记录日志。这三个操作分属三个不同的Service方法，每个方法都标注了@Transactional。当库存扣减成功但积分增加失败时，整个操作应该回滚到哪个状态？日志记录应该独立提交还是随主流程回滚？这些问题的答案，全部隐藏在Spring事务传播行为的细节之中。

更令人头疼的是，很多开发者在生产环境遇到过“@Transactional竟然没生效”的诡异问题——方法明明标注了事务注解，数据却依然出现了部分成功部分失败的情况。这些失效场景背后的原理是什么？如何从根本上避免？

本文将深入Spring事务的源码实现，结合生活化类比与完整代码示例，为你彻底解开这两个核心谜题。

核心概念：事务传播行为的生活化理解

在深入源码之前，让我们先建立一个直观认知。假设事务是一个“工作小组”，每个事务注解方法就像一个需要小组协作完成的工作任务：

• REQUIRED（默认）：如果当前已有小组在工作，新任务加入现有小组；否则新建一个小组。这就像公司里遇到项目，有项目组就加入，没有就成立新组。

• REQUIRES_NEW：无论是否存在小组，一律挂起当前小组，新建独立小组。就像紧急事故处理队，不干扰正常生产，独立行动。

• NESTED：如果存在小组，则在当前小组内设置一个“保存点”，后续操作可以单独回滚到保存点，不影响外层已完成的进度。类似代码版本管理中的分支提交。

• MANDATORY：必须存在小组，否则抛异常。就像必须加入既有项目组，否则拒绝工作。

• SUPPORTS：有小组就加入，没有就以非事务方式运行。如同“锦上添花”，有资源就利用，没有也不强求。

• NOT_SUPPORTED：挂起当前事务，以非事务方式运行。就像让事务小组暂停，自己去处理非事务性工作。

• NEVER：如果存在事务则抛异常。明确拒绝在事务环境中运行。

这些传播行为定义了方法之间事务边界的融合或隔离策略，其底层实现依赖于Spring的TransactionInterceptor与AbstractPlatformTransactionManager的协作。

源码深度分析：Spring事务拦截的核心机制

Spring声明式事务的基础是AOP代理。当我们调用一个标注了@Transactional的方法时，实际是通过代理对象调用的。核心拦截器TransactionInterceptor的invoke方法内部会调用TransactionAspectSupport.invokeWithinTransaction。

// TransactionAspectSupport.java (简化版)
private Object invokeWithinTransaction(Method method, @Nullable Class<?> targetClass, 
        final InvocationCallback invocation) throws Throwable {
    
    // 1. 解析事务属性
    TransactionAttributeSource tas = getTransactionAttributeSource();
    TransactionAttribute txAttr = (tas != null ? tas.getTransactionAttribute(method, targetClass) : null);
    
    // 2. 确定事务管理器
    TransactionManager tm = determineTransactionManager(txAttr);
    
    // 3. 关键：获取事务对象（此处决定传播行为）
    if (txAttr != null && tm instanceof PlatformTransactionManager) {
        PlatformTransactionManager ptm = (PlatformTransactionManager) tm;
        // 如果调用点在事务中，则获取当前线程绑定的TransactionInfo
        TransactionInfo txInfo = createTransactionIfNecessary(ptm, txAttr, joinpointIdentification);
        Object retVal = null;
        try {
            // 4. 执行目标方法
            retVal = invocation.proceedWithInvocation();
        } catch (Throwable ex) {
            // 5. 异常时回滚
            completeTransactionAfterThrowing(txInfo, ex);
            throw ex;
        } finally {
            // 6. 清理TransactionInfo
            cleanupTransactionInfo(txInfo);
        }
        // 7. 正常提交
        commitTransactionAfterReturning(txInfo);
        return retVal;
    }
}

传播行为在AbstractPlatformTransactionManager中的落地

真正决定传播行为逻辑的是AbstractPlatformTransactionManager.getTransaction()方法。以最常用的REQUIRED为例：

// AbstractPlatformTransactionManager.java (关键逻辑)
public final TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException {
    
    // 查找当前线程是否存在事务
    Object transaction = doGetTransaction();
    
    if (definition == null) {
        definition = new DefaultTransactionDefinition();
    }
    
    // 关键：判断当前是否存在事务
    if (isExistingTransaction(transaction)) {
        // 存在事务时，根据传播行为决定策略
        return handleExistingTransaction(definition, transaction, debugEnabled);
    }
    
    // 不存在事务时，判断传播行为是否允许新建
    if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||
        definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||
        definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
        // 挂起当前事务（如果有）
        SuspendedResourcesHolder suspendedResources = suspend(transaction);
        // 开启新事务
        return startTransaction(definition, transaction, debugEnabled, suspendedResources);
    } else {
        // 其他传播行为（如SUPPORTS、NOT_SUPPORTED）走非事务路径
        // ...
    }
}

private TransactionStatus handleExistingTransaction(...) {
    switch (definition.getPropagationBehavior()) {
        case TransactionDefinition.PROPAGATION_REQUIRES_NEW:
            // 挂起当前事务，创建新事务
            SuspendedResourcesHolder suspendedResources = suspend(transaction);
            return startTransaction(definition, transaction, debugEnabled, suspendedResources);
        case TransactionDefinition.PROPAGATION_NESTED:
            // 关键：NESTED使用Savepoint机制
            if (useSavepointForNestedTransaction()) {
                // 创建保存点，后续可回滚到此
                DefaultTransactionStatus status = newTransactionStatus(...);
                status.createAndHoldSavepoint();
                return status;
            }
        // REQUIRED 直接复用当前事务
    }
}

事务传播的核心时序

下面用mermaid图展示REQUIRES_NEW传播行为的完整时序：

sequenceDiagram participant A as ServiceA.methodA() participant P as TransactionInterceptor participant TM as PlatformTransactionManager participant C as Connection participant B as ServiceB.methodB() A->>P: 调用methodA P->>TM: getTransaction(REQUIRED) TM->>C: 获取连接，开启事务 C-->>TM: 返回事务连接 TM-->>P: 返回TransactionStatus P->>A: 执行方法体 A->>B: 调用methodB (REQUIRES_NEW) B->>P: 进入新拦截器 P->>TM: getTransaction(REQUIRES_NEW) TM->>C: 挂起当前连接 TM->>C: 获取新连接，开启新事务 C-->>TM: 返回新事务连接 TM-->>P: 返回新TransactionStatus P->>B: 执行方法体 B-->>P: 返回结果 P->>TM: commit(新事务) TM->>C: 提交并释放新连接 TM->>C: 恢复挂起的原连接 A-->>P: 方法返回 P->>TM: commit(原事务) TM->>C: 提交原事务

事务同步管理器：ThreadLocal的巧妙运用

Spring通过TransactionSynchronizationManager将事务资源绑定到当前线程，这是事务传播实现的基石：

public abstract class TransactionSynchronizationManager {
    // 维护当前线程的事务资源（Connection、EntityManager等）
    private static final ThreadLocal<Map<Object, Object>> resources = new NamedThreadLocal<>("Transactional resources");
    // 维护当前线程的事务同步器列表
    private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations = new NamedThreadLocal<>("Transaction synchronizations");
    // 维护当前线程的事务名称、只读状态、隔离级别等
    private static final ThreadLocal<TransactionInfo> currentTransactionInfo = new NamedThreadLocal<>("Current transaction");
    
    // 绑定资源到当前线程
    public static void bindResource(Object key, Object value) {
        Map<Object, Object> map = resources.get();
        if (map == null) {
            map = new HashMap<>();
            resources.set(map);
        }
        map.put(key, value);
    }
}

正是这种ThreadLocal机制，使得同一线程内的多次方法调用可以共享同一个数据库连接，从而实现事务的传播。当传播行为要求REQUIRES_NEW时，Spring会挂起当前的资源绑定，建立新的绑定。

事务失效场景的根源剖析

理解了源码机制后，事务失效的场景就变得清晰可循了。以下是生产环境中最常见的5大类失效场景：

场景一：自调用（内部方法调用）

这是最经典的失效场景。Spring的@Transactional基于代理实现，当类内部方法调用时，走的是this.method()，相当于绕过了代理对象，事务拦截器根本不会执行。

@Service
public class OrderService {
    
    public void createOrder(Order order) {
        // 调用内部方法，事务失效！
        this.updateStock(order.getProductId());
        this.insertOrder(order);
    }
    
    @Transactional
    public void updateStock(Long productId) {
        // 期望在事务中执行
        productDao.decreaseStock(productId);
    }
    
    @Transactional
    public void insertOrder(Order order) {
        orderDao.insert(order);
    }
}

解决方案：注入自身代理，或者将事务方法拆分到另一个Bean中。

场景二：异常被吞掉

@Transactional
public void processOrder(Order order) {
    try {
        updateStock(order);
        insertOrder(order);
    } catch (Exception e) {
        // 异常被捕获，事务不会回滚！
        log.error("处理订单失败，但事务不会回滚", e);
    }
}

Spring默认只对RuntimeException和Error回滚。如果异常被捕获且未重新抛出，事务自然无法感知失败。

场景三：非RuntimeException默认不回滚

@Transactional
public void processOrder(Order order) throws Exception {
    updateStock(order);  // 执行成功
    insertOrder(order);  // 抛出SQLException（受检异常）
    // 默认情况下，受检异常不会触发回滚！
}

场景四：传播行为与ORPHAN事务

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void updatePoint(Long userId, int points) {
    // 这个方法的调用方如果自己也在事务中，其事务会被挂起
    // 若这里出现异常，只会回滚这个新事务，外层事务不受影响
}

场景五：数据库引擎不支持事务

// MySQL的MyISAM引擎不支持事务，即使标注了@Transactional也无济于事

实战代码示例

示例一：传播行为REQUIRED与REQUIRES_NEW的协作

/**
 * 场景：用户下单后，扣减库存（主事务），赠送积分（独立子事务）
 * 需求：如果赠送积分失败，不应该影响库存扣减的提交
 * 反之，如果库存扣减失败，积分赠送也需要回滚
 */
@Service
public class OrderService {
    
    private final InventoryService inventoryService;
    private final PointService pointService;
    private final OrderRepository orderRepository;
    
    @Transactional(rollbackFor = Exception.class)
    public void createOrder(Order order) {
        // 1. 保存订单（主事务）
        orderRepository.save(order);
        
        try {
            // 2. 扣减库存（REQUIRED，加入主事务）
            inventoryService.decreaseStock(order.getProductId(), order.getQuantity());
            
            // 3. 赠送积分（REQUIRES_NEW，独立新事务）
            // 即使积分赠送失败回滚，也不会影响主事务
            pointService.addPoints(order.getUserId(), order.calculatePoints());
        } catch (Exception e) {
            // 此处捕获异常，如果库存或订单有问题，仍会回滚主事务
            // 但积分赠送的REQUIRES_NEW事务已经独立提交
            log.error("处理订单失败，尝试补偿积分", e);
            // 可以使用消息队列做最终一致性补偿
        }
    }
}

@Service
public class PointService {
    
    /**
     * 使用REQUIRES_NEW开启独立事务
     * 注意：此处如果抛出异常，不会影响调用方的事务
     */
    @Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class)
    public void addPoints(Long userId, int points) {
        // 模拟积分操作
        pointRepository.increment(userId, points);
        // 模拟可能失败的情况
        if (points > 1000) {
            throw new IllegalArgumentException("积分超出限制");
        }
    }
}

示例二：NESTED传播与保存点回滚

/**
 * 场景：批量处理订单，希望单个订单失败不影响整体，但能记录失败状态
 */
@Service
public class BatchOrderService {
    
    private final OrderRepository orderRepository;
    
    /**
     * 外层事务：REQUIRED
     */
    @Transactional(rollbackFor = Exception.class)
    public void batchProcess(List<Order> orders) {
        for (Order order : orders) {
            try {
                // 使用REQUIRES_NEW会让每个订单独立提交，性能较慢
                // 使用NESTED则可以通过保存点回滚单个订单
                processSingleOrder(order);
            } catch (Exception e) {
                // 捕获异常，继续处理下一个订单
                // 由于NESTED使用保存点，此处的回滚不会影响外层其他订单
                order.setStatus(OrderStatus.FAILED);
                order.setErrorMsg(e.getMessage());
                orderRepository.save(order);  // 保存失败状态
            }
        }
        // 如果外层事务提交，所有成功处理的订单一起提交
    }
    
    /**
     * NESTED：在调用点创建保存点，失败时回滚到保存点
     * 而非回滚整个外层事务
     */
    @Transactional(propagation = Propagation.NESTED)
    public void processSingleOrder(Order order) {
        // 处理订单逻辑，如状态流转、库存操作等
        order.setStatus(OrderStatus.PROCESSING);
        orderRepository.save(order);
        
        // 模拟可能出现的部分失败
        if (order.getAmount() < 0) {
            throw new IllegalArgumentException("订单金额异常");
        }
        order.setStatus(OrderStatus.SUCCESS);
        orderRepository.save(order);
    }
}

性能提示：NESTED依赖数据库的Savepoint特性，在MySQL中使用SAVEPOINT语句，性能开销比REQUIRES_NEW小，但比纯REQUIRED大。适用于批量处理且需要部分回滚的场景。

示例三：事务失效的完整修复方案

/**
 * 修复示例：展示如何正确使用事务，避免自调用和内部方法问题
 */
@Service
public class TransactionFixDemo {
    
    // 方法一：注入自身代理（循环依赖解决方式之一）
    @Autowired
    private TransactionFixDemo selfProxy;  // Spring Boot 2.6+ 默认禁止循环依赖
    
    // 方法二（推荐）：拆分为两个Bean，通过AOP代理调用
    private final ExternalPointService externalPointService;
    
    public TransactionFixDemo(ExternalPointService externalPointService) {
        this.externalPointService = externalPointService;
    }
    
    /**
     * 正确示例：确保事务方法通过代理调用
     */
    @Transactional(rollbackFor = Exception.class)
    public void correctTransactionFlow(Order order) {
        // 1. 先执行主业务逻辑
        orderRepository.save(order);
        
        // 2. 调用外部Bean的事务方法（通过代理，事务生效）
        externalPointService.addPointsWithTransaction(order.getUserId(), 100);
        
        // 3. 如果在同一个类中，使用selfProxy调用
        // selfProxy.internalStockOperation(order);
    }
    
    /**
     * 正确示例：指定rollbackFor处理受检异常
     */
    @Transactional(rollbackFor = Exception.class)
    public void processWithCheckedException() throws Exception {
        // 业务逻辑
        try {
            // 可能会抛出受检异常
            externalApi.call();
        } catch (Exception e) {
            // 记录日志后重新抛出，触发回滚
            log.error("调用外部API失败", e);
            throw new RuntimeException("业务处理失败", e); // 包装为RuntimeException
        }
    }
    
    /**
     * 正确示例：事务边界与异步任务
     */
    @Transactional
    public void transactionWithAsync() {
        // 事务内同步操作
        orderRepository.updateStatus(1L, OrderStatus.PROCESSING);
        
        // 注意：异步方法无法参与当前事务！
        // 如果需要异步且事务，必须在异步方法内自行开启事务
        asyncNotificationService.sendNotification(1L);
    }
}

@Service
public class ExternalPointService {
    
    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
    public void addPointsWithTransaction(Long userId, int points) {
        pointRepository.increment(userId, points);
    }
}

示例四：编程式事务的兜底方案

当声明式事务遇到自调用、动态代理失效等棘手问题时，编程式事务是最后的兜底方案：

/**
 * 编程式事务示例：在极端情况下确保事务控制
 */
@Service
public class ProgrammaticTransactionDemo {
    
    private final TransactionTemplate transactionTemplate;
    
    public ProgrammaticTransactionDemo(PlatformTransactionManager transactionManager) {
        // 可以基于DataSourceTransactionManager构造
        this.transactionTemplate = new TransactionTemplate(transactionManager);
        // 设置传播行为
        this.transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
        // 设置隔离级别
        this.transactionTemplate.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITTED);
    }
    
    public void executeWithTransaction() {
        // 使用编程式事务，可以完全控制事务边界
        transactionTemplate.execute(status -> {
            try {
                // 业务逻辑
                orderRepository.save(order);
                pointRepository.increment(userId, points);
                return null;
            } catch (Exception e) {
                // 设置回滚标记
                status.setRollbackOnly();
                throw e;
            }
        });
    }
}

方案对比：声明式事务 vs 编程式事务 vs 分布式事务

维度	声明式事务	编程式事务	分布式事务
使用方式	@Transactional注解	TransactionTemplate	Seata、TCC等中间件
代码侵入性	低，注解声明即可	中等，需编写模板代码	高，需引入额外依赖
事务粒度	方法级别	代码块级别	跨服务级别
性能开销	低	低	高（需协调者参与）
适用场景	单体应用，大部分业务	需要细粒度控制，或解决失效问题	微服务跨库一致性
失效风险	存在自调用、异常捕获等失效源	无失效可能	依赖中间件稳定性
回滚粒度	整个方法	代码块	整个全局事务

最佳实践与避坑指南

黄金准则

1. 事务方法必须是public：Spring AOP只对public方法生效
2. 统一配置rollbackFor = Exception.class：避免受检异常不回滚的坑
3. 事务方法尽量通过代理调用：避免自调用导致失效
4. 事务方法内避免长时间外部RPC调用：长事务会持有数据库连接，可能导致连接池耗尽
5. 合理设置事务超时时间：@Transactional(timeout = 5)防止慢SQL拖垮系统

避坑清单

• 坑1：事务方法内部使用this调用 → 拆分类或注入自身代理

• 坑2：catch住异常不抛出 → 要么重新抛出，要么手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()

• 坑3：方法内部开启新线程执行事务方法 → 新线程没有事务上下文，需手动传播

• 坑4：使用@Transactional在接口上 → 可能被JDK动态代理忽略，放在实现类上保险

• 坑5：事务方法内进行集合操作后修改对象 → 确保在事务提交前完成所有写操作

总结

Spring事务传播行为是构建可靠数据一致性的基石。通过深入源码，我们理解了传播行为本质上是TransactionInterceptor与TransactionSynchronizationManager基于ThreadLocal的协作结果。REQUIRED复用当前事务，REQUIRES_NEW挂起旧事务，NESTED利用Savepoint实现部分回滚——这些机制共同构成了Spring事务的灵活性。

同时，事务失效的根源大多在于Spring的AOP代理特性：自调用绕过代理、异常被吞、受检异常默认不回滚等。理解这些失效场景后，开发者可以从容应对，通过拆分类、注入代理、编程式事务等方案进行修复。

延伸思考：在如今的微服务时代，本地事务已经无法解决跨服务的数据一致性。你是否思考过，如何将Spring的传播行为思想应用到分布式事务的设计中？Saga模式中的“子事务”与REQUIRES_NEW是否有异曲同工之妙？这些问题的探索，将帮助你在架构设计的道路上走得更远。