Java接口通过定义事件监听器和发布者契约实现发布订阅模式解耦：函数式接口声明监听行为，CopyOnWriteArrayList管理多订阅者，Spring中可用@EventListener零侵入集成并支持异步等增强能力。
Java 中接口本身不直接实现发布订阅模式，但它是构建该模式的核心契约工具——通过定义统一的事件监听器接口和事件发布者接口，让发布者与订阅者仅依赖抽象，彻底解耦。
定义标准化的事件监听器接口
这是解耦的起点。用 函数式接口（如 @FunctionalInterface）声明监听行为，明确“谁来响应什么事件”：
@FunctionalInterface
public interface OrderEventListener {
void onOrderCreated(Order order);
void onOrderPaid(Order order);
}
- 所有具体监听器（如库存服务、通知服务）都实现这个接口，但彼此不知道对方存在
- 发布者只持有
OrderEventListener引用，不关心实现类是InventoryService还是SmsNotifier - 接口方法应聚焦业务语义（如
onOrderPaid），避免泛化命名（如handleEvent）
用 List 或 Map 管理多订阅者，支持动态增删
发布者内部维护监听器集合，而非硬编码调用。典型做法是使用线程安全的 CopyOnWriteArrayList（适合读多写少场景）：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
public class OrderEventPublisher {
private final List<OrderEventListener> listeners =
new CopyOnWriteArrayList<>();
public void addListener(OrderEventListener listener) {
listeners.add(listener);
}
public void removeListener(OrderEventListener listener) {
listeners.remove(listener);
}
public void publishOrderPaid(Order order) {
listeners.forEach(l -> l.onOrderPaid(order));
}
}
- 新增模块只需调用
addListener()，无需修改发布者源码 - 移除监听器可立即生效，避免内存泄漏（注意：若监听器是匿名内部类，需保留引用以便移除）
- 如需按事件类型分发，可用
Map<Class<? extends Event>, List<EventListener>>替代单列表
结合 Spring 的 @EventListener 实现零侵入集成
在 Spring 环境中，不必手动管理监听器列表。用接口定义事件，再用注解自动注册：
立即学习“Java免费学习笔记（深入）”；
// 1. 定义事件（普通 POJO）
public class OrderPaidEvent {
private final Order order;
// 构造器、getter...
}
// 2. 任意 Bean 方法加 @EventListener 即成订阅者
@Component
public class InventoryService {
@EventListener
public void handleOrderPaid(OrderPaidEvent event) {
// 扣减库存逻辑
}
}
// 3. 发布方直接使用 ApplicationEventPublisher
@Service
public class OrderService {
@Autowired
private ApplicationEventPublisher publisher;
public void completePayment(Order order) {
publisher.publishEvent(new OrderPaidEvent(order));
}
}
- 订阅者无需实现特定接口，Spring 通过反射匹配参数类型完成绑定
- 发布者完全不感知监听器存在，连监听器接口都不需要依赖
- 支持异步（
@Async）、事务绑定（@TransactionalEventListener）等增强能力
关键设计提醒：避免常见陷阱
- 不要在监听器里抛出未检查异常——默认同步调用下，一个监听器崩溃会导致后续监听器跳过；建议用 try-catch 包裹业务逻辑并记录日志
- 警惕循环依赖——比如 A 发布事件 → B 订阅并修改状态 → 触发 C 发布新事件 → A 又被触发；可通过事件标识或状态标记拦截
- 区分本地事件与分布式事件——上述方案限于单 JVM。跨服务需升级为消息队列（Kafka/RocketMQ），此时接口退化为序列化契约，由消息中间件承担分发职责
