爲什麼我先拿“數據結構和算法”說事捏？這玩意是寫程序最最基本的東東。不管你使用 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 的能力，效果會比較好。
三：缺少良好的編程習慣
★隨意地命名
有些新手寫程序，當需要定義某個變量名（也可能是函數名、類名、包名等）時，隨意地一敲鍵盤，名字就起好了…若干星期後，碰到某 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 上），時間長了會由於資源耗盡而導致整個進程出問題。
四：異常處理使用不當
★空的 catch 語句塊
犯這種錯誤的人比較少，一般發生在剛學會 Java 或者剛參加工作不久的人身上。
所謂“空 catch 語句塊”就是在 catch 語句塊中沒有對異常作任何處理（比如記錯誤日誌），導致異常信息被丟棄/忽略。一旦程序不能正確運行，由於查不到任何 log 信息，只好從頭看代碼，靠肉眼找 bug。
★沒有使用 finally
很多人在 catch 語句之後不使用 finally 語句。由於在 try 語句中可能會涉及資源的申請和釋放。如果在資源申請之後、資源釋放之前拋出異常，就會發生資源泄露。
（資源泄露的嚴重性，上面已經聊過了）
★籠統的 catch 語句塊
有些人爲了省事，只在自己模塊的最外層代碼包一個 try 語句塊，然後 catch(Exception)。不管捕獲到什麼異常，都作統一 log 了事。這種做法比“空 catch 語句塊”稍好，但由於不能對具體的異常進行具體處理，對一些可恢復的異常（下面會提到），喪失了恢復的機會。而且也可能導致上述提到的資源泄露的問題。
★使用函數返回值進行錯誤處理
有些人放着 Java 的異常機制不用，而用函數返回值來表示成功/失敗（比如：返回 true 表示成功、false 表示失敗），簡直是“捧着金碗要飯”。個人感覺，從 C 轉到 Java 的人比較容易有此毛病。這種做法會導致如下幾個問題：
1.返回值一般用整數值或布爾值表示，傳遞的信息過於簡陋；
2.一旦調用者忽略了錯誤返回碼，就會導致和“空 catch 語句塊”類似的問題；
3.對同一個函數的多處調用，都需要對返回值進行重複判斷，導致代碼冗餘（代碼冗餘的壞處，上面也已經聊過了）。
★不清楚“Checked Exception”和“Runtime Exception”的區別
這個現象比較普遍，俺發現很多2年以上 Java 工作經驗的人尚未完全搞明白兩者的區別。看來這個問題得詳細說一下。
當初Java的設計者有意區分這兩種異常，是別有深意的。其中“Checked Exception”用於表示可恢復的異常（也就是你必須檢查的異常）；而“Runtime Exception”表示不可恢復的異常（也就是運行時異常，主要是程序 bug 和致命錯誤，你【不需要】檢查）。不過這種做法引來了很多爭議（包括很多 Java 大牛），鑑於本帖子主要針對新手，以後再專門來聊這個爭議的話題。
爲了便於理解，下面我舉一個例子來說明。假設你要寫一個 Download 函數，根據傳入的 URL（String 參數）返回對應網頁的內容文本。這時候有兩種情況你需要處理：
1.如果傳入的 URL 參數是 null，這表明該函數的調用者出 bug 了，而程序本身的 bug 是很難在運行時自我恢復的。這時候 Download 函數必須拋出 Runtime Exception。並且 Download 函數的調用者【不應該】嘗試去處理這個異常，必須讓它【儘早】暴露出來（比如讓 JVM 自己終止運行）。
2.如果傳入的 URL 參數非 null，但是它包含的字符串不是一個合法的URL格式（可能由於用戶輸入錯誤導致）。這時候 Download 函數必須拋出 Checked Exception。並且 Download 函數的調用者必須捕獲該異常並進行相應的處理（比如提示用戶重新輸入 URL）。
五：不瞭解 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微信企業付款到零錢(十分鐘搞定)
微信授權獲取用戶openId的方法和步驟
一個微信號同時支持多個環境網頁授權
微信兩種簽名算法MD5和HMAC-SHA256