直接用ArrayList存事件监听器会因多线程并发修改导致ConcurrentModificationException，或遍历时漏通知/重复通知；CopyOnWriteArrayList通过快照机制解决该问题，读多写少场景下最轻量可靠。
为什么直接用 ArrayList 存事件监听器会出问题
多个线程同时调用 add 或 remove 时，ArrayList 会抛 ConcurrentModificationException；更隐蔽的问题是，遍历过程中另一个线程修改了列表结构，导致漏通知或重复通知。这不是偶发 bug，而是并发下的确定性行为。
- 监听器注册/注销和事件触发通常跨不同线程（如 UI 线程注册，后台线程触发）
-
CopyOnWriteArrayList是最轻量且语义清晰的解法：读多写少场景下，迭代安全、无需额外同步 - 避免用
Collections.synchronizedList—— 它只保证单个方法原子性，遍历时仍需手动加锁，容易遗漏
如何用 CopyOnWriteArrayList 实现基础事件总线
核心是把监听器集合声明为 CopyOnWriteArrayList，并在触发逻辑中直接遍历——它内部已处理了快照一致性。
public class EventBus {
private final CopyOnWriteArrayList> listeners = new CopyOnWriteArrayList<>();
public void addListener(Consumer listener) {
listeners.add(listener);
}
public void removeListener(Consumer listener) {
listeners.remove(listener);
}
public void fireEvent(String event) {
// 遍历时自动使用当前快照，线程安全
for (Consumer listener : listeners) {
listener.accept(event);
}
}
}
- 注册/注销操作本身线程安全，无需额外
synchronized - 触发时遍历的是「不可变快照」，即使其他线程正在增删，也不影响本次遍历完整性
- 注意：监听器执行是同步的，若某个监听器耗时长或阻塞，会拖慢整个通知链；如需异步，应由监听器自行提交到线程池，而非在
fireEvent中调度
监听器执行异常会中断后续通知吗
会。默认遍历是顺序执行，一个监听器抛出未捕获异常，循环立即终止，后面的监听器收不到事件。
- 必须显式捕获每个监听器的异常，否则事件传播中断是静默失败
- 推荐在
fireEvent内部加try-catch，记录异常但不中断循环 - 不要依赖
Thread.setDefaultUncaughtExceptionHandler—— 它对Consumer这类函数式接口无效
public void fireEvent(String event) {
for (Consumer listener : listeners) {
try {
listener.accept(event);
} catch (Throwable t) {
// 记录日志，但继续下一个
System.err.println("Listener failed: " + t);
}
}
}
什么时候不该用 CopyOnWriteArrayList
当监听器数量大（千级以上）且注册/注销频繁时，CopyOnWriteArrayList 的每次写操作都会复制整个数组，GC 压力陡增，吞吐下降明显。
立即学习“Java免费学习笔记（深入）”；
- 此时可考虑
ConcurrentHashMap+ 自增 ID 作为键，值为监听器，遍历时用values().toArray()获取快照 - 或引入更重的方案如
Disruptor，但仅适用于超高吞吐、低延迟要求的场景（如金融行情推送） - 绝大多数业务系统，监听器几十到几百个，
CopyOnWriteArrayList是最简单可靠的起点
真正容易被忽略的不是怎么写，而是监听器本身的线程安全性——比如监听器内部修改了共享的 HashMap 却没加锁，这会让整个事件机制形同虚设。
