你好呀，我是歪歪。

前段時間看到同事在項目里面使用了一個叫做 @EventLintener 的注解。

在這之前，我知道這個注解的用法和想要達到的目的，但是也僅限于此，其內(nèi)部工作原理對我來說是一個黑盒，我完完全全不知道它怎么就實現(xiàn)了“監(jiān)聽”的效果。

現(xiàn)在既然已經(jīng)出現(xiàn)在項目里面了，投入上生產(chǎn)上去使用了，所以我打算盤一下它，以免以后碰到問題的時候錯過一個裝逼的...

哦，不。

錯過一個表現(xiàn)自己的機會。

Demo

首先，按照歪歪歪師傅的老規(guī)矩，第一步啥也別說，先搞一個 Demo 出來，沒有 Demo 的源碼解讀，就像是吃面的時候沒有大蒜，差點意思。

先鋪墊一個背景吧。

假設(shè)現(xiàn)在的需求是用戶注冊成功之后給他發(fā)個短信，通知他一下。

正常來說，偽代碼很簡單：

boolean success = userRegister(user);
if(success){
    sendMsg("客官，你注冊成功了哦。記得來玩兒~");
}

這代碼能用，完全沒有任何問題。但是，你仔細(xì)想，發(fā)短信通知這個動作按理來說，不應(yīng)該和用戶注冊的行為“耦合”在一起，難道你短信發(fā)送的時候失敗了，用戶就不算注冊成功嗎？

上面的代碼就是一個耦合性很強的代碼。

怎么解耦呢？

應(yīng)該是在用戶注冊成功之后，發(fā)布一個“有用戶注冊成功了”的事件：

boolean success = userRegister(user);
if(success){
    publicRegisterSuccessEvent(user);
}

然后有地方去監(jiān)聽這個事件，在監(jiān)聽事件的地方觸發(fā)“短信發(fā)送”的動作。

這樣的好處是后續(xù)假設(shè)不發(fā)短信了，要求發(fā)郵件，或者短信、郵件都要發(fā)送，諸如此類的需求變化，我們的用戶注冊流程的代碼不需要進行任何變化，僅僅是在事件監(jiān)聽的地方搞事情就完事了。

這樣就算是完成了兩個動作的“解耦”。

怎么做呢？

我們可以基于 Spring 提供的 ApplicationListener 去做這個時間。

我的 Demo 里面用的 Spring 版本是 5.2.10。

這次的 Demo 也非常的簡單，我們首先需要一個對象來封裝事件相關(guān)的信息，比如我這里用戶注冊成功，肯定要關(guān)心的是 userName：

@Data
public class RegisterSuccessEvent {

    private String userName;

    public RegisterSuccessEvent(String userName) {
        this.userName = userName;
    }
}

我這里只是為了做 Demo，對象很簡單，實際使用過程中，你需要什么字段就放進去就行。

然后需要一個事件的監(jiān)聽邏輯：

@Slf4j
@Component
public class RegisterEventListener {

    @EventListener
    public void handleNotifyEvent(RegisterSuccessEvent event) {
        log.info("監(jiān)聽到用戶注冊成功事件：" +
                "{}，你注冊成功了哦。記得來玩兒~", event.getUserName());
    }

}

接著，通過 Http 接口來進行事件發(fā)布：

@Resource
private ApplicationContext applicationContext;
@GetMapping("/publishEvent")
public void publishEvent() {
    applicationContext.publishEvent(new RegisterSuccessEvent("歪歪"));
}

最后把服務(wù)啟動起來，調(diào)用一次：

輸出正常，完事兒，這個 Demo 就算是搞定了，就只有十多行代碼。

這么簡單的 Demo 你都不想親自動手去搭一個的話，想要靠肉眼學(xué)習(xí)的話，那么我只能說：

Debug

來，我問你，如果是你的話，就這幾行代碼，第一個斷點你會打在哪里？

這沒啥好猶豫的，肯定是選擇打事件監(jiān)聽的這個地方：

然后直接就是一個發(fā)起調(diào)用，拿到調(diào)用棧再說：

通過觀察調(diào)用棧發(fā)現(xiàn)，全是 Spring 的 event 包下的方法。

此時，我還是一頭霧水的，完全不知道應(yīng)該怎么去看，所以我只有先看第一個涉及到 Spring 源碼的地方，也就是這個反射調(diào)用的地方：

org.springframework.context.event.ApplicationListenerMethodAdapter#doInvoke

通過觀察這三個關(guān)鍵的參數(shù)，我們可以斷定此時確實是通過反射在調(diào)用我們 Demo 里面的 RegisterEventListener 類的 handleNotifyEvent 方法，入?yún)⑹?RegisterSuccessEvent 對象，其 userName 字段的值是“歪歪”：

