最近再回顧java編程這些日子,以爲寫出優美的java代碼是個人所追崇的驕傲。做爲一位程序員不斷積累知識溫故知新,才能厚積薄發利於不敗之地。 java
對於方法的註釋應該包含詳細的入參和結果說明,有異常拋出的狀況也要詳細敘述;類的註釋應該包含類的功能說明、做者和修改者。 程序員
多處使用的相同值的變量應該儘可能概括爲一個常量,方便往後的維護。 編程
儘可能在循環中少作一些可避免的方法調用,這樣能夠節省方法棧的建立。例如: 數組
for(int i=0;i System.out.println(i);
} 緩存
能夠修改成: jvm
for(int i=0,size=list.size();i System.out.println(i);
} 性能
在Java中,接口裏只容許存在常量,所以把常量放到接口中聲明就能夠省去public static final這幾個關鍵詞。 ui
這個問題比較常見。一般程序員最好可以對list的使用場景作出評估,而後根據特性做出選擇。ArrayList底層是使用數組實現的,所以隨機讀取數據會比LinkedList快不少,而LinkedList是使用鏈表實現的,新增和刪除數據的速度比ArrayList快很多。 spa
這個問題也比較常見。在進行字符串拼接處理的時候,String一般會產生多個對象,並且將多個值緩存到常量池中。例如: code
String a=」a」;
String b=」b」;
a=a+b;
這種狀況下jvm會產生」a」,」b」,」ab」三個對象。並且字符串拼接的性能也很低。所以一般須要作字符串處理的時候儘可能採用StringBuffer和StringBuilder來。
在代碼中,若是可使用基本數據類型來作局部變量類型的話儘可能使用基本數據類型,由於基本類型的變量是存放在棧中的,包裝類的變量是在堆中,棧的操做速度比堆快不少。
這樣作能夠幫助jvm更快的進行內存回收。固然不少人其實對這種作法並不感冒。
典型的場景是使用io流的時候,不管是否出現異常最後都應該在finally中對流進行關閉。
在jdk的HashMap實現中,判斷兩個Object類型的key是否相同的標準是hashcode是否相同和equals方法的返回值。若是業務上須要對兩個數據相同的內存對象看成不一樣的key存儲到hashmap中就要對hashcode和equals方法進行覆蓋。