代碼優化的目標是：

1、減小代碼的體積

2、提高代碼運行的效率

3、打發時間

本文的內容有些來自網絡，有些來自平時工作和學習，當然這不重要，重要的是這些代碼優化的細節是否真真正正地有用。那本文會保持長期更新，只要有遇到值得分享的代碼優化細節，就會不定時地更新此文。

（0）儘量使用HashMap、ArrayList、StringBuilder，除非線程安全需要，否則不推薦使用Hashtable、Vector、StringBuffer，後三者由於使用同步機制而導致了性能開銷

（1）儘可能使用局部變量

調用方法時傳遞的參數以及在調用中創建的臨時變量都保存在棧中，速度較快，其他變量，如靜態變量、實例變量等，都在堆中創建，速度較慢。另外，棧中創建的變量，隨著方法的運行結束，這些內容就沒了，不需要額外的垃圾回收。

（2）慎用異常

異常對性能不利。拋出異常首先要創建一個新的對象，Throwable接口的構造函數調用名為fillInStackTrace()的本地同步方法，fillInStackTrace()方法檢查堆棧，收集調用跟蹤信息。只要有異常被拋出，Java虛擬機就必須調整調用堆棧，因為在處理過程中創建了一個新的對象。異常只能用於錯誤處理，不應該用來控制程序流程。

（3）儘量在合適的場合使用單例

使用單例可以減輕加載的負擔、縮短加載的時間、提高加載的效率，但並不是所有地方都適用於單例，簡單來說，單例主要適用於以下三個方面：

• 控制資源的使用，通過線程同步來控制資源的併發訪問

• 控制實例的產生，以達到節約資源的目的

• 控制數據的共享，在不建立直接關聯的條件下，讓多個不相關的進程或線程之間實現通信

（4）儘量減少對變量的重複計算

明確一個概念，對方法的調用，即使方法中只有一句語句，也是有消耗的，包括創建棧幀、調用方法時保護現場、調用方法完畢時恢復現場等。所以例如下面的操作：

for (int i = 0; i < list.size(); i++){...}

建議替換為：

for (int i = 0, length = list.size(); i < length; i++){...}

這樣，在list.size()很大的時候，就減少了很多的消耗

（5）不要將數組聲明為public static final

因為這毫無意義，這樣只是定義了引用為static final，數組的內容還是可以隨意改變的，將數組聲明為public更是一個安全漏洞，這意味著這個數組可以被外部類所改變

（6）及時關閉流

Java編程過程中，進行數據庫連接、I/O流操作時務必小心，在使用完畢後，及時關閉以釋放資源。因為對這些大對象的操作會造成系統大的開銷，稍有不慎，將會導致嚴重的後果。

（7）儘量重用對象

特別是String對象的使用，出現字符串連接時應該使用StringBuilder/StringBuffer代替。由於Java虛擬機不僅要花時間生成對象，以後可能還需要花時間對這些對象進行垃圾回收和處理，因此，生成過多的對象將會給程序的性能帶來很大的影響。

（8）儘量指定類、方法的final修飾符

帶有final修飾符的類是不可派生的。在Java核心API中，有許多應用final的例子，例如java.lang.String，整個類都是final的。為類指定final修飾符可以讓類不可以被繼承，為方法指定final修飾符可以讓方法不可以被重寫。如果指定了一個類為final，則該類所有的方法都是final的。Java編譯器會尋找機會內聯所有的final方法，內聯對於提升Java運行效率作用重大，具體參見Java運行期優化。此舉能夠使性能平均提高50%。

（9）儘量採用懶加載的策略，即在需要的時候才創建

例如：

String str = "aaa";if (i == 1)
{
list.add(str);
}

建議替換為：

if (i == 1)
{
String str = "aaa";
list.add(str);
}

（10）不要在循環中使用try...catch...，應該把其放在最外層

根據網友們提出的意見，這一點我認為值得商榷

已完結專題（關注後查看）：

【mysql優化專題】【HTTP協議】

【架構技術專題】【多線程/池專題】

更新中專題（關注後查看）：

• 【dubbo專題】【dubbo源碼專題】

• 【JVM專題】【HTTP協議專題】

• 【設計模式專題】【高併發專題】

• 【架構技術專題】【netty專題】

• 【數據結構專題】【redis專題】