中培偉業《JAVA高級開發技術實戰》培訓專家程老師 是中國第一批分析設計師、UML/UP專家、UP統一軟件過程資深教練（國內首位軟件項目過程教練）、國內較早引入模型驅動開發方法的倡導人之一、國內最早的UP過程推動人之一。 擅長企業級應用分析設計與開發；在系統分析設計和開發方面均有豐富經驗。能夠結合實際,在復雜的應用環境中能夠選擇適合需求分析方法定義并改進需求規格說明,降低項目開發風險、縮短開發周期、提高應用系統的可維護性和可擴展性。他在性能優化和提升方面也有很深刻的見解，下面他將和大家分享一下常見的10個影響Java EE性能問題。

1.缺乏正確的容量規劃

容量規劃是一個全面的和發展的過程標準，預測當前和未來的IT環境容量需求。制定合理的容量規劃不僅會確保和跟蹤當前IT生產能力和穩定性，同時也會確保新項目以最小的風險部署到現有的生產環境中。硬件、中間件、JVM、調整等在項目部署之前就應該準備好。

2.Java EE中間件環境規范不足

“無規矩不成方圓”。第二個比較普遍的原因是Java EE中間件或者基礎架構不規范。在項目初始，新平臺上面沒有制定合理的規范，導致系統穩定性差。這會增加客戶成本，所以花時間去制定合理的Java EE中間件環境規范是必須的。這項工作應與初始容量規劃迭代相結合。

3.Java虛擬機垃圾回收過度

各位對“java.lang.OutOfMemoryError”這個錯誤信息是不是很熟悉呢？由于JVM的內存空間過度消耗（Java堆、本機堆等）而拋出的異常。

垃圾收集問題并不一定會表現為一個OOM條件，過度的垃圾收集可以理解成是JVM GC線程在短時間里進行輕微或超量收集集合數據而導致的JVM暫停時間很長和性能下降。可能有以下幾個原因：

與JVM的負載量和應用程序內存占用量相比，Java堆可能選擇的太小。 JVM GC策略使用不合理。 應用程序靜態或動態內存占用量太大，不適合在32位JVM上使用。 JVM OldGen隨著時間推移，泄漏越來越嚴重，而GC在幾個小時或者幾天后才發現。 JVM PermGen空間(只有HotSpot VM）或本機堆隨著時間推移會泄露是一個非常普遍的問題；OOM的錯誤往往是觀察一段時間后，應用程序進行動態調動。 YoungGen和OldGen的比例空間與你的應用程序不匹配。 

Java堆在32位的VM上太大，導致本機堆溢出，具體可以表現為OOM試著去鏈接一個新的Java EE應用程序、創建一個新的Java線程或者需要計算本地內存分配任務。 

建議：觀察和深入理解JVM垃圾回收。啟動GC，根據健康合理的評估來提供所有的數據。 記住，GC方面的相關問題不會在開發中或者功能測試時發現，它需要在多用戶高負載的測試環境下發現。 

4.與外部系統集成過多或過少

導致Java EE性能差的第四個原因是高分布式系統，典型案例是電信IT環境。在這個環境中，一個中間件領域（例如，服務總線）很少會做所有的工作，而僅僅是把一些業 務“委托”給其他部分，例如產品質量，客戶資料和訂單管理，到其他Java EE中間件平臺或遺留系統中，如支持各種不同的負載類型和通信協議的大型機。

這樣的外部系統調用意味著客戶端的Java EE應用程序觸發創建或重用套接字鏈接從外部系統中讀寫數據。根據業務流程的實施和實現可以配置成同步調用或異步調用。需要注意的是，響應時間會根據外部 系統的穩定狀況進行改變，所以通過適當的使用超時來保護Java EE應用程序和中間件也是非常重要的。

5.缺乏適當的數據庫SQL調優和容量規劃

大家可能會對這一個感到驚奇：數據庫問題。大多數Java EE企業系統是依賴關系型數據庫處理復雜的業務流程。一個基礎扎實穩固的數據庫環境可以確保IT環境有規模的增長，來支持日益不斷擴大的業務。

在實際中，與數據庫相關的性能問題是很常見的。由于多數數據庫事務處理都是由JDBC數據源執行的（包括關系持久化API，例如Hibernate）。而性能問題最初都會表現為線程阻塞。

6.特定應用程序性能問題

下面關注的是比較嚴重的Java EE應用程序問題。關于特定應用程序性能問題，總結了以下幾個點：

（一）線程安全的代碼問題 

（二）通信API缺少超時設置 

（三）I/O、JDBC或者關系型API資源管理問題 

（四）缺乏適當的數據緩存 

（五）數據緩存過度 

（六）過多的日志記錄 

7.Java EE中間件調優問題

一般Java EE中間件都已經夠用了，只是缺少必要的優化。大多數Java EE容器都能有多種方案供你的應用程序和業務進程選擇。如果沒有進行適當的調整和實踐，那么Java EE容器可能會處于一種消極的狀態。

8.主動監控不足

缺乏監控，并不會帶來實際性能問題，但它會影響你對Java EE平臺性能和健康狀況的了解。最終，這個環境可以達到一個破發點，這可能會暴露出一些缺陷和問題(JVM的內存泄漏，等等)。

以我的經驗來看，如果一開始不進行監控，而是運行幾個月或者幾年后再進行，平臺穩定性將大打折扣。也就是說，改善現有的環境永遠都不會晚。下面是一些建議：

復查現有Java EE環境監測能力和找到需改進的地方, 監測方案應該盡可能的覆蓋整個環境, 監控方案應該符合容量規劃進程。 

9.公共基礎設施硬件飽和

這個問題經常在有太多的Java EE中間件環境隨著JVM進程被部署到現有硬件上面時看到。太多的JVM進程對有限的物理CPU核心來說是一個真正的程序性能殺手。另外，隨著客戶端業務的增長，硬件方面也需要再次考慮。

10.網絡延遲

最后一個影響性能問題的是網絡，網絡問題時不時的都會發生，如路由器、交換機和DNS服務器失敗。更常見的是在一個高度分散的IT環境中定期或間歇性延遲。

間歇或定期的延遲會觸發一些重要的性能問題，以不同的方式影響Java EE應用程序。因為大量的fetch迭代（網絡傳入和傳出），涉及大數據集的數據查詢問題的應用會非常受網絡延遲的影響 

應用程序在處理外部系統大數據負載（例如XML數據）時也會很受網絡延遲的影響，會在發送和接收響應時產生巨大的響應間隔。 

Java EE容器復制過程（集群）也會受到影響，并且會讓故障轉移功能（如多播或單播數據包損失）處于風險中。 JDBC行數據“預取”、XML數據壓縮和數據緩存可以減少網絡延遲。在設計一個新的網絡拓撲時，應該仔細檢查這種網絡延遲問題。