一點一點看JDK源碼（〇）
liuyuhang原創，未經允許進制轉載
寫在前面：
幾乎所有的大神都會強調看源碼，也強調源碼的重要性；
但是如何看源碼，源碼看什么？看了什么用？看了怎么用？
困擾很多人，尤其是初學者。
本系列的目的在於看源碼，並非學習和總結源碼，先能夠粗略的瀏覽大量的原碼
並保證知曉有這么個東西，有個基本概念，再對其中的設計原理，優化方案進行學習
本文簡單的回答以下幾個問題：
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的設計模式，是我們開發模式的抽象集成。如：
如何把控類的邊界？
如何把控類的擴展性？
如何提高類的可維護性？
如何提高類的健壯性？
如何進行代碼重構？
難道架構師真的是個滿嘴跑火車號令群猿的人而已么？
難道接口工程師只是命名寫注釋么？
難道開發工程師拿到固定需求是隨便寫類的么？
如果一個大型的研發體系中，沒有人懂源碼，沒有人懂架構，哦~呵呵~
這必將影響這個研發項目產出產品的生命周期了。
怎么用，取決於個人，看多深，也取決於個人，也許看到了一個新奇的代碼很是喜歡呢。
理論就說這些，之后將一個一個拆，對於源碼的體系，進行慢慢的剖析。
我也不知道會更多久，會不會更下去，堅持一點是一點吧。
6.已更列表：
一點一點看JDK源碼（一）Collection體系概覽
一點一點看JDK源碼（二）java.util.List
一點一點看JDK源碼（三）java.util.ArrayList 前偏
一點一點看JDK源碼（四）java.util.ArrayList 中篇
一點一點看JDK源碼（五）java.util.ArrayList 后篇之forEach
一點一點看JDK源碼（五）java.util.ArrayList 后篇之sort與Comparator
一點一點看JDK源碼（五）java.util.ArrayList 后篇之SubList
一點一點看JDK源碼（五）java.util.ArrayList 后篇之Spliterator
一點一點看JDK源碼（五）java.util.ArrayList 后篇之removeIf與Predicate
一點一點看JDK源碼（六）java.util.LinkedList前篇之鏈表概要
以上！