概念

观察者模式，原理很简单，把A类的子类分别注入到B类中，通过用B类调用方法，循环调用A类的方法，就是所谓观察者模式

伪代码如下，最快的速度理解观察者模式：

接口 A{// 观察者接口notify();
}
Class A1 extend A{// 等待被调的接口notify(){// A1类特有的实现println(A1被通知);}
}
Class A2 extend A{notify(){println(A2被通知);}
}
Class B{List<A> alist;addA(A a){//将观察者注入到B中alist.add(a);}void notify(){for(A a : alist){// 循环通知每一个A的实现对象a.notify();}}
}
Class Test{main方法(){// 定义通知者BB b = new B();// 将两个观察者A1,A2注册到B中b.addA(new A1());b.addA(new A2());// 当B发出通知后，就会循环调用那些曾经在自己这里注册过的观察者b.notify();}
}

观察者使用场景

上面的伪代码，是最简单的观察者模式的原型。
观察者模式一般用于一个变化（B的notify方法）要引起多个变化（A的notify方法）的场景。比如我执行完一个操作后，需要同时执行好几个方法。

举个例子：消息通知

当系统生成一条消息后，需要同时发送系统消息，邮件消息，短信消息，甚至以后还会有其他类型的消息。
那就可以搞个消息的父类A，定义好发送接口notify。
后面每种消息都是A的子类，然后有着自己的发消息的不同实现。
然后搞个发消息的类B，提前将A的这些子类注册给B，当系统产生消息的时候，只需要调用B的发送，就可以将消息发给各个地方了。

再举个例子：地主剥削

地主就是那个通知者
所有长工都是观察者
每个长工，都要观察地主的命令。比如地主说打扫卫生，然后在地主那里注册的所有长工，都开始打扫卫生。如果新来了长工，那就在地主那里注册下，下次地主再发命令，新来的长工也就和之前的长工一样了。

观察者的优缺点

优点：解耦了观察者，可以很容易的新增多个观察者。
缺点：观察者和通知者耦合，就是上面伪代码中，A和B是耦合的。

为了解决这个缺点，于是有了观察者模式的升级版：发布订阅模式

发布订阅模式

发布订阅模式，一听都比较熟悉，因为我们用的mq就是基于发布订阅模式
发布订阅模式，就是观察者模式的增强版。
哪里增强了呢？我们知道观察者模式中，观察者和通知者是耦合的，是不能随意更换的。那发布订阅模式就是解了这种耦合。
将以前的通知者，叫发布者
将以前的观察者，叫订阅者
然后发布者和订阅者中间有个第三方，记录发布者和订阅者的关系，即谁订阅了谁
那么从此发布者和调用者，就不用互相耦合了。

除了mq，简单的还可以研究下google的eventbus，可以参考我之前的一篇文章，有现成的能运行的例子，可以去感受一下。
spring boot 整合 谷歌guava的EventBus 实现单机版的消息发布订阅