登录
首页 >  文章 >  java教程

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

时间:2026-04-23 19:31:38 479浏览 收藏

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

如何实现Java的观察者模式_接口回调机制实战应用

Java里用Observer接口写观察者模式,现在还行吗? 不行。Java 9 开始 java.util.Observerjava.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学习网公众号也会发布文章相关知识,快来关注吧!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>