在技術職場中廣泛存在以下幾種現象:程序員
- 對待工做中所使用的技術不須要閱讀源碼,只需在開發過程當中可以熟練運用就行
- 看源碼太費時間,並且容易忘記,若是從實際使用過程當中出現的問題出發,針對性的閱讀源碼,其學習效率會更高效,因此平時無需看源碼。
對此我有着不一樣的理解,容我慢慢道來。面試
本文將從以下4個角度進行剖析:編程
- 源碼閱讀的必要性
- 源碼閱讀技巧
- 源碼閱讀的三種境界
- 源碼閱讀的誤區
一、源碼閱讀必要性
1.1 通用型基礎技術應該深刻源碼研究
在 JAVA 領域中筆者認爲通用型基礎技術包含 JAVA 集合、Java併發(JUC)。這類技術是項目中使用的高頻技術,在合適的場景中選用合適的數據結構、選用合適的線程併發模型、合理控制鎖粒度等都能顯著提升應用程序的可用性、健壯性。數據結構
通用型技術正由於其具備廣泛性,橫向對比更具表明性,職場面試時的可辨別性很是高,如何在高樣本中突出本身就顯得極爲必要,經過閱讀源碼,深入理解其內部原理成爲咱們的不二法寶。架構
固然經過閱讀源碼並非知曉原理的惟一方法,但做爲一個名程序員、直面代碼,親自感覺代碼的魅力或許來的更加直接。併發
1.2 重點領域應深刻源碼研究
爲了提升辨識度做爲職場的咱們應該打造本身的專屬標籤,即**「亮點」**。一般狀況咱們應該選擇在平常工做中使用的技術,在積累了豐富的使用經驗、線上故障排查經驗的前提下,應該深刻研究其源碼,成體系掌握該技術,從而對其更具掌控性,作到提早預判線上問題,規避大量線上故障,提高穩定性,助力業務降本增效。框架
例如筆者所在公司在微服務、消息中間件領域分別採用了 Dubbo、RocketMQ,而且筆者有幸參與到這項技術棧的運用與運維,積累了豐富的使用經驗,爲此筆者爲了突出在這兩個領域的優點,詳細閱讀其源碼,並做成專欄發佈在『中間件興趣圈』公衆號與CSDN等知識分享平臺,因爲是成體系剖析的緣由被出版社相中,邀請出書,《RocketMQ技術內幕》一書就在這樣的背景中應運而生,從而成爲筆者職業技能中很是亮眼的標籤,助力職場。運維
源碼閱讀確實很重要,但必定須要成體系研究,大部分人認爲在處理問題時再根據具體問題去看源碼,會更有針對性,以爲不必成體系看。微服務
不能否認這有其正確性的一面,從問題自己出發,看源碼效率更快,「投入產出比」更高,隨着遇到的問題愈來愈多,對該技術理解也會愈來愈深,這個其實就是咱們一般講的**「經驗」**。我以爲大部分狀況下是可取的,這個過程實際上是一個被動的過程,而且若是生產環節因爲併發不高等因素,可能一年、兩年也不會出現一兩次故障,這樣就會形成經驗的積累會很是慢,從而使得工做了四、5年的朋友其競爭力還不如工做2,3年的重要緣由,因此個人觀點是若是是想打形成本身的專屬亮點的話,咱們仍是須要主動經過閱讀其源碼,成體系掌握其設計理念、實現原理,更好的打造本身的專屬亮點。高併發
二、如何閱讀源碼
既然閱讀源碼很是有必要,那如何閱讀源碼呢?筆者根據多年的源碼閱讀經驗整理了以下方法論:
- 瞭解這款中間件的使用場景、以及架構設計中將承擔的責任。
- 尋找官方文檔,從總體上把握這款中間件的設計理念。
- 搭建本身的開發調試環境,運行官方提供Demo示例,爲後續深刻研究打下基礎。
- 先主幹流程再分支流程,注意切割,逐個擊破。
- 閱讀源碼過程當中帶着思考與質疑思惟。
理解了其使用場景後,結合官方文檔,嘗試理解該中間件須要解決的問題、並思考如何解決,思考過程當中並不必定要求咱們想出一個具體的答案,只是在真正步入源碼閱讀時能更快感悟其代碼含義。
固然在閱讀源碼的過程當中可能會到難題,遇到沒法理解做者的實現意圖,特別是遇到一些本身不太熟悉的編程方式(例如位運算),此時一般有兩種解決方案:
- 經過DEBUG,結合運行時數據,方便對代碼的理解。
- 從易到難,能夠先嚐試閱讀一下JAVA集合框架的源碼,提煉出一套本身的源碼研究方法論。
源碼閱讀其實最難的不是代碼自己,也不是沒法理解其設計理念,最難的是堅持,故在這裏借用筆者的座右銘與你們共勉:越努力越幸運,惟有堅持不懈。
三、源碼閱讀的三層境界
接下來我想再結合筆者4年源碼閱讀的歷程,談談我對源碼閱讀的一些更深層次的理解,介紹一下筆者在各個階段閱讀源碼所處的狀態。
-
源碼閱讀的初級階段 筆者的老粉絲們應該能感受到筆者初期的源碼閱讀文章,基本上是記流水帳,其最直觀的表現現象是對源碼同樣一行加註釋,只關注底層實現細節,但並未造成更高層次認知,對其設計理念並未提煉與深度領悟。
-
能提問、思考、並提煉 隨着技術類文章的持續分享,筆者認識了不少大牛、發現與大牛交流的時候,一開始並不會說細節,而是講設計理念,這就要求咱們在閱讀源碼的時候多思考,並反問本身若是須要本身實現的話咱們該如何着手,如何設計,帶着疑問去研究源碼,經過對比,思考,會對其背後的理念有了更深入的理解。
-
思考、質疑、驗證 其實不管是哪一個開源框架都會存在BUG或者實現並不合理的地方,若是你們在閱讀源碼的時候可以思考並開始質疑其不合理性,並能經過驗證證實本身的觀點,而後與官方取得聯繫,交流,建Isuue,共同促進社區的發展,說明咱們的能力、思考獲得了極大的提高。
關於這一點,能夠參考筆者對 Sentinel 對應熔斷實現機制進行的質疑與思考過程。
從Sentinel Dubbo 適配器看限流與熔斷(實戰思考篇)
四、源碼閱讀誤區
源碼閱讀是手段,但必定不是目的。
我在面試過程當中發現好多候選者在談到某一項技術時,首先不是介紹其原理,而是一會兒具體到某個類啥的,這些類是如何如何工做等等,其實這是不太穩當的,源碼閱讀的目的是主要是深刻理解其設計理念、工做機制,方便咱們在實際使用過程當中對其成體系的認識,增強對它的駕馭能力,作到提早規避風險。
其次源碼閱讀很是不建議一上來就直接DEBUG。若是一開始就使用DEBUG,很容易會迷失在代碼的各個分支中,缺少全局視角,從而變得沒有頭緒,極大的增長了源碼理解的難度,很容易讓咱們半途而廢。
最後學習一門技術並必定要深刻源碼,特別是非主流,非重點打造的領域。對於此類咱們一般只需根據閱讀官方文檔,瞭解其使用場景、能解決什麼問題,理解其設計理念、工做機制,靈活運用解決具體問題便可。
五、總結
源碼閱讀並非目的,只是手段。對於通用型基礎技術諸如JAVA集合、併發、需重點打造爲亮點的領域建議你們閱讀其源碼,成體系深刻細節掌握其工做機制,加強其駕馭能力,擁有提早規避風險的能力。
歡迎關注公衆號『中間件興趣圈』,共同探究源碼,交流高併發、架構經驗,回覆 PDF 更是可獲取大量學習資料。