聊聊Spring事件：一些自己的QA

爱跑步的猕猴桃發表於2024-12-10
Spring事件

關於Spring事件機制Q&A

使用者提問：

Spring事件機制是否可以理解為系統內部的小型訊息佇列，任何被容器管理的bean都可以是生產者，釋出的事件可以被監聽（消費），也可以不被監聽（類似於SpringBoot釋出的各種事件也是為了擴充套件用的）。

回答：

Spring 的事件機制確實有點類似於一個輕量級的訊息佇列，但與完整的訊息佇列（如 Kafka、RabbitMQ）相比，Spring 的事件機制是為了在應用內部進行解耦和擴充套件設計的。具體表現：

  1. 事件釋出者：任何被 Spring 容器管理的 Bean 都可以釋出事件。
  2. 事件監聽者：任何實現了監聽邏輯的 Bean 都可以消費事件。
  3. 事件傳遞：事件是透過 Spring 的 ApplicationEventMulticaster 在容器內進行分發的，可以被一個或多個監聽者消費，也可以不被任何人監聽（被丟棄）。
  4. 用途：常用於模組之間的松耦合通訊和擴充套件機制（如 Spring Boot 的啟動事件）。

使用者提問：

Spring的事件機制會出現事件傳送失敗或者事件監聽失敗的情況嗎？

回答：

Spring 的事件機制是基於方法呼叫的，本質上較為簡單，因此：

  1. 事件傳送失敗：通常不會出現，只要呼叫了 publishEvent 方法，事件就會成功釋出到 ApplicationEventMulticaster 中。

    • 可能的異常場景：未配置正確的事件釋出器或釋出器被銷燬。

  2. 事件監聽失敗：可能會發生，例如：

    • 監聽器丟擲未捕獲的異常，導致處理失敗。
    • 非同步監聽器可能因執行緒池耗盡或配置錯誤而處理失敗。

解決辦法是為監聽器增加異常處理機制，例如使用 try-catch 塊捕獲異常。

使用者提問：

如果一個事件有多個監聽器監聽，具體監聽處理邏輯是怎麼樣的？

回答：

如果一個事件有多個監聽器監聽，Spring 的事件機制會依次將事件傳遞給每個監聽器進行處理。具體邏輯如下：

  1. 按順序呼叫監聽器：
    Spring 使用 ApplicationEventMulticaster 查詢所有匹配事件型別的監聽器，並逐一呼叫這些監聽器的方法。

  2. 預設無順序保證：

    • 預設情況下，監聽器的執行順序是不確定的。
    • 如果需要指定順序，可以使用 @Order 註解（或實現 Ordered 介面）。

示例：

@Component
@Order(1)
public class ListenerA implements ApplicationListener<MyEvent> {
    public void onApplicationEvent(MyEvent event) {
        System.out.println("Listener A handling event.");
    }
}
@Component
@Order(2)
public class ListenerB implements ApplicationListener<MyEvent> {
    public void onApplicationEvent(MyEvent event) {
        System.out.println("Listener B handling event.");
    }
}

在上面的例子中，ListenerA 會在 ListenerB 之前被呼叫。

  1. 非同步監聽器的特殊性：
    如果某個監聽器標記為非同步（@Async），它的執行會交由執行緒池完成，不會阻塞事件釋出者執行緒。

使用者提問：

是否可以理解Spring的事件監聽，是執行緒之間的一種通訊方式，傳送事件的是一個執行緒，監聽事件的又是其他一個執行緒。

回答：

Spring 的事件機制可以支援兩種執行緒模型：

  1. 同步事件監聽（預設行為）：

    • 事件釋出者執行緒會直接呼叫監聽器的邏輯。
    • 釋出事件和監聽器處理事件都發生在同一個執行緒中，因此不涉及執行緒之間的通訊。

  2. 非同步事件監聽（透過 @Async 實現）：

    • 如果監聽器方法加了 @Async 註解，監聽器的處理邏輯會被交給執行緒池中的其他執行緒執行。
    • 此時可以理解為釋出事件的執行緒和監聽事件的執行緒之間進行了一次通訊。

示例：

@Component
public class MyAsyncEventListener {
    @Async
    @EventListener
    public void handleEvent(MyCustomEvent event) {
        System.out.println("Async listener processing event: " + event);
    }
}

使用者提問：

同步事件是不是可以近似的看作是釋出者執行緒呼叫了很多方法，以序列的方式依次執行所有的方法。

回答：

完全正確！同步事件在本質上就是釋出者執行緒呼叫了一系列方法（監聽器的處理方法），並且以序列的方式依次執行，直到所有監聽器完成處理後，釋出者執行緒才會繼續執行。

使用者提問：

那我有更深一步的理解：

  1. Spring事件機制，首先事件機制的發起物件必須註冊在Spring容器。
  2. 同步事件是一個釋出者執行緒阻塞的過程，釋出事件以後釋出者執行緒會等待所有監聽事件的執行緒處理事件到結束。
  3. 如果無人消費的話，同步事件的釋出者執行緒不會被阻塞。
  4. 非同步事件釋出者不會被阻塞也不關心事件後續的處理結果，事件會交由非同步執行緒池來處理。

回答：

你的理解是完全正確的！以下是詳細補充：

  1. 事件發起物件必須註冊在 Spring 容器：
    只有被 Spring 管理的 Bean 才能釋出和監聽事件。非 Spring 容器管理的物件無法使用事件機制。
  2. 同步事件是阻塞的：
    釋出者執行緒會等待所有監聽器依次執行完畢後，才繼續執行釋出事件後的邏輯。
  3. 無人消費的情況下不會阻塞：
    如果沒有監聽器監聽事件，Spring 會直接跳過處理邏輯，釋出者執行緒不會被阻塞。
  4. 非同步事件交由執行緒池：
    非同步事件不會阻塞釋出者執行緒，監聽器的處理完全由執行緒池中的執行緒執行，釋出者執行緒和監聽器執行緒互不干擾。

使用者提問：

比如我現在程式裡即有定時任務，也有非同步事件需要監聽，也有非同步方法。那我是否可以自定義三個執行緒池，分別來執行這三個任務？

回答：

是的，完全可以！ 為了合理分配資源、避免任務之間相互干擾，為定時任務、非同步事件監聽、非同步方法分別自定義執行緒池是一種非常好的實踐。

相關文章