Java EE應用的性能問題對嚴肅的項目和產品來說是一個非常重要的問題。特別是企業級的應用，並發用戶多，數據傳輸量大，業務邏輯復雜，占用系統資源多，因此性能問題在企業級應用變得至關重要，它和系統的穩定性有著直接的聯系。更加重要的是，性能好的應用在完成相同任務的條件下，能夠占用更少的資源，獲得更好的用戶體驗，換句話說，就是能夠節省費用和消耗，獲得更高的利潤。
要獲得更好的性能，就需要對原來的系統進行性能調優。對運行在Glassfish上的JavaEE應用，調優是一件相對復雜的事情。在調優以前必須要認識到：對JavaEE的系統，調優是多層次的。一個JavaEE的應用其實是整個系統中很少的一部分。開發人員所開發的JavaEE程序，無論是JSP還是 EJB，都是運行在JavaEE應用服務器（Glassfish）之上。而應用服務器本身也是Java語言編寫的，需要運行在Java虛擬機之上。 Java虛擬機也只不過是操作系統的一個應用而已，和其他的應用（如Apache）對於操作系統來說沒有本質的區別。而操作系統卻運行在一定的硬件環境中，包括CPU，內存，網卡和硬盤等等。在這麼多的層次中，每一個層次的因素都會影響整個系統的性能。因此，對一個系統的調優，事實上需要同時對每個層次都要調優。JavaEE應用性能調優不僅僅和Glassfish有關，Java語言有關，還要和操作系統以及硬件都有關系，需要調優者有綜合的知識和技能。這些不同層面的方法需要綜合縱效，結合在一起靈活使用，才能快速有效的定位性能瓶頸。下面是一些具體的案例分析:
內存洩漏問題
某個JavaEE應用運行在8顆CPU的服務器上。上線運行發現性能不穩定。性能隨著時間的增加而越來越慢。通過操作系統的工具（mpstat），發現在系統很慢的時候，只有一顆CPU很忙，其他的CPU都很空閒。因此懷疑是Java虛擬機經常進行內存回收，因為虛擬機在內存回收的時候，有的回收算法通常只能運行在一個CPU上。通過Java虛擬機的工具“jstat”可以清楚的看到，Java虛擬機進行內存回收的頻率非常高，幾乎每5秒中就有一次，每次回收的時間為2秒鐘。另外，通過“jstat”的輸出還發現每次回收釋放的內存非常有限，大多數對象都無法回收。這種現象很大程度上暗示著內存洩漏。使用 Java虛擬機的工具“jmap”來獲得當前的一個內存映象。發現有很多（超過10000）個的session對象。這是不正常的一個現象。一般來說， session對應於一個用戶的多次訪問，當用戶退出的時候，session就應該失效，對象應該被回收。當我們和這個系統的開發工程師了解有關 session的設置，發現當他們部署應用的時候，竟然將session的timeout時間設置為50分鐘，並且沒有提供logout的接口。這樣的設置下，每個session的數據都會保存50分鐘才會被回收。根據我們的建議，系統提供了logout的鏈接，並且告訴用戶如果退出應用，應該點擊這個 logout的鏈接；並且將session的timeout時間修改為5分鐘。通過幾天的測試，證明洩漏的問題得到解決。
數據庫連接池問題
某財務應用運行在JavaEE服務器上，後台連接Oracle數據庫。並發用戶數量超過100人左右的時候系統停止響應。通過操作系統層面的進程監控工具發現進程並沒有被殺死或掛起，而CPU使用率幾乎為零。那麼是什麼原因導致系統停止響應用戶請求呢？我們利用Java虛擬機的工具（kill -3 pid）將當前的所有線程狀態DUMP出來，發現JavaEE服務器的大部分處理線程都在等待數據庫連接池的連接，而那些已經獲得數據庫連接的線程卻處於阻塞狀態。數據庫管理員應要求檢查了數據庫的狀態，發現所有的連接的session都處於死鎖狀態。顯然，這是因為數據庫端出現了死鎖的操作，阻塞了那些有數據庫操作的請求，占用了所有數據庫連接池中的連接。後續的請求如果還要從連接池中獲取連接，就會阻塞在連接池上。當解決數據庫死鎖的問題之後，性能問題迎刃而解。
大對象緩存問題
電信應用運行在64位Java虛擬機上，系統運行得很不穩定，系統經常停止響應。使用進程工具查看，發現進程並沒有被殺死或掛起。利用Java虛擬機的工具發現系統在長時間的進行內存回收，內存回收的時間長達15分鐘，整個系統在內存回收的時候就像掛起一樣。另外還觀察到系統使用了12G的內存（因為是 64位虛擬機所以突破了4G內存的限制）。從開發人員那裡了解到，這個應用為了提高性能，大量使用了對象緩存，但是事與願違，在Java中使用過多的內存，雖然在正常運行的時候能夠獲得很好的性能，但是會大大增加內存回收的時間。特別是對象緩存，本系統使用了8G的緩存空間，共緩存了6000多萬個對象，對這些對象的遍歷導致了長時間的內存回收。根據我們的建議，將緩存空間減少到1G，並調整回收算法（使用增量回收的算法），使得系統由於內存回收而造成的最大停頓時間減少到4秒，基本滿足用戶的需求。
外部命令問題
數字校園應用運行在4CPU的Solaris10服務器上，中間件為JavaEE服務器。系統在做大並發壓力測試的時候，請求響應時間比較慢，通過操作系統的工具（mpstat）發現CPU使用率比較高。並且系統占用絕大多數的CPU資源而不是應用本身。這是個不正常的現象，通常情況下用戶應用的CPU占用率應該占主要地位，才能說明系統是正常工作。通過Solaris 10的Dtrace腳本，我們查看當前情況下哪些系統調用花費了最多的CPU資源，竟然發現最花費CPU的系統調用是“fork”。眾所周知， “fork”系統調用是用來產生新的進程，在Java虛擬機中只有線程的概念，絕不會有進程的產生。這是個非常異常的現象。通過本系統的開發人員，我們找到了答案：每個用戶請求的處理都包含執行一個外部shell腳本，來獲得系統的一些信息。這是通過Java的“Runtime.getRuntime ().exec”來完成的，但是這種方法在Java中非常消耗資源。Java虛擬機執行這個命令的方式是：首先克隆一個和當前虛擬機一樣的進程，再用這個新的進程去執行外部命令，最後再退出這個進程。如果頻繁執行這個操作，系統的消耗會很大，不僅在CPU，內存操作也很重。用戶根據建議去掉這個shell 腳本執行的語句，系統立刻回復了正常。
文件操作問題
內容管理（CMS）系統運行在JavaEE服務器上，當系統長時間運行以後，性能非常差，用戶請求的延時比系統剛上線的時候要大很多，並且用戶的並發量很小，甚至是單個用戶也很慢。通過操作系統的工具觀察，一切都很正常，CPU利用率不高，IO也不是很大，內存很富余，網絡幾乎沒有壓力（因為並發用戶少）。先不考慮線程互鎖的問題，因為單個用戶性能也不好。通過Java虛擬機觀察也沒有發現什麼問題（內存回收很少發生）。這使得我們不得不使用代碼跟蹤器來全程跟蹤代碼。我們采用了Netbeans的Profiler，跟蹤的結果非常意外，用戶請求的90％的時間在創建新文件。從系統設計人員了解到，此系統使用了一個目錄用於保存所有上傳和共享的文件，文件用其命名方式來唯一區別於其他文件。我們查看了那個文件目錄，發現該目錄下已經擁有80萬個文件了。這時候我們才定位到問題了：在同個目錄下放置太多的文件，在創建新文件的時候，系統的開銷是比較大的，例如為了防止重名，文件系統會遍歷當前目錄下所有的文件名等等。根據我們的建議，將文件分類保存在不同的目錄下，性能有了大幅度的提高。
高速緩存命中率問題
運行在JavaEE服務器上的ERP系統，在CPU充分利用的情況下性能仍然不太好。從操作系統層面上觀察不到什麼大問題，而且ERP系統過於復雜，代碼跟蹤比較困難。於是進行了CPU狀態的進一步檢查，發現CPU的TLB命中率不是很高，於是對Java虛擬機的啟動參數進行了修改，強迫虛擬機使用大尺寸的內存頁面，提高TLB的命中率。下面的參數是在Sun的HOTSPOT中調整大尺寸（4M）頁面的設置：
-XX:+AggressiveHeap
-XX:LargePageSizeInBytes=256m
通過調整，TLB命中明顯提高，性能也得到近40％的提升。
