前言
以下是在日常工作中總結(jié)出的一些編碼經(jīng)驗
,還有一些提高程序運行效率
的小技巧,讓我們一起來寫出更好的代碼吧。
盡量減少對變量的重復計算
明確一個概念,對方法的調(diào)用,即使方法中只有一句語句,也是有消耗的,包括創(chuàng)建棧幀、調(diào)用方法時保護現(xiàn)場、調(diào)用方法完畢時恢復現(xiàn)場等。所以例如下面的操作:
for?(int?i?=?0;?i?{...}
建議替換為:
for?(int?i?=?0,?length?=?list.size();?i?{...}
這樣,在list.size()很大的時候,就減少了很多的消耗
字符串拼接問題
循環(huán)體內(nèi)不要使用"+
"進行字符串拼接,而直接使用StringBuilder
不斷append
虛擬機碰到"+"這個操作符對字符串進行拼接的時候,會new出一個StringBuilder,然后調(diào)用append方法。
最后調(diào)用toString()方法轉(zhuǎn)換字符串賦值給oriStr對象,即循環(huán)多少次
,就會new出多少個StringBuilder()
來,這對于內(nèi)存是一種浪費。
指定類、方法用final修飾
帶有final修飾符的類是不可派生的。在Java核心API中,有許多應用final的例子,例如java.lang.String,整個類都是final的。
為類指定final修飾符可以讓類不可以被繼承,為方法指定final修飾符可以讓方法不可以被重寫。如果指定了一個類為final,則該類所有的方法都是final的。
Java編譯器會尋找機會內(nèi)聯(lián)所有的final方法,內(nèi)聯(lián)對于提升Java運行效率作用重大,具體參見Java運行期優(yōu)化。此舉能夠使性能平均提高50%。
盡可能使用局部變量
調(diào)用方法時傳遞的參數(shù)以及在調(diào)用中創(chuàng)建的臨時變量都保存在棧中,速度較快,其他變量,如靜態(tài)變量、實例變量等,都在堆中創(chuàng)建,速度較慢。
另外,棧中創(chuàng)建的變量,隨著方法的運行結(jié)束,這些內(nèi)容就沒了,不需要額外的垃圾回收。
及時關(guān)閉流
Java編程過程中,進行數(shù)據(jù)庫連接、I/O流操作時務(wù)必小心,在使用完畢后,及時關(guān)閉以釋放資源。因為對這些大對象的操作會造成系統(tǒng)大的開銷,稍有不慎,將會導致嚴重的后果。
盡量采用懶加載的策略
借鑒這種思想,就是需要掙個對象時在去創(chuàng)建
例如:
String?str?=?"aaa";
if?(i?==?1)
{
??list.add(str);
}
建議替換為:
if?(i?==?1)
{
??String?str?=?"aaa";
??list.add(str);
}
慎用異常
異常對性能不利。拋出異常首先要創(chuàng)建一個新的對象,Throwable接口的構(gòu)造函數(shù)調(diào)用名為fillInStackTrace()的本地同步方法,fillInStackTrace()方法檢查堆棧,收集調(diào)用跟蹤信息。
只要有異常被拋出,Java虛擬機就必須調(diào)整調(diào)用堆棧,因為在處理過程中創(chuàng)建了一個新的對象。異常只能用于錯誤處理,不應該用來控制程序流程。
try/catch
不要在循環(huán)中使用try…catch…,應該把其放在最外層
使用集合時指定大小
比如ArrayList、LinkedLlist、StringBuilder、StringBuffer、HashMap、HashSet等等,以StringBuilder為例:
-
StringBuilder()??????// 默認分配16個字符的空間
-
StringBuilder(int size)??// 默認分配size個字符的空間
-
StringBuilder(String str)?// 默認分配16個字符+str.length()個字符空間
可以通過類(這里指的不僅僅是上面的StringBuilder)的構(gòu)造函數(shù)來設(shè)定它的初始化容量,這樣可以明顯地提升性能。比如StringBuilder吧,length表示當前的StringBuilder能保持的字符數(shù)量。
因為當StringBuilder達到最大容量的時候,它會將自身容量增加到當前的2倍再加2,無論何時只要StringBuilder達到它的最大容量,它就不得不創(chuàng)建一個新的字符數(shù)組然后將舊的字符數(shù)組內(nèi)容拷貝到新字符數(shù)組中----這是十分耗費性能的一個操作。試想,如果能預估到字符數(shù)組中大概要存放5000個字符而不指定長度,最接近5000的2次冪是4096,每次擴容加的2不管,那么:
在4096 的基礎(chǔ)上,再申請8194個大小的字符數(shù)組,加起來相當于一次申請了12290個大小的字符數(shù)組,如果一開始能指定5000個大小的字符數(shù)組,就節(jié)省了一倍以上的空間
把原來的4096個字符拷貝到新的的字符數(shù)組中去
這樣,既浪費內(nèi)存空間又降低代碼運行效率。所以,給底層以數(shù)組實現(xiàn)的集合、工具類設(shè)置一個合理的初始化容量是錯不了的,這會帶來立竿見影的效果。但是,注意,像HashMap這種是以數(shù)組+鏈表實現(xiàn)的集合,別把初始大小和你估計的大小設(shè)置得一樣,因為一個table上只連接一個對象的可能性幾乎為0。初始大小建議設(shè)置為2的N次冪,如果能估計到有2000個元素,設(shè)置成new HashMap(128)、new HashMap(256)都可以。
當復制大量數(shù)據(jù)時
使用System.arraycopy()命令
乘法和除法使用移位操作
例如:
for?(val?=?0;?val?100000;?val?+=?5)
{
??a?=?val?*?8;
??b?=?val?/?2;
}
用移位操作可以極大地提高性能,因為在計算機底層,對位的操作是最方便、最快的,因此建議修改為:
for?(val?=?0;?val?100000;?val?+=?5)
{
????a?=?val?<3;
????b?=?val?>>?1;
}
移位操作雖然快,但是可能會使代碼不太好理解,因此最好加上相應的注釋。
循環(huán)內(nèi)不要不斷創(chuàng)建對象引用
例如:
for?(int?i?=?1;?i?<=?count;?i++)
{
????Object?obj?=?new?Object();????
}
這種做法會導致內(nèi)存中有count份Object對象引用存在,count很大的話,就耗費內(nèi)存了,建議為改為:
Object?obj?=?null;
for?(int?i?=?0;?i?<=?count;?i++)
{
????obj?=?new?Object();
}
這樣的話,內(nèi)存中只有一份Object對象引用,每次new Object()的時候,Object對象引用指向不同的Object罷了,但是內(nèi)存中只有一份,這樣就大大節(jié)省了內(nèi)存空間了。
數(shù)組不要聲明為public static final
因為這毫無意義,這樣只是定義了引用為static final,數(shù)組的內(nèi)容還是可以隨意改變的,將數(shù)組聲明為public更是一個安全漏洞,這意味著這個數(shù)組可以被外部類所改變
盡量在合適的場合使用單例
使用單例可以減輕加載的負擔、縮短加載的時間、提高加載的效率,但并不是所有地方都適用于單例,簡單來說,單例主要適用于以下三個方面:
-
控制資源的使用,通過線程同步來控制資源的并發(fā)訪問
-
控制實例的產(chǎn)生,以達到節(jié)約資源的目的
-
控制數(shù)據(jù)的共享,在不建立直接關(guān)聯(lián)的條件下,讓多個不相關(guān)的進程或線程之間實現(xiàn)通信
盡量避免隨意使用靜態(tài)變量
要知道,當某個對象被定義為static的變量所引用,那么gc通常是不會回收這個對象所占有的堆內(nèi)存的,如:
public?class?A
{
????private?static?B?b?=?new?B();??
}
此時靜態(tài)變量b的生命周期與A類相同,如果A類不被卸載,那么引用B指向的B對象會常駐內(nèi)存,直到程序終止
及時清除不再需要的會話
為了清除不再活動的會話,許多應用服務(wù)器都有默認的會話超時時間,一般為30分鐘。當應用服務(wù)器需要保存更多的會話時,如果內(nèi)存不足,那么操作系統(tǒng)會把部分數(shù)據(jù)轉(zhuǎn)移到磁盤,應用服務(wù)器也可能根據(jù)MRU(最近最頻繁使用)算法把部分不活躍的會話轉(zhuǎn)儲到磁盤,甚至可能拋出內(nèi)存不足的異常。
如果會話要被轉(zhuǎn)儲到磁盤,那么必須要先被序列化,在大規(guī)模集群中,對對象進行序列化的代價是很昂貴的。因此,當會話不再需要時,應當及時調(diào)用HttpSession的invalidate()方法清除會話。
for和foreach
實現(xiàn)RandomAccess接口的集合比如ArrayList,應當使用最普通的for循環(huán)而不是foreach循環(huán)來遍歷
這是JDK推薦給用戶的。JDK API對于RandomAccess接口的解釋是:實現(xiàn)RandomAccess接口用來表明其支持快速隨機訪問,此接口的主要目的是允許一般的算法更改其行為,從而將其應用到隨機或連續(xù)訪問列表時能提供良好的性能。
實際經(jīng)驗表明,實現(xiàn)RandomAccess接口的類實例,假如是隨機訪問的,使用普通for循環(huán)效率將高于使用foreach循環(huán);反過來,如果是順序訪問的,則使用Iterator會效率更高??梢允褂妙愃迫缦碌拇a作判斷:
if?(list?instanceof?RandomAccess)
{
????for?(int?i?=?0;?i?}
else
{
????Iterator>?iterator?=?list.iterable();
????while?(iterator.hasNext()){iterator.next()}
}
foreach循環(huán)的底層實現(xiàn)原理就是迭代器Iterator,參見Java語法糖1:可變長度參數(shù)以及foreach循環(huán)原理。所以后半句"反過來,如果是順序訪問的,則使用Iterator會效率更高"的意思就是順序訪問的那些類實例,使用foreach循環(huán)去遍歷。
使用同步代碼塊替代同步方法
除非能確定一整個方法都是需要進行同步的,否則盡量使用同步代碼塊,避免對那些不需要進行同步的代碼也進行了同步,影響了代碼執(zhí)行效率。
將常量聲明為static final,并以大寫命名
這樣在編譯期間就可以把這些內(nèi)容放入常量池中,避免運行期間計算生成常量的值。另外,將常量的名字以大寫命名也可以方便區(qū)分出常量與變量
程序運行過程中避免使用反射
反射是Java提供給用戶一個很強大的功能,功能強大往往意味著效率不高。
不建議在程序運行過程中使用尤其是頻繁使用反射機制,特別是Method的invoke方法。
如果確實有必要,一種建議性的做法是將那些需要通過反射加載的類在項目啟動的時候通過反射實例化出一個對象并放入內(nèi)存----用戶只關(guān)心和對端交互的時候獲取最快的響應速度,并不關(guān)心對端的項目啟動花多久時間。
使用數(shù)據(jù)庫連接池和線程池
這兩個池都是用于重用對象的,前者可以避免頻繁地打開和關(guān)閉連接,后者可以避免頻繁地創(chuàng)建和銷毀線程
使用帶緩沖的輸入輸出流進行IO操作
帶緩沖的輸入輸出流,即BufferedReader、BufferedWriter、BufferedInputStream、BufferedOutputStream,這可以極大地提升IO效率
ArrayList和LinkedList
順序插入和隨機訪問比較多的場景使用ArrayList,元素刪除和中間插入比較多的場景使用LinkedList
equals
字符串變量和字符串常量equals的時候?qū)⒆址A繉懺谇懊?,這么做主要是可以避免空指針異常
if?("abc".equals(str))?{
}
不要對數(shù)組使用toString()方法
看一下對數(shù)組使用toString()打印出來的是什么:
public?static?void?main(String[]?args)
{
????int[]?is?=?new?int[]{1,?2,?3};
????System.out.println(is.toString());
????//?輸出內(nèi)容:[I@156643d4
}
本意是想打印出數(shù)組內(nèi)容,卻有可能因為數(shù)組引用is為空而導致空指針異常。不過雖然對數(shù)組toString()沒有意義,但是對集合toString()是可以打印出集合里面的內(nèi)容的,因為集合的父類AbstractCollections重寫了Object的toString()方法。
公用的集合類中不使用的數(shù)據(jù)一定要及時remove掉
如果一個集合類是公用的(也就是說不是方法里面的屬性),那么這個集合里面的元素是不會自動釋放的,因為始終有引用指向它們。所以,如果公用集合里面的某些數(shù)據(jù)不使用而不去remove掉它們,那么將會造成這個公用集合不斷增大,使得系統(tǒng)有內(nèi)存泄露的隱患。
基本數(shù)據(jù)類型轉(zhuǎn)為字符串效率
把一個基本數(shù)據(jù)類型轉(zhuǎn)為字符串,基本數(shù)據(jù)類型.toString()是最快的方式、String.valueOf(數(shù)據(jù))次之、數(shù)據(jù)+""最慢
測試速度:
public?static?void?main(String[]?args)
{
????int?loopTime?=?50000;
????Integer?i?=?0;
????long?startTime?=?System.currentTimeMillis();
????for?(int?j?=?0;?j?????{
????????String?str?=?String.valueOf(i);
????}????
????System.out.println("String.valueOf():"?+?(System.currentTimeMillis()?-?startTime)?+?"ms");
????startTime?=?System.currentTimeMillis();
????for?(int?j?=?0;?j?????{
????????String?str?=?i.toString();
????}????
????System.out.println("Integer.toString():"?+?(System.currentTimeMillis()?-?startTime)?+?"ms");
????startTime?=?System.currentTimeMillis();
????for?(int?j?=?0;?j?????{
????????String?str?=?i?+?"";
????}????
????System.out.println("i +?\"\":"?+?(System.currentTimeMillis()?-?startTime)?+?"ms");
}
運行結(jié)果為:
String.valueOf():11ms
Integer.toString():5ms
i?+?"":25ms
原因:
-
String.valueOf()方法底層調(diào)用了Integer.toString()方法,但是會在調(diào)用前做空判斷
-
Integer.toString()方法就不說了
-
i + ""底層使用了StringBuilder實現(xiàn),先用append方法拼接,再用toString()方法獲取字符串
遍歷Map效率最高的方式
遍歷Map的方式有很多,通常場景下我們需要的是遍歷Map中的Key和Value,那么推薦使用的、效率最高的方式是:
public?static?void?main(String[]?args)
{
????HashMap?hm?=?new?HashMap();
????hm.put("111",?"222");
????Set>?entrySet?=?hm.entrySet();
????Iterator>?iter?=?entrySet.iterator();
????while?(iter.hasNext())
????{
????????Map.Entry?entry?=?iter.next();
????????System.out.println(entry.getKey()?+?"\t"?+?entry.getValue());
????}
}
如果你只是想遍歷一下這個Map的key值,那用Set keySet = hm.keySet();會比較合適一些
對資源的close()建議分開操作
例如:
try
{
????XXX.close();
????YYY.close();
}
catch?(Exception?e)
{
????...
}
建議修改為:
try
{
????XXX.close();
}
catch?(Exception?e)
{
????...
}
try
{
????YYY.close();
}
catch?(Exception?e)
{
????...
}
雖然有些麻煩,卻能避免資源泄露。我們想,如果沒有修改過的代碼,萬一XXX.close()拋異常了,那么就進入了catch塊中了,YYY.close()不會執(zhí)行,YYY這塊資源就不會回收了,一直占用著,這樣的代碼一多,是可能引起資源句柄泄露的。而改為下面的寫法之后,就保證了無論如何XXX和YYY都會被close掉
ThreadLocal使用前或者使用后一定要先remove
線程池技術(shù)做的是一個線程重用,這意味著代碼運行過程中,一條線程使用完畢,并不會被銷毀而是等待下一次的使用。我們看一下Thread類中,持有ThreadLocal.ThreadLocalMap的引用:
/*?ThreadLocal?values?pertaining?to?this?thread.?This?map?is?maintained
?*?by?the?ThreadLocal?class.?*/
ThreadLocal.ThreadLocalMap?threadLocals?=?null;
線程不銷毀意味著上條線程set的ThreadLocal.ThreadLocalMap中的數(shù)據(jù)依然存在,那么在下一條線程重用這個Thread的時候,很可能get到的是上條線程set的數(shù)據(jù)而不是自己想要的內(nèi)容。
這個問題非常隱晦,一旦出現(xiàn)這個原因?qū)е碌腻e誤,沒有相關(guān)經(jīng)驗或者沒有扎實的基礎(chǔ)非常難發(fā)現(xiàn)這個問題,因此在寫代碼的時候就要注意這一點,這將給你后續(xù)減少很多的工作量。
重寫方法必須保留@Override注解
-
清楚地可以知道這個方法由父類繼承而來
-
getObject()和get0bject()方法,前者第四個字母是"O",后者第四個子母是"0",加了@Override注解可以馬上判斷是否重寫成功
-
在抽象類中對方法簽名進行修改,實現(xiàn)類會馬上報出編譯錯誤
END
作者:thekingisalways
來源:民工哥技術(shù)之路
免責聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!