Spring 的 ApplicationEventPublisher 默认以同步方式调用监听器（即发布线程阻塞等待），但若配置了异步事件多播器（如 SimpleApplicationEventMulticaster 启用了 taskExecutor），则监听器将异步执行，导致发布方法不等待。本文详解原因及同步保障方案。

spring 的 `applicationeventpublisher` 默认以同步方式调用监听器（即发布线程阻塞等待），但若配置了异步事件多播器（如 `simpleapplicationeventmulticaster` 启用了 `taskexecutor`），则监听器将异步执行，导致发布方法不等待。本文详解原因及同步保障方案。

在 Spring 中，事件发布默认是同步的——也就是说，publishEvent() 调用会阻塞当前线程，直到所有注册的同步监听器执行完毕。你观察到的“发布方法未等待监听器”现象，并非 Spring 行为变更导致的 bug，而是项目中意外启用了异步事件多播器（常见于升级 Spring Boot 或显式配置了 taskExecutor）。

? 根本原因：异步多播器被激活

Spring 的事件广播由 ApplicationEventMulticaster 实现，默认使用 SimpleApplicationEventMulticaster。该类在以下任一情况下会转为异步执行：

• 显式为其注入了 TaskExecutor（例如 @Async 相关配置影响了它）；
• Spring Boot 2.3+ 中，若存在 TaskExecutor Bean 且未显式配置多播器，部分自动配置可能触发异步行为；
• 自定义 ApplicationEventMulticaster Bean 时误设了 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 注解替代接口实现。
同步语义应由基础设施保障，而非业务代码补偿。