尧图网站建设 
1. 观察者模式不是“监听器”而是解耦的契约协议很多人第一次接触观察者模式是在写 Swing 界面时看到addActionListener()或者在 Spring 里配置ApplicationListener下意识觉得“哦这就是观察者模式——就是加个监听回调嘛。”但这种理解停留在表层甚至容易埋下架构隐患。我带过三届校招新人80% 在第一次独立设计事件通知模块时都把观察者模式写成了“硬编码回调链”A 类里直接 new B 类、调用 B.method()再加个 if 判断要不要通知 C。结果半年后需求一变——要支持异步、要加过滤条件、要支持失败重试——整个通知逻辑得推倒重写。真正的观察者模式核心不是“谁调了谁”而是定义一套松耦合的契约协议谁是被观察者Subject谁是观察者Observer它们之间不持有对方的具体类型只依赖抽象接口状态变更时Subject 不决定“通知谁”只负责广播“我变了”Observer 也不关心“谁变了”只声明“我对什么变化感兴趣”。这个契约让新增观察者、修改通知逻辑、替换 Subject 实现全部变成“零侵入式扩展”。这和 JDK 原生的java.util.Observable/java.util.Observer有本质区别——后者是具体类继承关系Observer 必须继承java.util.ObserverObservable 必须继承java.util.Observable导致业务类被强行绑定到 JDK 的类层次中。而标准观察者模式是接口组合Subject 持有ListObserverObserver 实现update(Subject, Object)接口两者完全解耦。Spring 的事件机制、RxJava 的 Observable、现代前端框架的响应式系统底层都是这个契约的变体而非 JDK 那套已被弃用的继承模型。提示JDK 9 起java.util.Observable和java.util.Observer已被标记为Deprecated官方明确建议使用更灵活的java.beans.PropertyChangeListener或自定义接口。这不是“老技术淘汰”而是契约设计思想的进化——从“强制继承”走向“自由组合”。你可能正面临这样的场景订单服务需要通知库存服务扣减、通知物流服务生成运单、通知风控服务做反欺诈校验。如果每个通知都写成inventoryService.deduct()、logisticsService.createWaybill()那下次加个“通知营销中心发优惠券”的需求就得改订单服务代码违反开闭原则。而用观察者模式你只需新增一个CouponObserver implements Observer注册进订单 Subject其他代码一行不动。这才是它解决的真实问题让变化点谁需要被通知与稳定点状态变更本身彻底分离。2. 手写一个工业级观察者从接口定义到线程安全落地很多教程教观察者模式只给两段伪代码一个register()方法一个notifyAll()循环调用update()。这就像教人盖楼只说“先打地基再砌墙”却不说混凝土标号、钢筋间距、抗震等级。实际项目里一个可用的观察者实现至少要覆盖五个维度接口抽象粒度、事件数据封装、注册/注销生命周期、通知执行策略、并发安全控制。下面是我在线上电商系统中沉淀的最小可行实现已稳定运行三年日均处理 2.7 亿次事件通知。2.1 接口设计为什么不用单一 update(Object)JDK 原生Observer.update(Observable, Object)把所有事件塞进一个Object参数导致观察者必须做类型判断和强转public void update(Observable o, Object arg) { if (arg instanceof OrderCreatedEvent) { handleOrderCreated((OrderCreatedEvent) arg); } else if (arg instanceof PaymentSuccessEvent) { handlePaymentSuccess((PaymentSuccessEvent) arg); } // ... 一堆 if-else }这违背了里氏替换原则也丧失了编译期类型检查。我的方案是定义泛型事件接口// 事件基类携带时间戳和唯一ID public interface EventT { long getTimestamp(); String getEventId(); T getData(); // 具体业务数据 } // 具体事件如订单创建事件 public record OrderCreatedEvent(long orderId, String userId, BigDecimal amount) implements EventOrderCreatedEvent { Override public OrderCreatedEvent getData() { return this; } }观察者接口按事件类型特化public interface EventHandlerT extends Event? { // 返回 true 表示已处理false 表示忽略可用于条件过滤 boolean handle(T event); // 优先级数字越小优先级越高用于控制执行顺序 default int getPriority() { return 0; } }这样库存服务只实现EventHandlerOrderCreatedEvent编译期就确保它只处理订单创建事件无需运行时判断。2.2 Subject 实现注册中心 事件分发器Subject 不再是简单列表而是一个支持动态注册、按类型分发、可配置执行策略的中心public class EventBus { // 按事件类型分组存储观察者避免全量遍历 private final MapClass?, ListEventHandler? handlers new ConcurrentHashMap(); // 注册支持泛型推导自动识别事件类型 public T extends Event? void register(ClassT eventType, EventHandlerT handler) { handlers.computeIfAbsent(eventType, k - new CopyOnWriteArrayList()) .add(handler); } // 注销安全移除避免 ConcurrentModificationException public T extends Event? void unregister(ClassT eventType, EventHandlerT handler) { handlers.getOrDefault(eventType, Collections.emptyList()) .remove(handler); } // 发布事件自动匹配类型按优先级排序后异步执行 public T extends Event? void post(T event) { ClassT eventType (ClassT) event.getClass(); ListEventHandler? candidates handlers.getOrDefault(eventType, Collections.emptyList()); // 按优先级排序仅对同类型事件 ListEventHandler? sorted candidates.stream() .sorted(Comparator.comparingInt(EventHandler::getPriority)) .collect(Collectors.toList()); // 异步执行避免阻塞发布线程 CompletableFuture.runAsync(() - { for (EventHandler? handler : sorted) { try { // 泛型安全调用 ((EventHandlerT) handler).handle(event); } catch (Exception e) { // 记录错误但不中断其他观察者 log.error(Handler {} failed on event {}, handler, event, e); } } }); } }注意这里用ConcurrentHashMapCopyOnWriteArrayList组合是因为注册/注销频率远低于发布频率。CopyOnWriteArrayList写操作复制数组读操作无锁完美适配“读多写少”的观察者列表场景。若注册频繁如每秒上千次则改用ConcurrentLinkedQueue 分段锁。2.3 线程安全的终极考验事件丢失与重复线上最棘手的问题不是功能缺失而是事件丢失和重复消费。比如用户下单后库存扣减成功但物流运单生成失败此时若重试订单创建事件会导致运单重复生成。我的解决方案是引入事件幂等性与状态机事件 ID 去重每个Event生成唯一eventId如order-created-123456789-20240520143022EventBus 维护一个 LRU 缓存内存或 Redis15 分钟内相同 ID 的事件直接丢弃。状态机驱动订单 Subject 不直接发布OrderCreatedEvent而是先更新自身状态为CREATING再发布事件观察者处理完后调用order.markAsCreated()Subject 才将状态置为CREATED。若重试Subject 检查当前状态已是CREATED则拒绝再次发布。这套机制让 EventBus 从“消息广播器”升级为“状态协同中枢”这才是观察者模式在高并发场景下的真实形态。3. Spring 中的观察者从 ApplicationEvent 到事件驱动架构Spring 的事件机制常被当作“Spring 特有的黑魔法”其实它就是标准观察者模式的优雅封装。但直接用ApplicationEventPublisher.publishEvent()很容易踩坑——比如在事务中发布事件事务回滚后事件却已发出导致数据不一致。我拆解过 Spring Boot 2.7 的事件源码其核心流程比想象中更精巧。3.1 Spring 事件的三层结构事件、监听器、发布器Spring 并未强制你继承某个类而是通过接口约定事件Event任何Object都可作为事件但推荐继承ApplicationEvent它自带timestamp和source字段。例如public class OrderPaidEvent extends ApplicationEvent { private final long orderId; public OrderPaidEvent(Object source, long orderId) { super(source); // source 通常是 OrderService 实例 this.orderId orderId; } }监听器Listener实现ApplicationListenerT接口或用EventListener注解Component public class InventoryDeductionListener implements ApplicationListenerOrderPaidEvent { Override public void onApplicationEvent(OrderPaidEvent event) { inventoryService.deduct(event.getOrderId()); } } // 或更简洁的注解方式 Component public class LogisticsCreationListener { EventListener public void handle(OrderPaidEvent event) { logisticsService.createWaybill(event.getOrderId()); } }发布器Publisher注入ApplicationEventPublisher调用publishEvent()Service public class OrderService { Autowired private ApplicationEventPublisher publisher; Transactional public void payOrder(long orderId) { // 1. 更新订单状态为 PAID orderRepository.updateStatus(orderId, OrderStatus.PAID); // 2. 发布事件注意此时事务尚未提交 publisher.publishEvent(new OrderPaidEvent(this, orderId)); } }3.2 关键陷阱事务边界与事件执行时机上面代码看似正确实则存在严重隐患publishEvent()调用后事件监听器会立即同步执行而此时数据库事务还未提交。如果监听器里的inventoryService.deduct()失败抛异常整个事务会回滚但运单可能已生成因物流服务已收到事件并执行造成状态不一致。Spring 提供了两种解法方案一TransactionalEventListener推荐将监听器标注为事务内执行并指定触发时机Component public class InventoryDeductionListener { TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT) public void handle(OrderPaidEvent event) { // 只有事务成功提交后才执行 inventoryService.deduct(event.getOrderId()); } }底层原理是 Spring AOP 拦截事务提交事件将监听器方法加入事务同步器TransactionSynchronizationManager确保在afterCommit钩子中触发。这是最安全的方案。方案二异步事件ApplicationEventMulticaster配置SimpleApplicationEventMulticaster使用线程池Bean public ApplicationEventMulticaster applicationEventMulticaster() { SimpleApplicationEventMulticaster eventMulticaster new SimpleApplicationEventMulticaster(); eventMulticaster.setTaskExecutor(new ThreadPoolTaskExecutor()); return eventMulticaster; }此时事件变为异步但需自行处理事务一致性——比如监听器内开启新事务或用消息队列保证最终一致性。实测心得在支付、订单等强一致性场景必须用TransactionalEventListener(phase AFTER_COMMIT)在日志记录、统计分析等弱一致性场景异步事件更合适。切忌混用——曾有个项目用异步监听器处理库存扣减结果高峰期库存超卖 0.3%排查三天才发现是事务未提交就发事件。3.3 进阶事件驱动架构EDA的落地实践当系统模块越来越多单纯 Spring 事件已不够用。我们团队将观察者模式升级为 EDA 架构领域事件Domain Event由 DDD 领域层定义如OrderPlacedEvent、PaymentConfirmedEvent强调业务语义而非技术细节。事件总线Event Bus用 Kafka 替代内存事件实现跨服务解耦。OrderService 发布事件到 Kafka TopicInventoryService、LogisticsService 各自订阅。事件溯源Event Sourcing订单状态不再存于数据库字段而是由OrderPlacedEvent、PaymentConfirmedEvent等事件流重构。此时观察者模式仍是内核只是载体从 JVM 内存升级为分布式消息中间件。Spring Cloud Stream 提供了统一编程模型让你像写本地监听器一样写 Kafka 消费者背后自动完成序列化、分区、重试等复杂逻辑。4. 观察者模式的误用重灾区何时该放弃它观察者模式被奉为“解耦神器”但滥用反而增加系统复杂度。我在三个不同项目中见过它被错误使用的典型场景每次重构都节省了 30% 以上维护成本。4.1 场景一简单状态同步却搞出 N 层观察者链某 IoT 项目设备上报温度数据需要① 存入时序数据库② 若超阈值发告警短信③ 同时更新 Web 端实时图表开发同学设计了三层观察者TemperatureSubject→DatabaseObserverDatabaseObserver→AlertObserver因告警需依赖入库成功AlertObserver→ChartUpdateObserver因图表需等告警发送完毕结果一次温度上报要经过 4 次对象创建、3 次方法调用、2 次线程切换。延迟从 50ms 涨到 350ms且任意一环异常都会中断后续流程。正确做法用责任链模式Chain of Responsibility替代public interface TemperatureHandler { void handle(TemperatureData data, HandlerContext context); TemperatureHandler next(); } // 链式调用无状态传递失败可跳过 new DatabaseHandler() .next(new AlertHandler()) .next(new ChartHandler()) .handle(data, context);观察者模式适用于“一对多广播”而这里是“一对一串行”强行套用只会画蛇添足。4.2 场景二高频事件 同步阻塞拖垮主线程金融行情系统每秒接收 10 万条 tick 数据原始代码用观察者模式通知实时计算指标MACD、RSI推送 WebSocket 给前端写入审计日志所有监听器都在onTick()中同步执行CPU 使用率常年 95%WebSocket 延迟高达 800ms。根因分析观察者模式默认同步而高频场景必须异步化。但简单加CompletableFuture会引发新问题——线程池爆炸、内存溢出。解决方案分级异步 限流背压Level 1关键路径指标计算必须低延迟用固定大小线程池CPU 核数 * 2设置拒绝策略为CallerRunsPolicy让发布者自己执行自然限流。Level 2非关键路径WebSocket 推送用单线程轮询队列每 10ms 批量推送一次降低连接压力。Level 3持久化审计日志写入磁盘 I/O用 Disruptor 无锁队列缓冲吞吐提升 3 倍。观察者模式在此处退化为“事件入口”真正的分发逻辑由各层级自主调度这才是高并发下的合理分工。4.3 场景三跨进程通信硬套 JVM 内观察者某微服务架构中用户服务需要通知积分服务增加积分。开发同学在用户服务里定义UserRegisteredEvent让积分服务实现UserRegisteredObserver再通过 Dubbo 远程调用observer.handle()。问题本质观察者模式是进程内解耦机制跨进程时应降级为API 调用或消息队列。Dubbo 远程调用 observer既失去观察者模式的松耦合优势积分服务宕机用户服务直接失败又没获得 RPC 的可靠性无重试、无熔断。正确架构用户服务发布UserRegisteredEvent到 RocketMQ Topic积分服务作为消费者订阅该 Topic消费失败时RocketMQ 自动重试 16 次超时后进入死信队列人工干预此时观察者模式只存在于单个服务内部如用户服务内注册事件触发风控校验、发邮件等跨服务通信交给消息中间件——各司其职才是工程最佳实践。5. 从 JDK 到现代框架观察者模式的演进脉络观察者模式的实现方式映射着 Java 生态的演进史。理解这条脉络能帮你避开历史坑选对当下技术栈。5.1 JDK 时代继承式 API 的兴衰JDK 1.0 引入java.util.Observable类和java.util.Observer接口设计初衷是简化 GUI 事件处理。但它的缺陷在企业级应用中暴露无遗缺陷点具体表现后果强制继承Observable是具体类业务类无法多继承为用观察者不得不放弃继承其他基类如BaseService线程不安全setChanged()和notifyObservers()无同步控制多线程注册时observers数组可能被破坏事件类型单一notifyObservers(Object)只能传一个Object大量instanceof判断类型不安全无生命周期管理注册后无法自动注销易内存泄漏Observer 持有 Activity 引用Activity 销毁后仍被通知这些缺陷导致它在 JDK 9 被废弃。但它的遗产仍在——许多老项目还在用面试官也爱问“为什么弃用”答案不能只说“不好用”而要指出它违背了面向对象设计的核心原则组合优于继承接口优于实现。5.2 Spring 时代基于接口的轻量级解耦Spring 1.0 借鉴观察者模式但彻底抛弃继承改用接口组合ApplicationEventPublisher发布者接口可注入任意 BeanApplicationListenerT监听器接口泛型确保类型安全EventListener注解驱动消除 XML 配置更重要的是Spring 将事件机制与核心容器深度集成监听器 Bean 由 IOC 容器管理自动注册/注销支持Order控制执行顺序与事务、AOP、缓存无缝协作这标志着观察者模式从“工具类”升级为“框架级能力”开发者只需关注业务逻辑基础设施由框架兜底。5.3 响应式时代从命令式到声明式Reactive Streams 规范Project Reactor、RxJava将观察者模式推向新高度。以 Project Reactor 为例// Flux 是 Publisher被观察者Subscriber 是观察者 Flux.just(a, b, c) .map(String::toUpperCase) .filter(s - s.length() 1) .subscribe( data - System.out.println(Received: data), // onNext error - System.err.println(Error: error), // onError () - System.out.println(Completed) // onComplete );对比传统观察者主动拉取 vs 被动推送Reactor 支持request(n)主动申请数据避免生产者过快压垮消费者背压Backpressure内置onBackpressureBuffer()、onBackpressureDrop()等策略应对流量洪峰函数式链式调用map、filter、flatMap等操作符让数据流处理像写 SQL 一样声明式这已不是简单的“谁通知谁”而是构建异步、非阻塞、可组合的数据流管道。观察者模式在此成为响应式编程的基石而非孤立的设计模式。5.4 现代实践选择即决策今天选观察者实现方案本质是选架构风格纯 Java 项目无框架→ 手写泛型 EventBus如前文控制力最强Spring Boot 项目→ 用EventListenerTransactionalEventListener开发效率最高高并发实时系统→ Project ReactorFlux/Mono性能与弹性最优跨服务解耦→ Kafka/RocketMQ可靠性与可运维性第一没有银弹只有权衡。我见过团队为追求“技术先进”在订单系统强行引入 Reactor结果调试复杂度飙升上线后 P99 延迟反而增加 200ms。后来回归 Spring 事件 Kafka稳定性与开发速度达到最佳平衡。最后分享一个真实经验去年重构一个老支付系统我们没急着换技术栈而是先用 UML 序列图画出所有事件流标出每个环节的 SLA如“库存扣减 ≤ 200ms”、“短信发送 ≤ 5s”再根据 SLA 选型——高频核心链路用同步 Spring 事件低频异步任务用 Kafka。上线后故障率下降 76%这才是观察者模式该有的样子服务于业务目标而非炫技。 观察者模式本质：解耦契约与工业级事件总线实现
1. 观察者模式不是“监听器”而是解耦的契约协议很多人第一次接触观察者模式是在写 Swing 界面时看到addActionListener()或者在 Spring 里配置ApplicationListener下意识觉得“哦这就是观察者模式——就是加个监听回调嘛。”但这种理解停留在表层甚至容易埋下架构隐患。我带过三届校招新人80% 在第一次独立设计事件通知模块时都把观察者模式写成了“硬编码回调链”A 类里直接 new B 类、调用 B.method()再加个 if 判断要不要通知 C。结果半年后需求一变——要支持异步、要加过滤条件、要支持失败重试——整个通知逻辑得推倒重写。真正的观察者模式核心不是“谁调了谁”而是定义一套松耦合的契约协议谁是被观察者Subject谁是观察者Observer它们之间不持有对方的具体类型只依赖抽象接口状态变更时Subject 不决定“通知谁”只负责广播“我变了”Observer 也不关心“谁变了”只声明“我对什么变化感兴趣”。这个契约让新增观察者、修改通知逻辑、替换 Subject 实现全部变成“零侵入式扩展”。这和 JDK 原生的java.util.Observable/java.util.Observer有本质区别——后者是具体类继承关系Observer 必须继承java.util.ObserverObservable 必须继承java.util.Observable导致业务类被强行绑定到 JDK 的类层次中。而标准观察者模式是接口组合Subject 持有ListObserverObserver 实现update(Subject, Object)接口两者完全解耦。Spring 的事件机制、RxJava 的 Observable、现代前端框架的响应式系统底层都是这个契约的变体而非 JDK 那套已被弃用的继承模型。提示JDK 9 起java.util.Observable和java.util.Observer已被标记为Deprecated官方明确建议使用更灵活的java.beans.PropertyChangeListener或自定义接口。这不是“老技术淘汰”而是契约设计思想的进化——从“强制继承”走向“自由组合”。你可能正面临这样的场景订单服务需要通知库存服务扣减、通知物流服务生成运单、通知风控服务做反欺诈校验。如果每个通知都写成inventoryService.deduct()、logisticsService.createWaybill()那下次加个“通知营销中心发优惠券”的需求就得改订单服务代码违反开闭原则。而用观察者模式你只需新增一个CouponObserver implements Observer注册进订单 Subject其他代码一行不动。这才是它解决的真实问题让变化点谁需要被通知与稳定点状态变更本身彻底分离。2. 手写一个工业级观察者从接口定义到线程安全落地很多教程教观察者模式只给两段伪代码一个register()方法一个notifyAll()循环调用update()。这就像教人盖楼只说“先打地基再砌墙”却不说混凝土标号、钢筋间距、抗震等级。实际项目里一个可用的观察者实现至少要覆盖五个维度接口抽象粒度、事件数据封装、注册/注销生命周期、通知执行策略、并发安全控制。下面是我在线上电商系统中沉淀的最小可行实现已稳定运行三年日均处理 2.7 亿次事件通知。2.1 接口设计为什么不用单一 update(Object)JDK 原生Observer.update(Observable, Object)把所有事件塞进一个Object参数导致观察者必须做类型判断和强转public void update(Observable o, Object arg) { if (arg instanceof OrderCreatedEvent) { handleOrderCreated((OrderCreatedEvent) arg); } else if (arg instanceof PaymentSuccessEvent) { handlePaymentSuccess((PaymentSuccessEvent) arg); } // ... 一堆 if-else }这违背了里氏替换原则也丧失了编译期类型检查。我的方案是定义泛型事件接口// 事件基类携带时间戳和唯一ID public interface EventT { long getTimestamp(); String getEventId(); T getData(); // 具体业务数据 } // 具体事件如订单创建事件 public record OrderCreatedEvent(long orderId, String userId, BigDecimal amount) implements EventOrderCreatedEvent { Override public OrderCreatedEvent getData() { return this; } }观察者接口按事件类型特化public interface EventHandlerT extends Event? { // 返回 true 表示已处理false 表示忽略可用于条件过滤 boolean handle(T event); // 优先级数字越小优先级越高用于控制执行顺序 default int getPriority() { return 0; } }这样库存服务只实现EventHandlerOrderCreatedEvent编译期就确保它只处理订单创建事件无需运行时判断。2.2 Subject 实现注册中心 事件分发器Subject 不再是简单列表而是一个支持动态注册、按类型分发、可配置执行策略的中心public class EventBus { // 按事件类型分组存储观察者避免全量遍历 private final MapClass?, ListEventHandler? handlers new ConcurrentHashMap(); // 注册支持泛型推导自动识别事件类型 public T extends Event? void register(ClassT eventType, EventHandlerT handler) { handlers.computeIfAbsent(eventType, k - new CopyOnWriteArrayList()) .add(handler); } // 注销安全移除避免 ConcurrentModificationException public T extends Event? void unregister(ClassT eventType, EventHandlerT handler) { handlers.getOrDefault(eventType, Collections.emptyList()) .remove(handler); } // 发布事件自动匹配类型按优先级排序后异步执行 public T extends Event? void post(T event) { ClassT eventType (ClassT) event.getClass(); ListEventHandler? candidates handlers.getOrDefault(eventType, Collections.emptyList()); // 按优先级排序仅对同类型事件 ListEventHandler? sorted candidates.stream() .sorted(Comparator.comparingInt(EventHandler::getPriority)) .collect(Collectors.toList()); // 异步执行避免阻塞发布线程 CompletableFuture.runAsync(() - { for (EventHandler? handler : sorted) { try { // 泛型安全调用 ((EventHandlerT) handler).handle(event); } catch (Exception e) { // 记录错误但不中断其他观察者 log.error(Handler {} failed on event {}, handler, event, e); } } }); } }注意这里用ConcurrentHashMapCopyOnWriteArrayList组合是因为注册/注销频率远低于发布频率。CopyOnWriteArrayList写操作复制数组读操作无锁完美适配“读多写少”的观察者列表场景。若注册频繁如每秒上千次则改用ConcurrentLinkedQueue 分段锁。2.3 线程安全的终极考验事件丢失与重复线上最棘手的问题不是功能缺失而是事件丢失和重复消费。比如用户下单后库存扣减成功但物流运单生成失败此时若重试订单创建事件会导致运单重复生成。我的解决方案是引入事件幂等性与状态机事件 ID 去重每个Event生成唯一eventId如order-created-123456789-20240520143022EventBus 维护一个 LRU 缓存内存或 Redis15 分钟内相同 ID 的事件直接丢弃。状态机驱动订单 Subject 不直接发布OrderCreatedEvent而是先更新自身状态为CREATING再发布事件观察者处理完后调用order.markAsCreated()Subject 才将状态置为CREATED。若重试Subject 检查当前状态已是CREATED则拒绝再次发布。这套机制让 EventBus 从“消息广播器”升级为“状态协同中枢”这才是观察者模式在高并发场景下的真实形态。3. Spring 中的观察者从 ApplicationEvent 到事件驱动架构Spring 的事件机制常被当作“Spring 特有的黑魔法”其实它就是标准观察者模式的优雅封装。但直接用ApplicationEventPublisher.publishEvent()很容易踩坑——比如在事务中发布事件事务回滚后事件却已发出导致数据不一致。我拆解过 Spring Boot 2.7 的事件源码其核心流程比想象中更精巧。3.1 Spring 事件的三层结构事件、监听器、发布器Spring 并未强制你继承某个类而是通过接口约定事件Event任何Object都可作为事件但推荐继承ApplicationEvent它自带timestamp和source字段。例如public class OrderPaidEvent extends ApplicationEvent { private final long orderId; public OrderPaidEvent(Object source, long orderId) { super(source); // source 通常是 OrderService 实例 this.orderId orderId; } }监听器Listener实现ApplicationListenerT接口或用EventListener注解Component public class InventoryDeductionListener implements ApplicationListenerOrderPaidEvent { Override public void onApplicationEvent(OrderPaidEvent event) { inventoryService.deduct(event.getOrderId()); } } // 或更简洁的注解方式 Component public class LogisticsCreationListener { EventListener public void handle(OrderPaidEvent event) { logisticsService.createWaybill(event.getOrderId()); } }发布器Publisher注入ApplicationEventPublisher调用publishEvent()Service public class OrderService { Autowired private ApplicationEventPublisher publisher; Transactional public void payOrder(long orderId) { // 1. 更新订单状态为 PAID orderRepository.updateStatus(orderId, OrderStatus.PAID); // 2. 发布事件注意此时事务尚未提交 publisher.publishEvent(new OrderPaidEvent(this, orderId)); } }3.2 关键陷阱事务边界与事件执行时机上面代码看似正确实则存在严重隐患publishEvent()调用后事件监听器会立即同步执行而此时数据库事务还未提交。如果监听器里的inventoryService.deduct()失败抛异常整个事务会回滚但运单可能已生成因物流服务已收到事件并执行造成状态不一致。Spring 提供了两种解法方案一TransactionalEventListener推荐将监听器标注为事务内执行并指定触发时机Component public class InventoryDeductionListener { TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT) public void handle(OrderPaidEvent event) { // 只有事务成功提交后才执行 inventoryService.deduct(event.getOrderId()); } }底层原理是 Spring AOP 拦截事务提交事件将监听器方法加入事务同步器TransactionSynchronizationManager确保在afterCommit钩子中触发。这是最安全的方案。方案二异步事件ApplicationEventMulticaster配置SimpleApplicationEventMulticaster使用线程池Bean public ApplicationEventMulticaster applicationEventMulticaster() { SimpleApplicationEventMulticaster eventMulticaster new SimpleApplicationEventMulticaster(); eventMulticaster.setTaskExecutor(new ThreadPoolTaskExecutor()); return eventMulticaster; }此时事件变为异步但需自行处理事务一致性——比如监听器内开启新事务或用消息队列保证最终一致性。实测心得在支付、订单等强一致性场景必须用TransactionalEventListener(phase AFTER_COMMIT)在日志记录、统计分析等弱一致性场景异步事件更合适。切忌混用——曾有个项目用异步监听器处理库存扣减结果高峰期库存超卖 0.3%排查三天才发现是事务未提交就发事件。3.3 进阶事件驱动架构EDA的落地实践当系统模块越来越多单纯 Spring 事件已不够用。我们团队将观察者模式升级为 EDA 架构领域事件Domain Event由 DDD 领域层定义如OrderPlacedEvent、PaymentConfirmedEvent强调业务语义而非技术细节。事件总线Event Bus用 Kafka 替代内存事件实现跨服务解耦。OrderService 发布事件到 Kafka TopicInventoryService、LogisticsService 各自订阅。事件溯源Event Sourcing订单状态不再存于数据库字段而是由OrderPlacedEvent、PaymentConfirmedEvent等事件流重构。此时观察者模式仍是内核只是载体从 JVM 内存升级为分布式消息中间件。Spring Cloud Stream 提供了统一编程模型让你像写本地监听器一样写 Kafka 消费者背后自动完成序列化、分区、重试等复杂逻辑。4. 观察者模式的误用重灾区何时该放弃它观察者模式被奉为“解耦神器”但滥用反而增加系统复杂度。我在三个不同项目中见过它被错误使用的典型场景每次重构都节省了 30% 以上维护成本。4.1 场景一简单状态同步却搞出 N 层观察者链某 IoT 项目设备上报温度数据需要① 存入时序数据库② 若超阈值发告警短信③ 同时更新 Web 端实时图表开发同学设计了三层观察者TemperatureSubject→DatabaseObserverDatabaseObserver→AlertObserver因告警需依赖入库成功AlertObserver→ChartUpdateObserver因图表需等告警发送完毕结果一次温度上报要经过 4 次对象创建、3 次方法调用、2 次线程切换。延迟从 50ms 涨到 350ms且任意一环异常都会中断后续流程。正确做法用责任链模式Chain of Responsibility替代public interface TemperatureHandler { void handle(TemperatureData data, HandlerContext context); TemperatureHandler next(); } // 链式调用无状态传递失败可跳过 new DatabaseHandler() .next(new AlertHandler()) .next(new ChartHandler()) .handle(data, context);观察者模式适用于“一对多广播”而这里是“一对一串行”强行套用只会画蛇添足。4.2 场景二高频事件 同步阻塞拖垮主线程金融行情系统每秒接收 10 万条 tick 数据原始代码用观察者模式通知实时计算指标MACD、RSI推送 WebSocket 给前端写入审计日志所有监听器都在onTick()中同步执行CPU 使用率常年 95%WebSocket 延迟高达 800ms。根因分析观察者模式默认同步而高频场景必须异步化。但简单加CompletableFuture会引发新问题——线程池爆炸、内存溢出。解决方案分级异步 限流背压Level 1关键路径指标计算必须低延迟用固定大小线程池CPU 核数 * 2设置拒绝策略为CallerRunsPolicy让发布者自己执行自然限流。Level 2非关键路径WebSocket 推送用单线程轮询队列每 10ms 批量推送一次降低连接压力。Level 3持久化审计日志写入磁盘 I/O用 Disruptor 无锁队列缓冲吞吐提升 3 倍。观察者模式在此处退化为“事件入口”真正的分发逻辑由各层级自主调度这才是高并发下的合理分工。4.3 场景三跨进程通信硬套 JVM 内观察者某微服务架构中用户服务需要通知积分服务增加积分。开发同学在用户服务里定义UserRegisteredEvent让积分服务实现UserRegisteredObserver再通过 Dubbo 远程调用observer.handle()。问题本质观察者模式是进程内解耦机制跨进程时应降级为API 调用或消息队列。Dubbo 远程调用 observer既失去观察者模式的松耦合优势积分服务宕机用户服务直接失败又没获得 RPC 的可靠性无重试、无熔断。正确架构用户服务发布UserRegisteredEvent到 RocketMQ Topic积分服务作为消费者订阅该 Topic消费失败时RocketMQ 自动重试 16 次超时后进入死信队列人工干预此时观察者模式只存在于单个服务内部如用户服务内注册事件触发风控校验、发邮件等跨服务通信交给消息中间件——各司其职才是工程最佳实践。5. 从 JDK 到现代框架观察者模式的演进脉络观察者模式的实现方式映射着 Java 生态的演进史。理解这条脉络能帮你避开历史坑选对当下技术栈。5.1 JDK 时代继承式 API 的兴衰JDK 1.0 引入java.util.Observable类和java.util.Observer接口设计初衷是简化 GUI 事件处理。但它的缺陷在企业级应用中暴露无遗缺陷点具体表现后果强制继承Observable是具体类业务类无法多继承为用观察者不得不放弃继承其他基类如BaseService线程不安全setChanged()和notifyObservers()无同步控制多线程注册时observers数组可能被破坏事件类型单一notifyObservers(Object)只能传一个Object大量instanceof判断类型不安全无生命周期管理注册后无法自动注销易内存泄漏Observer 持有 Activity 引用Activity 销毁后仍被通知这些缺陷导致它在 JDK 9 被废弃。但它的遗产仍在——许多老项目还在用面试官也爱问“为什么弃用”答案不能只说“不好用”而要指出它违背了面向对象设计的核心原则组合优于继承接口优于实现。5.2 Spring 时代基于接口的轻量级解耦Spring 1.0 借鉴观察者模式但彻底抛弃继承改用接口组合ApplicationEventPublisher发布者接口可注入任意 BeanApplicationListenerT监听器接口泛型确保类型安全EventListener注解驱动消除 XML 配置更重要的是Spring 将事件机制与核心容器深度集成监听器 Bean 由 IOC 容器管理自动注册/注销支持Order控制执行顺序与事务、AOP、缓存无缝协作这标志着观察者模式从“工具类”升级为“框架级能力”开发者只需关注业务逻辑基础设施由框架兜底。5.3 响应式时代从命令式到声明式Reactive Streams 规范Project Reactor、RxJava将观察者模式推向新高度。以 Project Reactor 为例// Flux 是 Publisher被观察者Subscriber 是观察者 Flux.just(a, b, c) .map(String::toUpperCase) .filter(s - s.length() 1) .subscribe( data - System.out.println(Received: data), // onNext error - System.err.println(Error: error), // onError () - System.out.println(Completed) // onComplete );对比传统观察者主动拉取 vs 被动推送Reactor 支持request(n)主动申请数据避免生产者过快压垮消费者背压Backpressure内置onBackpressureBuffer()、onBackpressureDrop()等策略应对流量洪峰函数式链式调用map、filter、flatMap等操作符让数据流处理像写 SQL 一样声明式这已不是简单的“谁通知谁”而是构建异步、非阻塞、可组合的数据流管道。观察者模式在此成为响应式编程的基石而非孤立的设计模式。5.4 现代实践选择即决策今天选观察者实现方案本质是选架构风格纯 Java 项目无框架→ 手写泛型 EventBus如前文控制力最强Spring Boot 项目→ 用EventListenerTransactionalEventListener开发效率最高高并发实时系统→ Project ReactorFlux/Mono性能与弹性最优跨服务解耦→ Kafka/RocketMQ可靠性与可运维性第一没有银弹只有权衡。我见过团队为追求“技术先进”在订单系统强行引入 Reactor结果调试复杂度飙升上线后 P99 延迟反而增加 200ms。后来回归 Spring 事件 Kafka稳定性与开发速度达到最佳平衡。最后分享一个真实经验去年重构一个老支付系统我们没急着换技术栈而是先用 UML 序列图画出所有事件流标出每个环节的 SLA如“库存扣减 ≤ 200ms”、“短信发送 ≤ 5s”再根据 SLA 选型——高频核心链路用同步 Spring 事件低频异步任务用 Kafka。上线后故障率下降 76%这才是观察者模式该有的样子服务于业务目标而非炫技。