高性能J2EE應用的技巧

高性能J2EE應用的技巧

　　Java性能的基礎—內存管理

　　任何Java應用，單機的或J2EE的性能基礎都可歸結到你的應用是如何管理內存的問題。Java的內存管理包括兩個重要任務：內存的分配和內存的回收。在內存的分配中，目標是要減少需要創建的對象。

　　內存回收是導致性能下降的普遍原因。也就是說，內存中的對象越多，垃圾回收越困難。所以我們對創建對象的態度應該越保守越好。

　　在J2EE應用中常見的兩個內存有關的問題是：游離的對象(也被稱為內存泄露)和對象循環(指大量頻繁創建和刪除-在Java中體現為解除引用---對象)。

　　我們應注意確保所有可到達的對象實際是活的，即這些對象不但在內存中，而且也要在執行的代碼中是存在的。當對象在應用中已經沒有用了，而我們卻忘記了刪除對該對象的引用時，游離的對象就出現了。

　　我們知道垃圾回收會占用CPU時間。短期對象的大量創建增加了垃圾回收的頻率會造成性能下降。

　　不要在Servlet中實現業務邏輯

　　在構建J2EE應用時，架構工程師通常會使用到J2EE的基本部分——Servlet。如果架構師不使用Session Beans, Entity Beans, 或 Message Beans, 那么改進性能的方法就很少。只能采用增加CPU或更多的物理服務器等方法。EJB使用了緩存(cache)和資源池等方法可以提高性能和擴展性。

　　盡可能使用本地接口訪問EJB

　　在早期的J2EE (遵循EJB1.X規范)應用中，訪問EJB是`通過RMI使用遠程接口實現的。隨著EJB2.0的出現，可以通過本地接口訪問EJB，不再使用RMI，在同一個JVM中使用遠程方法已經少多了。但是現在還是有一些使用EJB1.X實現的應用和不知道使用本地接口的一些EJB新手。為說明這點，我們作個比較：

　　1、客戶端應用調用本地Stub

　　2、該Stub裝配參數

　　3、該Stub傳到skeleton

　　4、該skeleton分解參數

　　5、該skeleton調用EJB對象

　　6、EJB對象執行容器服務

　　7、EJB對象調用企業BEAN實例

　　8、企業BEA執行操作

　　9、執行組裝/分解步驟然后返回

　　與遠程接口處理相比較，本地接口的EJB方法是：

　　1、客戶端調用本地對象

　　2、本地對象執行容器服務

　　3、本地對象調用企業Bean實例

　　4、企業Bean實例執行操作

　　5、沒有其他返回步驟!

　　如果你不需要從遠程的客戶端訪問一個特殊EJB，就應該使用本地方法。

　　在實現Session Bean的服務中封裝對實體EJB的訪問

　　從Servlet訪問實體EJB不但效率低而且難于維護。使用Session Facade(會話外觀)模式可把對實體EJB的訪問封裝在會話EJB中，在該會話EJB中通過使用本地接口訪問實體EJB而避免過多的遠程調用。

　　這項技術會有額外的性能和擴展方面的好處，這是因為會話和實體EJB可以使用緩存和資源池技術來進行改進。另外，由于負載的需要，會話和實體EJB可被擴展部署到其他硬件設備上，這比將Servlet層復制擴展到其他硬件設備上要簡單的多。

　　盡量粗粒度訪問遠程EJB

　　當訪問遠程EJB時，調用set/get方法將產生過多的網絡請求，同時也導致遠程接口處理的過載。為避免這種情況，可考慮將數據屬性集中在一個對象中，這樣通過一次對遠程EJB的調用就可以傳遞所有數據。這項技術就是數據傳輸對象(Data Transfer Object)模式。

　　優化SQL

　　J2EE的架構設計工程師和開發人員通常不是SQL專家或經驗豐富的數據庫管理員。首先應該確保SQL使用了數據庫提供的索引支持。在某些情況下，將數據庫的索引和數據分開存放會提高性能。但要知道，增加額外的索引可以提高SELECT性能但也會降低INSERT的性能。對于某些數據庫，關聯表之間的排序會嚴重影響性能�？梢远嘞驍祿�庫管理員咨詢。

　　避免在實體EJB中過多執行SQL

　　有時候，通過實體EJB訪問數據會執行多個SQL語句。根據J2EE 規范，第一步，將調用實體Bean的find(發現)方法;第二步，在第一次調用實體EJB的業務方法時，容器會調用ejbLoad()從數據庫中獲得信息。

　　很多CMP(容器管理持久性)在調用發現方法時就緩存了實體數據，所以在調用ejbLoad()時就不再訪問數據庫了。應該避免使用BMP(Bean管理的持久性)或者自己實現緩存算法避免二次訪問數據庫。

　　使用Fast Lane Reader 模式訪問只讀數據

　　J2EE應用經常要以只讀方式訪問大量長時間不變的數據，而不是訪問單個實體，例如瀏覽在線產品目錄。在這種只讀情況下，使用實體EJB訪問數據會導致嚴重過載并且實現很麻煩。實體EJB 適合于對單個實體的粗粒度訪問，訪問大量的列表只讀數據時效率不高。不管是使用CMP還是BMP，一定需要編寫代碼操作多個實體EJB及其關聯。這將導致訪問多個數據庫并存在大量的也是不必要的事務開銷。

　　利用Java Messaging Servce(消息服務)

　　J2EE規范在JMS中提供了內置的異步處理服務。當涉及到系統需求時，應該了解在什么情況下應該采用JMS進行異步處理的設計。一旦確定要執行一些異步處理，那么同步處理的任務就應該越少越好，將數據庫密集的操作安排在稍后的異步處理中完成。

　　緩存JNDI Lookup查找

　　很多操作在進行JNDI查找時要消耗大量資源。通常應該緩存JNDI資源避免網絡調用和某些處理的過載。可以緩存的JNDI查找包括：

　　EJB Home Interfaces

　　Data Sources

　　JMS Connection Factories

　　MS Destinations/Topics

　　一些JNDI包實現了緩存功能。但是調用對EJB主接口的narrow方法時，這種功能作用有限。緩存查找的設計應該使用共享的IntialContext實例，盡管構建它很麻煩。這是因為需要訪問多種數據源，包括應用資源文件JNDI.properties,系統屬性的各項參數,傳入到構造函數的各項參數。

【高性能J2EE應用的技巧】相關文章：

構建高性能J2EE應用的技巧03-20

J2EE應用的十個技巧03-26

J2EE學習技巧03-20

J2EE應用服務器03-29

J2EE應用下基于AOP的抓取策略03-09

J2EE應用服務器介紹03-20

J2EE應用服務器集群03-06

j2ee應用技術開發結構03-04

AutoCAD布局應用技巧03-20