影響Java EE性能的十大問題

本文做者是一名有10多年經驗的高級系統架構師，他的主要專業領域是Java EE、中間件和JVM技術。他在性能優化和提高方面也有很深入的看法，下面他將和你們分享一下常見的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暫停時間很長和性能降低。可能有如下幾個緣由：

1. 與JVM的負載量和應用程序內存佔用量相比，Java堆可能選擇的過小。
2. JVM GC策略使用不合理。
3. 應用程序靜態或動態內存佔用量太大，不適合在32位JVM上使用。
4. JVM OldGen隨着時間推移，泄漏愈來愈嚴重，而GC在幾個小時或者幾天後才發現。
5. JVM PermGen空間(只有HotSpot VM）或本機堆隨着時間推移會泄露是一個很是廣泛的問題；OOM的錯誤每每是觀察一段時間後，應用程序進行動態調動。
6. YoungGen和OldGen的比例空間與你的應用程序不匹配。
7. Java堆在32位的VM上太大，致使本機堆溢出，具體能夠表現爲OOM試着去連接一個新的Java EE應用程序、建立一個新的Java線程或者須要計算本地內存分配任務。

建議：

1. 觀察和深刻理解JVM垃圾回收。啓動GC，根據健康合理的評估來提供全部的數據。
2. 記住，GC方面的相關問題不會在開發中或者功能測試時發現，它須要在多用戶高負載的測試環境下發現。 

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

致使Java EE性能差的第四個緣由是高分佈式系統，典型案例是電信IT環境。在這個環境中，一箇中間件領域（例如，服務總線）不多會作全部的工做，而僅僅是把一些業務「委託」給其餘部分，例如產品質量，客戶資料和訂單管理，到其餘Java EE中間件平臺或遺留系統中，如支持各類不一樣的負載類型和通訊協議的大型機。

這樣的外部系統調用意味着客戶端的Java EE應用程序觸發建立或重用套接字連接從外部系統中讀寫數據。根據業務流程的實施和實現能夠配置成同步調用或異步調用。須要注意的是，響應時間會根據外部系統的穩定情況進行改變，因此經過適當的使用超時來保護Java EE應用程序和中間件也是很是重要的。

下面這3種狀況是常常出現問題和性能下降的地方：

1. 同步和相繼調用太多的外部系統。
2. 在Java EE客戶端應用程序和外部系統之間連接超時，使數據丟失或者值過高致使客戶端線程被卡住，從而致使多米拉效應。
3. 超時，但程序仍正常執行，但是中間件不處理這種奇怪的路徑。

最後，建議多進行負面測試，這意味着須要「人爲」創造產生這些問題的條件，用來測試應用程序和中間件之間是如何處理外部系統錯誤。

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

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

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

如下是我在10年的工做中，常常出現的關於數據庫方面的問題（以Oracle數據庫爲例）：

1. 孤立的，長時間運行的SQL。主要表現爲線程阻塞、SQL沒有進行優化、缺乏索引、非最佳的執行計劃、返回大量數據集等等。
2. 表或行級數據鎖定。當提交一個雙階段事務模型時（例如，臭名昭著的Oracle可疑事務）。Java EE容器可能會留下一些未處理的事務等待最後的提交或回滾，留下的數據鎖能觸發性能問題，直到最後的鎖被移除。例如中間件斷電或者服務器崩潰均可能引發這些狀況發生。
3. 缺少合理規範的數據庫管理工具。例如Oracle裏面的REDO logs，數據庫數據文件等。磁盤空間不足，日誌文件不旋轉等都會觸發較大的性能問題和斷電狀況。

建議：

1. 合理的容量規劃，包括負載和性能測試都是必不可少的，優化數據環境和及時發現問題。
2. 若是是使用Oracle數據庫，確保DBA團隊按期審查AWR報告，尤爲是在上下關聯的事件和根源分析過程當中。
3. 使用JVM線程存儲和AWR報告查明SQL運行緩慢的緣由或者使用監控工具來作。
4. 增強「操做」方面的數據庫環境（磁盤空間、數據文件、重作日誌、表空間等）以適當的監視和報警。若是不這麼作，會讓客戶端IT環境出現較多的斷電狀況和花許多時間進行故障調修。

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

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

1. 線程安全的代碼問題
2. 通訊API缺乏超時設置
3. I/O、JDBC或者關係型API資源管理問題
4. 缺少適當的數據緩存
5. 數據緩存過分
6. 過多的日誌記錄

7.Java EE中間件調優問題

通常Java EE中間件都已經夠用了，只是缺乏必要的優化。大多數Java EE容器都能有多種方案供你的應用程序和業務進程選擇。

若是沒有進行適當的調整和實踐，那麼Java EE容器可能會處於一種消極的狀態。下圖是視圖和檢查列表示例：

8.主動監控不足

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

以個人經驗來看，若是一開始不進行監控，而是運行幾個月或者幾年後再進行，平臺穩定性將大打折扣。

也就是說，改善現有的環境永遠都不會晚。下面是一些建議：

1. 複查現有Java EE環境監測能力和找到需改進的地方。
2. 監測方案應該儘量的覆蓋整個環境。
3. 監控方案應該符合容量規劃進程。

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

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

10.網絡延遲

最後一個影響性能問題的是網絡，網絡問題時不時的都會發生，如路由器、交換機和DNS服務器失敗。更常見的是在一個高度分散的IT環境中按期或間歇性延遲。下面圖片中的例子是一個位於同一區域的Weblogic集羣通訊與Oracle數據庫服務器之間的延遲。

間歇或按期的延遲會觸發一些重要的性能問題，以不一樣的方式影響Java EE應用程序。

1. 由於大量的fetch迭代（網絡傳入和傳出），涉及大數據集的數據查詢問題的應用會很是受網絡延遲的影響
2. 應用程序在處理外部系統大數據負載（例如XML數據）時也會很受網絡延遲的影響，會在發送和接收響應時產生巨大的響應間隔。
3. Java EE容器複製過程（集羣）也會受到影響，而且會讓故障轉移功能（如多播或單播數據包損失）處於風險中。

JDBC行數據「預取」、XML數據壓縮和數據緩存能夠減小網絡延遲。在設計一個新的網絡拓撲時，應該仔細檢查這種網絡延遲問題。

但願本文可以幫助您理解一些常見的性能問題和壓力點，每一個IT環境都是獨一無二的，因此文中提到的問題不必定會是您遇到的，您能夠把您遇到的問題拿出來和你們一塊兒分享一下！