观察者模式是软件设计中极为经典的一种行为型模式。它建立了一种一对多的依赖关系，当被观察对象的状态发生改变时，所有依赖于它的对象都会得到通知并自动更新。在Java开发中，利用接口来定义观察者和被观察者之间的契约，是实现这一模式最自然且最符合面向对象原则的方式。通过接口的抽象，我们可以确保系统在运行时能够动态地增删观察者，而无需修改被观察者的核心逻辑。
观察者模式的核心原理与接口定义
要掌握观察者模式，首先需要理解其核心角色划分。通常情况下，系统需要包含两个核心接口。一个是主题接口，它负责维护观察者列表，并提供注册、注销和通知的方法。另一个是观察者接口，它定义了当主题状态变化时观察者需要执行的具体操作。这种设计将动作的发起者与执行者彻底分离，使得双方仅通过接口进行交互，互不关心对方的具体实现。
在Java中定义这两个接口非常直观。主题接口通常会声明注册、移除和通知方法，而观察者接口则包含一个更新方法。通过这种契约式的接口设计，系统实现了高度的松耦合。被观察者不需要知道观察者具体是谁，只要它实现了观察者接口，就可以被安全地加入到通知列表中。
public interface Subject {
void registerObserver(Observer o);
void removeObserver(Observer o);
void notifyObservers(String event);
}
public interface Observer {
void update(String event);
}
这种基于接口的设计带来了极大的灵活性。当后续业务需要增加新的观察者时，只需新建一个类实现观察者接口即可，完全符合开闭原则。同时，由于接口定义了统一的通信协议，不同类型的观察者可以在同一个主题下协同工作，互不干扰。这种设计在事件驱动架构、消息广播以及GUI交互等场景中有着不可替代的作用。
在Java中手写实现观察者模式
有了基础接口后，我们需要编写具体的实现类。被观察者实现类需要维护一个线程安全的集合来存放观察者引用。在通知方法中，被观察者会遍历这个集合并调用每个观察者的更新方法。这里需要特别注意的是，如果在多线程环境下运行，集合的读写操作必须进行同步控制，否则可能会引发并发修改异常。使用CopyOnWriteArrayList是一个不错的策略，它在写入时复制容器，既能保证读写的线程安全，又不会阻塞通知操作。
import java.util.List;
import java.util.concurrent.CopyOnWriteArrayList;
public class NewsPublisher implements Subject {
private List<Observer> observers = new CopyOnWriteArrayList<>();
@Override
public void registerObserver(Observer o) {
if (!observers.contains(o)) {
observers.add(o);
}
}
@Override
public void removeObserver(Observer o) {
observers.remove(o);
}
@Override
public void notifyObservers(String event) {
for (Observer observer : observers) {
observer.update(event);
}
}
}
在数据传递方面，观察者模式通常分为推模型和拉模型。推模型是指主题对象将状态数据封装成一个对象主动推送给观察者，这种方式适用于观察者需要大量数据的场景。拉模型则是主题对象在通知时将自身实例传递给观察者，由观察者根据自身需求主动拉取所需数据。两种模型各有优劣，推模型减少了观察者的查询开销，但可能传递了不必要的数据；拉模型则更加灵活，但增加了观察者的逻辑复杂度。
在实际开发中，推模型的应用更为广泛。我们可以定义一个事件对象来封装状态变化的具体信息，这样不仅类型安全，而且便于后续扩展。当业务逻辑发生变化需要增加新字段时，只需修改事件对象，而无需改变观察者接口的方法签名，这大大降低了系统重构的风险。同时，这种设计使得通知的上下文信息更加清晰，便于调试和问题追踪。
Java内置观察者模式API的对比与选择
许多开发者可能不知道，Java标准库在早期就内置了对观察者模式的支持，主要通过java.util.Observable类和java.util.Observer接口来实现。使用内置API可以快速搭建观察者机制，被观察者只需继承Observable类并调用setChanged和notifyObservers方法即可完成状态广播。
import java.util.Observable;
import java.util.Observer;
public class NewsData extends Observable {
public void dataChanged() {
setChanged();
notifyObservers("最新新闻数据");
}
}
public class NewsDisplay implements Observer {
@Override
public void update(Observable o, Object arg) {
System.out.println("接收到数据: " + arg);
}
}
然而，内置API的设计存在明显的缺陷。首先，Observable是一个类而不是接口，这导致被观察者必须继承它。由于Java不支持多重继承，如果被观察者本身已经有父类，就无法使用这种机制。其次，Observable类中的某些关键方法如setChanged被protected修饰，这意味着子类可以重写它，但也限制了其在跨包使用时的灵活性，破坏了封装性。
正因为这些局限性，从Java 9开始，这两个内置组件被标记为废弃。现代Java开发中，强烈推荐使用自定义接口来实现观察者模式。通过自定义接口，我们可以完全掌控依赖关系，避免继承带来的限制，并且可以结合泛型设计出更加类型安全的观察者框架，使代码更加健壮和易于维护。自定义接口还能更好地与函数式编程结合，例如使用Lambda表达式简化观察者的注册过程。
实战中的避坑指南与性能优化
虽然观察者模式在解耦方面表现优异，但在实际应用中如果不注意细节，很容易掉入陷阱。最常见的问题就是内存泄漏。当观察者对象被注册到主题后，如果在使用完毕后没有显式调用注销方法，主题会一直持有观察者的引用，导致垃圾回收器无法回收这些对象，最终引发内存溢出。特别是在Android或Web应用中，生命周期较短的组件如果作为观察者注册到单例主题中，内存泄漏的风险极高。
另一个高频问题是通知死锁或栈溢出。如果观察者在接收到通知后的处理逻辑中又去调用了主题的某个方法，而这个方法又触发了新的通知，就会形成无限循环。为了避免这种情况，观察者的处理逻辑应当尽量轻量，且绝对不能在处理过程中反向修改被观察者的状态。如果处理逻辑非常耗时，应当将任务放入独立的线程池中异步执行，避免阻塞通知流程。
import java.lang.ref.WeakReference;
import java.util.List;
import java.util.concurrent.CopyOnWriteArrayList;
public class SafeSubject implements Subject {
private List<WeakReference<Observer>> observers = new CopyOnWriteArrayList<>();
@Override
public void registerObserver(Observer o) {
observers.add(new WeakReference<>(o));
}
@Override
public void notifyObservers(String event) {
for (WeakReference<Observer> weakRef : observers) {
Observer observer = weakRef.get();
if (observer != null) {
observer.update(event);
}
}
}
// 省略其他方法
}
对于复杂的业务系统，可以考虑使用弱引用来存储观察者，这样即使忘记注销，当观察者没有其他强引用时也会被自动回收。同时，在多线程环境下，通知的顺序也可能影响业务逻辑，如果对通知顺序有严格要求，可以使用有序集合如LinkedHashSet来维护观察者列表。掌握这些细节，才能真正在生产环境中游刃有余地运用观察者模式，构建出高可用、易维护的系统架构。