Spring 的 ApplicationEventPublisher 默认以同步方式调用监听器（即发布线程阻塞等待），但若配置了异步事件多播器（如 SimpleApplicationEventMulticaster 启用了 taskExecutor），则监听器将异步执行，导致发布方法不等待。本文详解原因及同步保障方案。
spring 的 `applicationeventpublisher` 默认以同步方式调用监听器（即发布线程阻塞等待），但若配置了异步事件多播器（如 `simpleapplicationeventmulticaster` 启用了 `taskexecutor`），则监听器将异步执行，导致发布方法不等待。本文详解原因及同步保障方案。
在 Spring 中，事件发布默认是同步的——也就是说，publishEvent() 调用会阻塞当前线程，直到所有注册的同步监听器执行完毕。你观察到的“发布方法未等待监听器”现象，并非 Spring 行为变更导致的 bug，而是项目中意外启用了异步事件多播器（常见于升级 Spring Boot 或显式配置了 taskExecutor）。
? 根本原因：异步多播器被激活
Spring 的事件广播由 ApplicationEventMulticaster 实现，默认使用 SimpleApplicationEventMulticaster。该类在以下任一情况下会转为异步执行：
- 显式为其注入了
TaskExecutor（例如@Async相关配置影响了它）； - Spring Boot 2.3+ 中，若存在
TaskExecutorBean 且未显式配置多播器，部分自动配置可能触发异步行为； - 自定义
ApplicationEventMulticasterBean 时误设了setTaskExecutor()。
此时 publishEvent() 仅将事件提交至线程池，立即返回，监听器在后台线程执行 → 输出顺序变为你所见的“先结束发布、后执行监听”。
✅ 正确做法：强制同步执行（推荐）
方案 1：禁用多播器的异步能力（最稳妥）
在 Project 1（发布端） 的配置类中，显式定义一个无 TaskExecutor 的 SimpleApplicationEventMulticaster：
@Configuration
public class EventConfig {
@Bean
public ApplicationEventMulticaster applicationEventMulticaster() {
SimpleApplicationEventMulticaster multicaster = new SimpleApplicationEventMulticaster();
// 关键：不设置 taskExecutor，确保严格同步
return multicaster;
}
}
⚠️ 注意：该 Bean 必须定义在事件发布方所在的 ApplicationContext 中（即 Project 1）。若 Project 2 是独立的上下文（如通过
@Import或模块化加载），需确保事件机制共享同一上下文，或改用跨上下文通信方案（如 Spring Cloud Stream）。
方案 2：使用 @EventListener + @TransactionalEventListener（更现代）
替代原始 ApplicationListener 接口，改用注解式监听，并确保其同步性：
@Component
public class MyConfig {
@EventListener
public void handleConfigEvent(ConfigEvent event) {
System.out.println("Start of Event listener");
// 模拟业务逻辑
System.out.println("End of Event listener");
}
}
只要未配置异步多播器，@EventListener 默认同步执行，且支持更多语义（如事务绑定）。
? 不推荐的做法
- ❌ 在监听器内手动
Thread.sleep()或CountDownLatch等待 —— 违背事件解耦原则，易引发死锁或资源耗尽； - ❌ 使用
@Async强制异步再回调 —— 增加复杂度，丧失事件模型初衷； - ❌ 依赖 Spring 版本回退 —— 问题根源是配置，非版本缺陷。
✅ 验证是否生效
添加日志并观察输出顺序。正确配置后，控制台将稳定输出：
Before publish Start of Event listener End of Event listener After publish End of publisher
总结
Spring 事件机制本身设计为同步阻塞，所谓“不等待”本质是多播器被意外异步化。解决核心在于：
① 检查是否存在全局 TaskExecutor 干扰；
② 显式声明无 taskExecutor 的 SimpleApplicationEventMulticaster；
③ 优先采用 @EventListener 注解替代接口实现。
同步语义应由基础设施保障，而非业务代码补偿。
