GlassFish 性能調優實戰：五大典型案例深度剖析

GlassFish 為主流 Java EE 應用伺服器，大量企業級應用運行其上，性能調優成關鍵議題。企業級應用併發用戶多、資料傳輸量大、邏輯複雜、資源佔用高，性能直接關係系統穩定性。優秀性能意味著同等任務下資源佔用更少、用戶體驗更佳、成本更低、利潤更高。

Java EE 系統調優為多層次工程：應用程式 → GlassFish → JVM → 作業系統 → 硬體。每層因素皆影響整體性能，需綜合知識靈活定位瓶頸。以下五大實戰案例：

案例一：記憶體洩漏導致性能遞減

現象：8 CPU 伺服器上線後性能不穩，隨時間變慢。mpstat 顯示僅 1 CPU 忙碌，其餘閒置。jstat 發現 GC 頻率極高（每 5 秒一次，每次 2 秒），釋放記憶體極少，強烈暗示記憶體洩漏。jmap 發現 10,000+ Session 物件。

根因：Session timeout 設 50 分鐘且無登出介面，導致 Session 長期佔用記憶體。

解決：提供登出連結引導用戶點擊，timeout 改為 5 分鐘。數天測試證實洩漏解決。

案例二：資料庫連線池耗盡導致系統無回應

現象：財務應用併發超 100 用戶時停止回應。OS 進程正常、CPU 近零。kill -3 pid 導出執行緒堆疊：多數處理執行緒等待連線池，已獲連線者處於阻塞。DBA 發現資料庫 Session 全處死鎖。

根因：資料庫端死鎖操作阻塞請求，佔滿連線池，後續請求阻塞於池上。

解決：解決資料庫死鎖，性能恢復。

案例三：大物件快取導致長時間 GC 停頓

現象：電信應用 64 位 JVM 運行不穩，頻繁停止回應。GC 時間長達 15 分鐘，系統如掛起。使用 12GB 記憶體（突破 4GB 限制），開發者為提性能大量使用物件快取：8GB 快取空間、6000+ 萬物件，遍歷導致長時間 GC。

解決：快取空間降至 1GB，調整演算法（增量回收），GC 最大停頓降至 4 秒，滿足需求。

案例四：外部命令執行耗盡 CPU 資源

現象：數位校園應用 4 CPU Solaris 10 壓測回應慢。mpstat CPU 使用率高，且系統佔用絕大多數 CPU（非應用）。DTrace 發現最耗 CPU 系統呼叫為 fork。

根因：每請求執行外部 Shell 腳本獲取系統資訊（Runtime.getRuntime().exec()）。JVM 執行方式：複製當前進程 → 新進程執行命令 → 退出進程。頻繁執行極耗 CPU 與記憶體。

解決：移除 Shell 腳本調用，系統恢復正常。

案例五：單一目錄文件過多導致建立檔案極慢

現象：CMS 系統長期運行後性能極差，單用戶也慢。OS 工具一切正常，JVM 觀察無異常。NetBeans Profiler 追蹤：90% 時間耗於建立新檔案。該系統單一目錄儲存 80 萬檔案，命名唯一區別。檔案系統防重名需遍歷所有檔名，開銷巨大。

解決：分類儲存不同目錄，性能大幅提升。

案例六：TLB 命中率低調優提升 40% 性能

現象：ERP 系統 CPU 充分利用下性能不佳。CPU 狀態檢查發現 TLB 命中率不高。調整 JVM 啟動參數強制使用大尺寸記憶體頁面：

-XX:+AggressiveHeap
-XX:LargePageSizeInBytes=256m

結果：TLB 命中顯著提高，性能提升近 40%。