你好呀，我是歪歪。

前段時(shí)間看到同事在項(xiàng)目里面使用了一個(gè)叫做 @EventLintener 的注解。

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

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

哦，不。

錯(cuò)過一個(gè)表現(xiàn)自己的機(jī)會。

Demo

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

先鋪墊一個(gè)背景吧。

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

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

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

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

上面的代碼就是一個(gè)耦合性很強(qiáng)的代碼。

怎么解耦呢？

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

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

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

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

這樣就算是完成了兩個(gè)動(dòng)作的“解耦”。

怎么做呢？

我們可以基于 Spring 提供的 ApplicationListener 去做這個(gè)時(shí)間。

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

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

@Data
public class RegisterSuccessEvent {

    private String userName;

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

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

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

@Slf4j
@Component
public class RegisterEventListener {

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

}

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

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

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

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

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

Debug

來，我問你，如果是你的話，就這幾行代碼，第一個(gè)斷點(diǎn)你會打在哪里？

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

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

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

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

org.springframework.context.event.ApplicationListenerMethodAdapter#doInvoke

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

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

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

然后順著這個(gè) method 找過去一看：

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

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

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

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

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

org.springframework.context.event.SimpleApplicationEventMulticaster#multicastEvent

為什么會在這個(gè)地方停下來呢？

因?yàn)樵谶@個(gè)方法里面，就是整個(gè)調(diào)用鏈中 listener 第一次出現(xiàn)的地方。

所以，第二個(gè)斷點(diǎn)的位置，我們也找到了，就是這個(gè)地方：

org.springframework.context.event.SimpleApplicationEventMulticaster#multicastEvent

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

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

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

怎么辦呢？

針對這種情況，有兩個(gè)辦法。

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

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

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

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

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

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

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

在斷點(diǎn)處右鍵，然后彈出框里面有個(gè) Condition 輸入框：

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

在 idea 的斷點(diǎn)這里，它是“條件”的意思，帶著個(gè)輸入框，代表讓你輸入條件的意思。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

org.springframework.context.event.AbstractApplicationEventMulticaster#retrieveApplicationListeners

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

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

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

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

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

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

supportsEvent(listener, eventType, sourceType)

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

因?yàn)槲覀冎喇?dāng)前的事件是我們發(fā)布的 RegisterSuccessEvent 對象。

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

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

前面說了 eventType 是 RegisterSuccessEvent 對象。

那么這個(gè) declaredEventTypes 是個(gè)啥玩意呢？

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

而這個(gè) declaredEventTypes，就是 RegisterSuccessEvent 對象：

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

所以，這個(gè) for 循環(huán)結(jié)束之后，里面一定是有 registerEventListener的，因?yàn)樗芴幚懋?dāng)前的 RegisterSuccessEvent 這個(gè)事件。

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

這個(gè)時(shí)候怎么辦？

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

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

通過 debug 我們知道這個(gè)時(shí)候我們拿到的就是我們自定義的 listener 了：

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

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

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

進(jìn)一步思考

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

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

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

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

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

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

這個(gè)...

好像...

是不是確實(shí)沒講？

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

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

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

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

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

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

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

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

org.springframework.context.event.EventListenerMethodProcessor#afterSingletonsInstantiated

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

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

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

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

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

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

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

就是這個(gè)地方：

這里，refreshContext，就是整個(gè) SpringBoot 框架啟動(dòng)過程的核心方法中的一步。

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

細(xì)節(jié)

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

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

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

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

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

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

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

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

那么怎么開啟呢？

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

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

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

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

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

再再比如，前面講到 ApplicationListenerMethodAdapter 這個(gè)類的時(shí)候：

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

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

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

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

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

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

org.springframework.context.event.EventListenerMethodProcessor#afterSingletonsInstantiated

這個(gè)方法屬于哪個(gè)類？

它屬于 EventListenerMethodProcessor 這個(gè)類。

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

這個(gè)...

好像...

是不是確實(shí)沒講？

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

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

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

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

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