Spring ApplicationEvent 是解决JVM内服务强耦合的最低成本方案,应优先用于日志、短信等非核心逻辑;事件用POJO定义,监听器用@EventListener注解,发布必须通过注入的ApplicationEventPublisher。

Spring 的 ApplicationEvent 机制不是“可选的优雅技巧”,而是解决服务内强耦合问题最直接、最低成本的路径——只要你的非核心逻辑(如日志、短信、统计)和主线业务跑在同一个 JVM 进程里,就该用它,而不是硬加 @Async 方法或手写线程池。
定义事件时别继承 ApplicationEvent(Spring 4.2+)
Spring 4.2 起支持 POJO 事件,无需再让事件类显式继承 ApplicationEvent。手动继承反而会限制灵活性,比如无法直接用 Lombok 的 @Data,也容易误传 source 参数导致空指针。
正确做法是定义一个纯数据类:
public class OrderCreatedEvent {
private final Long orderId;
private final String userId;
public OrderCreatedEvent(Long orderId, String userId) {
this.orderId = orderId;
this.userId = userId;
}
// getter...
}
Spring 会自动用 PayloadApplicationEvent 包装它。这样事件类更轻量,测试也更容易 mock。
监听器必须用 @EventListener 注解,别手写 ApplicationListener
直接实现 ApplicationListener 接口是老式写法,会导致泛型擦除、无法指定事件类型、难以做条件过滤,而且 Spring Boot 的条件监听(@EventListener(condition = "..."))完全失效。
推荐写法:
- 用
@EventListener标注方法,参数即事件类型,类型安全、IDE 可跳转、支持 SpEL 条件表达式 - 监听器类本身不需要加
@Component,但方法所在类必须是 Spring 管理 Bean - 若需异步,直接在方法上加
@Async,无需自己管理线程池(前提是已启用@EnableAsync)
示例:
@Service
public class SmsNotificationListener {
@EventListener
public void handleOrderCreated(OrderCreatedEvent event) {
// 同步执行:适合轻量、必须成功才返回的场景(如关键审计日志)
}
@EventListener
@Async
public void sendWelcomeSms(UserRegisteredEvent event) {
// 异步执行:适合容错性强、失败不影响主流程的场景(如短信、邮件)
}
}
事件发布必须通过 ApplicationEventPublisher,别 new 实例
常见错误是把 ApplicationEventPublisher 当成工具类,在任意位置 new ApplicationEventPublisherImpl() 或用静态工厂创建——这会导致事件脱离 Spring 容器生命周期,监听器根本收不到。
正确姿势只有这一种:
- 在任意 Spring Bean 中通过构造注入或
@Autowired获取ApplicationEventPublisher - 调用
publishEvent(...)方法,参数是事件对象(POJO 或继承自ApplicationEvent) - 不要试图在非 Bean 类(如 DTO、工具类、单元测试 setup)中发布事件;如果真需要,考虑用
ApplicationContext.publishEvent(),但前提是能拿到上下文引用
注意:publishEvent 默认同步,所有监听器按注册顺序依次执行,任一监听器抛异常会中断后续监听器(除非用 @TransactionalEventListener 控制事务边界)。
@Async 异步监听器的线程池配置不能忽略
只加 @Async 不配线程池,Spring 会 fallback 到简单的 SimpleAsyncTaskExecutor,它为每次调用新建线程,无复用、无上限、易 OOM。
必须显式配置一个有界线程池:
- 定义
@Bean返回ThreadPoolTaskExecutor,设置corePoolSize、maxPoolSize、queueCapacity - 在
@EnableAsync中指定executor名称,或设为默认 bean 名taskExecutor - 监控建议:暴露
ThreadPoolTaskExecutor的getActiveCount()和getQueue().size()到 Actuator endpoint
否则,高并发下短信监听器卡住,会拖垮整个事件分发链路,而你查日志只会看到“没报错”,却找不到慢在哪。
最容易被忽略的一点:事件对象里的字段要是不可变的(final + 无 setter),否则多个监听器并发修改同一事件实例,会出现状态污染——比如 A 监听器改了 userId,B 监听器读到的就是脏值。这不是理论风险,是真实发生过的线上问题。










