我給Apache頂級(jí)項(xiàng)目貢獻(xiàn)了點(diǎn)源碼.
這是why哥的第 91 篇原創(chuàng)文章
這篇文章其實(shí)并沒有什么技術(shù)性的分享，從我的角度而言，更多是記錄和思考。
把我對(duì)于源碼和之前寫的部分文章反哺給我的一些東西，帶來的一點(diǎn)點(diǎn)思考分享給大家。
一行源碼
我很長(zhǎng)時(shí)間沒打開我的 Outlook 郵箱了。
前兩天打開的時(shí)候發(fā)現(xiàn)我之前給 Dubbo 提交的 pr 居然已經(jīng)被合并到 master 了：
這是第一次，我提交的 pr 被合并了。
這個(gè) pr 是修復(fù) LFU 緩存策略在 Dubbo 中即使配置了，也不起作用的 bug。
于是我也算是為開源項(xiàng)目貢獻(xiàn)過源碼的人了。
什么你問我貢獻(xiàn)了多少代碼？
一行，是的，就一行！
而且，說起來，這次提交真的是沒有什么技術(shù)含量的事情。因?yàn)檫@是一個(gè)必現(xiàn)的 bug，只是很少有人用到這個(gè)功能而已。
你知道的，當(dāng)一個(gè) bug 能穩(wěn)定復(fù)現(xiàn)的時(shí)候，其實(shí)它已經(jīng)就不算是一個(gè) bug 了。
但是我想聊聊這次提交背后的一些東西。
發(fā)現(xiàn)與解決
從宿命論的角度來說，當(dāng)我寫下面這篇文章的第一個(gè)字的時(shí)候，這個(gè) bug 就注定是等著我去發(fā)現(xiàn)并修復(fù)了：
而這篇文章我敲下第一個(gè)字的時(shí)間是 2020 年 12 月的下旬，這是我 2020 年的最后一篇技術(shù)原創(chuàng)文章。
當(dāng)我寫 LRU 的時(shí)候，我就知道 LFU 肯定也是需要專門寫一篇的。
于是 2021 年的第一篇技術(shù)原創(chuàng)文章，我就選題了 LFU。
產(chǎn)生了這篇文章：
寫這篇文章的時(shí)候，我想起之前看 Dubbo 的版本，好像是提到了一下 LFU。
于是我翻到了 2.7.7 版本的發(fā)布內(nèi)容：
果然是支持了 LFU 緩存策略，于是翻出了提交的代碼記錄：
雖然他的實(shí)現(xiàn)邏輯沒有問題，Test 類也跑過去了。
但是毫不夸張的說，我看了一眼這個(gè)提交記錄，通過眼神編譯，就發(fā)現(xiàn)了這里勢(shì)必是有問題的。
他僅僅是把 LFU 緩存策略集合到了 Dubbo 代碼中，但是卻未提供使用的入口。
因?yàn)檫@里是基于 SPI 實(shí)現(xiàn)的，他沒有在對(duì)應(yīng)的配置文件中加入配置。
這個(gè)問題非常容易驗(yàn)證，我們可以看一下。
其源碼的位置是：org.apache.dubbo.common.utils.LFUCache
源碼里面告訴我這樣配置一下就可以使用 LFU 的緩存策略：
但是，當(dāng)我這樣配置，發(fā)起調(diào)用之后，是這樣的：
可以看到當(dāng)前請(qǐng)求的緩存策略確實(shí)是 LFU。
但是會(huì)拋出一個(gè)錯(cuò)誤：
No such extension org.apache.dubbo.cache.CacheFactory by name lfu
沒有 LFU 這個(gè)策略。
這不是玩我嗎？
再看一下具體的原因：
在 org.apache.dubbo.common.extension.ExtensionLoader#getExtensionClasses 處只獲取到了 4 個(gè)緩存策略，并沒有我們想要的 LFU。
所以，在這里拋出了異常：
為什么沒有找到我們想要的 LFU 呢？
那就得看你熟不熟悉 SPI 了。
在 SPI 文件中，確實(shí)沒有 LFU 的配置：
所以，這是個(gè) Bug，而這個(gè) Bug 的解決方案，就是在 SPI 文件里面加上一行 LFU 的配置即可。
經(jīng)過上面的分析，其實(shí)你也發(fā)現(xiàn)了，這個(gè)并不是一個(gè)有什么技術(shù)含量的提交。
更多的是運(yùn)氣成分。
只是由于對(duì)于 Dubbo 框架有些許的了解，所以對(duì)于這個(gè)地方，我發(fā)現(xiàn)問題、定位問題、解決問題的速度非常的快。
這是運(yùn)氣給不了我的東西。
這需要日復(fù)一日的潛入到框架中去，去感受它的脈絡(luò)，梳理它的結(jié)構(gòu)，學(xué)習(xí)它的思想。
這是需要時(shí)間去沉淀和學(xué)習(xí)的東西。
注意，我說的是“潛入”，而非是流于表面的。
什么是流于表面的呢？
比如，如果你之前沒有用過 Dubbo 框架，但你又想去了解，學(xué)習(xí)它。
于是你看到了我的這篇或者其他的和 Dubbo 相關(guān)的文章，企圖從這些文章中入手。
記住魯迅先生的話：
這里只適合查漏補(bǔ)缺，不適合系統(tǒng)的學(xué)習(xí)。
亦或者是你在搜索框里面，輸入 “Dubbo”，然后漫無目的的看了起來。
哪怕你買了一本 Dubbo 相關(guān)的書或者看了 Dubbo 相關(guān)的系列視頻，進(jìn)行系統(tǒng)的學(xué)習(xí)。
我覺得，只要沒有自己親手去做，都屬于流于表面。
而自己動(dòng)手的第一步，就是搭建 Demo，從 Demo 入手。
到后面高階一點(diǎn)的就是你了解到了這個(gè)框架的前世今生，能在幾個(gè)大版本之間進(jìn)行橫向?qū)Ρ龋罏槭裁瓷?jí)、怎么升級(jí)、升級(jí)之后是怎么樣的。
再之后，能細(xì)致到某一個(gè)大的模塊的演變是怎樣的，歷史上出現(xiàn)過哪些 Bug，是怎么去修復(fù)的，在哪個(gè)版本之后修復(fù)了，是穩(wěn)定的。
再舉個(gè)例子吧。
另外一個(gè)bug
回到最開始的地方，我為什么會(huì)在寫 LFU 的時(shí)候聯(lián)想到 Dubbo 呢？
因?yàn)樵?2.7.7 這個(gè)版本發(fā)布的時(shí)候，我就關(guān)注到了它。
而當(dāng)時(shí)關(guān)注到它的原因并不是 LFU ，而是新增了一種負(fù)載均衡策略：
于是我把之前的文章進(jìn)行了匯總，寫下了這篇文章：
吐血輸出：2萬字長(zhǎng)文帶你細(xì)細(xì)盤點(diǎn)五種負(fù)載均衡策略。
而其中一致性哈希負(fù)載均衡策略，我在實(shí)踐的時(shí)候也發(fā)現(xiàn)了一個(gè) bug。
其實(shí)這個(gè) bug 也是一個(gè)必現(xiàn)的 bug，為什么沒有被爆出來的原因，我想是因?yàn)楫?dāng)前的版本使用的人不多，而使用一致性哈希負(fù)載均衡策略的就更少了，甚至沒有。
這個(gè) bug 具體是這樣的：
https://github.com/apache/dubbo/issues/5429
我已經(jīng)知道了在一致性哈希算法中的這行代碼就是導(dǎo)致 bug 的原因：
System.identityHashCode(invokers)
甚至我也知道了，這行代碼導(dǎo)致 bug 的原因是 invokers 這個(gè)集合的地址變了。
這個(gè)集合里面，放的就是服務(wù)提供者列表。
集合里面的服務(wù)者列表其實(shí)并沒有變化，只是每次都用了一個(gè)新的 list 來裝這些服務(wù)提供者。
而為什么每次都用一個(gè)新的 list 來裝，我也找到了。
問題就出在 TagRouter 中：
org.apache.dubbo.rpc.cluster.router.tag.TagRouter#filterInvoker
基本上到這里，也就明確原因了。
但是我前面說了，更高一級(jí)的是了解這個(gè)框架的前世今生。
問題出在 TagRouter，那么這個(gè) TagRouter 怎么來的呢？
如果了解 Dubbo 2.7.x 版本新特性的朋友可能知道，標(biāo)簽路由是 Dubbo2.7 引入的新功能。
巧就巧在我還真的清楚這個(gè)地方的來龍去脈。
因?yàn)槲业牡谝黄夹g(shù)文章就是寫的 Dubbo 2.7 新特性，當(dāng)時(shí)進(jìn)行了一個(gè)了解。
沒想到一年多以后，竟然還呼應(yīng)上了。
而這個(gè) bug，其實(shí)也是一行代碼就能修復(fù)；
而我當(dāng)時(shí)為什么沒有去修復(fù)呢？
因?yàn)樽铋_始找到這個(gè) bug 的時(shí)候，我想到的解決方案是寫個(gè)工具類。
思路也是只關(guān)心 List 里面的元素，而不關(guān)心 List 這個(gè)容器，但是實(shí)現(xiàn)方式比較復(fù)雜，改動(dòng)點(diǎn)較多，還需要寫一個(gè)工具類。
當(dāng)時(shí)就沒動(dòng)手，想著先提個(gè) issue 放著，有時(shí)間了再弄。
結(jié)果，沒想到 issue 放上去的當(dāng)天就有人回復(fù)并了一個(gè)我沒有想到的解決方案：
看到這個(gè)回復(fù)的時(shí)候，我才一下回過神來，原來一行代碼就能代替我寫的工具類了啊。
而對(duì)于其中涉及到的知識(shí)點(diǎn)，我是知道的。
我反思了一下自己為什么沒有想到這個(gè)方案。
其實(shí)就是對(duì)于已知道的知識(shí)點(diǎn)，掌握不夠深刻導(dǎo)致的，沒有達(dá)到融會(huì)貫通的地步。
知其然，也知其所以然，可惜在需要使用的場(chǎng)景稍稍一變的情況下，就想不起來了。
知道知識(shí)點(diǎn)，但是該用的時(shí)候卻記不起來，這種情況其實(shí)挺常見的，那怎么解決呢？
于是我寫下了這篇文章：
夠強(qiáng)！一行代碼就修復(fù)了我提的Dubbo的Bug。
這篇文章就是我的解決方案，記錄下來嘛。
就像高中的時(shí)候人手一本的錯(cuò)題本，做錯(cuò)的題，不會(huì)的題都抄下來嘛。沒事的時(shí)候翻一翻，總有下次碰到的時(shí)候。再次碰到時(shí)，就是“一雪前恥”的機(jī)會(huì)。
寫過但沒有發(fā)現(xiàn)的bug
?我之前還寫過一樣的一篇文章：
當(dāng)時(shí)這個(gè)版本推出之后，我就趕緊去研究了一下對(duì)應(yīng)部分的源碼，然后寫下這篇自稱為全網(wǎng)第一篇解析 Dubbo 2.7.5 里程碑版本中的客戶端線程模型優(yōu)化的文章。
但是前兩天我看提交記錄的時(shí)候，發(fā)現(xiàn)了這樣的一個(gè)提交：
并找到了對(duì)應(yīng)的 issue：
https://github.com/apache/dubbo/issues/7054
根據(jù)這個(gè) issue，我去看了一下對(duì)應(yīng)的源碼，確實(shí)是存在他描述的問題。
于是我就在想，我當(dāng)時(shí)寫文章的時(shí)候也是深入到源碼里面了呀，為什么沒有發(fā)現(xiàn)這樣的問題呢？
我想原因還是在于自己當(dāng)時(shí)思考的深度不夠，僅僅是搭建了一個(gè)非常簡(jiǎn)陋的 Demo，而且把心思聚焦到了前后版本差異對(duì)比上。
只是摸到了一個(gè)大概的樣子，于是被源碼牽著走了，并沒有跳出源碼的包圍，帶著質(zhì)疑的眼光去審視它。
所以，對(duì)于這種比較深層次的、一環(huán)扣一環(huán)的問題，自己還是流于表面了一些。
一旦被源碼牽著走了，大概率的情況下就會(huì)無條件的相信源碼。毫無質(zhì)疑之心。
怎么看源碼
前面舉了三個(gè)例子，一個(gè)是發(fā)現(xiàn)并解決了 bug，一個(gè)是僅發(fā)現(xiàn)未解決的 bug，一個(gè)是有 bug 但沒有發(fā)現(xiàn)。
前兩個(gè) bug 都有一個(gè)共性，在簡(jiǎn)單的 Demo 下就是必現(xiàn)的，只要跑到了對(duì)應(yīng)的地方，就會(huì)出現(xiàn)和預(yù)期不符的情況，比較容易發(fā)現(xiàn)。
最后一個(gè) bug 隱藏的比較深入一點(diǎn)，也許你觸發(fā)了，但是程序自愈了。
當(dāng)有一天我能發(fā)現(xiàn)并解決這樣的 bug 時(shí)，我就不會(huì)說這是運(yùn)氣了。
但是發(fā)現(xiàn)這些 bug 的前提是得動(dòng)手搭建 Demo 呀。
你不看源碼，只是看網(wǎng)上的文章，是永遠(yuǎn)發(fā)現(xiàn)不了問題的，也是潛入不進(jìn)去的。
分享一下我看源碼的方法吧。
我們知道開源框架的設(shè)計(jì)和理念大多是非常優(yōu)秀的，但是源碼里面的細(xì)枝末節(jié)特別的多，一不小心就容易在源碼里面迷失，直接就是一波勸退。
所以，對(duì)于初讀源碼的同學(xué)，首先要做的就是把核心流程梳理出來，邊梳理邊畫圖，要多畫圖，別怕麻煩。
對(duì)于幾處關(guān)鍵的源碼，一定要寫上自己的備注。因?yàn)槟阒赖?，?dāng)時(shí)也許你對(duì)這個(gè)地方為什么這樣寫門清，但是隔段時(shí)間再回來看，就摸不著頭腦了。這個(gè)時(shí)候，備注就顯得非常重要了。
對(duì)于看不明白的地方，打斷點(diǎn)，瘋狂的調(diào)試，反復(fù)的調(diào)試。
等待主流程摸清楚之后，再去進(jìn)入到源碼的細(xì)節(jié)部分。
舉個(gè)簡(jiǎn)單的例子，比如你看 Dubbo 源碼，先摸清楚它一次請(qǐng)求大概的調(diào)用鏈路之后，再去細(xì)致了解其中負(fù)載均衡的部分。
然后，就是多復(fù)習(xí)，多鞏固了。
你發(fā)現(xiàn)沒有，我說的這些其實(shí)你也知道，或者其他人也是這樣說的。
為什么你看的時(shí)候就老是看不進(jìn)去呢？不得要領(lǐng)呢？
是的，我開始也是這樣的。但是，無它，唯反復(fù)練習(xí)爾。
共勉之。
荒腔走板
周末的時(shí)候拿著投影儀去新家那邊試了一下效果，當(dāng)窗簾一拉，幕布放下，電影一放，酒杯相碰的那一下。
啊，舒服了，是裝修之前想象中的家庭影院的效果。
本來之前說的在新家看的第一部電影得是紅紅火火的那種，但是沒想到誤打誤撞放了一個(gè)動(dòng)作片。
你別說，我們一起窩在沙發(fā)上，看完之后，一致認(rèn)為還挺好看的。
由于我們還沒搬家，空間顯得也比較凌亂，投影儀也是放在餐桌上，而為了一個(gè)好的投影角度，移動(dòng)了餐桌。
導(dǎo)致完全擋住了去往衛(wèi)生間的路，于是看電影的間隙，我想去衛(wèi)生間，是從桌子下面鉆過去的。
發(fā)現(xiàn)這問題的時(shí)候，我說：到時(shí)候這邊的墻上做一個(gè)擱物板，就可以放其他東西，也可以找到更好的角度放下這個(gè)投影儀了。
她說：對(duì)呀，這些問題其實(shí)在我們沒有住進(jìn)來之前是很難想到的，只有搬進(jìn)來之后，慢慢的折騰。
她說這句話之后，我就覺得兩個(gè)人在一起，沒有什么是一蹴而就，都是在慢慢磨合中悄無聲息的打造出來的。
也許我都沒有注意到，而打造出來的東西，它就叫做：
生活。
另外，我還想隨口問一句：
有人知道靠譜的除甲醛的騷操作嗎？別說通風(fēng)，我一直在通。
最后，昨天氣氛到位了，發(fā)了個(gè)朋友圈，于是很多人在朋友圈問我投影儀是怎么弄的。
其實(shí)我之前說過的：別問，問就是一個(gè)電動(dòng)幕布而已，不用的時(shí)候可以收上去。
而且我發(fā)現(xiàn)收上去之后，直接投影到窗簾上，還挺有氣氛的，簡(jiǎn)直是氛圍組擔(dān)當(dāng)。
大概就是這樣的：
最后說一句（求關(guān)注）
好了，看到了這里安排個(gè)“一鍵三連”（轉(zhuǎn)發(fā)、在看、點(diǎn)贊）吧，周更很累的，需要一點(diǎn)正反饋。
才疏學(xué)淺，難免會(huì)有紕漏，如果你發(fā)現(xiàn)了錯(cuò)誤的地方，可以在后臺(tái)提出來，我對(duì)其加以修改。
感謝您的閱讀，我堅(jiān)持原創(chuàng)，十分歡迎并感謝您的關(guān)注。
最后，大家覺得文章還行，可以給我的號(hào)標(biāo)個(gè)星。如果不標(biāo)星，按照微信的推送機(jī)制，后續(xù)有可能會(huì)看不到我的文章。
之前把我標(biāo)星了的讀者，你也可以看一下，遷移之后應(yīng)該神不知鬼不覺的被官方取消掉了，也需要重新進(jìn)行標(biāo)星。
你的星標(biāo)，對(duì)我非常重要。
推薦???：我酸了，來看看那些955的公司。
推薦???：我錯(cuò)了，打我可以，別打臉。
推薦???：面試官叫我設(shè)計(jì)一個(gè)排行榜。
推薦???：我一般在B站看這些破玩意...
推薦???：布隆，牛逼！布谷鳥，牛逼！
我是 why，一個(gè)主要寫代碼，經(jīng)常寫文章，偶爾拍視頻的程序猿。
轉(zhuǎn)發(fā)、點(diǎn)贊、在看、一鍵三連。
