举例场景说明；一个人一直在看电影，当电影播放到4秒的时候，这个人要去上厕所。
图1
图2
首先设置一个标记来标记是否已经到了需要上厕所的时间。如果到了把他改为true;
图3
这个人一直在看电影直到电影那边返回true他才要去上厕所。
run方法以下面的为准。
通过上面的例子我们发现，这个人一直在看电影，一直在while循环中，这样cpu消耗很大。我们能不能改成这样比如电影在播出4秒后主动通知这个人呢，这样这个人就可以做其他事情，没有必要一直在while循环中。
这个就是所谓的观察者模式。
图4
被观察者持有观察者的引用。下面是修改后的
图5
图6
改成这样但是问题又来了，如果这个电影有温情的片段，应该有落泪的动作，有搞笑的片段，应该笑等动作，而不单单只是上厕所这么一个动作。那么 我们可以把温情的片段，搞笑的片段抽取为一个事件。这个事件可以根据不同的片段场景来做不同的动作。
图7
这个是事件类。source是事件源；为什么要有事件源呢，举例，吃饭可能对应多个事件源，人，饭，筷子，等事件源。
图8
图9
图10
执行结果。问题来了。如果不是一个人看电影，多个人看电影咋办。多个人看电影的同一个场景有可能有不同的动作。例如a 看到温情会调眼泪，b看到温情会大笑。
图11
不可能在这个里面在传入一个b人的参数吧，如果多个人，难道要传n个参数吗， 于是就有了监听器的概念（监听器里抽象出一个公共的动作方法接口，每一个人均要实现他这个方法，来执行不同的动作），监听器是一个包含多个人的list也可以说是包含多个观察者的list, 对外提供一个add方法。当有一个人的时候，add进去一个人，多个人的时候add多个人，。在事件片段发生的时刻，依次遍历调用每一人的动作方法。
图12
监听器。
图13
图14
图15
图16
图17
jdk的观察者模式。
图18
被观察者。
图18-0
图18-2
图19
观察者
图20
观察者。 Observable为被观察者。
传说中观察者的设计模式可以取消，咋取消啊。图21
图21
结果确实不打印了。这种观察者模式的好处时解耦。
图22
任何一步出现问题，这个订单就下载失败，这个是没有办法接受的。
图23
监听模式是这样，多个监听器来监听，一旦订单生成。第一个监听器负责发红包，第二个负责发短信。如果我们这个是做活动。一旦不需要可以灵活去掉，采用从监听器中移除。这个是jdk的观察者模式，在spring中是什么样的呢，
图24
Spring中观察者模式。
图25
图26
对应的子事件。这几个事件的事件源都是ApplicationContext
图27
图27-1
自定义事件，继承ApplicationEvent
图27-2
自定义监听器。
图27-3
,触发事件，赋值事件源。
图27-4
执行结果。
图28
spring中有个事件委派器，当event1发生事件后通过ApplicationEvenMulticater 委派给listener1.