最近的機器記憶體又爆滿了,除了新增機器記憶體外,還應該好好review一下我們的代碼,有很多代碼編寫過于随意化,這些不好的習慣或對程式語言的不了解是應該好好打壓打壓了。
下面是參考網絡資源總結的一些在java程式設計中盡可能要做到的一些地方。
1. 盡量在合适的場合使用單例
使用單例可以減輕加載的負擔,縮短加載的時間,提高加載的效率,但并不是所有地方都适用于單例,簡單來說,單例主要适用于以下三個方面:
第一,控制資源的使用,通過線程同步來控制資源的并發通路;
第二,控制執行個體的産生,以達到節約資源的目的;
第三,控制資料共享,在不建立直接關聯的條件下,讓多個不相關的程序或線程之間實作通信。
2. 盡量避免随意使用靜态變量
要知道,當某個對象被定義為stataic變量所引用,那麼gc通常是不會回收這個對象所占有的記憶體,如
java代碼
1. public class a{
2. static b b = new b();
3. }
此時靜态變量b的生命周期與a類同步,如果a類不會解除安裝,那麼b對象會常駐記憶體,直到程式終止。
3. 盡量避免過多過常的建立java對象
盡量避免在經常調用的方法,循環中new對象,由于系統不僅要花費時間來建立對象,而且還要花時間對這些對象進行垃圾回收和處理,在我們可以控制的範圍内,最大限度的重用對象,最好能用基本的資料類型或數組來替代對象。
4. 盡量使用final修飾符
帶有final修飾符的類是不可派生的。在java核心api中,有許多應用final的例子,例如java.lang.string。為string類指定final防止了使用者覆寫length()方法。另外,如果一個類是final的,則該類所有方法都是final的。java編譯器會尋找機會内聯(inline)所有的final方法(這和具體的編譯器實作有關)。此舉能夠使性能平均提高50%。
5. 盡量使用局部變量
調用方法時傳遞的參數以及在調用中建立的臨時變量都儲存在棧(stack)中,速度較快。其他變量,如靜态變量、執行個體變量等,都在堆(heap)中建立,速度較慢。
6. 盡量處理好包裝類型和基本類型兩者的使用場所
雖然包裝類型和基本類型在使用過程中是可以互相轉換,但它們兩者所産生的記憶體區域是完全不同的,基本類型資料産生和處理都在棧中處理,包裝類型是對象,是在堆中産生執行個體。
在集合類對象,有對象方面需要的處理适用包裝類型,其他的處理提倡使用基本類型。
7. 慎用synchronized,盡量減小synchronize的方法
都知道,實作同步是要很大的系統開銷作為代價的,甚至可能造成死鎖,是以盡量避免無謂的同步控制。synchronize方法被調用時,直接會把目前對象鎖 了,在方法執行完之前其他線程無法調用目前對象的其他方法。是以synchronize的方法盡量小,并且應盡量使用方法同步代替代碼塊同步。
8. 盡量使用stringbuilder和stringbuffer進行字元串連接配接
這個就不多講了。
9. 盡量不要使用finalize方法
實際上,将資源清理放在finalize方法中完成是非常不好的選擇,由于gc的工作量很大,尤其是回收young代記憶體時,大都會引起應用程式暫停,是以再選擇使用finalize方法進行資源清理,會導緻gc負擔更大,程式運作效率更差。
10. 盡量使用基本資料類型代替對象
string str = "hello";
上面這種方式會建立一個“hello”字元串,而且jvm的字元緩存池還會緩存這個字元串;
string str = new string("hello");
此時程式除建立字元串外,str所引用的string對象底層還包含一個char[]數組,這個char[]數組依次存放了h,e,l,l,o
11. 單線程應盡量使用hashmap、arraylist
hashtable、vector等使用了同步機制,降低了性能。
12. 盡量合理的建立hashmap
當你要建立一個比較大的hashmap時,充分利用另一個構造函數
public hashmap(int initialcapacity, float loadfactor)
避免hashmap多次進行了hash重構,擴容是一件很耗費性能的事,在預設中initialcapacity隻有16,而loadfactor是 0.75,需要多大的容量,你最好能準确的估計你所需要的最佳大小,同樣的hashtable,vectors也是一樣的道理。
13. 盡量減少對變量的重複計算
如
for(int i=0;i<list.size();i++)
應該改為
for(int i=0,len=list.size();i<len;i++)
并且在循環中應該避免使用複雜的表達式,在循環中,循環條件會被反複計算,如果不使用複雜表達式,而使循環條件值不變的話,程式将會運作的更快。
14. 盡量避免不必要的建立
a a = new a();
if(i==1){list.add(a);}
if(i==1){
list.add(a);}
15. 盡量在finally塊中釋放資源
程式中使用到的資源應當被釋放,以避免資源洩漏。這最好在finally塊中去做。不管程式執行的結果如何,finally塊總是會執行的,以確定資源的正确關閉。
16. 盡量使用移位來代替'a/b'的操作
"/"是一個代價很高的操作,使用移位的操作将會更快和更有效
int num = a / 4;
int num = a / 8;
int num = a >> 2;
int num = a >> 3;
但注意的是使用移位應添加注釋,因為移位操作不直覺,比較難了解
17.盡量使用移位來代替'a*b'的操作
同樣的,對于'*'操作,使用移位的操作将會更快和更有效
int num = a * 4;
int num = a * 8;
int num = a << 2;
int num = a << 3;
18. 盡量确定stringbuffer的容量
stringbuffer 的構造器會建立一個預設大小(通常是16)的字元數組。在使用中,如果超出這個大小,就會重新配置設定記憶體,建立一個更大的數組,并将原先的數組複制過來,再 丢棄舊的數組。在大多數情況下,你可以在建立 stringbuffer的時候指定大小,這樣就避免了在容量不夠的時候自動增長,以提高性能。
如:stringbuffer buffer = new stringbuffer(1000);
19. 盡量早釋放無用對象的引用
大部分時,方法局部引用變量所引用的對象 會随着方法結束而變成垃圾,是以,大部分時候程式無需将局部,引用變量顯式設為null。
例如:
1. public void test(){
2. object obj = new object();
3. ……
4. obj=null;
5. }
上面這個就沒必要了,随着方法test()的執行完成,程式中obj引用變量的作用域就結束了。但是如果是改成下面:
5. //執行耗時,耗記憶體操作;或調用耗時,耗記憶體的方法
6. ……
7. }
這時候就有必要将obj指派為null,可以盡早的釋放對object對象的引用。
20. 盡量避免使用二維數組
二維資料占用的記憶體空間比一維數組多得多,大概10倍以上。
21. 盡量避免使用split
除非是必須的,否則應該避免使用split,split由于支援正規表達式,是以效率比較低,如果是頻繁的幾十,幾百萬的調用将會耗費大量資源,如果确實需 要頻繁的調用split,可以考慮使用apache的stringutils.split(string,char),頻繁split的可以緩存結果。
22. arraylist & linkedlist
一 個是線性表,一個是連結清單,一句話,随機查詢盡量使用arraylist,arraylist優于linkedlist,linkedlist還要移動指 針,添加删除的操作linkedlist優于arraylist,arraylist還要移動資料,不過這是理論性分析,事實未必如此,重要的是了解好2 者得資料結構,對症下藥。
23. 盡量使用system.arraycopy ()代替通過來循環複制數組
system.arraycopy() 要比通過循環來複制數組快的多
24. 盡量緩存經常使用的對象
盡可能将經常使用的對象進行緩存,可以使用數組,或hashmap的容器來進行緩存,但這種方式可能導緻系統占用過多的緩存,性能下降,推薦可以使用一些第三方的開源工具,如ehcache,oscache進行緩存,他們基本都實作了fifo/flu等緩存算法。
25. 盡量避免非常大的記憶體配置設定
有時候問題不是由當時的堆狀态造成的,而是因為配置設定失敗造成的。配置設定的記憶體塊都必須是連續的,而随着堆越來越滿,找到較大的連續塊越來越困難。
26. 慎用異常
當建立一個異常時,需要收集一個棧跟蹤(stack track),這個棧跟蹤用于描述異常是在何處建立的。建構這些棧跟蹤時需要為運作時棧做一份快照,正是這一部分開銷很大。當需要建立一個 exception 時,jvm 不得不說:先别動,我想就您現在的樣子存一份快照,是以暫時停止入棧和出棧操作。棧跟蹤不隻包含運作時棧中的一兩個元素,而是包含這個棧中的每一個元素。
如 果您建立一個 exception ,就得付出代價。好在捕獲異常開銷不大,是以可以使用 try-catch 将核心内容包起來。從技術上講,您甚至可以随意地抛出異常,而不用花費很大的代價。招緻性能損失的并不是 throw 操作——盡管在沒有預先建立異常的情況下就抛出異常是有點不尋常。真正要花代價的是建立異常。幸運的是,好的程式設計習慣已教會我們,不應該不管三七二十一就
抛出異常。異常是為異常的情況而設計的,使用時也應該牢記這一原則。
轉自:http://mp.weixin.qq.com/s?__biz=mzaxndmwmtmwmw==&mid=2247484684&idx=3&sn=161a8880242d51410ef82024600b7654&chksm=9b942414ace3ad02f45183cd46663cb107fa58731deed8788d6cb171bff96c468b1f162918e0&mpshare=1&scene=23&srcid=0227fh1pnojy1hkxptdbedyl#rd