現象

很多類的命名相同（例如：常見於異常、常量、日誌等類），導致在import時，有時候張冠李戴，這種錯誤有時候很隱蔽。因為往往同名的類功能也類似，所以IDE不會提示warn。

解決

寫完代碼時，掃視下import部分，看看有沒有不熟悉的。替換成正確導入後，要註意下註釋是否也作相應修改。

啟示

命名盡量避開重復名，特別要避開與JDK中的類重名，否則容易導入錯，同時存在大量重名類，在查找時，也需要更多的辨別時間。

2.想當然的API

現象

有時候調用API時，會想當然的通過名字直接自信滿滿地調用，導致很驚訝的一些錯誤：

示例一：flag是true？

boolean flag = Boolean.getBoolean("true");

可能老是false。

示例二：這是去年的今天嗎（今年是2012年，不考慮閏年）？結果還是2012年：

Calendar calendar = GregorianCalendar.getInstance;calendar.roll(Calendar.DAY_OF_YEAR, -365);

下面的才是去年：

calendar.add(calendar.DAY_OF_YEAR, -365);

解決辦法

問自己幾個問題，這個方法我很熟悉嗎？有沒有類似的API? 區別是什麽？就示例一而言，需要區別的如下：

Boolean.valueOf(b) VS Boolean.parseBoolean(b) VSBoolean.getBoolean(b);

啟示

名字起的更詳細點，註釋更清楚點，不要不經了解、測試就想當然的用一些API，如果時間有限，用自己最為熟悉的API。

3.有時候溢出並不難

現象

有時候溢出並不難，雖然不常復現：

示例一：

數字1×數字2×數字3…

示例二：

在檢查是否為正數的參數校驗中，為了避免重載，選用參數number, 於是下面代碼結果小於0，也是因為溢出導致：

解決

讓第一個操作數是long型，例如加上L或者l（不建議小寫字母l，因為和數字1太相似了）；

不確定時，還是使用重載吧，即使用doubleValue，當參數是BigDecimal參數時，也不能解決問題。

啟示

對數字運用要保持敏感：涉及數字計算就要考慮溢出；涉及除法就要考慮被除數是0；實在容納不下了可以考慮BigDecimal之類。

4.日誌跑哪了？

現象

有時候覺得log都打了，怎麽找不到？

示例一：沒有stack trace！

} catch (Exception ex) { log.error(ex); }

示例二：找不到log！

} catch (ConfigurationException e) { e.printStackTrace; }

解決

1.替換成log.error(ex.getMessage,ex);

2.換成普通的log4j吧，而不是System.out。

啟示

1.API定義應該避免讓人犯錯，如果多加個重載的log.error(Exception)自然沒有錯誤發生

2.在產品代碼中，使用的一些方法要考慮是否有效，使用e.printStackTrace要想下終端(Console)在哪。

5.遺忘的Volatile

現象

在DCL模式中，總是忘記加一個Volatile。

privatestatic CacheImpl instance; //lose volatilepublicstaticCacheImpl getInstance { if (instance == null) { synchronized(CacheImpl.class) { if (instance == null) { instance = newCacheImpl ; } } } return instance; }

解決

毋庸置疑，加上一個吧，synchronized 鎖的是一塊代碼（整個方法或某個代碼塊），保證的是這”塊“代碼的可見性及原子性，但是instance == null第一次判斷時不再範圍內的。所以可能讀出的是過期的null。

啟示

我們總是覺得某些低概率的事件很難發生，例如某個時間並發的可能性、某個異常拋出的可能性，所以不加控制，但是如果可以，還是按照前人的“最佳實踐”來寫代碼吧。至少不用過多解釋為啥另辟蹊徑。

6.不要影響彼此

現象

在釋放多個IO資源時，都會拋出IOException ，於是可能為了省事如此寫：

publicstaticvoidinputToOutput(InputStream is, OutputStream os, boolean isClose) throws IOException { BufferedInputStream bis =new BufferedInputStream(is, 1024); BufferedOutputStream bos = newBufferedOutputStream(os, 1024); …. if (isClose) { bos.close; bis.close; } }

假設bos關閉失敗，bis還能關閉嗎？當然不能！

解決辦法

雖然拋出的是同一個異常，但是還是各自捕獲各的為好。否則第一個失敗，後一個面就沒有機會去釋放資源了。

啟示

代碼/模塊之間可能存在依賴，要充分識別對相互的依賴。