此時，我的第一個問題就來了：Spring 是怎么知道要去觸發(fā)我的這個方法的呢？

或者換個問法：handleNotifyEvent 這個我自己寫的方法名稱怎么就出現(xiàn)在這里了呢？

然后順著這個 method 找過去一看：

哦，原來是當(dāng)前類的一個字段，隨便還看到了 beanName，也是其一個字段，對應(yīng)著 Demo 的 RegisterEventListener。

到這里，第二個問題就隨之而來了：既然關(guān)鍵字段都在當(dāng)前類里面了，那么這個當(dāng)前類，也就是 ApplicationListenerMethodAdapter 是什么時候冒出來的呢？

帶著這個問題，繼續(xù)往下查看調(diào)用棧，會看到這里的這個 listener 就是我們要找的這個“當(dāng)前類”：

所以，我們的問題就變成了，這個 listener 是怎么來的？

然后你就會來到這個地方，把目光停在這個地方：

org.springframework.context.event.SimpleApplicationEventMulticaster#multicastEvent

為什么會在這個地方停下來呢？

因為在這個方法里面，就是整個調(diào)用鏈中 listener 第一次出現(xiàn)的地方。

所以，第二個斷點的位置，我們也找到了，就是這個地方：

org.springframework.context.event.SimpleApplicationEventMulticaster#multicastEvent

但是，朋友們注意，我要但是了。

但是，當(dāng)然把斷點打在這個地方，重啟服務(wù)準(zhǔn)備調(diào)試的時候，你會發(fā)現(xiàn)重啟的過程中就會停在斷點處，而停下來的時候，你去調(diào)試會發(fā)現(xiàn)根本就不是你所關(guān)心的邏輯。

全是 Spring 啟動過程中觸發(fā)的一些框架的監(jiān)聽邏輯。比如應(yīng)用啟動事件，就會在斷點處停下：

怎么辦呢？

針對這種情況，有兩個辦法。

第一個是服務(wù)啟動過程中，把斷點停用，啟動完成之后再次打開斷點，然后觸發(fā)調(diào)用。

idea 也提供了這樣的功能，這個圖標(biāo)就是全局的斷點啟用和停用的圖標(biāo)：

這個方法在我們本次調(diào)試的過程中是行之有效的，但是假設(shè)如果以后你想要調(diào)試的代碼，就是要在框架啟動過程中調(diào)試的代碼呢？

所以，我更想教你第二種方案：使用條件斷點。

通過觀察入?yún)?，我們可以看?event 對象里面有個 payload 字段，里面放的就是我們 Demo 中的 RegisterSuccessEvent 對象：

那么，我們可不可以打上斷點，然后讓 idea 識別到是上述情況的時候，即有 RegisterSuccessEvent 對象的時候，才在斷點處停下來呢？

當(dāng)然是可以的，打條件斷點就行。

在斷點處右鍵，然后彈出框里面有個 Condition 輸入框：

Condition，都認(rèn)識吧，高考詞匯，四級詞匯了，抓緊時間背一背：

在 idea 的斷點這里，它是“條件”的意思，帶著個輸入框，代表讓你輸入條件的意思。

另外，關(guān)于 Condition 還有一個短語，叫做 in good condition。

反應(yīng)過來大概是“狀況良好”的意思。

比如：我已出倉，in good condition。

再比如：Your hair is not in good condition。

就是說你頭發(fā)狀況不太好，需要注意一下。

扯遠(yuǎn)了，說回條件斷點。

在這里，我們的條件是：event 對象里面的 payload 字段放的是我們 Demo 中的 RegisterSuccessEvent 對象時就停下來。

所以應(yīng)該是這樣的：

event instanceof PayloadApplicationEvent && (((PayloadApplicationEvent) event).payload instanceof RegisterSuccessEvent)

當(dāng)我們這樣設(shè)置完成之后，重啟項目，你會發(fā)現(xiàn)重啟過程非常絲滑，并沒有在斷點處停下來，說明我們的條件斷點起作用了。

然后，我們再次發(fā)起調(diào)用，在斷點處停下來了：

主要關(guān)注 134 行的 listener 是怎么來的。

當(dāng)我們觀察 getApplicationListeners 方法的時候，會發(fā)現(xiàn)這個方法它主要是在對 retrieverCache 這個緩存在搞事情。

這個緩存里面放的就是在項目啟動過程中已經(jīng)觸發(fā)過的框架自帶的 listener 對象：

