Java Transactional 自调用 怎样处理

如果一个 Spring Bean 的方法带了 @Transactional，另一个同类方法却用 this.save() 调用它，事务很可能没有生效。关键不在注解有没有写上，而在调用有没有穿过 Spring 创建的代理：默认的 proxy 模式只拦截从代理对象进入的外部调用，同一个目标对象里的自调用会直接落到目标方法。

官方地址：https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/annotations.html

最稳妥的处理是把独立事务边界拆到另一个 Spring Bean，由外部 Bean 通过代理调用它。若必须保持同类结构，可以显式拿到代理对象或改用 TransactionTemplate；只有确实需要拦截类内部调用时，才评估 AspectJ 编织。

先看清楚：为什么 this 调用会绕过事务

声明式事务依赖 AOP 代理。容器里的调用对象通常可以理解为“代理对象”，代理在进入目标方法前执行事务拦截器，然后再决定提交或回滚。外部代码拿到的是代理，因而能触发拦截。

但目标对象内部的 this.save() 是普通 Java 调用。它既没有回到容器，也没有经过代理，所以 save() 上的事务传播级别、只读属性和回滚规则不会因为这次调用而单独建立。Spring 官方文档把这种情况称为 self-invocation，并明确说明默认 proxy 模式只处理通过代理进入的调用。

下面的代码故意保留这个边界。外部调用 createOrder() 可以穿过代理，但其中的 this.writeDetail() 不会再次穿过代理：

@Service
public class OrderService {
    @Transactional
    public void createOrder(OrderCommand command) {
        // 这里是从代理进入的事务入口
        orderRepository.insertOrder(command);

        // 这是同一个目标对象内的普通 Java 调用，不会再次经过代理
        this.writeDetail(command);
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void writeDetail(OrderCommand command) {
        // REQUIRES_NEW 只有在调用真正穿过事务代理时才有机会生效
        detailRepository.insert(command);
    }
}

因此，不能只看注解或方法名判断事务是否生效。要先确认三个条件：这个类确实是 Spring Bean；事务管理已经启用；调用路径从另一个 Bean、控制器或其他外部对象进入代理，而不是在目标对象内部通过 this 直达方法。

首选方案：把事务方法拆到另一个 Bean

最容易维护的改法是让“编排流程”和“独立事务边界”分开。OrderService 只负责组织业务，OrderWriteService 负责需要被代理拦截的写操作。两个 Bean 之间的调用会经过 Spring 代理，传播级别也有明确的归属。

@Service
public class OrderService {
    private final OrderWriteService orderWriteService;

    public OrderService(OrderWriteService orderWriteService) {
        // 通过构造器注入，依赖关系和事务边界都更清晰
        this.orderWriteService = orderWriteService;
    }

    public void createOrder(OrderCommand command) {
        // 外部调用进入 OrderService 后，再通过另一个 Bean 的代理进入写操作
        orderWriteService.writeDetail(command);
    }
}

@Service
public class OrderWriteService {
    @Transactional
    public void writeDetail(OrderCommand command) {
        // 事务边界放在独立 Bean 上，调用关系不会被 this 隐藏
        detailRepository.insert(command);
    }
}

如果外层方法本身也需要事务，可以在外层声明默认的 REQUIRED，让内层加入已有事务；如果内层需要 REQUIRES_NEW，也能明确表达“挂起外层、单独处理”的意图。拆分不等于一定要增加很多类，关键是把需要被拦截的方法放在调用者拿到的另一个代理对象上。

必须保持同类结构时，怎么显式走代理

有些遗留服务不适合马上拆分。这时可以让 Bean 注入自己的代理，再通过代理调用事务方法。下面的写法能工作，但它把代理语义写进了业务类，容易造成循环依赖、测试替身不自然或阅读者误以为 this 与代理等价，因此只适合作为过渡方案。

@Service
public class LegacyOrderService {
    private final LegacyOrderService proxy;

    public LegacyOrderService(@Lazy LegacyOrderService proxy) {
        // Lazy 用来延后取代理，避免构造阶段立即形成循环依赖
        this.proxy = proxy;
    }

