代碼優化,一個很重要的課題。可能有些人以爲沒用,一些細小的地方有什麼好修改的,改與不改對於代碼的運行效率有什麼影響呢?這個問題我是這麼考慮的,就像大海里面的鯨魚同樣,它吃一條小蝦米有用嗎?沒用,可是,吃的小蝦米一多以後,鯨魚就被餵飽了。java
代碼優化也是同樣,若是項目着眼於儘快無BUG上線,那麼此時能夠抓大放小,代碼的細節能夠不精打細磨;可是若是有足夠的時間開發、維護代碼,這時候就必須考慮每一個能夠優化的細節了,一個一個細小的優化點累積起來,對於代碼的運行效率絕對是有提高的。算法
代碼優化的目標是:數據庫
減少代碼的體積編程
提升代碼運行的效率數組
代碼優化細節安全
一、儘可能使用final修飾符服務器
帶有final修飾符的類是不可派生的,在Java核心API中,有不少應用final的例子,例如Java.lang.String,整個類都是final的。爲類指定final修飾符可讓類不可繼承,爲方法指定final修飾符可讓方法不能夠被重寫。若是制定了一個類爲final,則該類全部的方法都是final的。Java編譯器會尋找機會內聯全部的final方法,內聯對於提高Java運行效率做用巨大,能使性能平均提高50%。併發
二、儘可能重用對象app
特別是String對象的使用,出現字符串鏈接時應該使用StringBuilder或StringBuffer代替。因爲Java虛擬機不只要花時間生成對象,之後可能還須要花時間對這些對象進行垃圾回收和處理,所以,生成過多的對象將會給程序的性能帶來很大的影響。dom
三、儘量使用局部變量
調用方法時傳遞的參數以及在調用中建立的臨時變量都會保存在棧中,速度較快,其它變量,如靜態變量、實例變量等,都在堆中建立,速度較慢。另外,棧中建立的變量,隨着方法的運行結束,這些內容就沒了,不須要額外的垃圾回收。
四、及時關閉流
Java編程過程當中,進行數據庫鏈接、IO流操做時務必當心,在使用完畢後,及時關閉以釋放資源。由於對這些大對象的操做會形成很大的開銷,稍有不慎,將會致使嚴重的後果。
五、儘可能減小對變量的重複計算
明確一個概念,對方法的調用,即便方法中只有一句語句,也是消耗的,包括建立棧幀、調用方法時保護現場、調用方法完畢時恢復現場。因此例以下面的操做:
for(int i=0;i<list.size;i++){}
建議替換爲:
for(int i=0,int length=list.size;i<length;i++){}
這樣,在list.size很大的時候,就減小了不少的消耗。
六、儘可能採用懶加載的策略,即在須要的時候才建立
例如:
String str = "aaa";if (i == 1){list.add(str);}
建議替換爲:
if (i == 1){String str = "aaa";list.add(str);}
七、慎用異常
異常對性能不利。拋出異常首先要建立一個新的對象,Throwable接口的構造函數調用名爲fillInStackTrace的本地同步方法,fillInStackTrace方法檢查堆棧,收集調用跟蹤信息。只要有異常被拋出,Java虛擬機就必須調整調用堆棧,由於在處理過程當中建立了一個新的對象。異常只能用於錯誤處理,不該該用來控制程序流程。
八、不要在循環中使用trycatch,應該把其放在最外層
除非不得已。若是毫無理由地這麼寫了,只要你的領導資深一點、有強迫症一點,八成就要罵你爲何寫出這種垃圾代碼來了。
九、儘可能能估計到待添加的內容的長度,爲底層以數組方式實現的集合、工具類指定初始長度
好比ArrayList、LinkedLlist、StringBuilder、StringBuffer、HashMap、HashSet等等,以StringBuilder爲例:
① StringBuilder //默認分配16個字符的空間
② StringBuilder(int size)//默認分配size個字符的空間
③ StringBuider(String str)//默認分配16個字符+st.length個字符空間
設定初始化容量,能夠明顯提高性能。好比StringBuilder,length表示當前StringBuilder能保持的字符數量。由於當StringBuilder達到最大容量的時候,它會將自身容量增長到當前的2倍再加2,不管什麼時候只StringBuilder達到它的最大容量,它就不得不建立一個新的字符數組而後將舊的字符數組內容拷貝到新字符數組中--這是一個很是耗費性能的操做。試想,若是能預估到字符數組中大概要存放5000個字符而不指定長度,最接近5000的2次冪是4096,每次擴容2倍加2,那麼:
① 在4096的基礎上,再申請8194個大小的字符數組,加起來至關於一次申請了12290個大小的字符數組,若是一開始能指定5000個大小的字符數組,就節省了一倍以上的空間。
② 把原來的4096個字符拷貝到新的字符數組中去。
這樣,既浪費內存空間又下降代碼運行效率。因此,給底層以數組實現的集合、工具類設置一個合理的初始化容量是錯不了的,這會帶來立竿見影的效果。可是,注意,像hashmap這種以數組+鏈表實現的集合,別把初始大小和你估計的大小設置的同樣,由於一個table上只鏈接一個對象的可能性幾乎爲0。初始大小建議設置爲2的N次冪,若是能估計到有2000個元素,設置成new hashmap(128)、new hashmap(256)均可以。
十、當複製大量數據時,使用system.arraycopy命令
十一、乘法和除法使用移位操做
例如:
int a = 0; int b = 0; for (int i = 0; i < 1000000000; i++){ a = i * 8; b = i / 2; }
用移位操做能夠極大地提升性能,由於在計算機底層,對位的操做是最方便、最快的,所以建議修改成:
int a1 = 0; int b1 = 0; for (int i = 0; i < 1000000000; i++){ a1 = i << 3; b1 = i >> 1; }
移位操做雖然快,可是可能會使代碼不太好理解,所以最好加上相應的註釋。
感受有點吹毛求疵了,這都多少循環了,才差了2毫秒!!!
十二、循環內不要不斷建立對象引用
例如:
for (int i = 1; i <= count; i++){ Object obj = new Object; }
這種作法會致使內存中有count份Object對象引用存在,count很大的話,就耗費內存了,建議爲改成:
Object obj = null; for (int i = 0; i <= count; i++) { obj = new Object; }
這樣的話,內存中只有一份Object對象引用,每次new Object的時候,Object對象引用指向不一樣的Object罷了,可是內存中只有一份,這樣就大大節省了內存空間了。
1三、基於效率和類型檢查的考慮,應該儘量使用array,沒法肯定數組大小時才使用ArrayList
1四、儘可能使用hashmap、ArrayList、stringbuilder,除非線程安全須要,不然不建議使用hashtable、vector、stringbuffer,後三者因爲使用同步機制而致使了性能開銷。
1五、不要講數組聲明爲public static final
1六、儘可能在覈實的場合使用單例模式
使用單例模式能夠減輕加載的負擔、縮短加載的時間、提升加載的效率,單並非全部地方都適合單例模式,簡單來講,單例模式主要適用於如下三個方面:
① 控制資源的使用,經過線程同步來控制資源的併發訪問
② 控制實例的產生,以達到節約資源的目的
③ 控制數據的共享,在不創建直接關聯的條件下,讓多個不相關的進程或線程之間實現通訊
1七、儘可能避免使用靜態變量
要知道,當某個對象被定義爲static的,那麼gc一般不會回收這個對象所佔有的堆內存的,
public class A{ private static B b = new B; }
此時靜態變量b的聲明週期與A類相同,若是A類不被卸載,那麼引用B指向的對象會常駐內存,知道程序終止。
1八、及時清除再也不須要的會話
爲了清除再也不活動的會話,許多服務器都會有默認的超時時間,通常爲30分鐘。當應用服務器須要保存更多的會話時,若是內存不足,那麼操做系統會把部分數據轉移到磁盤,應用服務器也可能把不活躍的會話轉儲到磁盤,甚至可能拋出內存不足的異常。若是會話要被轉儲到磁盤,那麼必需要先被序列化,在大規模集羣中,對對象序列化的代價是很高昂的。所以,當會話再也不須要時,應當及時調用httpseesion的invalidate方法清除會話。
1九、實現RandomAccess接口的集合好比ArrayList,應當使用最普通的for循環而不是foreach循環
實現RandomAccess接口用來代表其支持快速隨機訪問,此接口的主要目的是容許通常的算法更改其行爲,從而將其應用到隨機或連續訪問列表時能提供良好的性能。實際經驗代表,實現RandomAccess接口的類實例,假如是隨機訪問的,使用普通for循環效率將高於使用foreach循環,反過來,若是是順序訪問的,使用Iterator效率會更高。可使用相似以下代碼做判斷:
if (list instanceof RandomAccess){ for (int i = 0; i < list.size; i++){} }else{ Iterator<?> iterator = list.iterable; while (iterator.hasNext){iterator.next} }
foreach的底層實現就是Iterator。
20、使用同步代碼塊代替同步方法
2一、將常量聲明爲static final,並以大寫命名
這樣在編譯期間就能夠將這些內容放入常量池中,避免運行期間計算生成常量的值。另外,將常量的名字以大寫命名也能夠方便區分出常量與變量。
2二、不要建立一些不使用的對象,不要導入一些不使用的類
2三、程序運行過程當中避免使用反射
反射是Java提供的一個很強大的功能,功能強大意味着效率不高。不建議在程序運行過程當中使用尤爲是頻繁的使用反射機制,特別是Method的invoke方法,若是確實有必要,一種建議性的作法是將那些須要經過反射加載的類在項目啓動的時候經過反射實例化出一個對象並放入內存--用戶只關心交互的速度,而不關心項目啓動的時間。
2四、使用數據庫鏈接池和線程池
前者能夠避免頻繁的打開關閉鏈接;後者能夠避免頻繁的建立和銷燬線程
2五、使用帶緩衝的輸入輸出流進行IO操做
帶緩衝的輸入輸出流,即BufferedReader、BufferedWriter、BufferedInputStream、BufferedOutputStream,這能夠極大地提高IO效率。
2六、順序插入和隨機訪問比較多的場景用ArrayList,元素刪除和中間插入比較多的場景使用LinkedList
2七、不要讓public方法中有太多的參數
2八、字符串變量和字符串常量equals的時候講字符串常量寫在前面
這麼作主要是能夠避免空指針異常。
2九、請知道,在java中if (i == 1)和if (1 == i)是沒有區別的,但從閱讀習慣上講,建議使用前者
30、不要對數組使用toString方法
3一、不要對超出範圍的基礎數據類型作向下強制類型轉型
3二、公用的集合類中不使用的數據必定要及時的remove掉
若是一個集合類是公用的(也就是說不是方法裏面的屬性),那麼這個集合裏面的元素是不會自動釋放的,由於始終有引用指向它們。因此,若是公用集合裏面的某些數據不使用而不去remove掉它們,那麼將會形成這個公用集合不斷增大,使得系統有內存泄露的隱患。
3三、把一個基本類型轉爲字符串,toString最快,String.valueOf次之,數據+「」最慢
因此之後遇到把一個基本數據類型轉爲String的時候,優先考慮使用toString方法。至於爲何,很簡單:
① String.valueOf方法底層調用了Integer.toString方法,可是會在調用前作空判斷
② Integer.toString方法就不說了,直接調用了
③ i + 「」底層使用了StringBuilder實現,先用append方法拼接,再用toString方法獲取字符串
三者對比下來,明顯是②最快、①次之、③最慢
3四、使用最有效率的方法去遍歷map
3五、對資源的close()建議分開操做
意思是,好比我有這麼一段代碼:
try{ XXX.close; YYY.close; }catch (Exception e){ ... }
建議修改成:
try{ XXX.close; }catch (Exception e) { ... } try{ YYY.close; }catch (Exception e) { ... }
雖然有些麻煩,卻能避免資源泄露。我想,若是沒有修改過的代碼,萬一XXX.close拋異常了,那麼就進入了cath塊中了,YYY.close不會執行,YYY這塊資源就不會回收了,一直佔用着,這樣的代碼一多,是可能引發資源句柄泄露的。而改成上面的寫法以後,就保證了不管如何XXX和YYY都會被close掉。