从订单创建说起：事件机制要解决什么问题
在订单服务中，创建订单后往往需要同时发送通知、更新统计信息。如果把这些操作直接写在订单创建的 service 方法里，代码会变得臃肿，而且一旦通知服务或统计服务出现故障，可能会影响主流程。Spring 的事件发布机制允许订单服务只发布一个“订单已创建”事件，由专门的监听器去处理通知和统计，从而降低耦合。
但事件机制不是没有代价。默认情况下，Spring 的事件发布是同步的，也就是说，publishEvent 方法会阻塞，直到所有监听器执行完毕。如果监听器里做了耗时操作（比如调用外部通知 API），订单创建的接口响应时间会被拉长。更关键的是，如果监听器在事务提交之前执行，而监听器本身又去访问数据库，它看到的数据可能还是未提交的状态，这会导致数据不一致。
本文以订单创建后发送通知、更新统计为贯穿场景，分析 Spring 事件发布的调用链、事务绑定监听器的执行阶段，以及异步监听器与事务事件结合时的常见陷阱。
同步发布：publishEvent 的调用链
Spring 的事件发布入口是 ApplicationEventPublisher 接口，ApplicationContext 实现了该接口。当调用 publishEvent 时，实际上会进入 AbstractApplicationContext 的 publishEvent 方法，最终委托给 ApplicationEventMulticaster 的 multicastEvent 方法。
默认情况下，Spring 使用的多播器是 SimpleApplicationEventMulticaster，它没有配置 Executor，因此会在当前线程中直接调用监听器。这意味着，publishEvent 返回时，所有监听器已经执行完毕。
下面是一个典型的事件发布代码：
@Service
public class OrderService {
@Autowired
private ApplicationEventPublisher publisher;
@Transactional
public void createOrder(Order order) {
// 保存订单到数据库
orderDao.insert(order);
// 发布订单创建事件
publisher.publishEvent(new OrderCreatedEvent(order));
}
}这里的 publishEvent 调用是同步的，监听器在同一个线程、同一个事务中执行。如果监听器抛出异常，异常会传播回 createOrder 方法，导致事务回滚。这是同步事件的一个重要特点：监听器的失败会影响主流程。
监听器的注册与匹配
Spring 支持两种注册监听器的方式：实现 ApplicationListener 接口，或使用 @EventListener 注解。
实现接口的方式很直接，监听器类实现 ApplicationListener
使用 @EventListener 注解更灵活，它可以直接标注在任意方法上，方法参数声明要监听的事件类型。Spring 内部通过 EventListenerMethodProcessor 这个 BeanFactory 后置处理器，在单例 Bean 实例化后扫描所有 Bean，找到带有 @EventListener 的方法，将其包装成 ApplicationListenerMethodAdapter，然后注册到多播器。
多播器在广播事件时，会根据事件类型查找匹配的监听器。查找过程有缓存，第一次查找时会遍历所有已注册的监听器，根据泛型或注解参数进行匹配，之后缓存结果。
事务绑定监听器：@TransactionalEventListener
默认的 @EventListener 在事件发布时立即执行，此时如果发布方在事务中，监听器也在同一事务中。但有些场景希望监听器在事务提交之后再执行，比如发送通知，如果事务回滚了，通知就不应该发送。Spring 提供了 @TransactionalEventListener 注解，可以将监听器的执行绑定到事务的特定阶段。
@TransactionalEventListener 的 phase 属性指定绑定阶段，默认是 AFTER_COMMIT，即在事务提交后执行。其他可选值包括 AFTER_ROLLBACK、AFTER_COMPLETION 和 BEFORE_COMMIT。
当事件发布时，如果当前没有事务，默认情况下监听器不会执行，除非设置 fallbackExecution = true。
下面是一个使用 @TransactionalEventListener 的示例：
@Component
public class OrderNotificationListener {
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onOrderCreated(OrderCreatedEvent event) {
// 发送通知
notificationService.send(event.getOrder());
}
}这里的关键点是，监听器在事务提交后执行，但它仍然运行在发布事件的线程中。如果监听器内部访问数据库，它会“参与”到原事务中，但此时事务已经提交，所以任何数据修改都不会被提交。实际上，Spring 文档明确警告：在 AFTER_COMMIT 阶段，事务资源可能仍然活跃，但数据访问代码的更改不会提交。因此，在事务监听器中应避免进行写操作，只做读操作或外部调用。
异步监听器：@Async 与事务的冲突
为了不阻塞主流程，可以将监听器设置为异步执行。Spring 支持在 @EventListener 方法上添加 @Async 注解，使其在单独的线程中执行。但异步监听器与事务事件结合时会产生问题。
首先，异步监听器默认不参与发布方的事务。如果监听器需要读取数据库，它可能看不到事务中尚未提交的数据。对于 @TransactionalEventListener，如果监听器是异步的，那么它会在事务提交后由另一个线程执行，此时数据已经提交，读取没问题，但事务上下文（ThreadLocal 中的事务）不会传递到新线程。
其次，异步监听器的异常不会影响主流程，因为它在另一个线程中抛出。这可能导致通知发送失败但订单创建成功，造成数据不一致。
Spring 文档指出，从 6.1 开始，事务事件监听器可以处理由 PlatformTransactionManager 管理的线程绑定事务，以及由 ReactiveTransactionManager 管理的响应式事务。对于响应式事务，事务上下文存储在 Reactor 上下文中，而不是线程本地变量中，因此需要将事务上下文包含在发布的事件实例中，参见 TransactionalEventPublisher。
实际场景：订单创建后的通知与统计
我们回到订单创建场景。假设 OrderService.createOrder 方法上有 @Transactional，它保存订单后发布 OrderCreatedEvent。我们希望：
- 发送通知（外部调用）在事务提交后执行，避免事务回滚时误发通知。
- 更新统计信息（数据库操作）在事务提交后执行，并且能够在独立事务中提交，避免“参与”原事务导致的不提交问题。
如果使用 @TransactionalEventListener 同步执行，监听器在提交后运行，但仍在原线程，如果监听器内调用统计服务更新数据库，由于事务已提交，更新操作不会提交，这会导致统计丢失。
解决方案是让统计更新监听器在独立事务中运行。可以给监听器方法添加 @Transactional(propagation = Propagation.REQUIRES_NEW)，这样它会挂起原事务（如果存在），开启新事务，提交后不影响原事务。但注意，在 AFTER_COMMIT 阶段，原事务已经提交，此时 REQUIRES_NEW 会开启全新事务，可以正常提交。
对于通知发送，可以异步执行，但需要处理失败重试。
下面是一个改进的监听器：
@Component
public class OrderStatisticsListener {
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void updateStatistics(OrderCreatedEvent event) {
statisticsService.incrementOrderCount(event.getOrder().getUserId());
}
}这里 @Transactional 注解在监听器方法上，确保它在新事务中执行，避免“参与”已提交事务的问题。
执行流程与决策对比
下面用流程图展示订单创建后事件发布的完整流程，包括同步、异步、事务绑定的不同路径。
flowchart TD
A[OrderService.createOrder] --> B[保存订单到数据库]
B --> C[发布 OrderCreatedEvent]
C --> D{是否配置了异步执行器?}
D -- 否 --> E[SimpleApplicationEventMulticaster 同步调用监听器]
D -- 是 --> F[TaskExecutor 异步调用监听器]
E --> G[监听器执行]
F --> G
G --> H{监听器类型?}
H -- @EventListener --> I[立即执行，参与当前事务]
H -- @TransactionalEventListener --> J[根据事务阶段触发]
J --> K{是否在事务中?}
K -- 否 --> L{fallbackExecution?}
L -- 否 --> M[事件被丢弃]
L -- 是 --> N[立即执行]
K -- 是 --> O[注册到事务同步回调]
O --> P{事务阶段}
P -- BEFORE_COMMIT --> Q[提交前执行]
P -- AFTER_COMMIT --> R[提交后执行]
P -- AFTER_ROLLBACK --> S[回滚后执行]
P -- AFTER_COMPLETION --> T[完成时执行]
图中展示了同步与异步的分支，以及事务监听器的阶段绑定。关键转折点是：默认同步执行时，监听器与发布方在同一线程和事务中；异步执行时，监听器在独立线程，不参与原事务。
为了帮助决策，下表对比了不同监听器配置的适用场景和风险：
| 配置方式 | 执行时机 | 事务参与 | 异常影响 | 适用场景 | 风险 |
|---|---|---|---|---|---|
| @EventListener 同步 | 发布时立即执行 | 参与发布方事务 | 异常导致发布方回滚 | 需要与主流程强一致的操作，如更新同一事务内的数据 | 监听器耗时阻塞主流程 |
| @EventListener + @Async | 异步执行 | 不参与发布方事务 | 异常不影响主流程 | 不需要事务一致性的外部调用，如发送邮件 | 数据不一致，异常丢失 |
| @TransactionalEventListener 同步 | 事务提交后执行 | 不参与原事务（但可能访问已提交数据） | 异常不影响主流程（但可能影响其他监听器） | 需要在事务成功后执行的逻辑，如发送通知 | 监听器内写操作不会提交 |
| @TransactionalEventListener + REQUIRES_NEW | 事务提交后，新事务中执行 | 独立新事务 | 异常导致新事务回滚，不影响主流程 | 需要在事务成功后独立更新数据，如统计 | 额外事务开销 |
| @TransactionalEventListener + @Async | 事务提交后异步执行 | 不参与原事务 | 异常不影响主流程 | 对实时性要求不高的通知 | 事务上下文丢失，异常难以追踪 |
常见陷阱与诊断
陷阱一：事务监听器中的写操作不生效
如前面所述，在 AFTER_COMMIT 阶段，事务已提交，但事务资源可能仍绑定到当前线程。如果监听器直接使用 JdbcTemplate 或 JPA 进行写操作，这些操作会“参与”到原事务中，但原事务已提交，所以更改不会持久化。解决方法是使用 REQUIRES_NEW 开启新事务，或者将写操作封装在独立的事务中。
陷阱二：异步监听器的事务上下文丢失
当 @TransactionalEventListener 与 @Async 结合时，监听器在新线程中执行，ThreadLocal 中的事务信息不会传递。如果监听器需要访问数据库，它看到的是已提交的数据，但无法参与原事务。对于响应式事务，情况更复杂，需要将事务上下文放入事件中。
陷阱三：异步监听器的异常被吞没
异步监听器抛出的异常不会传播到发布方，可能只记录在日志中。如果通知发送失败，订单已经创建成功，导致用户未收到通知。可以通过引入消息队列、重试机制或补偿事务来解决。
诊断方法
- 在监听器方法中打印当前线程名称和事务状态，确认是否异步、是否在事务中。
- 使用 Spring 的 TransactionSynchronizationManager.isActualTransactionActive() 检查事务是否活跃。
- 对于异步监听器，确保配置了合适的 TaskExecutor，并监控线程池队列和拒绝策略。
- 在事务监听器中，如果发现数据未更新，检查是否由于“参与”已提交事务导致。
总结与适用边界
Spring 事件发布机制提供了同步和异步、事务绑定的多种执行方式，但每种方式都有其适用边界。同步监听器适合需要与主流程强一致的操作，但会增加响应时间；事务监听器适合在事务提交后执行，但要注意写操作不生效的问题；异步监听器适合外部调用，但需要处理异常和事务上下文丢失。
在实际项目中，应根据业务对一致性、延迟和可靠性的要求选择合适的配置。对于关键业务，建议使用事务监听器 + REQUIRES_NEW 或引入消息队列；对于非关键通知，可以使用异步监听器并配合重试机制。
理解事件发布的调用链和事务绑定语义，是避免数据不一致的关键。