在對每個類進行分解之前，我們再來看一下各個類之間的關聯關系：

它有這么幾個字段：

• 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的設計方式，放棄采用統一的接口、統一的事件對象類型。轉而采用基于注解掃描的綁定方式。

其實無論是強制實現統一的接口，還是基于注解的實現方式都是在構建一種關聯關系（或者說滿足某種契約）。很明顯接口的方式是編譯層面上強制的顯式契約，而注解的方式則是運行時動態綁定的隱式契約關系。接口的方式是傳統的方式，編譯時確定觀察者關系，清晰明了，但通常要求有一致的事件類型、方法簽名。而基于注解實現的機制，剛好相反，編譯時因為沒有接口的語法層面上的依賴關系，顯得不那么清晰，至少靜態分析工具很難展示觀察者關系，但無需一致的方法簽名、事件參數，至于多個訂閱者類之間的繼承關系，可以繼承接收事件的通知，可以看作既是其優點也是其缺點。