一、從最簡單的源碼開始:別幻想一步登天node
二、按部就班:先搞定底層依賴的技術面試
三、必定要以Hello World做爲入口來閱讀算法
四、抓大放小,邊寫註釋邊畫圖數據庫
五、反覆三遍,真正理解源碼網絡
六、借力打力,參考源碼分析書籍及博客架構
七、最後寄語:用幾年時間鍛造本身的核心技術併發
這篇文章,給你們簡單介紹一下不少同窗都很是關心的一個問題:如何閱讀一個開源項目的源碼。框架
我相信不少同窗都但願可以去閱讀一些源碼來提高本身的技術水平,畢竟在面試的時候,不少大廠都常常會扣到很是深刻的底層源碼。分佈式
其實開源項目有不少種,好比說有Spring這種框架類的,還有好比數據庫鏈接池、log4j等這種工具類的。微服務
固然還有特別重型的中間件類的,好比說RocketMQ、Kafka、Redis。更有甚者也有上百萬行代碼的大數據類的,好比Hadoop、Spark。
因此若是不少同窗想要讀源碼的話,面臨的第一個問題:不知道從何下手。
那麼是否是說只要隨便挑選一個開源技術的源碼,採用愚公移山的精神,直接硬着頭皮去讀,堅持就是勝利,鐵杵必定就能磨成針嗎?
不是的!其實不少同窗始終都沒掌握到閱讀源碼的順序、技巧和方法,因此致使嘗試看過一些源碼,卻仍是看不懂。
首先你要明白一個前提,好比說Kafka的做者,Hadoop的做者,他們自己都是有不少年經驗,技術功底極爲紮實,都是技術大牛的人,站在一個很高的角度去設計和開發出來了這些極爲出色的分佈式系統。
那麼若是你的技術實力達不到他們的水平,你以爲你直接去讀他們寫出來的源碼,就能看懂嗎?
那估計是很難的,由於裏面蘊含的各類底層技術細節,分佈式架構設計思想,還有複雜的算法和機制,都不是你能理解的。
因此建議你們第一點,想看源碼,先挑一個最最簡單的,適合本身技術水平的去看。
給你們舉個例子,好比說你平時經常使用的一些源碼都有什麼?顯而易見,每一個人都會用Spring Web MVC、Spring、MyBatis、Spring Boot,等等。
其實這些開源框架的源碼也不能說就簡單了,他們一樣蘊含了開源做者深厚的技術功底在裏面。
可是你要考慮一點,這些開源項目已經相對來講是普通人能夠優先觸碰的了。由於他們不是分佈式系統,不涉及到複雜的架構,網絡通訊,IO,等技術細節。
他們大多就是依賴一些底層的Java基礎技術,好比說動態代理、Servlet、HTTP協議、JDBC等等。
而他們依賴的那些基礎,大多數普通工程師都是掌握的,你徹底能夠優先嚐試去閱讀一些這種開源框架類的源碼。
好,如今假如說你通過了幾個月的努力,把一些開源框架的源碼,好比上面說的SSM三大框架的源碼都看過了,如今你的技術實力有了進一步的提高。
這些提高,主要體如今對開源項目的設計思想,組件設計,組件交互,還有框架封裝,等等,都有了進一步的理解。
接下來,你就能夠嘗試去讀一些更難一點的源碼。
給你們舉個例子,假設你這個時候去閱讀Kafka的源碼。沒問題。可是這裏有一些是你須要注意的地方,Kafka的底層是重度依賴ZooKeeper的。
若是你不把ZooKeeper給掌握精通的話,會致使Kafka你也難以理解。
因此這個時候你得先把底層依賴的技術給搞定,那麼你就得回過頭去先閱讀ZooKeeper的源碼,把ZK這個技術先給搞精通一些。
同理,若是你在研究ZK的時候,發現他底層有一些技術是你掌握很差的,好比你發現他大量運用了Java併發包下的東西。
所以若是你對Java併發包掌握的不夠好,那麼建議你去把Java併發包下的源碼先仔細研究一下。
經過這種方式,你能夠自行追蹤到本身還不熟悉的不少底層技術,而後一個一個擊破,把這些底層依賴的技術的源碼你能夠先研究透徹一些。
而後,你再一步一步往上層的技術去研究,這樣看那些複雜技術的源碼就會輕鬆不少了。
閱讀源碼有一個很是很是有用的技巧,那就是你別下載了源碼到本地IDE裏而後直接胡亂的翻看,那是不行的。
通常建議就是基於一個開源技術寫一個最最基本的HelloWorld程序,就是一個入門級的程序,而後把他的核心功能給跑通。
舉個例子,假如說你要閱讀ZooKeeper的源碼,那麼你先寫一個ZK的HelloWorld程序。
好比說先鏈接,而後建立一個znode,對znode註冊一個監聽。接着觸發這個監聽,接着再關閉鏈接,就這樣的一個簡單的程序。
而後就能夠打斷點,跟蹤這個Hello World級別的源碼一步一步調試追蹤,他是如何發起和創建鏈接的,底層的代碼流程是什麼樣的。
在看源碼的過程當中,不少人會被核心流程中混雜的一些特殊業務邏輯的處理給搞懵。
給你們舉個例子,看下面的代碼,是一段隨手寫出來演示的:
checkUser();
fetchFromPeers();
countMetrics();
你們能夠看到,上面就三行代碼,從方法名稱就能夠看出來,先是作了一個權限檢查之類的操做,而後是核心業務邏輯去抓取數據,最後是作了一些metric指標統計。
那麼不少同窗看源碼的時候,就喜歡把每一行代碼都看懂,最後不停的點到很深層的地方去,把本身給繞暈了。最後淹死在源碼的海洋裏。。。
其實這個是不對的,這就是沒有掌握源碼閱讀的一大典型原則:
抓大放小。
好比上面的三行代碼,你應該直接跳過第一行和第三行,連看都別去看,直接進入第二行核心邏輯。
也就是說,你只須要抓最核心的代碼流程就能夠了,那些可有可無的代碼,千萬別有強迫症點進去反覆看,那樣絕對會讓你對源碼從入門到放棄。
因此,再次強調!強調!強調!重要的事情說三遍。閱讀源碼,你必定要有粗大的神經,反覆告訴本身,剛開始先把握代碼的主流程便可。
不少細節看不懂直接跳過去,別有強迫症讓本身看明白每一個細節。
此外,你們必定要造成一個習慣,在看源碼的過程當中儘可能多本身對源碼寫一些註釋。
你應該結合本身的理解,儘量把本身對源碼閱讀過程當中的思考都寫成註釋寫在源碼裏。
這個習慣能夠促使你一邊閱讀一邊思考,並且有本身註釋的源碼,是你寶貴的財富。
此外,還有一個很是重要的點,那就是必定要多畫圖。
你能夠嘗試在閱讀的過程當中,提取源碼運行的核心流程,一邊讀源碼,一邊本身畫在圖上,能夠用那種畫圖軟件來做圖便可。
你們記住,人腦對圖片的敏感度,是遠高於對文字或者代碼的,這個是大腦機制決定的。
筆者公衆號寫的不少篇文章,裏面對各類技術的講解,無一不是經過大量的畫圖。相比於冗長的文字描述,圖片會讓人容易理解接受的多。
經過畫圖,能幫助你抽象和總結出源碼的核心流程,之後若是你要回顧和複習,直接看圖便可。
另一個要注意的點,源碼這個東西,是多看幾遍理解的就會越深入。
由於你看第一遍,按照上面說的抓大放小的思路,可能不少東西就直接略過去了,由於剛開始你看不懂一些非核心代碼在幹什麼。
可是第一遍看完之後,經過寫註釋,本身動手畫圖,對一個開源項目的核心流程、架構以及原理都有了必定的理解了。
此時再去讀第二遍源碼,再過一遍,你會發現以前不少看不懂的細節都能看懂了。而後再看第三遍源碼,你會發現大多數的代碼本身都能看懂了。
因此說任何一個源碼,都是要至少反覆看三遍的過程,不是看一遍就能夠完成的。
其實如今有不少對熱門開源項目進行源碼分析的書籍以及博客,你大體能夠認爲就是一些技術比較牛的兄弟本身看了源碼以後,寫出來的一些分析和感悟。
可是那畢竟是別人的東西,若是你上來就直接看源碼分析書籍或者博客,那麼不必定能夠看懂,由於文字的信息傳遞未必能很好的讓你理解有些複雜的東西。
因此比較建議的方式,就是先本身嘗試看幾遍,有了必定的理解以後,此時能夠藉助源碼分析書籍或者是博客,參考其餘技術牛的同窗對這個源碼理解,結合本身以前的一些思考,綜合起來進行分析,相信必定會大有裨益。
你會發現人家的一些理解能夠很好的補充你沒想明白的一些問題,或者是忽略的一些細節。
不過,須要提醒的一點,網上很多博客,包括一些書籍,他們寫出的一些源碼分析,多是錯誤的。
因此,盡信書不如無書,你須要帶着必定的糾錯眼光。在和你的理解相悖時,不必定就是你錯了。
其實上面那個過程提及來很簡單,作起來很是的困難。
由於在上面任何一個步驟,閱讀的過程當中你都有大量的東西是不會的,並且會以爲很難,甚至常常有想放棄的衝動。
畢竟人的大腦天生就是會對困難的事情產生抗拒感,這是本能,天生就是對舒服、放鬆的事情有嚮往。
可是隻有那些能克服人的動物本能,惰性本能,迎難而上,堅韌不拔的同窗,才能真正攻克各類技術難題。
讓本身的大腦不停的開動,不停的思考上面那個過程,也許你要持續一年纔能有個小的開悟,持續三年纔能有必定的心得,持續五年甚至八年,才能說真的融匯貫通,打通任督二脈,成爲技術大牛。
可是堅持這個事情一樣是很可怕的,一旦你堅持作到了,那麼你將鍛造出來本身最硬核的技術實力,遠遠不是普通人,或者剛畢業的年輕同窗能夠追上你的。技術深度、技術功底,這是每個工程師最最硬核的技術實力。
但願各位同窗能夠從如今開始,嘗試着用筆者分享的技巧閱讀源碼。跳出溫馨區,去擁抱更大的溫馨區。
真正體驗一下讀透源碼以後,根據報錯日誌,從源碼層面精肯定位項目問題、精確制導線上bug,感覺一下這種上帝視角解決問題的快感吧!