一點一點看JDK源碼（〇） 原創文章，版權所有，未經允許進位轉載 寫在前面： 幾乎所有的大神都會強調看源碼，也強調源碼的重要性； 但是如何看源碼，源碼看什麼？看了什麼用？看了怎麼用？ 困擾很多人，尤其是初學者。 本文簡單的回答以下幾個問題： 1.為什麼要看源碼？ 2.什麼時候或什麼條件下看源碼？ 3 ...
一點一點看JDK源碼（〇）
原創文章，版權所有，未經允許進位轉載
寫在前面：
幾乎所有的大神都會強調看源碼，也強調源碼的重要性；
但是如何看源碼，源碼看什麼？看了什麼用？看了怎麼用？
困擾很多人，尤其是初學者。
本文簡單的回答以下幾個問題：
1.為什麼要看源碼？
2.什麼時候或什麼條件下看源碼？
3.看源碼看什麼？
4.看源碼有什麼用？
5.源碼看完了怎麼用？
接下來以個人見解依次回答以上問題：
1.為什麼要看源碼？
究這個問題，很多人都認為軟體會用即可，寫代碼也是一種軟體應用，這個是本質！
我們都站在巨人的肩膀上，過去是，現在是，將來也是，這個巨人，是歷史！
在拿到每一個產品並使用的時候，我們需要仔細閱讀產品說明書：（從不看說明書的人左轉）
①瞭解產品的使用功能
②瞭解產品的安全性能
③瞭解產品的毒性和副作用
④瞭解產品的維護周期和生命周期
⑤瞭解產品的廠商與聲明
對於不正確使用產品至死致殘又狀告商家的，就好像被人砍了要找賣刀的算賬一樣，
只要超越了一般產品的正常使用方式，出現的問題沒人會代你負責的。（扯遠了）
源碼就是編碼的說明書，因為我們在使用這個源碼。
我們需要閱讀源碼，從說明書的角度去正確使用這些工具。
2.什麼時候或什麼條件下看源碼？
本人只有java開發經驗，所以只能以java舉例進行說明瞭。
- 如果java的基礎語法已經學習完了，能夠寫一些簡單的代碼了
- 如果對於java的面向對象設計能夠依葫蘆畫瓢了，已經學完了jdk中的大部分工具了
- 如果每天學習4小時以上，已經連續學習超過一個月了
- 如果你很閑（不知道做什麼）
- 如果你很窮（還會寫點代碼）
- 如果你想吃這口技術飯
以上六條只要滿足三條以上，已經是應該適當看看源碼的時候了。
3.看源碼看什麼？
我們說萬物究其本源，要透過現象看本質，實際上這兩句話並不是完全正確的。
萬物的本源應該是微觀粒子領域吧，事物的本質都是宇宙基本定律，也許還能更細究。
假設我們要看java的原碼，那麼又要考慮java是運行在jvm上的，應該看jvm原碼。
同時jvm又是c++寫的，我們應該看c++原碼。
同時c++運行在電腦底層是彙編，我們應該看彙編原碼。
這哪裡有完。
所以，看java原碼，先看使用的工具集，即jdk就足夠了。
一項一項向上系統的看才是正確的，至於其他的也並非不進行接觸，可能不是那麼系統而已。
而jdk看什麼？
打開API，好像隨便點一個類，都會有一個繼承（extends）的類，同時又實現（implements）很多介面
難道一個一個向上看，看到最頂層，然後從頂層開始向下學習麽？
筆者也想過用這種方式，剛看了幾分鐘就覺得不對，原因如下：
- java雖然是單根繼承體系，但是允許多介面實現；
- java的設計根類是Object，但是根介面有很多；
- java中很多類的設計是網狀的，並非一個單根樹結構；
- java中很的介面可能又有很多子介面，孫子介面，光看介面，非常疲乏；
所以，看java，要從一個常用的工具開始看，
這個工具一定是一個具體的實現類，而並非抽象類，並非是介面。
從一個點開始，向上開始展開。同時這個類最好不是jvm底層有運算符相關的
（如String類的設計不建議最開始就看）
4.看源碼有什麼用？
這個問題看起來好像和為什麼看源碼是一個意思，但是實際上要解釋的是不同的內涵。
看源碼，主要是看源碼體現出的幾個問題，他分為兩個層次：
4.1.源碼的構成模式
構成模式，是指從一個類開始看，瞭解這個類的構成。一般包括：
①類的繼承體系
②類的實現體系
③類的成員變數
④類的構造器
⑤類的方法實現
在看類的構造器和方法實現的時候，會發現有些類的構造器是使用了父類構造器，或
加工了父類的構造器的。同理，類的方法實現，即時具體代碼看不懂，也要知道這個
方法是做什麼的，比如入參，出參，加工邏輯，是否是繼承，是否是父介面實現等。
4.2.源碼的設計模式
看源碼的繼承體系和實現體系的時候，肯定會有一種不知所然的感覺，
“這個為啥要繼承？”“這個為啥要那麼多介面？”
當然，看的數量少，必定會有這種感覺。
而源碼中的設計模式，實際上是妙不可言的，有些變數的命名，也是很走心的，
有些沒有寫在doc中的雙斜杠註釋，才是真的應該關心，在API中看不到的內容。
5.源碼看完了怎麼用？
看源碼看jdk的原碼（自己說的，自己打臉），實際上對jdk進行改動的人少之又少，雖然開源。
我們看源碼，看完了，明白了其中的良苦用心，難道我們在使用這些工具的時候能玩出花來麽？
也許根本做不到，美麗花朵夏天一場雨也許就掉光了。
我們會不用jdk設計好的基類，而是在其基礎上進行擴展麽？好像也不會。
實際上jdk的設計模式，是我們開發模式的抽象集成。如：
如何把控類的邊界？
如何把控類的擴展性？
如何提高類的可維護性？
如何提高類的健壯性？
如何進行代碼重構？
難道架構師真的是個滿嘴跑火車號令群猿的人而已麽？
難道介面工程師只是命名寫註釋麽？
難道開發工程師拿到固定需求是隨便寫類的麽？
如果一個大型的研發體系中，沒有人懂源碼，沒有人懂架構，哦~呵呵~
這必將影響這個研發項目產出產品的生命周期了。
怎麼用，取決於個人，看多深，也取決於個人，也許看到了一個新奇的代碼很是喜歡呢。
理論就說這些，之後將一個一個拆，對於源碼的體系，進行慢慢的剖析。
我也不知道會更多久，會不會更下去，堅持一點是一點吧。
以上！
