程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> J2EE系統優化的幾點體會

J2EE系統優化的幾點體會

編輯:關於JAVA

J2EE系統優化的幾點體會(一、對象)

說到系統優化,是一個比較復雜的問題,涉及到軟件的各個方面:需求、模塊劃分、數據庫設計、程序編碼以及一些特殊的優化方法如緩存技術等。而不同的應用又有其特殊的優化策略和技術。同時優化是貫穿系統從需求到實現再到維護的各個階段的一項活動,而在各個階段又有其不同的著眼點和具體方法。

本文立足於具體的J2EE項目實踐,結合一些已有的優化條例,提出自己的一些體會,也算是作為一次對實際項目經驗教訓的總結。

優化一般意義上說是提高已有系統的性能,減少如內存、數據庫、網絡帶寬等資源的占用,是在系統開發告一段落的前提下進行。一般是通過壓力測試或具體使用發現性能方面的問題,然後尋找性能瓶頸,並結合項目進度、人員安排、技術儲備等因素,提出相應的優化策略。

下面結合一些案例,進行具體的討論,並希望能總結出一些具有代表性的條例:

條例一:盡量重用對象,避免創建過多短時對象

對象在面向對象編程中隨處可見,甚至可以毫不誇張的說是:“一切都是對象”。如何更好的創建和使用對象,是優化中要考慮的一個重要方面。筆者將對象按使用分為兩大類:獨享對象和共享對象。獨享對象指由某個線程單獨擁有並維護其生命周期的對象,一般是通過new 創建的對象,線程結束且無其它對這個對象的引用,這個對象將由垃圾收集機制自動GC。共享對象指由多個線程共享的對象,各線程保持多個指向同一個對象的引用,任何對這個對象的修改都會在其它引用上得到體現,共享對象一般通過Factory工廠的getInstace()方法創建,單例模式就是創建共享對象的標准實現。獨享對象由於無其它指向同一對象的引用,不用擔心其它引用對對象屬性的修改,在多線程環境裡,也就不需要對其可能修改屬性的方法加以同步,減少了出錯的隱患和復雜性,但由於需要為每個線程都創建對象,增加了對內存的需求和JVM GC的負擔。共享對象則需要進行適當的同步(避免較大的同步塊,同時防止死鎖)。

還有幾種特殊對象:不變對象和方法對象。不變對象指對象對外不含有修改對象屬性的方法(如set方法),外部要修改屬性只能通過new新的實例來實現。不變對象最大的好處就是無需擔心屬性被修改,避免了潛在的bug,並能無需任何額外工作(如同步)就很好的工作在多線程環境下。如JDK的String對象就是典型的不變對象。方法對象簡單的說就是僅包含方法,不含有屬性的對象。由於沒有對象屬性,方法中無需進行修改屬性的操作,也就能采用static方法或單例模式,避免每次使用都要new對象,減少對象的使用。

那麼該如何確定創建何種對象,這就要結合對象的使用方式和生命周期、對象大小、構建花銷等方面來綜合考慮。如果對象生命周期較長,會存在修改操作,不能容忍其它線程對其的修改,就應該采用獨享對象,如常見的Bean類。而如果對象生命周期較長,且能為各個線程共享,就可以考慮共享對象。共享有2種常見情況,一種是系統全局對象,如配置屬性等,各個線程應該引用同一對象,任何對這個對象的修改都會影響其它線程;另一種是由於對象創建開銷較大,各線程對此對象是瞬時訪問,且無需再次讀取其屬性,如常見的Date 對象,一般這種對象的使用是瞬時的,比如把它format成String,如果每次創建然後等待GC就會浪費大量內存和CPU時間,較好做法就是做成共享對象,各個線程先set再使用,注意對進行set並訪問的方法要同步。不變對象一般使用在對象創建開銷較小(屬性較少,類層次較少),且需要能自由共享的情形。如一個對象裡的常量對象,使用public static final AAA=new AAA(…) 創建。方法對象使用較廣,如Util類、DAO類等,這些對象提供操作其它對象(一般是bean對象)的接口,能對系統在層次和功能上進行解耦合。

