java中的EventBus事件总线技术

dl810672731

已于 2024-05-27 16:35:16 修改

阅读量850

点赞数 5

分类专栏：个人笔记博客文章标签： java 开发语言

于 2024-05-23 16:46:28 首次发布

本文链接：https://blog.csdn.net/qq_33517635/article/details/139146511

版权

个人笔记博客专栏收录该内容

15 篇文章 0 订阅

订阅专栏

概念

EventBus 中文一般称为“事件总线”。采用发布订阅的模式（有时描述为注册监听的模式），创建并维护一个【事件发送器】，通过【注册器】将【订阅者】注册到【总线】中，维护【事件】和【订阅者】的订阅关系；应用程序运行中，通过【事件发送器】发布具体【事件载体】，然后使用【事件分发器】调用【订阅者】来执行具体的订阅者消费逻辑。

组织结构

eventbus主要有以下几部分组成：
在这里插入图片描述

eventbus、asyncEventBus：事件发送器。

EventBus 本身确实扮演着事件总线的角色。在这一架构中，EventBus 是一个中心化的消息传输机制，允许不同的组件（无论是Android中的Activity、Fragment，Vue中的组件，还是Java应用中的各种对象）通过它来相互通信，而无需这些组件直接引用彼此。组件可以向EventBus发布事件，同时其他组件可以订阅这些事件。EventBus负责匹配和分发这些事件，确保发布的事件能到达所有注册了相应类型事件的订阅者那里。因此，EventBus既是事件的接收站（收集发布的事件），也是转发器（将事件传递给订阅者），实质上起到了事件总线的作用。
事件发送器，尤其是在使用EventBus这一框架的上下文中，它确实就是那个作为通信中枢的“总线”，负责事件的传递与管理

event：事件承载单元，用于携带数据。
SubscriberRegistry：订阅者注册器，将订阅者注册到总线上，即将有注解 Subscribe 的方法和 event绑定起来。

一般的描述中，我们说的是将订阅者注册到事件总线上。这意味着订阅者并不直接注册到某个特定的事件上，而是向事件总线（EventBus）声明自己对某种或某些类型事件的兴趣。事件总线扮演着中介的角色，负责在事件发生时，根据事件类型将事件分发给所有对此事件感兴趣的（即已经注册的）订阅者。因此，表述得更准确一些，是订阅者通过事件总线注册其对特定事件类型的订阅

Dispatcher：事件分发器，调用事件的订阅者来执行逻辑。
Subscriber、SynchronizedSubscriber：订阅者，前者并发订阅，后者同步订阅。

核心类图

在这里插入图片描述

运行原理
在这里插入图片描述

数据结构

订阅关系用线程安全的 map 维护，所谓的【注册】流程，就是启动过程中，去维护这个map (对应源码中的 subscribers)
在这里插入图片描述

源码理解

Subscribe 注解

应用程序编码中，在订阅者类中，一般有如下的写法

public interface BaseSubscriber {


}


/**
* 业务类  ASubscriber
*/

@Component
public class ASubscriber implements BaseSubscriber{

    // 略

    @Subscribe
    public void subscribe(AEvent event){
       // 略
	}
}

以下是注解对应的源码
在这里插入图片描述

@Target(ElementType.METHOD)是Java注解的一个元注解，用于指定被标注的注解可以在哪些类型的Java元素上使用。在这个例子中，@Subscribe注解被定义为只能应用于方法上，因为它的@Target元注解值为ElementType.METHOD。

这意味着当你在代码中看到@Subscribe注解时，它应该被放置在一个方法的声明之前，表示这个方法是一个事件订阅方法。在事件驱动编程中，特别是使用诸如EventBus这样的库时，这样的方法会在对应的事件被发布到EventBus时被自动调用。简言之，通过@Target(ElementType.METHOD)的设定，@Subscribe注解限制了它只能用于标记那些作为事件处理器的方法，从而指导编译器或框架（如EventBus）正确地识别和处理这些方法。

默认单线程

在这里插入图片描述

MoreExecutors.directExecutor()实际上并不是一个典型的线程池实现，它并不提供线程池的功能。从源码角度理解，这个方法返回的是一个DirectExecutor实例，该实例不是一个真正的线程池，而是一个简单的执行器（Executor），它直接在调用它的线程中执行提交的任务，没有线程管理和重用的机制。

注册 register

业务编码实现

TestEventBus 是业务代码。