調(diào)用的時候，如果能從緩存中拿到對應(yīng)的 listener，則直接返回。而我們 Demo 中的自定義 listener 是第一次觸發(fā)，所以肯定是沒有的。

因此關(guān)鍵邏輯就在 retrieveApplicationListeners 方法里面：

org.springframework.context.event.AbstractApplicationEventMulticaster#retrieveApplicationListeners

這個方法里面的邏輯較多，我不會逐行解析。

只說一下這個關(guān)鍵的 for 循環(huán)：

這個 for 循環(huán)在干啥事呢？

就是循環(huán)當(dāng)前所有的 listener，過濾出能處理當(dāng)前這個事件的 listener。

可以看到當(dāng)前一共有 20 個 listener，最后一個 listener 就是我們自定義的 registerEventListener：

每一個 listener 都經(jīng)過一次 supportsEvent 方法判斷：

supportsEvent(listener, eventType, sourceType)

這個方法，就是判斷 listener 是否支持給定的事件：

因為我們知道當(dāng)前的事件是我們發(fā)布的 RegisterSuccessEvent 對象。

對應(yīng)到源碼中，這里給定的事件，也就是 eventType 字段，對應(yīng)的就是我們的 RegisterSuccessEvent 對象。

所以當(dāng)循環(huán)到我們的 registerEventListener 的時候，在 supportsEventType 方法中，用 eventType 和 declaredEventTypes 做了一個對比，如果比上了，就說明當(dāng)前的 listener 能處理這個 eventType。

前面說了 eventType 是 RegisterSuccessEvent 對象。

那么這個 declaredEventTypes 是個啥玩意呢？

declaredEventTypes 字段也在之前就出現(xiàn)過的 ApplicationListenerMethodAdapter 類里面。supportsEventType 方法也是這個類的方法：

而這個 declaredEventTypes，就是 RegisterSuccessEvent 對象：

這不就呼應(yīng)上了嗎？

所以，這個 for 循環(huán)結(jié)束之后，里面一定是有 registerEventListener的，因為它能處理當(dāng)前的 RegisterSuccessEvent 這個事件。

但是你會發(fā)現(xiàn)循環(huán)結(jié)束之后 list 里面有兩個元素，突然冒出來個 DelegatingApplicationListener 是什么鬼？

這個時候怎么辦？

別去研究它，它不會影響我們的程序運行，所以可以先做個簡單的記錄，不要分心，要抓住主要矛盾。

經(jīng)過前面的一頓分析，我們現(xiàn)在又可以回到這里了。

通過 debug 我們知道這個時候我們拿到的就是我們自定義的 listener 了：

從這個 listener 里面能拿到類名、方法名，從 event 中能拿到請求參數(shù)。

后續(xù)反射調(diào)用的過程，條件齊全，順理成章的就完成了事件的發(fā)布。

看到這里，你細(xì)細(xì)回想一下，整個的調(diào)試過程，是不是一環(huán)扣一環(huán)。只要思路不亂，抓住主干，問題不大。

進一步思考

到這里，你是不是認(rèn)為已經(jīng)調(diào)試的差不多了？

自己已經(jīng)知道了 Spring 自定義 listener 的大致工作原理了？

閉著眼睛想一想也就知道大概是一個什么流程了？

那么我問你一個問題：你回想一下我最最開始定位到反射這個地方的時候是怎么說的？

是不是給了你這一張圖，說 beanName、method、declaredEventTypes 啥的都在 ApplicationListenerMethodAdapter 這個類里面？

請問：這些屬性是什么時候設(shè)置到這個類里面的呢？

這個...

好像...

是不是確實沒講？

是的，所以說這部分我也得給你補上。

但是如果我不主動提，你是不是也想不起來呢，所以我也完全可以就寫到這里就結(jié)束了。

我把這部分單獨寫一個小節(jié)就是提一下這個問題：如果你只是跟著網(wǎng)上的文章看，特別是源碼解讀或者方案設(shè)計類文章，只是看而不帶著自己的思路，不自己親自下手，其實很多問題你思考不全的，關(guān)鍵是看完以后你還會誤以為你學(xué)全了。

現(xiàn)在我們看一下 ApplicationListenerMethodAdapter 這個類是咋來的。

我們不就是想看看 beanName 是啥時候和這個類扯上關(guān)系的嘛，很簡單，剛剛才提到的條件斷點又可以用起來了：

重啟之后，在啟動的過程中就會在構(gòu)造方法中停下，于是我們又有一個調(diào)用棧了：

可以看到，在這個構(gòu)造方法里面，就是在構(gòu)建我們要尋找的 beanName、method、declaredEventTypes 這類字段。

