在对每个类进行分解之前，我们再来看一下各个类之间的关联关系：

它有这么几个字段：

• identifier：事件总线的标识，这说明在一个应用里是可以有多个EventBus的。如果不指明它的值，它将以“default”作为其默认名称。
• executor：它是Executor接口的实例，用于对订阅者处理事件方法的执行。这里需要注意的是，该字段的实例化是在EventBus内部构造器中，并不是从外部注入进来的，另外真正的执行订阅者方法的时机也不由EventBus负责，而是由Subscriber负责，因此该字段会被公开给外部访问。
• exceptionHandler：它是SubscribeExceptionHandler的实例，用于处理订阅者在执行事件处理方法时抛出的异常。EventBus可以接收一个外部定义的异常处理器，也可以采用内部缺省的日志记录处理器。
• subscribers：订阅者注册表，用于存储所有的事件以及事件处理器、订阅对象的对应关系。
• dispatcher：事件分发器，用于分发事件给订阅对象的事件处理器，该对象在EventBus构造方法内部初始化，默认的实现是PerThreadQueuedDispatcher，该分发器将事件存入队列，并保证在同一个线程上发送的事件能够按照他们发布的顺序被分发给所有的订阅者。

• register：注册subscriber；
• unregister：移除注册过的subscriber；
• post：发布事件；

一个支持异步发布模式的EventBus，它覆盖了EventBus的默认构造方法，指定了一个异步的分发器：LegacyAsyncDispatcher，这个分发器基于一个全局的队列来暂存未发布的事件。

之前也提到Subscriber的名称是比较容易混淆的。这个类的名称看似表示一个订阅者对象，但其实是用来封装“一个订阅者的一个事件处理器”对象。因为当一个订阅者存在多个处理方法被标注为@Subscribe的时候，那么每个处理方法都对应于一个独立的Subscriber对象的实例。我个人觉得这个名称与其具体的实现语义有些混淆。当然也许实现者认为：一个对象以及一个事件处理器就是一个Subscriber的话，那是没有问题的。因此这里为了理解方便，你可以将其看做是一个封装了订阅者对象以及一个订阅者处理器方法的实体类。

Subscriber的访问级别是package的，它还承担了执行事件处理的责任。通过一个create静态工厂方法创建它：

static Subscriber create(EventBus bus, Object listener, Method method) {return isDeclaredThreadSafe(method)? new Subscriber(bus, listener, method): new SynchronizedSubscriber(bus, listener, method);}

它接收三个参数：

• bus：EventBus的实例，通过它来获取事件的执行器（executor）
• listener：真实的订阅者对象
• method：订阅对象的事件处理方法的Method实例

该类的两个关键方法之一：

dispatchEvent:

final void dispatchEvent(final Object event) {executor.execute(new Runnable() {@Overridepublic void run() {try {invokeSubscriberMethod(event);} catch (InvocationTargetException e) {bus.handleSubscriberException(e.getCause(), context(event));}}});}

它调用一个多线程执行器来执行事件处理器方法。

另一个方法：invokeSubscriberMethod以反射的方式调用事件处理器方法。

另外，该类对Object的equals方法进行了override并标识为final。主要是为了避免同一个对象对某个事件进行重复订阅，在SubscriberRegistry中会有相应的判等操作。当然这里Subscriber也override并final了hashCode方法。这是最佳实践，不必多谈，如果不了解的可以去看看《Effective Java》。

该类还有个内部类，就是我们上面谈到的SynchronizedSubscriber，它继承了Subscriber，与Subscriber唯一的不同就是在invokeSubscriberMethod的执行上做了同步。

针对单个EventBus的订阅与事件的关系维护。在内部用来存储订阅者关系的对象是java并发包下的并发Map:ConcurrentMap，该map以Class对象为键，值的类型是CopyOnWriteArraySet<Subscriber>集合类型。

SubscriberRegistry直接依赖EventBus对象，所以在构造器中需要注入EventBus的实例。

SubscriberRegistry里有两个关键的实例方法：register/unregister。

接收订阅者对象作为参数并建立Event跟Subscriber的关联关系。

我们来看看它的实现：

void register(Object listener) {Multimap<Class<?>, Subscriber> listenerMethods = findAllSubscribers(listener);for (Map.Entry<Class<?>, Collection<Subscriber>> entry : listenerMethods.asMap().entrySet()) {Class<?> eventType = entry.getKey();Collection<Subscriber> eventMethodsInListener = entry.getValue();CopyOnWriteArraySet<Subscriber> eventSubscribers = subscribers.get(eventType);if (eventSubscribers == null) {CopyOnWriteArraySet<Subscriber> newSet = new CopyOnWriteArraySet<Subscriber>();eventSubscribers = MoreObjects.firstNonNull(subscribers.putIfAbsent(eventType, newSet), newSet);}eventSubscribers.addAll(eventMethodsInListener);}}

