观察者模式适用于GUI事件处理、消息队列、状态更新等场景，通过主题与观察者解耦实现灵活扩展；其与发布/订阅模式在耦合度、消息过滤和复杂性上存在差异；可通过弱引用、事件队列或中间层避免循环依赖；具备解耦和扩展性优点，但存在性能开销和通知顺序不可控缺点；多线程环境下可采用同步锁、并发集合或线程池保障安全；还可借助Guava EventBus、Spring ApplicationEvent或RxJava等框架实现。
观察者模式是一种行为设计模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。当主题对象的状态发生改变时，所有依赖于它的观察者对象都会收到通知并自动更新。
解决方案：
-
定义主题接口 (Subject Interface): 这个接口声明了添加、删除和通知观察者的方法。
public interface Subject { void attach(Observer observer); void detach(Observer observer); void notifyObservers(); } -
定义观察者接口 (Observer Interface): 这个接口声明了
update()
方法，当主题状态改变时，观察者会调用这个方法。立即学习“Java免费学习笔记（深入）”；
public interface Observer { void update(String message); } -
创建具体主题类 (Concrete Subject): 这个类实现了
Subject
接口，并维护一个观察者列表。当状态改变时，它会通知所有观察者。import java.util.ArrayList; import java.util.List; public class ConcreteSubject implements Subject { private Listobservers = new ArrayList<>(); private String message; public String getMessage() { return message; } public void setMessage(String message) { this.message = message; notifyObservers(); } @Override public void attach(Observer observer) { observers.add(observer); } @Override public void detach(Observer observer) { observers.remove(observer); } @Override public void notifyObservers() { for (Observer observer : observers) { observer.update(message); } } } -
创建具体观察者类 (Concrete Observer): 这个类实现了
Observer
接口，并定义了接收通知后的具体行为。public class ConcreteObserver implements Observer { private String name; public ConcreteObserver(String name) { this.name = name; } @Override public void update(String message) { System.out.println(name + " received message: " + message); } } -
使用观察者模式:
public class Main { public static void main(String[] args) { ConcreteSubject subject = new ConcreteSubject(); ConcreteObserver observer1 = new ConcreteObserver("Observer 1"); ConcreteObserver observer2 = new ConcreteObserver("Observer 2"); subject.attach(observer1); subject.attach(observer2); subject.setMessage("Hello, Observers!"); subject.detach(observer1); subject.setMessage("Goodbye, Observer 1!"); } }
观察者模式在实际项目中有哪些应用场景？
观察者模式在实际项目中有很多应用场景，比如：
- GUI 事件处理： 比如按钮点击事件，多个组件可能需要响应这个事件。
- 消息队列： 生产者发布消息，多个消费者订阅消息。
- 状态更新： 比如订单状态更新，需要通知物流系统、支付系统等。
- 数据同步： 比如数据库数据更新，需要同步到缓存系统。
- 监控系统： 监控系统监控服务器状态，当服务器状态发生变化时，需要通知管理员。
观察者模式与发布/订阅模式的区别是什么？
虽然观察者模式和发布/订阅模式很相似，但它们之间存在一些关键区别：
- 耦合度： 观察者模式中，观察者直接订阅主题，观察者和主题之间是直接耦合的。而发布/订阅模式中，发布者和订阅者通过消息代理进行通信，发布者和订阅者之间是解耦的。
- 消息过滤： 观察者模式中，主题会将所有消息通知给所有观察者，观察者需要自己过滤消息。而发布/订阅模式中，消息代理可以根据订阅者的需求过滤消息。
- 复杂性： 观察者模式相对简单，容易实现。而发布/订阅模式相对复杂，需要引入消息代理。
简单来说，观察者模式更适合于小规模的应用，而发布/订阅模式更适合于大规模的分布式系统。 我个人感觉，很多时候界限并没有那么清晰，甚至有些地方会混用这些概念。
如何避免观察者模式中的循环依赖问题？
循环依赖指的是观察者A观察主题B，主题B又观察观察者A，这样就形成了一个循环依赖。这会导致程序陷入死循环。
避免循环依赖的方法有很多，这里列举一些常用的方法：
- 使用弱引用： 使用弱引用可以避免观察者和主题之间的强引用，从而避免循环依赖。
- 使用事件队列： 将事件放入队列中，异步处理事件，避免立即通知观察者。
- 使用中间层： 引入一个中间层，观察者和主题都依赖于中间层，从而避免直接依赖。
- 仔细设计： 在设计系统时，仔细考虑对象之间的依赖关系，避免出现循环依赖。
实际开发中，我遇到过因为循环依赖导致程序崩溃的情况，当时排查了很久才找到原因，所以一定要注意避免循环依赖。
观察者模式的优缺点是什么？
优点：
- 解耦： 主题和观察者之间解耦，可以独立地修改主题和观察者。
- 扩展性： 可以方便地添加新的观察者，而不需要修改主题的代码。
- 灵活性： 可以动态地添加和删除观察者。
缺点：
- 性能问题： 如果观察者过多，或者通知过于频繁，可能会影响性能。
- 循环依赖： 容易出现循环依赖问题。
- 通知顺序： 无法保证通知的顺序。 这个问题其实挺让人头疼的，尤其是当观察者之间存在依赖关系时。
如何在多线程环境下使用观察者模式？
在多线程环境下使用观察者模式需要注意线程安全问题。 最常见的问题就是多个线程同时修改观察者列表，导致数据不一致。
以下是一些解决线程安全问题的方法：
- 使用同步锁： 在添加、删除和通知观察者时，使用同步锁来保护观察者列表。
-
使用并发集合： 使用
ConcurrentHashMap
或CopyOnWriteArrayList
等并发集合来存储观察者。 - 使用线程池： 将通知操作放入线程池中执行，避免阻塞主线程。
选择哪种方法取决于具体的应用场景。 一般来说，如果观察者列表的修改频率不高，可以使用同步锁。 如果观察者列表的修改频率很高，可以使用并发集合。 如果通知操作比较耗时，可以使用线程池。
除了经典的实现方式，还有没有其他的观察者模式实现方式？
当然有。 除了经典的接口实现方式，还可以使用：
-
Guava EventBus: Guava 库提供了一个
EventBus
类，可以方便地实现观察者模式。 它支持多种事件类型和线程模型，使用起来非常灵活。 -
Spring ApplicationEvent: Spring 框架提供了一个
ApplicationEvent
类，可以用来发布和订阅事件。 它与 Spring 的 IoC 容器集成，使用起来非常方便。 -
RxJava/Reactor: 响应式编程框架 RxJava 和 Reactor 也提供了观察者模式的实现。 它们使用
Observable
和Observer
接口来定义主题和观察者，并提供了丰富的操作符来处理事件流。
选择哪种实现方式取决于具体的项目需求和技术栈。 如果项目已经使用了 Guava 或 Spring，那么可以使用它们提供的事件机制。 如果项目需要处理复杂的事件流，那么可以使用 RxJava 或 Reactor。
