在理論上, 理論和實踐是沒有差異的; 但在實踐中, 是有的。
In theory, there is no difference between theory and practice. But in practice, there is.
——Snepscheut
為了方便閱讀，把本系列帖子的目錄整理如下：
為什么我先拿“數據結構和算法”說事捏？這玩意是寫程序最最基本的東東。不管你使用 Java 還是其它的什么語言，都離不開它。而且這玩意是跨語言的，學好之后不管在哪門語言中都能用得上。
既然“數據結構和算法”這么重要，為什么很多 Java 新手卻很不熟悉捏？我琢磨了一下，估計有兩種可能。有些人雖然是計算機系畢業的，但是當初壓根沒好好學過這門課程，到工作時早都還給老師了；還有一些人是中途轉行干編程，轉行后又沒有好好地打基礎（都指望速成）。
下面列出幾個很基本的問題，如果你每一個問題都搞得很清楚，那說明你過了這關，可以去看看下一個帖子了。否則的話，你趕緊去找本算法和數據結構的書惡補一下吧。
什么時候該用數組型容器、什么時候該用鏈表型容器？
什么是散列函數？HashMap 的實現原理是什么？
什么是遞歸？如果你以前從來沒寫過遞歸函數，嘗試著寫一個（比如用遞歸函數進行目錄樹遍歷）。
什么是算法復雜度？
你是否理解空間換時間的思想？
寫一個針對整數數組的冒泡排序函數，看看你要修改幾次才能跑通。
寫一個針對整數數組的二分查找函數，看看你要修改幾次才能跑通。
按理說 Java 是一個很 OO 的語言，Java 社區也一向是充滿了“對象”的氛圍。但俺在面試 Java 程序員時，卻屢屢碰到令人大跌眼鏡的事情。俺碰到不止一個求職者，連什么是“多態”都講不清楚。很多人號稱用過設計模式，但一半以上都僅限于單鍵模式和抽象工廠模式。當我深入問他/她抽象工廠模式到底有什么好處時，很多人語焉不詳。
為什么很多 Java 程序員會缺乏面向對象基本功？這得怪那些 Java 框架。現在 Java 的各種框架太發達、太傻瓜化了，導致很多程序員只需要按部就班、照著框架進行代碼填空，基本已經喪失了 OOA 和 OOD 的能力。我手下有些個 Java 程序員，對 Spring、Hibernate 等框架了如指掌；但如果給他一個簡單需求，讓他寫一個脫離 Web 框架的獨立 Application，他就不知所措了。這樣的開發人員，將來只能成為所謂的“軟件藍領”，崗位很難得到提升。
同上一個帖子一樣，我這次也提如下幾個問題：
★基于接口的繼承和基于實現的繼承各有什么優缺點？
★繼承（包括 extend 和 implement）有什么【缺點】？
★多態（polymorphism）有什么【缺點】？
★為什么 Java 可以多繼承 interface，而不可以多繼承 class？
★假如讓你寫一個小游戲（比如人機對戰的五子棋），你會如何設計類結構？
★類結構設計時，如何考慮可擴展性？
如果上述這些問題你都能夠搞得比較清楚，說明你的 OO 基礎還過得去。否則的話，我建議你一邊找些 OOAD 和設計模式的書看看，同時自己動手寫些簡單的小程序（不依賴那些框架），把學到的模式理論結合到實踐中。通過這種方式來提高自己 OOAD 的能力，效果會比較好。
目錄
★隨意地命名
★習慣于代碼的 copy & paste
★Magic Number 滿天飛
★代碼耦合度太大
★被 GC 寵壞
上次聊了“缺乏面向對象基本功”，今天來說說編程習慣的問題。今天說的這些壞習慣大部分都是跨語言的（C++、Python 新手也有），而且大部分都需要靠平時不斷地努力才能慢慢改掉。
★隨意地命名
有些新手寫程序，當需要定義某個變量名（也可能是函數名、類名、包名等）時，隨意地一敲鍵盤，名字就起好了......若干星期后，碰到某 bug，再來看自己寫的代碼時，心中暗自嘀咕：“這代碼是我寫的嗎？咋都看不懂捏？”
所以我常跟新來的菜鳥說，命名不規范害死人啊！鑒于該問題相當普遍，我整理了幾種典型的作為反面教材，具體如下：使用單字母命名變量；使用一些沒太大意義的變量名（例如 s1、s2、s3）；對同一個業務概念使用不同的術語/縮寫（容易讓讀代碼的人神經分裂）；使用拼音命名（如果你團隊中有港臺人士或者老外，就慘了）。
★習慣于代碼的 copy & paste
這是一個很普遍的問題。很多新手寫代碼的時候，如果發現要寫的某個函數和前幾天寫的某個函數差不多，就把原來的那個函數貼過來，然后稍微改幾下，心中還暗喜：“又快速搞定了一個功能”......
同學，如果你也喜歡這么干，可要注意了。這種做法是代碼臭味（借用《重構 - 改善既有代碼的設計》的提法）的主要來源，導致代碼可維護性大大下降。當你將來需要增加功能或修改 bug 的時候，要同時改動多個地方，而那時你估計已經想不起來這砣代碼有幾個克隆了。
★Magic Number 滿天飛
如果你沒有聽說過“Magic Number”，先看“這里”了解一下。
為了說明Magic Number的問題，咱找個例子來說事兒：假設有個業務邏輯中需要進行10秒的超時等待，你會怎么寫這個sleep語句？我估計大部分人不外乎下面三種寫法：
1、直接寫上 sleep(101000); 了事
2、定義一個常量 TIMEOUT_XXX = 101000; 然后 sleep(TIMEOUT_XXX);
3、在配制文件中加入一個超時項，然后程序讀取配制文件獲得超時值，然后調用 sleep。（此處提到的“配置文件”是廣義的，泛指各種可用于存儲配置信息的機制，如：xml 文件、ini 文件、數據庫 ...）
如果你的做法類似于寫法1，你多半喜歡隨手硬編碼。硬編碼不光缺乏可讀性，而且具有和“代碼拷貝粘貼”類似的代碼臭味（可能會存在多個 Magic Number 克隆），不利于日后維護。
至于寫法2，比寫法1稍好（至少可讀性好了）。但是，將來一旦發生需求變更，要求在【運行時】調整超時間隔（甚至要求讓用戶來配制超時間隔），則寫法2的缺點立馬暴露無遺。
★代碼耦合度太大
每當說到 MVC 或者設計模式，幾乎每個 Java 開發人員都能說得頭頭是道？但是說歸說，真正寫代碼的時候，鮮有人寫出的代碼是層次清楚的。至于說到代碼耦合分別由哪些情況引起？什么是正交的設計？（關于耦合與正交設計，我后面會專門討論一下）能完全搞明白的人就更少了。
所以很多 Java 新手的代碼耦合度大也就不足為奇了。我曾經抽查過試用期員工的代碼，各種業務邏輯糾纏在一起，代碼臭味都要熏死人。想重構都無從下手，只好讓他推倒重寫。
★被 GC 寵壞
由于 Java 在語言層面提供了內存的垃圾回收機制，程序員只管申請內存，不需要再關心釋放的問題。因此很多新手養成了壞習慣，對于其它資源（比如數據庫連接）也只申請不釋放（有些人甚至天真地以為 JVM 會幫你搞定資源回收）。
還有些人雖然知道資源需要釋放，但是常常忘記（比如寫了打開數據庫連接和相關代碼，【即將】寫關閉數據庫連接時，突然有人叫你去吃中飯，回來后就把這茬給忘了）。
這個壞習慣會導致資源的泄露，而資源泄露往往比內存泄露更要命。如果你寫的程序是長時間運行的（比如運行在 Web Server 上），時間長了會由于資源耗盡而導致整個進程出問題。
4 異常處理使用不當
目錄
★空的 catch 語句塊
★沒有使用 finally
★籠統的 catch 語句塊
★使用函數返回值進行錯誤處理
★不清楚“Checked Exception”和“Runtime Exception”的區別
上一個帖子討論了“編程習慣的問題”，今天來聊聊關于異常處理的話題。
★空的 catch 語句塊
犯這種錯誤的人比較少，一般發生在剛學會 Java 或者剛參加工作不久的人身上。
所謂“空 catch 語句塊”就是在 catch 語句塊中沒有對異常作任何處理（比如記錯誤日志），導致異常信息被丟棄/忽略。一旦程序不能正確運行，由于查不到任何 log 信息，只好從頭看代碼，靠肉眼找 bug。
★沒有使用 finally
很多人在 catch 語句之后不使用 finally 語句。由于在 try 語句中可能會涉及資源的申請和釋放。如果在資源申請之后、資源釋放之前拋出異常，就會發生資源泄露。
（資源泄露的嚴重性，上一個帖子已經聊過了）
★籠統的 catch 語句塊
有些人為了省事，只在自己模塊的最外層代碼包一個 try 語句塊，然后 catch(Exception)。不管捕獲到什么異常，都作統一 log 了事。這種做法比“空 catch 語句塊”稍好，但由于不能對具體的異常進行具體處理，對一些可恢復的異常（下面會提到），喪失了恢復的機會。而且也可能導致上述提到的資源泄露的問題。
★使用函數返回值進行錯誤處理
有些人放著 Java 的異常機制不用，而用函數返回值來表示成功/失敗（比如：返回 true 表示成功、false 表示失敗），簡直是“捧著金碗要飯”。個人感覺，從 C 轉到 Java 的人比較容易有此毛病。這種做法會導致如下幾個問題：
- 返回值一般用整數值或布爾值表示，傳遞的信息過于簡陋；
- 一旦調用者忽略了錯誤返回碼，就會導致和“空 catch 語句塊”類似的問題；
- 對同一個函數的多處調用，都需要對返回值進行重復判斷，導致代碼冗余（代碼冗余的壞處，上一個帖子也已經聊過了）。
★不清楚“Checked Exception”和“Runtime Exception”的區別
這個現象比較普遍，俺發現很多2年以上 Java 工作經驗的人尚未完全搞明白兩者的區別。看來這個問題得詳細說一下。
當初Java的設計者有意區分這兩種異常，是別有深意的。其中“Checked Exception”用于表示可恢復的異常（也就是你必須檢查的異常）；而“Runtime Exception”表示不可恢復的異常（也就是運行時異常，主要是程序 bug 和致命錯誤，你【不需要】檢查）。不過這種做法引來了很多爭議（包括很多 Java 大牛），鑒于本帖子主要針對新手，以后再專門來聊這個爭議的話題。
為了便于理解，下面我舉一個例子來說明。假設你要寫一個 Download 函數，根據傳入的 URL（String 參數）返回對應網頁的內容文本。這時候有兩種情況你需要處理：
- 如果傳入的 URL 參數是 null，這表明該函數的調用者出 bug 了，而程序本身的 bug 是很難在運行時自我恢復的。這時候 Download 函數必須拋出 Runtime Exception。并且 Download 函數的調用者【不應該】嘗試去處理這個異常，必須讓它【盡早】暴露出來（比如讓 JVM 自己終止運行）。
- 如果傳入的 URL 參數非 null，但是它包含的字符串不是一個合法的URL格式（可能由于用戶輸入錯誤導致）。這時候 Download 函數必須拋出 Checked Exception。并且 Download 函數的調用者必須捕獲該異常并進行相應的處理（比如提示用戶重新輸入 URL）。
上面就是幾種常見的Java異常處理的誤用。下一個帖子我們來聊一下“對虛擬機（JVM）了解不足”。
目錄
★關于基本類型和引用類型
★關于垃圾回收（Garbage Collection）
★關于字符串
★關于范型（Generic Programming）
★關于多線程
上次的帖子討論了Java異常機制的幾種誤用，今天咱們來說說 JVM（以及 Java 編譯器）相關的話題。為啥要聊 JVM 捏？因為有很多 Java 程序員，由于對 JVM 缺乏了解，在碰到某些技術問題時無從下手；另外，由于缺乏對 JVM 的了解，可能導致寫出來的代碼性能巨差或者有嚴重的 Bug。所以俺在之前的帖子“學習技術的三部曲：WHAT、HOW、WHY”中，強調了掌握內部機制的重要性。對于一個 Java 程序員來說，你不一定要非常清楚 JVM 的細節，但是對于一些關鍵的運作機制，還是要掌握大致的概念。
按照本系列的慣例，俺會問幾個和 JVM 相關的問題，你如果對這些問題不是很明白，那得考慮花點時間去了解一下了。另外，鑒于有網友批評“本系列”帖子：光診斷毛病，不開出藥方。（說得很形象，也很中肯）俺會針對下面提出的問題，寫一些帖子來解答。
★關于基本類型和引用類型
很多新手不理解Java的基本類型和引用類型在本質上有什么區別。請看如下的問題：
◇這兩種類型在內存存儲上有什么區別？
◇這兩種類型在性能上有什么區別？
◇這兩種類型對于 GC 有什么區別？
關于前兩個問題，請看之前的帖子“Java性能優化[1]：基本類型 vs 引用類型”。
★關于垃圾回收（Garbage Collection）
很多新手不理解 GC 的實現機制。請看如下的問題：
◇GC 是如何判斷哪些對象已經失效？
◇GC 對性能會有哪些影響？
◇如何通過 JVM 的參數調優 GC 的性能？
關于 GC 的問題，可以參見之前的帖子“Java性能優化[3]：關于垃圾回收（GC）”。
★關于字符串
對于 Java 提供的 String 和 StringBuilder，想必很多人都知道：String 用于常量字符串，StringBuilder 用于可變字符串。那 Java 當初為什么要這樣設計捏？為啥不用一個類來統一搞定捏？
★關于范型（Generic Programming）
從 JDK 1.5開始，Java 引入了一個重量級的語法：范型。不過捏，很多新手僅僅知道范型的皮毛，而對于很多本質的東東，不甚了解。
◇GP 是在編譯時實現的還是在運行時實現的？為什么要這么實現？
◇GP 的類型擦除機制是咋回事？有啥優點/缺點？
◇使用范型容器（相對于傳統容器）在性能上有啥影響？為什么？
★關于多線程
另外，多線程也是大部分 Java 新手的短板。所以俺最后再來提幾個關于多線程的問題。
◇synchronized 關鍵字是怎么起作用滴？
◇synchronized 的顆粒度（或者說作用域）如何？是針對某個類還是針對某個類對象實例？
◇synchronized 對性能有沒有影響？為什么？
◇volatile 關鍵字又是派啥用滴？啥時候需要用這個關鍵字捏？
參考： Java核心技術（極簡教程）