它首先获得一个Multimap实例（它是Google Guava集合框架提供的一个多值Map类型，也就是说一个key可以对应多个value），该Multimap用于存储事件类型对应的该订阅者内所有关于该事件的处理器方法集合，其key为事件的Class类型。这里在for循环的中通过asMap获取其map视图，即可将Multimap对应的多个值存储到一个Collection中。

也就是说这里for循环的每个entry，表示的是一个事件的Class实例对应的一组Subscriber的集合，即eventMethodsInListener。

然后根据该事件的Class对象从注册表中获取对应的存储Subscriber实例的集合，如果不存在则创建该集合，然后将该订阅者内所有的事件处理器方法都加入到注册表中去。

unregister的实现跟register有些类似，先查找该订阅者所有的事件类型与处理器的对应关系。然后，遍历所有的事件类型，移除针对当前订阅者的所有Subscriber实例。

register/unregister方法都调用了findAllSubscribers方法，它有一些特别之处，这里需要单独拎出来提一下。

findAllSubscribers用于查找事件类型以及事件处理器的对应关系。查找注解需要涉及到反射，通过反射来获取标注在方法上的注解。因为Guava针对EventBus的注册采取的是“隐式契约”而非接口这种“显式契约”。而类与接口是存在继承关系的，所有很有可能某个订阅者其父类（或者父类实现的某个接口）也订阅了某个事件。因此这里的查找需要顺着继承链向上查找父类的方法是否也被注解标注，代码实现：

  private Multimap<Class<?>, Subscriber> findAllSubscribers(Object listener) {Multimap<Class<?>, Subscriber> methodsInListener = HashMultimap.create();Class<?> clazz = listener.getClass();for (Method method : getAnnotatedMethods(clazz)) {Class<?>[] parameterTypes = method.getParameterTypes();Class<?> eventType = parameterTypes[0];methodsInListener.put(eventType, Subscriber.create(bus, listener, method));}return methodsInListener;}

同样涉及这个问题的，还有根据事件类型获取Subscriber实例的方法：getSubscribers。

  Iterator<Subscriber> getSubscribers(Object event) {ImmutableSet<Class<?>> eventTypes = flattenHierarchy(event.getClass());List<Iterator<Subscriber>> subscriberIterators =Lists.newArrayListWithCapacity(eventTypes.size());for (Class<?> eventType : eventTypes) {CopyOnWriteArraySet<Subscriber> eventSubscribers = subscribers.get(eventType);if (eventSubscribers != null) {// eager no-copy snapshotsubscriberIterators.add(eventSubscribers.iterator());}}return Iterators.concat(subscriberIterators.iterator());}

Dispatcher

abstract void dispatch(Object event, Iterator<Subscriber> subscribers);

另一个异步分发器的实现：LegacyAsyncDispatcher，之前在介绍AsyncEventBus的时候提到，它就是用这种实现来分发事件。

它在内部通过一个ConcurrentLinkedQueue<EventWithSubscriber>的全局队列来存储事件。从关键方法：dispatch的实现来看，它跟PerThreadQueuedDispatcher的区别主要是两个循环上的差异（这里基于队列的缓存事件的方式，肯定会存在两个循环：循环取队列里的事件以及循环发送给Subscriber）。

PerThreadQueuedDispatcher：是两层嵌套循环，外层是遍历队列取事件，内存是遍历事件的订阅处理器。

LegacyAsyncDispatcher：是一前一后两个循环。前面一个是遍历事件订阅处理器，并构建一个事件实体对象存入队列。后一个循环是遍历该事件实体对象队列，取出事件实体对象中的事件进行分发。

其实以上两个基于中间队列的分发实现都可以看做是异步模式，而ImmediateDispatcher则是同步模式：只要有事件发生就会立即分发并被立即得到处理。ImmediateDispatcher从感官上看类似于线性并顺序执行，而采用队列的方式有多线程汇聚到一个公共队列的由发散到聚合的模型。因此，ImmediateDispatcher的分发方式是一种深度优先的方式，而使用队列是一种广度优先的方式。

它是一个实体对象，封装了没有订阅者的事件。DeadEvent由两个属性组成：

• source：事件源（通常指发布事件的EventBus对象）
• event：事件对象

Guava的EventBus源码还是比较简单、清晰的。从源码来看，它一番常用的Observer的设计方式，放弃采用统一的接口、统一的事件对象类型。转而采用基于注解扫描的绑定方式。

其实无论是强制实现统一的接口，还是基于注解的实现方式都是在构建一种关联关系（或者说满足某种契约）。很明显接口的方式是编译层面上强制的显式契约，而注解的方式则是运行时动态绑定的隐式契约关系。接口的方式是传统的方式，编译时确定观察者关系，清晰明了，但通常要求有一致的事件类型、方法签名。而基于注解实现的机制，刚好相反，编译时因为没有接口的语法层面上的依赖关系，显得不那么清晰，至少静态分析工具很难展示观察者关系，但无需一致的方法签名、事件参数，至于多个订阅者类之间的继承关系，可以继承接收事件的通知，可以看作既是其优点也是其缺点。