Java EE 應用在 GlassFish 上的性能調優實戰：六大經典案例深度剖析

性能調優的多層次認知

Java EE 應用性能受多層因素影響：應用代碼 → GlassFish 容器 → JVM → 作業系統 → 硬體 (CPU/記憶體/網卡/磁碟)。調優需綜合知識，跨層定位瓶頸，組合拳出擊。

案例一：Session 洩漏導致 GC 風暴

現象

• 8 CPU 伺服器，隨時間性能遞減
• mpstat 顯示單 CPU 狂忙，其餘閒置
• jstat：GC 每 5 秒一次，耗時 2 秒，釋放記憶體極少

根因

jmap 發現 10,000+ Session 物件堆積。配置 session-timeout=50 分鐘 且無 Logout 介面，導致 Session 長期佔用堆疊。

對策

1. 提供 Logout 連結引導用戶主動銷毀 Session
2. 將 timeout 降為 5 分鐘

結果

數天測試證實洩漏徹底解決，GC 回歸正常頻率。

案例二：資料庫死鎖耗盡連接池

現象

• 併發 >100 用戶系統停止回應
• OS 進程存活、CPU 近零
• kill -3 線程堆疊：大量執行緒阻塞於連接池 getConnection()

根因

DBA 發現所有 DB Session 處於死鎖，佔滿連接池，後續請求永久等待。

對策

解決 DB 端死鎖 (索引優化、鎖順序、隔離級別調整)，性能立即恢復。

案例三：大對象快取引發長時間 Full GC

現象

• 64-bit JVM，12GB 堆，8GB 快取、6000 萬物件
• 系統周期性假死 15 分鐘 (Full GC 耗時)

根因

超大快取導致標記-掃描階段遍歷海量物件，GC 停頓不可接受。

對策

1. 快取縮減至 1GB
2. 啟用增量/並行 GC 算法 (-XX:+UseConcMarkSweepGC 等)

結果

最大停頓從 15 分鐘降至 4 秒，滿足 SLA。

案例四：外部命令執行拖垮 CPU

現象

• 4 CPU Solaris 10，高併發下響應緩慢
• mpstat：系統佔用絕大多數 CPU
• DTrace 顯示 fork() 系統調用消耗最高

根因

每請求呼叫 Runtime.getRuntime().exec() 執行 Shell 腳本。JVM 實作：fork() 克隆整個 JVM 進程 → exec() → 退出。高併發下進程創建/銷毀開銷驚人。

對策

移除外部腳本調用，改用純 Java API (如 OperatingSystemMXBean) 獲取系統資訊。

案例五：單目錄百萬檔案導致創建效能崩潰

現象

• CMS 系統長期運行後極慢，甚至單用戶緩慢
• OS/ JVM 指標皆正常，無鎖競爭
• Profiler 定位：90% 時間消耗在 new File() 創建

根因

單目錄累積 80 萬檔案，檔案系統為防重名需遍歷目錄項，創建複雜度隨檔案數線性增長。

對策

按日期/用戶/雜湊分桶存儲，單目錄檔案數控制在千級以內，性能大幅提升。

案例六：TLB 未命中優化提升 40% 吞吐

現象

• ERP 系統 CPU 飽和但吞吐不理想
• OS 層面無明顯異常，代碼追蹤困難

根因

CPU TLB (Translation Lookaside Buffer) 命中率偏低，記憶體存取效率受損。

對策

HotSpot 啟用大頁面：

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

結果

TLB 命中率顯著提升，整體性能增長近 40%。

調優方法論總結

1. 自上而下分層排查： 應用 → 容器 → JVM → OS → 硬體
2. 善用工具鏈： mpstat/jstat/jmap/kill -3/DTrace/Profiler
3. 數據驅動： 拒絕猜測，堆疊/GC/系統調用數據為準
4. 最小化變更驗證： 單一變更、觀測、迭代