/**
* 1:Component 注解，目的是托管给spring,这样应用程序启动后，会实例化这个  TestEventBus 的一个实例
* 2:实现 InitializingBean, ApplicationContextAware 接口,重写 afterPropertiesSet 从而将应用中的订阅者注册到总线中（TestEventBus扮演了总线的角色，相当于简单包装了一层 eventBus）
* 3:是否线程安全
* 因为本身 Component 注解决定了 TestEventBus 是单例的,应用程序启动过成中  afterPropertiesSet 可以线程安全的执行
*/
@Component
public class TestEventBus implements InitializingBean, ApplicationContextAware {

    private EventBus eventBus;

    private ApplicationContext applicationContext;

    public void post(Object event) {
        if (eventBus != null) {
            eventBus.post(event);
        }
    }
】	

	
    @Override
    public void afterPropertiesSet() {
    // applicationContext.getBeansOfType(Class<T> type) 方法在 Spring框架中用于查找并返回所有匹配指定类型（或其子类型）的已注册bean实例的集合。这意味着它返回的是类对应的实例对象的集合，而不是类对象（即类定义）本身。
        Map<String, BaseSubscriber> subscriberBeanMap = this.applicationContext.getBeansOfType(BaseSubscriber.class);
        List<BaseSubscriber> subscribers = new ArrayList<>(subscriberBeanMap.values());
		// eventBus = new EventBus() 这里是简单写个事件发送器
		// 如果追求高性能的话，可以灵活传入参数去控制线程池类型和异常处理器，以及线程名称这些，参考 EventBus 的几个构造方法
        eventBus = new EventBus();
        // subscriber 是订阅者的实例对象
        subscribers.forEach(subscriber -> eventBus.register(subscriber));
    }
    

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

在Spring框架中，ApplicationContext是一个核心接口，提供了多种访问和管理bean的能力，包括通过名称获取bean、通过类型获取bean集合等。当你调用getBeansOfType方法时，实际上是期望从Spring IoC容器中获取指定类型的全部bean实例。

关于“哪个ApplicationContext在生效”的问题，这取决于你的应用上下文是如何被初始化和配置的。Spring提供了多种ApplicationContext的实现，比如AnnotationConfigApplicationContext、ClassPathXmlApplicationContext、FileSystemXmlApplicationContext等，具体使用哪种实现取决于你的应用如何启动和配置Spring容器。

如果你在基于Java配置的Spring
Boot应用中，可能通过SpringApplication.run(YourMainClass.class,
args)自动创建了一个ApplicationContext，这时候往往是AnnotationConfigApplicationContext或者更特化的实现（如BootstrapApplicationContext）在背后工作。
如果你的应用使用XML配置，可能会显式创建如ClassPathXmlApplicationContext或FileSystemXmlApplicationContext来加载bean定义。
当你在代码中没有直接指定ApplicationContext的实现类，并且直接使用了getBeansOfType这样的方法，通常意味着这个方法的调用是在某个已经初始化好的ApplicationContext实例上下文中发生的。例如，你可能通过依赖注入的方式获得了对ApplicationContext的引用，或者在某些框架提供的回调方法中（比如实现了ApplicationContextAware接口的类）间接得到了它。

例如，如果你的类实现了ApplicationContextAware接口，Spring会自动将当前的ApplicationContext注入到你的类中，这样你就可以调用getBeansOfType方法了

在Spring框架中，当一个类被@Component标记并且实现了InitializingBean接口时，Spring容器会在以下时机执行该类的afterPropertiesSet方法：Bean的初始化阶段：在所有必需的属性（依赖注入）完成后，Spring容器会自动调用afterPropertiesSet方法。这意味着在该方法被调用之前，所有使用@Autowired或其他注解标记的依赖都已经注入完毕。

关于线程安全性，afterPropertiesSet方法的执行是由Spring容器管理的，它在单例Bean的情况下，通常是在容器初始化单例Bean的线程中执行的。由于Spring默认情况下管理的单例Bean在初始化后会被缓存，并且在后续请求中复用，因此对于单例Bean而言，afterPropertiesSet方法通常只会在容器启动时被执行一次，这时是线程安全的，因为容器初始化过程通常是同步进行的。

然而，需要注意的是，尽管afterPropertiesSet方法的调用时机本身是线程安全的，但该方法内部的操作仍然需要考虑线程安全。如果你在afterPropertiesSet方法中执行了修改共享状态的操作，你需要自行确保这些操作是线程安全的，尤其是在涉及到非final的实例字段或静态字段时。如果Bean的设计导致了状态的共享，你可能需要使用锁机制（如synchronized关键字或Lock接口）或其他并发控制工具来保护这些状态，以防止多线程并发访问导致的问题。

总之，afterPropertiesSet的调用时机由Spring容器保证线程安全，但方法内的逻辑需要根据实际情况来确保线程安全。

findAllSubscribers 方法如下：根据入参数的订阅者类型，取出订阅者类中被声明为 Subscribe 的方法，

发布 post

业务编码实现

见 TestEventBus 类的post 方法

相关源码

在这里插入图片描述
214行，入参数传入具体的事件对象，
215行，通过最初启动后维护好的订阅关系，查到对应事件的订阅者集合。
217行，通过调用事件分发器的 dispatch 方法，执行具体的订阅者逻辑。其参数中第2个参数是具体的订阅者集合。
218行，如果此事件没有对应的订阅者，则视为死亡事件。
在这里插入图片描述
以下是分发器的3种实现类。具体使用哪种实现类，取决于创建 EventBus时的传入参数。默认是 PerThreadQueuedDispatcher

进入分发器的 dispatch 逻辑：
从数据结构上使用了 ThreadLocal，目的在于在同一个EventBus中，发送器 PerThreadQueuedDispatcher 是一个成员变量。当并发调用 EventBus 的post方法时，对于
PerThreadQueuedDispatcher 来说，等价于并发调用 dispatch 方法。EventBus 类中对于 dispatch 是同步调用的，需要等待 dispatch 的阻塞时间。在同一个 EventBus 中，多次调用post 方法的时候，各个post方法之间是串行的。综上所述，为了提高并行度，PerThreadQueuedDispatcher 在执行 dispatch 方法时，采用了 ThreadLocal 的数据结构去维护n个线程请求对应的线程上线文信息，可以理解为提高了 PerThreadQueuedDispatcher#dispatch方法的并行度。从而提高上层post 方法的执行效率。
在这里插入图片描述

Queue 的使用，这里使用队列，目的在于提高单线程情况下频繁调用 dispatch 的执行效率。
每个线程对应一个队列。
当线程T1，循环调用 dispatch 方法时，101行首次加入队列尾部，会在首次调用时103行设置为 true，表示T1线程正在处理中。后续107行从头部取出元素处理。109行内部异步执行。
循环调用T1期间，101行正常入队列，102行是否进去需要依据最初114行是否执行完毕。因为在当前的实现中，dispatch 在一个线程内部是单线程执行的，所以即便是T1线程循环调用 dispatch，第1次的调用依然会执行完112行的代码段，第2次调用的102行依然会是 this.dispatching.get() == false.‘
从实际效果来看，还是单线程内部顺序执行的对 Queue 的处理。
在这里插入图片描述
109行进去后，如下，是线程池里提交执行的。

这段代码定义了一个 invokeSubscriberMethod 方法，它的主要职责是使用反射来调用某个预设的 method，并将 event 作为参数传递给该方法。这个方法带有 @VisibleForTesting
注解，表明它主要是为了测试目的而设计为可见的，可能在类的正常运行时逻辑中并不直接被外部调用。下面是该方法的关键点分析：

反射调用: 使用 method.invoke(target, checkNotNull(event))
来动态地调用目标对象(target)上的方法，并传入事件(event)作为参数。这里假设 method
是一个之前通过其他方式（如在订阅事件时）获得的 java.lang.reflect.Method 实例，而
checkNotNull(event) 确保了事件参数不为 null，以防止空指针异常。

异常转换和重新抛出:

IllegalArgumentException: 如果方法调用因参数不合法被拒绝（例如，类型不匹配），则捕获此异常并将其转换为
Error，附带详细的错误信息，表明是参数问题导致的。 IllegalAccessException:
如果在调用时失去了访问权限（这在正常的运行环境中应该很少发生，除非有安全管理器的介入），同样转换为 Error 并提供相关信息。
InvocationTargetException: 当被调用的方法内部抛出异常时被捕获。如果该异常是 Error
的实例，则直接重新抛出；否则，原样抛出 InvocationTargetException，保留原始的异常链，以便于调试和问题追踪。
测试友好: 由于标记了
@VisibleForTesting，说明这个方法的设计考虑到了单元测试的需求，允许测试代码直接调用它来验证事件处理逻辑是否正确，包括异常处理路径是否按预期工作。

总之，invokeSubscriberMethod
是事件处理机制的核心部分，它负责执行实际的事件处理逻辑，同时通过细致的异常处理确保了错误情况下的健壮性和可调试性，且对测试友好，便于进行单元测试和功能验证。