    public void createOrder(OrderCommand command) {
        // 这里明确调用代理，而不是使用 this.writeDetail(command)
        proxy.writeDetail(command);
    }

    @Transactional
    public void writeDetail(OrderCommand command) {
        // 只有 proxy.writeDetail 才会进入事务拦截器
        detailRepository.insert(command);
    }
}

另一种常见写法是使用 AopContext.currentProxy()。它依赖开启暴露代理，并且只有在当前调用已经处于代理拦截链时才可用；把它散落在业务代码里会让方法依赖运行时上下文，所以通常不如拆分 Bean 直观。无论选择哪种方式，都不要在构造器、字段初始化或 @PostConstruct 阶段依赖一个尚未完全初始化的代理。

事务只是一个局部动作时，改用 TransactionTemplate

如果需求不是“让某个方法自动拥有事务”，而是“在流程中的一小段代码明确开启、提交并处理异常”，TransactionTemplate 往往更直接。它不依赖同类方法是否穿过 AOP 代理，事务边界就在代码块里。

@Service
public class ImportService {
    private final TransactionTemplate transactionTemplate;

    public ImportService(PlatformTransactionManager transactionManager) {
        // 使用应用已经配置的事务管理器创建模板
        this.transactionTemplate = new TransactionTemplate(transactionManager);
    }

    public void importOne(ImportCommand command) {
        transactionTemplate.executeWithoutResult(status -> {
            // 事务范围明确限定在这个回调中，避免依赖 self-invocation
            repository.insert(command);

            if (command.shouldReject()) {
                // 标记回滚后仍由模板负责结束事务
                status.setRollbackOnly();
            }
        });
    }
}

这种方式适合批处理中的单条落库、需要动态决定是否回滚的局部操作，以及不值得为了一个事务边界再拆 Bean 的代码。代价是事务控制代码更显式，调用者需要自己理解回滚条件，不能把它当成完全声明式的替代品。

什么时候考虑 AspectJ

Spring 文档给出的另一条路径是 AspectJ 模式。它不是创建代理后等待外部调用，而是通过编织修改目标类，使事务切面可以作用于类内部调用。这样可以覆盖 self-invocation，但需要引入 spring-aspects，并配置编译期或加载期编织，构建和排查成本都会上升。

@Configuration
@EnableTransactionManagement(mode = AdviceMode.ASPECTJ)
public class TransactionConfig {
    // AspectJ 模式需要额外的编织配置，不能只添加这一行就算完成迁移
}

因此，AspectJ 更适合已经采用编织体系、确实要求类内部调用也具备事务语义的项目。对普通 Spring Boot 服务，先拆 Bean 或使用 TransactionTemplate 通常更容易让团队理解和维护。不要为了修一个自调用问题，直接把整个项目切换到更复杂的拦截模型。

改完后重点检查哪些边界

还要检查异常类型和事务传播设置。默认回滚规则、REQUIRED 与 REQUIRES_NEW 的行为，只有在事务拦截器确实介入后才有意义；如果调用依旧是 this.method()，单纯修改注解参数不会修复代理绕过问题。

结语：先定位代理边界，再选改法

Java 中的自调用本身没有问题，问题是它绕过了 Spring 默认的代理入口。把事务方法拆到独立 Bean，是可读性和可维护性最平衡的方案；显式代理适合短期兼容，TransactionTemplate 适合局部编程式事务，AspectJ 则留给确有编织需求的工程。

相关问题

• 为什么加了 REQUIRES_NEW 还是没有新事务？ 先检查调用是否通过代理；自调用绕过拦截器时，传播级别没有机会执行。
• 把 @Transactional 放在接口上可以吗？ 优先标注具体类和具体方法，并确认项目使用的代理或 AspectJ 模式与注解解析方式一致。
• 为什么事务在 @PostConstruct 中表现异常？ Bean 可能尚未完成代理初始化，不应把初始化阶段当作正常的事务入口。

参考资料

https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/annotations.html

https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/tx-decl-explained.html