而之所以會觸發(fā)這個構(gòu)造方法，是因為 Spring 容器在啟動的過程中調(diào)用了下面這個方法：

org.springframework.context.event.EventListenerMethodProcessor#afterSingletonsInstantiated

在這個方法里面，會去遍歷 beanNames，然后在 processBean 方法里面找到帶有 @EventListener 注解的 bean：

在標(biāo)號為 ① 地方找到這個 bean 具體是哪些方法標(biāo)注了 @EventListener。

在標(biāo)號為 ② 的地方去觸發(fā) ApplicationListenerMethodAdapter 類的構(gòu)造方法，此時就可以把 beanName，代理目標(biāo)類，代理方法通過參數(shù)傳遞過去。

在標(biāo)號為 ③ 的地方，將這個 listener 加入到 Spring 的上下文中，后續(xù)觸發(fā)的時候直接從這里獲取即可。

那么 afterSingletonsInstantiated 這個方法是什么時候觸發(fā)的呢？

還是看調(diào)用棧：

你即使再不熟悉 Spring，你至少也聽說過容器啟動過程中有一個 refresh 的動作吧？

就是這個地方：

這里，refreshContext，就是整個 SpringBoot 框架啟動過程的核心方法中的一步。

就是在這個方法里面中，在服務(wù)啟動的過程中，ApplicationListenerMethodAdapter 這個類和一個 beanName 為 registerEventListener 的類扯上了關(guān)系，為后續(xù)的事件發(fā)布的動作，埋好了伏筆。

細(xì)節(jié)

前面了解了關(guān)于 Spring 的事件發(fā)布機制主干代碼的流程之后，相信你已經(jīng)能從“容器啟動時”和“請求發(fā)起時”這兩個階段進行了一個粗獷的說明了。

但是，注意，我又要“但是”了。

里面其實還有很多細(xì)節(jié)需要注意的，比如事件發(fā)布是一個串行化的過程。假設(shè)某個事件監(jiān)聽邏輯處理時間很長，那么勢必會導(dǎo)致其他的事件監(jiān)聽出現(xiàn)等待的情況。

比如我搞兩個事件監(jiān)聽邏輯，在其中一個的處理邏輯中睡眠 3s，模擬業(yè)務(wù)處理時間。發(fā)起調(diào)用之后，從日志輸出時間上可以看出來，確實是串行化，確實是出現(xiàn)了等待的情況：

針對這個問題，我們前面講源碼關(guān)于獲取到 listener 之后，其實有這樣的一個邏輯：

這不就是線程池異步的邏輯嗎？

只不過默認(rèn)情況下是沒有開啟線程池的。

開始之后，日志就變成了這樣：

那么怎么開啟呢？

主干流程都給你說了個大概了，這些分支細(xì)節(jié)，就自己去研究吧。

再比如，@EventListener 注解里面還有這兩個參數(shù)，我們是沒有使用到的：

它應(yīng)該怎么使用并且其到的作用是什么呢？

對應(yīng)的源碼是哪個部分呢？

這也是屬于分支細(xì)節(jié)的部分，自己去研究吧

再再比如，前面講到 ApplicationListenerMethodAdapter 這個類的時候：

你會發(fā)現(xiàn)它還有一個子類，點過去一看，它有一個叫做 ApplicationListenerMethodTransactionalAdapter 的兒子：

這個兒子的名字里面帶著個 “Transactional”，你就知道這是和事務(wù)相關(guān)的東西了。

它里面有個叫做 TransactionalEventListener 的字段，它也是一個注解，里面對應(yīng)著事務(wù)的多個不同階段：

想都不用想，肯定是可以針對事務(wù)不同階段進行事件監(jiān)聽。

這部分“兒子”的邏輯，是不是也可以去研究研究。

再再再比如，前面提到了 Spring 容器在啟動的過程中調(diào)用了下面這個方法：

org.springframework.context.event.EventListenerMethodProcessor#afterSingletonsInstantiated

這個方法屬于哪個類？

它屬于 EventListenerMethodProcessor 這個類。

那么請問這個類是什么時候出現(xiàn)在 Spring 容器里面的呢？

這個...

好像...

是不是確實沒講？

是的，但是這個類在整個框架里面只有一次調(diào)用：

調(diào)試起來那不是手拿把掐的事情？

也可以去研究研究嘛，看著看著，不就慢慢的從 @EventLintener 這個小口子，把源碼越撕越大了？

好了，本文的技術(shù)部分就到這里啦。

 本文轉(zhuǎn)載自微信公眾號「 why技術(shù)」，作者北上。轉(zhuǎn)載本文請聯(lián)系why技術(shù)公眾號。