Java性能的基礎(chǔ)----內(nèi)存管理

????????任何Java應(yīng)用，單機的或J2EE的性能基礎(chǔ)都可歸結(jié)到你的應(yīng)用是如何管理內(nèi)存的問題。Java的內(nèi)存管理包括兩個重要任務(wù)：內(nèi)存的分配和內(nèi)存的回收。在內(nèi)存的分配中，目標是要減少需要創(chuàng)建的對象。 內(nèi)存回收是導(dǎo)致性能下降的普遍原因。也就是說，內(nèi)存中的對象越多，垃圾回收越困難。所以我們對創(chuàng)建對象的態(tài)度應(yīng)該越保守越好。

????????在J2EE應(yīng)用中常見的兩個內(nèi)存有關(guān)的問題是：游離的對象（也被稱為內(nèi)存泄露）和對象循環(huán)（指大量頻繁創(chuàng)建和刪除-在Java中體現(xiàn)為解除引用---對象）。

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

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

不要在Servlet中實現(xiàn)業(yè)務(wù)邏輯

????????在構(gòu)建J2EE應(yīng)用時，架構(gòu)工程師通常會使用到J2EE的基本部分，Servlet。

????????如果架構(gòu)師不使用Session Beans, Entity Beans, 或 Message Beans, 那么改進性能的方法就很少。只能采用增加CPU或更多的物理服務(wù)器等方法。EJB使用了緩存（cache）和資源池等方法可以提高性能和擴展性。

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

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

????????1. 客戶端應(yīng)用調(diào)用本地Stub

????????2. 該Stub裝配參數(shù)

????????3. 該Stub傳到skeleton

????????4. 該skeleton分解參數(shù)

????????5. 該skeleton調(diào)用EJB對象

????????6. EJB對象執(zhí)行容器服務(wù)

????????7. EJB對象調(diào)用企業(yè)BEAN實例

????????8. 企業(yè)BEA執(zhí)行操作

????????9. 執(zhí)行組裝/分解步驟然后返回

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

????????????????1. 客戶端調(diào)用本地對象

????????????????2. 本地對象執(zhí)行容器服務(wù)

????????????????3. 本地對象調(diào)用企業(yè)Bean實例

????????????????4. 企業(yè)Bean實例執(zhí)行操作

????????????????5. 沒有其他返回步驟

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

在實現(xiàn)Session Bean的服務(wù)中封裝對實體EJB的訪問

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

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

盡量粗粒度訪問遠程EJB

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

優(yōu)化SQL

????????J2EE的架構(gòu)設(shè)計工程師和開發(fā)人員通常不是SQL專家或經(jīng)驗豐富的數(shù)據(jù)庫管理員。首先應(yīng)該確保SQL使用了數(shù)據(jù)庫提供的索引支持。在某些情況下，將數(shù)據(jù)庫的索引和數(shù)據(jù)分開存放會提高性能。但要知道，增加額外的索引可以提高SELECT性能但也會降低INSERT的性能。對于某些數(shù)據(jù)庫，關(guān)聯(lián)表之間的排序會嚴重影響性能。可以多向數(shù)據(jù)庫管理員咨詢。

避免在實體EJB中過多執(zhí)行SQL

????????有時候，通過實體EJB訪問數(shù)據(jù)會執(zhí)行多個SQL語句。根據(jù)J2EE 規(guī)范，第一步，將調(diào)用實體Bean的find(發(fā)現(xiàn))方法；第二步，在第一次調(diào)用實體EJB的業(yè)務(wù)方法時，容器會調(diào)用ejbLoad()從數(shù)據(jù)庫中獲得信息。

????????很多CMP(容器管理持久性)在調(diào)用發(fā)現(xiàn)方法時就緩存了實體數(shù)據(jù)，所以在調(diào)用ejbLoad()時就不再訪問數(shù)據(jù)庫了。應(yīng)該避免使用BMP(Bean管理的持久性)或者自己實現(xiàn)緩存算法避免二次訪問數(shù)據(jù)庫。

使用Fast Lane Reader 模式訪問只讀數(shù)據(jù)

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

利用Java Messaging Servce(消息服務(wù))

????????J2EE規(guī)范在JMS中提供了內(nèi)置的異步處理服務(wù)。當涉及到系統(tǒng)需求時，應(yīng)該了解在什么情況下應(yīng)該采用JMS進行異步處理的設(shè)計。一旦確定要執(zhí)行一些異步處理，那么同步處理的任務(wù)就應(yīng)該越少越好，將數(shù)據(jù)庫密集的操作安排在稍后的異步處理中完成。

緩存JNDI Lookup查找

????????很多操作在進行JNDI查找時要消耗大量資源。通常應(yīng)該緩存JNDI資源避免網(wǎng)絡(luò)調(diào)用和某些處理的過載。可以緩存的JNDI查找包括：

????????EJB Home Interfaces

????????Data Sources

????????JMS Connection Factories

????????JMS Destinations/Topics

????????一些JNDI包實現(xiàn)了緩存功能。但是調(diào)用對EJB主接口的narrow方法時，這種功能作用有限。

????????緩存查找的設(shè)計應(yīng)該使用共享的IntialContext實例，盡管構(gòu)建它很麻煩。這是因為需要訪問多種數(shù)據(jù)源，包括應(yīng)用資源文件JNDI.properties,系統(tǒng)屬性的各項參數(shù),傳入到構(gòu)造函數(shù)的各項參數(shù)。

（北京鑄銳數(shù)碼科技有限公司 www.InnovateDigital.com）