J2EE系統優化的幾點體會(二、循環)

條例二:在循環處,多下功夫

循環作為程序編寫的基本語法,可以說是隨處可見。一些小的細節能帶來性能上的提升,而對循環體的一些改寫,能帶來性能的大幅提升。

比如最簡單的List遍歷,會有這樣的寫法:for(int i=0;i

同樣是對List的操作,如果要在遍歷同時進行增加和刪除操作,代碼如下:for(int i=0,j=l.size();i=0;i--){l.remove(i);}。經過測試,如果采用ArrayList,兩種寫法在循環次數較少時沒有太大的區別,循環次數為1000,均為1ms以內,次數為10000,前一種為60ms左右,後一種為1ms以內,,而次數上到100000,前一種為6000ms左右,後一種為15ms,隨著循環次數的增多,後一種較前一種的效率優勢明顯提高。

這是由Collection庫ArrayList的實現決定的,以下是JDK1.3的ArrayList源碼:

public Object remove(int index) {

RangeCheck(index);

modCount++;

Object oldValue = elementData[index];

int numMoved = size - index - 1;

if (numMoved > 0)

System.arraycopy(elementData, index+1, elementData, index,

numMoved);

elementData[--size] = null; // Let gc do its work

return oldValue;

}

從中我們可以看出,numMoved代表了需要進行arraycopy操作的數量,它是由remove的位置決定的,如果index=0,也就是刪除第一個元素,則需要arraycopy後面的所有數據,

而如果index=size-1,則只需將最後一個元素設為null即可。所以從後面向前循環remove是比較好的寫法。

如果List中的確存在較多的add或remove操作,且容量較大(如存儲幾萬個對象),則應該采用LinkedList作為實現。LinkedList內部采用雙向鏈表作為數據結構,比ArrayList占用較多內存空間,且隨機訪問操作較慢(需要從頭或尾循環到相應位置),但插入刪除操作很快(僅需進行鏈表操作,無須大量移動或拷貝)。

對於List操作如果循環規模較小,其實對性能影響非常小(ms級),遠遠不是性能瓶頸所在。但心中有著優化的意識,並力求寫出簡潔高效的程序應該是我們每個程序員的追求。而且一旦在循環規模較大時,如果有了這些意識,也就能有效的消除性能隱患。

再舉一個與優化無關但確實可能成為性能殺手(可以說是bug)的循環的例子。下面是源代碼:

for(; totalRead < m_totalBytes; totalRead += readBytes)

{

readBytes = m_request.getInputStream().read(m_binArray, totalRead, m_totalBytes - totalRead);

}

這個代碼意圖很清楚,就是將一個InputStream流讀到一個byte數組中去。它使用read方法循環讀取InputStream,該方法返回讀取的字節數。正常情況下,該循環運行良好,當totalRead=m_totalBytes時,結束循環,byte數組被正常填充。但如果仔細看一下InputStream的read方法的說明,了解一下其返回值就會發現,返回值可能為-1,即已讀到InputStream末尾再繼續讀時。如果發生讀取異常,可能出現這個問題,而這個循環沒有檢查readBytes值是否為-1就往totalRead上加,這樣再次進入循環體繼續讀取InputStream,又返回-1,繼續循環。如此循環直到int溢出才會跳出循環。而這個循環也就成了實實在在的CPU殺手,可以占去大量的CPU時間(取決於操作系統)。其實解決很簡單,對readBytes進行判斷,如果為-1則跳出循環。

這個例子告訴我們:對循環一定要搞清循環的循環規模、每次循環體執行時間、循環結束條件包括異常情況等,只有這樣才能寫出高效且沒有隱患的代碼。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved