观察者模式的定义：
观察者模式（Observer Pattern）也叫发布订阅模式（Publish/Subscribe），它是一个在项目中经常使用到的模式，其定义如下：
Define a one-to-many dependency between objects so that when one object change state,all its dependents are notified and update automatically.（在多个对象之间定义一对多的依赖关系，当一个对象的状态发生改变时，会通知依赖于它的对象，并根据新状态做出相应的反应。）
观察者模式通用类图如下：
观察者模式具有几个角色：
- Subject被观察者 定义被观察者必须实现的职责，它必须能够动态地增加、取消观察者。它一般是抽象类或者是实现类，仅仅完成作为被观察者必须实现的职责：管理观察者并通知观察者。
- Observer观察者 观察者接收到消息后，即进行update操作，对接收到的信息进行处理。
- ConcreteSubject具体的被观察者 定义被观察者自己的业务逻辑，同时定义对哪些事件进行通知。
- ConcreteObject具体的观察者 每个观察在接收到消息后的处理反应是不同，各个观察者有自己的业务逻辑。
代码清单1：Subject.java （被观察者）
import java.util.Vector;/** * 被观察者 * * @author Barudisshu */public class Subject { //定义一个观察者数组 private Vector obsVector = new Vector<>(); /** * 增加一个观察者 */ public void addObserver(Observer o) { this.obsVector.add(o); } /** * 删除一个观察者 */ public void delObserver(Observer o) { this.obsVector.remove(o); } /** * 通知所有观察者 */ public void notifyObservers() { for (Observer o : this.obsVector) { o.update(); } }} 被观察者职责非常简单，就是定义谁能够观察，谁不能够观察，程序中使用ArrayList类和使用Vector没有太大的区别，ArrayList是线程异步，不安全；Vector是线程同步，安全——就这点区别。
代码清单2：ConcreteSubject.java （具体被观察者）
/** * 具体被观察者 * * @author Barudisshu */public class ConcreteSubject extends Subject { /** * 具体的业务 */ public void doSomething() { super.notifyObservers(); }} 这是一个比较纯净的被观察者，在具体项目中有很多变化，并且被观察者可以有很多个。
代码清单3：Observer.java （观察者）
/** * 观察者 * * @author Barudisshu */public interface Observer { /** * 更新方法 */ public void update();} 代码清单4：ConcreteObserver.java （具体观察者）
/** * 具体观察者 * * @author Barudisshu */public class ConcreteObserver implements Observer { @Override public void update() { System.out.println("接收到信息并进行处理！"); }} 代码清单5：Client.java （场景类）
/** * 场景类 * * @author Barudisshu */public class Client { public static void main(String[] args) { //创建一个被观察者 ConcreteSubject subject = new ConcreteSubject(); //定义一个观察者 Observer observer = new ConcreteObserver(); //观察者观察被观察者 subject.addObserver(observer); //被观察者开始活动 subject.doSomething(); }} 运行结果显而易见，如下：
观察者模式的应用
观察者模式的优点
- 观察者和被观察者之间是耦合关系 如此设计，即使是增加观察者还是被观察者都非常容易扩展，而且在Java中都已经实现抽象层的定义，在系统扩展方面更是得心应手。
- 建立一套触发机制 根据单一职责原则，每个类的职责是单一的，如果一个对象既是观察者又是被观察者，则能实现链条式的触发机制。
观察者模式的缺点
观察者模式需要考虑开发效率和运行效率问题，一个被观察者，多个观察者，开发和调试就会比较复杂，而且在Java中消息的通知默认是顺序执行的，一个观察者卡壳，会影响整体的运行效率。在这种情况下，一般考虑使用异步的方式。
观察者模式的使用场景
- 关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”的关系。
- 事件多级触发场景。
- 跨系统的消息交换场景，如消息队列处理机制。
观察者模式的注意事项
使用观察者模式也有一下两点问题需要解决：
- 广播链的问题 如果你做过数据库的触发器，你就应该知道有一个触发器链的问题，比如表A上写了一个触发器，内容是一个字段更新后更新表B的一条数据，而表B上也有一个触发器，要更新表C，表C也有一个触发器… 完蛋了，这个数据库基本上就毁了！我们观察者模式也是同样的问题，一个观察者可以有双重身份，既是观察者，也是被观察者，这没什么问题，但是链一旦建立起来，这个逻辑就比较复杂，可维护性非常差，根据经验建议，在一个观察者模式中最多出现一个对象既是观察者也是被观察者，也就是说消息最多转发一次（传递两次），这还是比较好控制的。
- 异步处理问题 被观察者发生动作了，观察者要做出回应，如果观察者比较多，而且处理时间比较长怎么办？那就需要使用异步处理机制。
观察者模式的扩展
Java世界中的观察者模式
事实上，Java的JDK中提供了：java.util.Observable实现类和java.util.Observer接口，所以我们可以完全用JDK中的类来实现观察者模式，并且是线程安全的。
代码清单6：ConcreteSubject.java （具体的被观察者）
import java.util.Observable;/** * 继承自API的Observable，其中Observable具有线程安全机制。 * * @author Barudisshu */public class ConcreteSubject extends Observable { //具体业务 public void doSomething() { System.out.println("韩信:我要吃饭了。"); //通知所有的观察者 super.setChanged(); super.notifyObservers("间谍：韩信要去吃饭了。"); } public void doOtherthing() { System.out.println("韩信:我要娱乐一下。"); //通知所有的观察者 super.setChanged(); super.notifyObservers("间谍：韩信要娱乐一下。"); }} 代码清单7：ConcreteObserver.java （具体的观察者）
import java.util.Observable;import java.util.Observer;/** * 具体的观察者 * * @author Barudisshu */public class ConcreteObserver implements Observer { @Override public void update(Observable o, Object obj) { System.out.println("观察到目标有活动，开始汇报！"); System.out.println(obj); System.out.println("汇报完毕！"); }} 代码清单8：Client.java （修改后的场景类）
/** * * @author Barudisshu */public class Client { public static void main(String[] args) { //创建一个被观察者 ConcreteSubject subject = new ConcreteSubject(); //定一个不同的观察者 ConcreteObserver obs = new ConcreteObserver(); //观察者观察被观察者 subject.addObserver(obs); //被观察者开始活动了 subject.doSomething(); subject.doOtherthing(); }} 运行结果如下：
项目中真实的观察者模式
为什么说是“真实”呢？因为我们刚刚讲的那些都是标准的模式，在系统设计中会对观察者模式进行改造和改装，主要在一下3个方面。
- 观察者和被观察者之间的消息沟通 被观察者状态改变会触发观察者的一个行为，同时会传递一个消息给观察者，这是正确的，在实际中一般的做法是：观察者中的update方法接收两个参数，一个是被观察者，一个是DTO（Data Transfer Object，数据传输对象），DTD一般是一个纯洁的JavaBean，由被观察者生成，由观察者消费。 当然，如果考虑到远程传输，一般消息是以XML传输。
- 观察者响应方式 为了提高系统的性能，观察者响应方式有两种：一是，采用多线程技术，甭管是被观察者启动线程还是被观察者启动线程，都可以明显提高系统性能，这也就是大家通常所说的异步架构；二是，采用缓存技术，甭管你谁来，我都有足够的资源给你，我保证快速响应，这当然也是一个比较好的方案，代价就是开发难度很大，而且压力测试要做的足够充分，这种方案也是大家所说的同步架构。
- 被观察者尽量自己做主 也就是说，被观察者对自己的业务逻辑要灵活考虑，决定是否要通知观察者。
订阅发布模式
观察者模式也叫订阅发布模式（Publish/Subscribe），如果你做过EJB（Enterprise JavaBean）的开发，这个你绝对不会陌生。在EJB中有3个类型的Bean：Session Bean、Entity和MessageDriven Bean，我们这里来说一下MessageDriven Bean，消息驱动Bean，消息的发布者（Provider）发布一个消息，也就是一个消息驱动Bean，通过EJB 容器通知订阅者做出回应，从原理上看很简单，就是观察者模式的升级版，或者说是观察者模式的BOSS版。