7.用斷言取代參數校驗

現象

如題所提，作為防禦式編程常用的方式：斷言，寫在產品代碼中做參數校驗等。例如：

privatevoidsend(List eventList) { assert eventList != null; }

解決

換成正常的統一的參數校驗方法。因為斷言默認是關閉的，所以起不起作用完全在於配置，如果采用默認配置，經歷了eventList != null結果還沒有起到作用，徒勞無功。

啟示

有的時候，代碼起不起作用，不僅在於用例，還在於配置，例如斷言是否啟用、log級別等，要結合真實環境做有用編碼。

8.用戶認知負擔有時候很重

現象

先來比較三組例子，看看那些看著更順暢？

示例一：

publicvoidcaller(int a, String b, float c, String d) { methodOne(d, z, b); methodTwo(b, c, d); }publicvoidmethodOne(String d, float z, String b)publicvoidmethodTwo(String b, float c, String d)

示例二：

publicbooleanremove(String key, long timeout) { Futurefuture = memcachedClient.delete(key); publicbooleandelete(String key, long

示例三：

publicstaticString getDigest(String filePath, DigestAlgorithm algorithm) publicstaticString getDigest(String filePath, DigestAlgorithm digestAlgorithm)

解決

保持參數傳遞順序；

remove變成了delete，顯得突兀了點， 統一表達更好；

保持表達，少縮寫也會看起來流暢點。

啟示

在編碼過程中，不管是參數的順序還是命名都盡量統一，這樣用戶的認知負擔會很少，不要要用戶容易犯錯或迷惑。例如用枚舉代替string從而不讓用戶迷惑到底傳什麽string, 諸如此類。

9.忽視日誌記錄時機、級別

現象

存在下面兩則示例：

示例一：該不該記錄日誌？

catch (SocketException e) { LOG.error("server error", e); thrownewConnectionException(e.getMessage, e); }

示例二：記什麽級別日誌？

在用戶登錄系統中，每次失敗登錄：

LOG.warn("Failed to login by "+username+");

解決

1.移除日誌記錄：在遇到需要re-throw的異常時，如果每個人都按照先記錄後throw的方式去處理，那麽對一個錯誤會記錄太多的日誌，所以不推薦如此做；但是如果re-throw出去的exception沒有帶完整的trace( 即cause)，那麽最好還是記錄下。

2.如果惡意登錄，那系統內部會出現太多WARN，從而讓管理員誤以為是代碼錯誤。可以反饋用戶以錯誤，但是不要記錄用戶錯誤的行為，除非想達到控制的目的。

啟示

日誌改不改記？記成什麽級別？如何記？這些都是問題，一定要根據具體情況，需要考慮：

1.是用戶行為錯誤還是代碼錯誤？

2.記錄下來的日誌，能否能給別人在不造成過多的幹擾前提下提供有用的信息以快速定位問題。

10.忘設初始容量

現象

在JAVA中，我們常用Collection中的Map做Cache,但是我們經常會遺忘設置初始容量。

cache=new LRULinkedHashMap

解決

初始容量的影響有多大？拿LinkedHashMap來說，初始容量如果不設置默認是16，超過16×LOAD_FACTOR,會resize(2 * table.length),擴大2倍：采用 Entry newTable = new Entry[newCapacity]; transfer(newTable)，即整個數組Copy， 那麽對於一個需要做大容量CACHE來說，從16變成一個很大的數量，需要做多少次數組復制可想而知。如果初始容量就設置很大，自然會減少resize, 不過可能會擔心，初始容量設置很大時，沒有Cache內容仍然會占用過大體積。其實可以參考以下表格簡單計算下, 初始時還沒有cache內容, 每個對象僅僅是4字節引用而已。

memory for reference fields (4 bytes each);

memory for primitive fields

啟示

不僅是map, 還有stringBuffer等，都有容量resize的過程，如果數據量很大，就不能忽視初始容量可以考慮設置下，否則不僅有頻繁的 resize還容易浪費容量。

在Java編程中，除了上面枚舉的一些容易忽視的問題，日常實踐中還存在很多。相信在不斷的實踐中自己就可以發現並改正。

總結：

不管是開發、測試、運維，每個技術人員心裏多多少少都有一個成為技術大牛的夢，畢竟“夢想總是要有的，萬一實現了呢”！正是對技術夢的追求，促使我們不斷地努力和提升自己。

Java編程最容易忘記的問題，請對號入座！