参考:https://blog.csdn.net/likun557/article/details/106045522?utm_medium=distribute.pc_feed.none-task-blog-alirecmd-11.nonecase&depth_1-utm_source=distribute.pc_feed.none-task-blog-alirecmd-11.nonecase&request_id=
答:系统解耦,如果不考虑性能可以采用默认的同步本地事件监听,也就是Spring ApplicationMulticaster. 也可以通过给ApplicationMulticaster设置executor线程池实现异步监听。如果要考虑拓展性和可靠性以及分布式等功能应该考虑采用消息中间件实现。
答:整体来说2种方式,第一种是通过接口的方式,第二种是在方法上使用注解的方式。通过接口实现,需要手动设置到ApplicationMulticaster消息广播者中,如果是注解的方式则会自动在构建Bean的后置处理起PostProcessor进行注册。
答:默认是同步在一个时间分发函数中循环同步执行,如果有给muticaster广播器设置线程池,则会采用线程池异步分发通知。这样设计的目的是为了避免影响主业务的性能。
答:可以通过Spring实现Ordered接口,或者给监听回调加@Order注解,之后在执行监听事件的时候就会按照Ordered顺序调用。由于Ordered接口是作用于排序比较器Comparator,谈不上最终的执行顺序,因此要实现真正的同步顺序执行,得确保Multicaster没有启用线程池,一旦启用了线程池,也就是异步执行了,如此一来最终的执行顺序将得不到保证(不受Ordered接口控制)
Spring的事件通过相比我们自己按照监听者模式的写法,集成了Spring喜欢用的注解,这些注解耦合在了SpringBean的生命周期中,包括了@Evenlistener和@Ordered,
我们可以利用Spring类库实现的抽象类自定义自己事件分发处理业务,免去了从头做起,其他很多事件分发工具类库也可以实现。
硬要说的话,就是我们可以很轻易把这些过程轻易得委托给Spring框架实现。他也遵循了从简单到复杂的设计思路,比如默认可以是简单单线程同步无序地分发。
也提供了线程池扩展口,给我们实现异步分发通知的可能(个人觉得事件大多都是非主要业务,应该是异步的场景多一点)
至于为什么说Spring事件分发器耦合了Spring框架呢?因为所有事件通知组件,包括了广播者,事件定义,监听者都和Spring上下文ApplicationContext捆绑。应该说,只要和Spring有关的一些都是这样。