在技術職場中廣泛存在以下幾種現象：程序員
- 對待工做中所使用的技術不須要閱讀源碼，只需在開發過程當中可以熟練運用就行
- 看源碼太費時間，並且容易忘記，若是從實際使用過程當中出現的問題出發，針對性的閱讀源碼，其學習效率會更高效，因此平時無需看源碼。
對此我有着不一樣的理解，容我慢慢道來。面試
本文將從以下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 更是可獲取大量學習資料。 