本文主讲Spring的事件机制，意图说清楚：
- 什么是观察者模式？
- 自己实现事件驱动编程，对标Spring的事件机制
- 彻底搞懂Spring中的事件机制，从而让大家
本文内容较长，代码干货较多，建议收藏后持续阅读。
Spring框架已然是Javaeee开发范畴的霸主，无论是利用SpringBoot还是SpringCloud，都离不开Spring框架。
作为Java开发者，无论是口试求职还是一样寻常开发，就必须得纯熟掌握、运用Spring框架。
因此学习Spring框架源码也就成为了大家最重要的事情之一。
Spring框架中用到的设计模式
Spring框架中运用了大量的设计模式，如果对设计模式掌握的不敷纯熟，阅读源码的时候就会感到很吃力，不明白作者为什么这样写，有时候一个方法一个方法的跟进去，到达一定的深度之后就断了，无法连贯起来，最后不得不放弃。
简单工厂，又叫静态工厂方法模式：Spring中的BeanFactory。
工厂方法模式：Spring中的FactoryBean。
单例模式：Spring中的BeanFactory就是全局单例的，我们一样寻常开发的service默认也是单例模式，单例存在于Spring容器中。
适配器模式：Spring中的AOP、拦截器。
包装器模式：Spring中的各种Wrapper、Decorator。
代理模式：Spring中的AOP就是采用的代理模式，代理有JDK动态代理（JdkDynamicAopProxy）和Cglib代理（Cglib2AopProxy）两种方式。
观察者模式：Spring中的ApplicationListener，事件驱动编程头脑。
策略模式：Spring中在实例化对象的时候用到Strategy模式。
模板方法：Spring中的JdbcTemplate、RestTemplate、RedisTemplate等。
纯熟掌握以上设计模式可以在阅读Spring、SpringBoot等框架源码的时候，可以做到流通无阻。
观察者模式
当一个对象发生改变时候，自动通知其他对象作出相关动作。
当一个事件发生时候，自动触发依赖这个事件的其他事件。
这就是观察者模式要做的事情。
举例：当一个开通会员的订单支付完成之后（第三方支付回调过来了），需要更改订单的支付状态、给用户开通会员、如果有分销的逻辑还要触发分润逻辑、给用户开通其他会员附属权益。伪代码如下：
这种做法是最简单也是最low的方法，如果再有其他业务需要依赖订单回调的话，那么需要订单业务开发职员持续的在这里添加相关业务，或同步或异步调用。
那么如果我发布一个订单事件呢？需要监听该事件的其他业务组自己订阅这个事件就好了，订单业务的开发同学再也不用改动自己业务的代码了。
单体应用下我们通常利用事件驱动的编程模式。分布式应用下大家都会采用消息队列发布-订阅的模式去做这块事情。无论采用哪种方式，其焦点头脑都是观察者模式。
观察者模式中有几个角色：
- 主题：主题中包含多个观察者，以及观察者的添加、删除，同时需要提供触发观察者事件的方法。
- 观察者：也叫监听器，会有多个观察者，差别的观察者监听到事件后做差别的逻辑处理。
自己实现事件驱动编程
先定义好事件的设计，类图如下：
事件定义类图
Event：事件的接口类，可以设置或获取数据EventObject
Event
AbstractEvent：事件抽象实现类，持有EventObject对象，并提供默认实现
AbstractEvent
OrderCallbackEvent：订单回调事件，用于定义具体的事件
OrderCallbackEvent
然后我们来定义事件的监听器（观察者），以及事件广播器（主题），类布局设计如下图：
EventListener：监听器接口类，定义监听器的方法
EventListener
AbstractEventListener：监听器抽象实现类，多了order属性，用于监听器执行顺序
AbstractEventListener
Test1EventListener：事件监听器1
Test1EventListener
Test2EventListener：事件监听器2
Test2EventListener
Test3EventListener：事件监听器3
Test3EventListener
OrderEventMulticaster:事件广播器
EventMulticaster
我们来写一个测试方法，看看当订单完成回调的时候是如何触发这3个监听器的：
运行输出：
可以看见，监听器按照我们给定的order顺序依次执行三个监听器的事件。
上面就是我们自己实现的基于事件驱动的代码，在这个底子上我们还可以针对EventMulticaster广播器再制定特制的OrderEventMulticater以及其他业务的事件广播器。
另外对于每一个监听器我们也可以单独开启一个独立的线程异步去执行监听器里的业务，而不阻塞订单回调事件的执行。
当有新的业务需要订单回调举行触发的时候，就可以再增加一个Listener到监听器集合里面就可以了。不需要再更改订单回调的业务，达到解耦的结果。
Spring的事件机制
Spring中的事件机制有四个关键的类：
ApplicationEvent：事件抽象类，全部的具体事件类都得继承这个类，支持将数据设置到EventObject中：
Spring中的事件有如下几种：
ApplicationListener：事件监听器接口，定义通用方法onApplicationEvent：
ApplicationEventMulticaster：事件广播器接口，用于事件监听器的注册和事件的广播。
ApplicationEventPublisher：事件发布者，调用ApplicationEventMulticaster中的multicastEvent方法触发广播器持有的监听器集合执行onApplicationEvent方法，从而完成事件发布。
Spring中的每一个具体的事件都跟随有一堆的监听器，以及事件的的广播器和发布者。
搞清楚Spring的事件机制可以让我们的Spring的源码阅读之路流通无阻。
大家在阅读文章的过程中，如果有发现不正确的地方，欢迎大家品评指正。也可以利用本日头条APP上分的搜索框搜索更多关于Spring、SpringBoot、SpringCloud等相关技术文章。
相关文章推荐：
源码剖析（一）：SpringBoot是怎么启动的？（基于最新版2.2.0）
源码剖析（二）：SpringBoot是如何一步步加载监听器的？
源码剖析（三）：SpringBoot是怎么执行监听器的？事件驱动头脑
欢迎大家评论、转发，我是java架构设计！关注我，持续为您提供JavaEE范畴优质文章、技术干货。也可以私信我“Spring”获取多线程、高并发、分布式、大数据等相关学习资料。 |
|
|
|
|
|
|
|
|
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
楼主
