com.google.common.eventbus.EventBus介紹

以下內容直接翻譯了EventBus的注釋：

com.google.common.eventbus.EventBus介紹：

首先這個類是線程安全的，
分發事件到監聽器，並提供相應的方式讓監聽器注冊它們自己。
EventBus允許組件之間進行 “發布-訂閱” 式的通信，而不需要這些組件彼此知道對方。EventBus是專門設計用來替代傳統的Java進程內的使用顯示注冊方式的事件發布模式。EventBus不是一個通用的發布-訂閱系統，也不是用於進程間通信。
接收事件
一個對象接收事件時，將這樣做：

• 暴露一個public方法 ，稱之為事件訂閱者（subscriber），這個方法接收一個參數，參數的類型是事件期望的類型。
• 用@Subscribe注解標計這個方法
• 通過一個EventBus實例的register(Object)方法注冊自己

提交事件
提交事件時，將簡單的把事件對象作為參數去調用 EventBus實例的pose(Object)方法。EventBus實例將根據事件對象的類型決定如何路由這個事件對象給所有已注冊的監聽器。
事件的路由是基於事件對象的類型—— 一個事件將被交付給可以被分配的任意的訂閱者。這個包括事件對象實現的接口，事件對象的所有的父類，所有被父類實現的接口。
當post方法被調用后，所有對這個事件進行注冊的訂閱者會按順序進行消費， 所以訂閱者會快速合理地運行。如果一個事件可能觸發一個擴展的過程(比如數據庫負載),生成一個線程或隊列之后處理。(一種方便的方法,使用一個AsyncEventBus)。

訂閱方法
事件訂閱者的方法必需只能接受一個參數：事件對象。
訂閱者方法如果拋出異常，EventBus實例將捕獲和記錄異常。很少有方案這樣去處理錯誤，只是在開發時可用於幫助我們發現問題時會這樣做。
EventBus實例保證在同時不會有多個線程調用，除非這個方法通過@AllowConcurrentEvents注解明確允許。如果這個注解沒有出現，訂閱者方法也無需擔心方法被重入，除非在EventBus實例之外有代碼調用該方法。

死事件
如果一個事件被提交了，但是沒有相應的訂閱者接受它，就可以認為這是一個死事件。然后會給系統一個機會來處理這個死事件。可以通過包裝一個類DeadEvent的實例來處理這個死事件。然后可以寫一個類專門負責訂閱死事件。
如果一個訂閱者監聽的事件對象是所有事件的父類，比如這個事件訂閱了一個Object的事件對象，那么將不會出現死事件。

 

原文如下：

Dispatches events to listeners, and provides ways for listeners to register themselves.

The EventBus allows publish-subscribe-style communication between components without requiring the components to explicitly register with one another (and thus be aware of each other). It is designed exclusively to replace traditional Java in-process event distribution using explicit registration. It is not a general-purpose publish-subscribe system, nor is it intended for interprocess communication.

Receiving Events

To receive events, an object should:

1. Expose a public method, known as the event subscriber, which accepts a single argument of the type of event desired;
2. Mark it with a Subscribe annotation;
3. Pass itself to an EventBus instance's register(Object) method.

Posting Events

To post an event, simply provide the event object to the post(Object) method. The EventBus instance will determine the type of event and route it to all registered listeners.

Events are routed based on their type — an event will be delivered to any subscriber for any type to which the event is assignable. This includes implemented interfaces, all superclasses, and all interfaces implemented by superclasses.

When post is called, all registered subscribers for an event are run in sequence, so subscribers should be reasonably quick. If an event may trigger an extended process (such as a database load), spawn a thread or queue it for later. (For a convenient way to do this, use an AsyncEventBus.)

Subscriber Methods

Event subscriber methods must accept only one argument: the event.

Subscribers should not, in general, throw. If they do, the EventBus will catch and log the exception. This is rarely the right solution for error handling and should not be relied upon; it is intended solely to help find problems during development.

The EventBus guarantees that it will not call a subscriber method from multiple threads simultaneously, unless the method explicitly allows it by bearing the AllowConcurrentEvents annotation. If this annotation is not present, subscriber methods need not worry about being reentrant, unless also called from outside the EventBus.

Dead Events

If an event is posted, but no registered subscribers can accept it, it is considered "dead." To give the system a second chance to handle dead events, they are wrapped in an instance of DeadEvent and reposted.

If a subscriber for a supertype of all events (such as Object) is registered, no event will ever be considered dead, and no DeadEvents will be generated. Accordingly, while DeadEvent extends Object, a subscriber registered to receive any Object will never receive a DeadEvent.