在业务开发中，我们经常会遇到这样一种场景：
某段逻辑必须等数据库事务成功提交之后才能执行。
例如：
- 创建订单成功后发送消息；
- 用户注册成功后发送欢迎邮件；
- 数据落库成功后刷新缓存；
- 业务状态变更成功后通知外部系统；
- 事务提交后再发布领域事件。
这些逻辑看起来很简单，但如果执行时机不对，很容易引发数据不一致问题。
比如在一个事务方法中，我们先保存数据库，再发送 MQ 消息：
@Transactional
public void createOrder(CreateOrderCommand command) {
orderRepository.save(order);
mqProducer.send(orderCreatedMessage);
}
这段代码的问题在于：消息发送成功，并不代表数据库事务一定提交成功。
如果 mqProducer.send(...) 执行成功后，事务在提交阶段失败或被回滚，那么下游系统就会收到一条“订单已创建”的消息，但数据库里并没有这条订单记录。这就造成了典型的数据不一致。
因此，在很多场景下，我们真正想要的不是“业务代码执行到这里就发送消息”，而是：
只有当前事务成功提交之后，才执行后续逻辑。
一个简单的工具类
基于 Spring 的事务同步机制，我们可以封装一个工具方法：
import org.springframework.transaction.support.TransactionSynchronization;
import org.springframework.transaction.support.TransactionSynchronizationManager;
public final class TransactionUtils {
private TransactionUtils() {
}
/**
* 在当前事务成功提交后执行指定逻辑；如果当前没有真实事务，则立即执行。
*
* @param runnable 事务提交后需要执行的逻辑
*/
public static void runAfterCommit(Runnable runnable) {
if (TransactionSynchronizationManager.isSynchronizationActive()
&& TransactionSynchronizationManager.isActualTransactionActive()) {
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
@Override
public void afterCommit() {
runnable.run();
}
});
return;
}
runnable.run();
}
}
这个方法的语义非常明确：
- 如果当前线程中存在一个真实事务，则把逻辑注册到事务提交后的回调中；
- 如果当前没有真实事务，则直接执行这段逻辑。
使用方式如下：
@Transactional
public void createOrder(CreateOrderCommand command) {
Order order = orderRepository.save(command.toOrder());
TransactionUtils.runAfterCommit(() -> {
mqProducer.send(new OrderCreatedMessage(order.getId()));
});
}
这样一来，消息发送逻辑就不会在事务尚未提交时执行，而是会等到当前事务成功提交之后再执行。
为什么要判断两个状态？
代码中有两个判断：
TransactionSynchronizationManager.isSynchronizationActive()
&& TransactionSynchronizationManager.isActualTransactionActive()
这两个判断看起来有点相似，但含义并不完全一样。
1. isSynchronizationActive
isSynchronizationActive() 表示当前线程是否开启了事务同步机制。
事务同步机制可以理解为 Spring 提供的一套事务生命周期回调能力。只有同步机制处于激活状态时，才允许注册 TransactionSynchronization 回调。
如果没有激活事务同步，直接调用：
TransactionSynchronizationManager.registerSynchronization(...)
会抛出异常。
因此，第一个判断用于保证：
当前线程允许注册事务同步回调。
2. isActualTransactionActive
isActualTransactionActive() 表示当前线程是否真的存在一个实际事务。
这一步也很关键。
因为在某些情况下，事务同步可能是激活的，但并不代表当前一定存在真实的数据库事务。比如某些事务传播行为、只读上下文或框架内部同步场景，都可能出现“同步机制存在，但实际事务不存在”的情况。
而这个工具方法的语义是“事务提交后执行”。如果根本没有真实事务，就不存在所谓的“提交之后”。
所以第二个判断用于保证：
当前确实存在一个真实事务，afterCommit 回调才有意义。
两个条件同时成立时，才注册 afterCommit 回调。
为什么没有事务时要立即执行？
工具方法中还有一段兜底逻辑：
runnable.run();
也就是说，如果当前没有真实事务，就直接执行。
这是一种比较实用的设计。
原因是这个工具方法的调用方通常只关心：
这段逻辑不要早于事务提交执行。
如果当前本来就没有事务，那么就不存在“提交之后”的时机，也没有必要强行延迟执行。此时立即执行反而更符合直觉。
例如：
public void sendWelcomeMessage(Long userId) {
TransactionUtils.runAfterCommit(() -> {
messageService.sendWelcomeMessage(userId);
});
}
这个方法既可以在事务方法中调用，也可以在非事务方法中调用。
如果在事务中调用，它会延迟到事务提交后执行。
如果不在事务中调用，它会立即执行。
这让业务代码不需要关心当前是否处于事务上下文中，调用方式更加统一。
afterCommit 的语义
这里使用的是：
@Override
public void afterCommit() {
runnable.run();
}
afterCommit 的含义是：当前事务已经成功提交之后执行。
这和在业务方法末尾直接执行逻辑不同。
在 @Transactional 方法中，业务方法返回并不等于事务已经提交。Spring 的声明式事务通常是通过 AOP 实现的，事务提交发生在代理逻辑中，而不是业务方法内部的最后一行代码。
也就是说：
@Transactional
public void doSomething() {
businessOperation();
// 这里仍然处于事务方法内部
doAfterSomething();
}
doAfterSomething() 执行时，事务大概率还没有真正提交。
而通过 TransactionSynchronization 注册的 afterCommit()，执行时机是在事务提交成功之后，因此更适合处理依赖已提交数据的逻辑。
适合哪些场景？
这个工具方法适合处理“必须等事务成功之后才能执行”的副作用逻辑。
典型场景包括：
1. 发送 MQ 消息
TransactionUtils.runAfterCommit(() -> {
orderMessageProducer.sendOrderCreated(orderId);
});
避免数据库回滚但消息已经发出的情况。
2. 删除或刷新缓存
TransactionUtils.runAfterCommit(() -> {
cacheManager.evict(userCacheKey);
});
避免事务尚未提交时缓存被提前刷新，导致其他线程读到旧数据或不一致数据。
3. 调用外部系统
TransactionUtils.runAfterCommit(() -> {
externalApi.notifyStatusChanged(businessId);
});
外部系统一旦被调用，通常很难跟随本地事务一起回滚，因此更适合放在事务提交之后。
4. 发布领域事件
TransactionUtils.runAfterCommit(() -> {
domainEventPublisher.publish(new UserRegisteredEvent(userId));
});
领域事件的消费者通常会基于数据库中的最新状态进行处理，因此事件发布时机最好晚于事务提交。
需要注意的问题
虽然这个工具方法很实用，但它并不是万能的。
1. afterCommit 中的异常不会回滚原事务
事务已经提交成功之后，afterCommit() 才会执行。
因此，如果 runnable.run() 抛出异常，原事务已经无法回滚。
例如：
TransactionUtils.runAfterCommit(() -> {
mqProducer.send(message);
});
如果这里发送消息失败，数据库事务已经提交成功了。
所以，对于重要的后置逻辑，需要考虑失败补偿机制，例如：
- 记录本地消息表；
- 使用定时任务重试；
- 引入可靠消息机制；
- 对异常进行捕获和告警。
更稳妥的写法通常是：
TransactionUtils.runAfterCommit(() -> {
try {
mqProducer.send(message);
} catch (Exception ex) {
log.error("Send order created message failed, orderId={}", orderId, ex);
// 记录失败状态，等待后续补偿
}
});
2. 不适合承载太重的逻辑
afterCommit() 回调通常仍然发生在当前请求线程中。
如果在里面执行耗时逻辑，会拉长接口响应时间。
例如：
TransactionUtils.runAfterCommit(() -> {
reportService.generateLargeReport();
});
这种逻辑就不适合直接放在 afterCommit() 中执行。
更合理的方式是：事务提交后只投递一个异步任务或消息，由后台消费者继续处理。
TransactionUtils.runAfterCommit(() -> {
asyncTaskPublisher.publish(new GenerateReportTask(reportId));
});
3. 嵌套事务和传播行为需要谨慎理解
在复杂事务传播场景下，比如 REQUIRES_NEW、嵌套事务、多个事务边界交织时，afterCommit() 的触发时机取决于当前注册同步回调所绑定的事务上下文。
因此，在简单业务中使用该工具通常没有问题；但在复杂事务传播链路中，需要明确当前代码到底运行在哪个事务边界内。
4. 它不能替代分布式事务或可靠消息
这个工具方法解决的是“本地事务提交后再执行某段逻辑”的时机问题。
它不能保证：
- MQ 一定发送成功；
- 外部接口一定调用成功；
- 下游系统一定消费成功；
- 本地事务和远程系统操作具备原子性。
因此，对于强一致或高可靠场景，仍然需要使用更完整的方案，比如事务消息、本地消息表、Outbox Pattern 或 Saga 等。
可以进一步增强的版本
在实际项目中，可以对这个工具类做一些增强。
例如增加异常处理：
public static void runAfterCommit(Runnable runnable) {
if (TransactionSynchronizationManager.isSynchronizationActive()
&& TransactionSynchronizationManager.isActualTransactionActive()) {
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
@Override
public void afterCommit() {
try {
runnable.run();
} catch (Exception ex) {
// 这里可以统一记录日志
throw ex;
}
}
});
return;
}
runnable.run();
}
也可以支持自定义异常处理器：
public static void runAfterCommit(Runnable runnable, Consumer<Throwable> exceptionHandler) {
Runnable safeRunnable = () -> {
try {
runnable.run();
} catch (Throwable ex) {
exceptionHandler.accept(ex);
}
};
if (TransactionSynchronizationManager.isSynchronizationActive()
&& TransactionSynchronizationManager.isActualTransactionActive()) {
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
@Override
public void afterCommit() {
safeRunnable.run();
}
});
return;
}
safeRunnable.run();
}
这样可以避免业务方每次都手动写 try-catch。
小结
这个工具类虽然只有十几行代码，但它解决了一个非常常见的工程问题：如何保证某段副作用逻辑在事务成功提交之后再执行。
它的核心价值在于：
- 避免事务回滚后外部副作用已经发生；
- 统一事务内和非事务内的调用方式；
- 降低业务代码对事务上下文的感知；
- 让消息发送、缓存刷新、事件发布等逻辑拥有更准确的执行时机。
不过，它也需要配合正确的工程实践使用。
对于普通的事务后置逻辑，它简单、直接、够用。
对于涉及高可靠消息、跨系统一致性或复杂补偿的场景，则应该进一步结合本地消息表、事务消息、Outbox Pattern 等方案，构建更完整的可靠性机制。
一个好的工具方法，不一定要复杂。
有时候，十几行代码就能把一个隐蔽的时序问题封装得足够清晰。