前段時間應 CSDN 邀請審核 Java 知識庫內容，藉此我也有機會好好梳理了下自己的 Java 知識體系， 成文一篇望能幫到即將走進或正在 Java 世界跋涉的程式設計師們。
第一張，基礎圖
大約在 2003 年我開始知道 Java 的（當時還在用 Delphi），但到 2004 年本科畢業才開始正式決定學習 Java。 那時覺得用 Delphi 寫 C/S 架構的程式沒什麼意思，Java 當時提出的 J2EE 規範概念，企業級架構感覺各種高大上，壓抑不住內心的慾望就這麼開啟了 Java 的征途。 老實說，當時一進入 Java 世界的大門就暈了，各種規範、概念和英文縮寫能把人整的暈暈。
J2SE
J2EE
J2ME
什麼是基礎？ Java 是一門物件導向語言，最重要的概念是對象，而其所有的語法不過都是圍繞著它。 而其他程式的基本的結構和變數：順序、循環、分支，有之前的其他語言基礎不過就是換了個形式而已。 理解了對象，那麼圍繞對象的概念：類別、介面都是自然的延伸。 當然掌握了核心概念和基本的語法，也不過就是能寫個 Hello World 的水準，但重點是你的起點對了，旅程就近了。
關於基礎，在我眼中最核心和重要的部分並不多，我這裡簡單列下：
核心概念
類別庫
差別只在理解和抽象的適度與否。 JDK 那麼多函式庫，這裡只列了上面幾個，lang 裡面其實最重要的我想說的是 String，這是很多人都忽略的。 C 裡沒有 String 的概念，Java 則提供了這個對象，但沒能好好理解並用好這個對象，以後會讓你踩無盡的坑，還反覆踩。 不信去搜搜關於各種字元編碼亂碼的低階問題有多少，除此還有由於 String 引發的各種效能問題。 由String 這個核心物件發散出去關於字元的編碼，字元的位元組表達（大端、小端、網路位元組序），對GC 的影響，正則表達，模式匹配，這可能是Java 裡內涵最豐富的對象了。 Collections 框架提供了大量常用的資料結構封裝，基本上讓 Java 程式設計師告別了手動實現你從資料結構課程上學來的絕大部分常用資料結構。 正確理解不同資料結構的適用場景比自己能手動實現它們有用的多，沒事多看看 Collections 中的程式碼，都是大師級的實現啊。 記得我學 Java 時還是 JDK 1.3，進入工作後主流是 1.4，那時是沒有 concurrent 庫的。 自己處理線程間通訊時，被各種通知遺漏、早通知，死鎖搞的死去活來。 所以現在的 Java 的程式設計師都要幸福的多了，concurrent 又一個大師級的類別庫實現，也是可以沒事多看看，多揣摩。 IO 庫，不論是文件IO 還是網絡IO 都是Java 程式設計師最常打交道的，熟悉它的API 固然重要， 但更重要的是理解是如何對IO 操作的抽象和建模，理解不同的IO 模型其背後的本質與原理。
好了，當完成可上面這些基礎內容的學習後，我們得到了第一張地圖，像下面這樣。
第二張，技能圖
即使掌握了第一張圖要在 Java 的世界自由馳騁還是有點小困難的。 現在 Java 的一個主流使用場景是後端開發，這個領域在它的上一個時代是 J2EE（現在叫 Java EE） 的天下，又稱為 Java 企業版。 J2EE 包含的內容很多，核心是 EJB。當時我剛在學校裡累死累活學完分散式物件技術，以 CORBA 和 EJB 為例來實作。 又看了好幾本 EJB 設計模式和最佳實踐的書，然後還沒畢業進入公司一實習發現大家說現在不用 EJB 了，我們用一個叫 Spring 的東東。 IoC、DI 等新的英文縮寫又出現了，一口老血還來不及噴出，又重新振作開始新的學習旅程。
是的，EJB 在那時（2005）開始慢慢退出主流。 音樂學博士 Rod Johnson 一本 《Expert One-on-One J2EE Development without EJB》宣判了 EJB 的死刑，Spring 登上歷史舞台。 從這個 Java 進入了 Framework 大發展的時代，SSH/SSI 等技術框架組合形成了 Java 開發的主流，並持續影響至今。
Java 的框架越來越多，生態越來越大，初學者面對如此龐雜的框架，想必也是內心茫然，感覺真是學無止境，沒完沒了。 其實真實的專案中，真正用到的框架不多，SSH/SSI 基本上作為 Java Web 專案的核心框架，是你上手的核心利器，自需熟練。 但知其然還需知其所以然，Spring 接手了物件創造和相互依賴管理的工作，把設計模式隱藏在框架的運用中，許多人只知用而未曾思。 Web 開發從早期的 JSP 一大亂燉煮（HTML + CSS + JS + Java + SQL，早期我就是把所有這些都放一個 JSP 裡，想想有多難維護），到 MVC 的職責劃分。 僅僅一個 View 層也經歷了從標籤庫到頁面模版（Velocity、Freemarker）的進化，如今更徹底的前後端分離模型我更喜歡。 曾幾何時調幾個頁面的CSS 樣式殺死了我多少時間，專業化分工是有利於效率和深度的，互聯網和移動互聯網大發展引發的Web 版本進化，讓如今的前端複雜度已不在後端之下。
那麼身為 Java 工程師我到底要掌握多少框架才夠？這是一個偽命題，因為要掌握多少個都不會夠。 核心的熟練幾個，泛泛了解大量的，掌握快速學習框架的能力才是解決之道。 還是以 SSH/SSI 為例，專業前端分工的趨勢越明顯，徹底解放了後端 Java 工程師的苦惱。 以 Spring 為例的框架解決了大量通用型的問題，今天的 Spring 比當初大了幾十倍不止吧（把所有以 Spring 冠名的子項目算上的話），都是解決特定的通用問題。 所以當你寫程式碼時突然想寫個以Util 命名的類別時，停住想想這是一個解決通用問題的類麼，不妨搜搜現成的類別庫，比如說不定Apache Commons 裡就有你需要的代碼。 通用類別庫和框架讓我們解放出來專注業務邏輯與效率，這很可能是你的程式碼最有價值的部分，有程式設計師可能會抱怨這些沒技術含量，而我認為能用最有效的技術實現業務價值最大化才是最有技術含量的事。
框架如兵器，十八般（遠不止十八）兵器我未必樣樣會，但我們得有一樣能力，如張無忌學太極劍一樣，臨敵學劍還能勝之。 這裡面的訣竅不在學習招式，好比你也許覺得你 Hibernate 用法掌握的爐火純青又如何，一上線數據庫卻先崩潰了。 這裡的本質還在理解關係（SQL）資料庫，現在也許還需要加上對特定非關係式（NoSQL）資料庫的原理與機制的理解，甚至包括對 O/R 映射模型的本質理解。
所以，基礎像內功、框架如兵器、運用為招式，存乎一心、運用之妙，三者融會貫通，則已可在 Java 世界縱橫一方。 如上所述，基於此我們有了第二張地圖。
第三張，延伸圖
而第三張圖，我已無法再給出一個我認為稍具普適性的建議。 到了這個階段每個人的成長發展方向會受其環境和實際狀況影響，我以自己為例稍加說明。 進入網路公司後這幾年，Java 技術的發展開始從 J2EE 容器化的單一應用向 SOA 和微服務發展變遷。 規模化的分散式系統成為常態，所以我更多的相關工作便集中於此領域。 一方面縱深挖掘繼續補全知識盲區，例如分散式程式的基礎是 RPC 調用，RPC 的本質是網路加物件序列化。 相對就去徹底搞懂 TCP 的原理，Unix/Linux 下網路程式設計模型，幾種不同的網路 IO 模型。 然後再上升到 Java 基於此提供的網路程式設計模型，BIO（阻塞）、NIO（非阻塞）和 AIO（非同步IO），並結合實際工作實踐去深入理解。
在這個過程接觸了大量不同的 RPC 技術，從 Java 自帶的 RMI 到 WebService 技術規格。 之後一些更簡潔、更強大的 RPC 框架層出不窮，如 Hessian、Thrift 等等。 不同框架的本質依然如一，隨著服務化的發展基於 RPC 框架又進一步衍生出提供額外增值功能的服務框架，如阿里開源的 Dubbo。 隨著工作實務的深入，向下有可能又會進入 JVM 層級去分析物件的記憶體使用，執行緒的調度運行和延遲情況。 這個階段發揮核心作用的依然是前面說的快速學習並應用於工作實踐的能力。
與縱深的另一面是橫向擴展，隨著工作性質的變化也可能需要更寬廣的技術知識面。 例如成為架構師後，對技術知識面的廣度要求某些方面會更高。 有方法的技術學習和涉獵技巧讓你能更快擴張技術寬度，站在更高維度來審視不同的技術方向和產品，最有效的做出合適的技術決策。
在這個階段的每個人都可能面臨不同的環境和實踐，所以這階段形成的地圖會千差萬別。 以下是我的第三張圖，僅供走在 Java 旅程上的同儕參考。 而按這千差萬別的地圖走過的路徑，正巧構成獨一無二的你。
即使你現在還沒地圖，但也別茫然而永遠的駐足不前。 保持前進總會找到路，其實我就是這麼過來的，一直以來，不敢停下來。
以上就是Java 旅程：行者的地圖的內容，更多相關內容請關注PHP中文網（www.php.cn）！
