最近奧運會，中國仍是依然 NB，尤爲前兩天的男子百米半決賽、決賽，完全被蘇神點燃了。程序員
說是亞洲奇蹟，一點也不爲過。redis
看比賽，有好的，也有氣人的，好比裁判，裁判適當照顧東道主也能忍了，可是有時候太過度了，直接選擇性眼瞎。算法
說到選擇性眼瞎，我想的一個事情。數據庫
我們幹程序員的，常常須要應用、研究一些開源組件。研究開源組件，就少不了去看資料、看源代碼。在看代碼、學習的過程當中，我們可不能像那些眼瞎的裁判，我們須要高效的學習：看清全局、主要脈絡、關鍵細節。緩存
這篇文章就和你們說說我本身高效學習的方法。安全
對我而言，作好這件事的關鍵就在於問本身七個問題。架構
問題1. 組件解決了什麼問題
問這個問題的目的是明確組件的問題域，任何組件的出現都是爲了解決某類問題的。併發
咱們在職業生涯裏，遇到的技術問題實際上是有限的。面對這些有限的問題，咱們熟悉的組件越多，解決問題的思路和辦法就越多。當你對某種技術問題，有着比別人更多的思路和辦法，那天然而然，你的技術話語權就會越大。高併發
以我曾經深刻研究過的 druid（阿里的開源數據庫鏈接池）組件爲例：性能
druid 要解決的問題本質實際上是如何下降應用和中間件交互所消耗的時間成本。
知道了 druid 要解決的問題，咱們就等於知道了它的核心主題。druid 的主要技術思路，所有都是圍繞着這個核心主題來實現的。
好比，druid 自己的 LRU 策略、對一些關鍵對象的緩存、競爭資源的高效率利用……都是圍繞着這個核心問題來設計和落地的。
同時，咱們明確了 druid 要解決的問題後，若是咱們對如今 jedis 這套東西不滿意，是否是就能夠利用 druid 的技術思路，從新設計和實現一套新組件，去替代 jedis，以便下降和 redis 交互的時間成本呢？
問題2. 組件有什麼優勢
確認了組件須要解決的問題，只是第一步。一套開源組件，每每項目都比較龐大。因此，就得想個辦法分而克之，分出各個具體的知識點去學習。
而這些知識點，每每和官方文檔宣傳的組件優勢能夠對上。
好比，druid 的官方文檔是這麼說的：
從上面這幅圖，就能夠看出來，druid 有以下幾個特色：
- 能被監控
- 容易擴展
- 性能優秀
- 穩定性好
- 安全
- 運行期問題容易排查
這些就是咱們要去學習的各個知識點。
問題3. 組件的主幹和分支都是哪些
知道了組件的優勢，就等同於知道了須要學習的知識點。但是，知識點若是多而雜，就須要確認好哪些學哪些不學？哪些先學哪些後學？
那麼，組件的主幹和分支就須要分解出來，以便定出學習計劃。而劃分出主幹和分支，就須要綜合咱們前面說的組件要解決的問題。
經過前面的學習，咱們知道 druid 解決的是下降中間件的時間成本，也知道了它的特色：
- 能被監控
- 容易擴展
- 性能優秀
- 穩定性好
- 安全
- 運行期問題容易排查
此時，咱們的學習計劃就是：先學習 druid 是如何實現高性能的；高性能後，若是咱們研究 druid 是爲了後續在工做中應用，那麼，能被監控這個特色就是下一個要學習的知識點。
因此，這一問，是爲了擬定學習計劃而問。
問題4. 組件的這些優勢是如何實現的
在上個問題以後，咱們就能夠分步驟的進行學習了。學的怎麼樣，就須要經過這個問題，來考察本身是否真的學懂了這些知識點。
回到 druid 上，讓人滿意的答案就是，咱們能用本身的話去總結出每一個知識點的技術實現。好比：
問：druid 的監控是如何實現的？
答：druid 經過本身實現 JDBC API 自身提供的 PooledConnection、Connection、Statement、ResultSet接口，得到了能夠在這些接口的關鍵方法中植入統計的能力。統計的數據會按期採樣後存儲在某些命名叫作 xxxStat 的對象裏，供後面展現使用。
問：druid 是如何實現擴展的？
答：能擴展的實現方式是第三方實現 druid 提供的一個 Filter 接口後，再被配置到 druid 的配置文件裏。這樣就會在 DruidDataSource 初始化的時候，去讀取並初始化這些實現了 Filter 接口的實例。初始化後的 Filter 會在後面 druid 從建立數據庫鏈接到執行 SQL 語句再到釋放鏈接這一系列步驟後，被不斷的鏈式執行。
就這樣，分知識點回答出讓本身滿意的答案，就等同於考覈了本身對每一個知識點學習的質量，若是回答不滿意，就再去查漏補缺便可。
問題5. 組件的系統設計思路是什麼
咱們學習了各個零散的知識點以後並不夠，由於學習一套開源組件，原理是基礎，系統設計則是骨架。
明白了技術點，只是對當編碼高手有用，可是當你本身設計組件的時候，你的底氣在哪裏呢？答案就在這些你看過的開源組件的系統設計思路上。
因此，把知識點融合起來造成一個總體，再去推斷出系統的設計思路，對咱們成爲一名優秀的架構師，是有很是大的幫助的。
好比,經過各個知識點的深刻學習，融會貫通後，我認爲 druid 的設計思路以下：
若是之後遇到爲公司底層構造一套池化中間件對象的需求時，這種設計思路天然就成了我設計的重要模板之一。
問題6. 組件的缺點是什麼
爲何會問組件的缺點？由於在我如此瞭解了一套組件以後，卻仍是免不了誤用和踩坑，這其中最嚴重的就是，生產環境在組件出現問題以後，咱們卻沒有緊急預案。
這種現象的緣由就是沒有去深刻思考過一套技術的利弊。問組件的缺點，就會迫使咱們去深刻思考利弊，從而在之後不論是應用組件，又或者是去根據學習到的知識本身實踐，都能胸有成竹，從容以對。
回到 druid 身上，當咱們去讀它源碼的時候，思考一下：
durid 的這些實現真的就是完美的嗎？
那確定不是， 好比：
-
druid 的採樣功能不少時候咱們並不須要，可是因爲 druid 的實現是寫死在實現的關鍵代碼裏的，因此沒法自由的對其進行插拔。這時候，就要注意，採樣可能形成的內存佔用問題。
-
druid 是對 JDBC API 作了層層封裝的，在這些封裝中 druid 又添加了不少本身的實現。可是，這些實現很難避免bug，然而因爲有這些封裝，就會致使 Bug 很難查，又或者很難本身改。這時候，就須要在測試環境，把 druid 的日誌級別調成 DEBUG 級別，而後仔細觀察日誌，看看是否有什麼不可知的風險。
因此，這一問，是爲了深度思考，讓咱們在任何新技術的學習和實戰時，都能成爲最穩定的那個仔。
無論之後咱們模仿仍是應用 druid，就能提早預測到風險，從而重點監控，提早準備預案。
問題7. 和同類別的組件之間有什麼區別
當學習完了組件，知道了組件的優缺點，理解了組件的運行原理，明白了組件的設計思路以後，一切就完整了嗎？
對不起，還不夠。
由於咱們還缺少一種東西，就是學習的拓展，即學習的廣度。
學習組件，咱們除了知道它要解決的問題域外，還須要知道它在同類組件中的地位。
爲何？由於之後咱們去任何一個稍微成規模的公司後，須要面臨一個問題，內部的競爭。
好比，咱們寫了一套消息治理中間件。若是想提高本身的技術話語權，就須要在全公司，和同類產品競爭。競爭勝出了，本身的職業生涯就有了巨大發展的可能。
回到 druid 上，在SpringBoot2.0時代，druid 出現了巨大的競爭對手——HiKariCP。
而 HiKariCP 之因此能勝出，是由於它排除了 druid 使用的公平鎖，使得性能提高了大約 70%。
經過 druid 和 HiKariCP 的比較和學習，咱們就能更加深刻的理解高併發，能更有效率的去壓榨出系統的性能。
經過 druid 和 HiKariCP 做者之間的互相較量，咱們還能明白如何去更好的對比競品，去展示最爲關鍵的數據指標，一舉贏得勝利。
以上列舉的七個問題，是我爲了解決高效高質研究開源組件，獲得的最佳實踐。
總結一下：
- 先經過問組件解決了什麼問題，去肯定本身的學習目的和思考邊界。
- 再問組件有什麼優勢，以及主幹和分支是哪些，去擬定出學習計劃。
- 再後，經過問組件的優勢是如何實現的，去考察本身的學習質量。
- 而後，經過問組件的系統設計思路是什麼，讓本身講學到的各類獨立的知識融匯貫通，打形成體系。
- 最後，經過問組件的缺點是什麼以及和競品的區別去迫使本身在學習以外，再行深度思考和廣度思考，對學習進行查漏補缺以及進一步提高學習質量，打造出更爲突出的知識體系。
IT這行業是須要不斷學習的，而高效高質量學習，是讓咱們的職業生涯走的更穩更順的關鍵所在。
但願這篇文章對你們有幫助，看完若是以爲有收穫，請幫忙隨手點個贊。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程序員，一路打拼，一路成長。
我會把本身的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注個人公衆號，關注後能夠領取高併發、算法學習資料。