Java观察者模式与回调实战详解

Java官方已彻底废弃内置的Observer模式实现，开发者必须转向自定义观察者接口以应对线程安全、泛型支持和灵活扩展等现实需求；本文直击核心——用轻量、可控、符合业务语义的接口设计替代过时API，厘清观察者模式与单次回调的本质区别，避开内存泄漏和生命周期混乱等高频陷阱，并理性分析LiveData与Flow在Android开发中的适用边界，最终强调：真正关键的不是代码怎么写，而是对“谁通知谁”“何时通知”“如何清理”的深度思考。

Java里用Observer接口写观察者模式，现在还行吗？ 不行。Java 9 开始 java.util.Observer 和 java.util.Observable 已被标记为 @Deprecated，JDK 14 彻底移除。这不是“不推荐”，是“不能用”。官方弃用理由很实在：线程不安全、API 设计僵硬、无法支持泛型。别再查老教程照搬 Observable.notifyObservers() 了。

替代方案就一条路：自己定义观察者接口 + 主动通知逻辑。核心就两件事——谁发通知、谁收通知，中间不依赖 JDK 内置类。

怎么写一个轻量又靠谱的自定义观察者接口？ 关键不是“模仿 Observer”，而是抓住事件驱动的本质：发布者持有观察者引用列表，状态变化时遍历调用统一方法。

实操建议：

• 定义接口别带实现，比如 interface DataChangeListener { void onDataChanged(String newData); }，方法名和参数按业务来，别硬套 update()
• 发布者类用 List 存观察者，不用 Vector 或加锁——如果需要线程安全，用 Collections.synchronizedList(new ArrayList<>()) 或更推荐 CopyOnWriteArrayList
• 注册/移除观察者必须提供 public 方法，比如 addChangeListener(DataChangeListener l) 和 removeChangeListener(DataChangeListener l)，别直接暴露 list 字段
• 通知时别在循环里做耗时操作，否则卡住所有观察者；如需异步，明确用 ExecutorService 分发，不要默认塞进主线程

public class DataSource {
    private final List<DataChangeListener> listeners = new CopyOnWriteArrayList<>();
    private String data;

    public void setData(String data) {
        this.data = data;
        listeners.forEach(l -> l.onDataChanged(data)); // 同步通知
    }

    public void addChangeListener(DataChangeListener l) {
        listeners.add(l);
    }
}

为什么不用接口回调（Callback）代替观察者？ 接口回调适合“一次调用、一次响应”的场景，比如网络请求完成、文件读完；观察者模式解决的是“一对多、长期监听状态变化”的问题。

容易踩的坑：

• 把 onSuccess() 这类单次回调接口强行复用为观察者——结果就是每次都要 new 一个新实例，内存泄漏风险高，且无法动态增删监听
• 回调接口没设计清除机制，Activity 或 Fragment 销毁后观察者还在列表里，导致空指针或内存泄漏
• 混淆“谁持有谁”：观察者模式中，发布者持有观察者；而典型回调中，调用方传入回调对象，生命周期由调用方管理——混用会导致引用链混乱

Android 里用 LiveData 或 Flow 替代手写观察者，靠谱吗？ 靠谱，但得看场景。LiveData 是 AndroidX 组件，自带生命周期感知，自动解注册，适合 UI 层数据绑定；Flow（配合 StateFlow）更通用，支持协程，适合纯 Kotlin 项目或需要背压的流式更新。

注意点：

• LiveData 在非主线程 postValue() 是安全的，但 setValue() 必须在主线程，误用会直接抛 IllegalStateException
• Flow 的 collect 默认在启动协程的 Dispatcher 上执行，UI 更新记得切回 Dispatchers.Main
• 它们都不是“银弹”：如果业务逻辑跨进程、要序列化、或需兼容 Java 8 环境，还是得回归自定义接口+手动管理

事情说清了就结束。真正难的不是写几个接口，而是想明白——这个状态变更是该“推”给谁，还是该让谁“拉”；要不要跨线程；观察者生命周期谁负责清理。这些判断比语法重要得多。

终于介绍完啦！小伙伴们，这篇关于《Java观察者模式与回调实战详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！