- 相關(guān)推薦
影響Java EE性能的因素
JavaEE 是 J2EE的一個(gè)新的名稱(chēng)，之所以改名，目的還是讓大家清楚J2EE只是Java企業(yè)應用。下面小編為大家整理了關(guān)于影響Java EE性能的因素，希望能為你提供幫助：
1.缺乏正確的容量規劃
容量規劃是一個(gè)全面的和發(fā)展的過(guò)程標準，預測當前和未來(lái)的IT環(huán)境容量需求。制定合理的容量規劃不僅會(huì )確保和跟蹤當前IT生產(chǎn)能力和穩定性，同時(shí)也會(huì )確保新項目以最小的風(fēng)險部署到現有的生產(chǎn)環(huán)境中。硬件、中間件、JVM、調整等在項目部署之前就應該準備好。
2.Java EE中間件環(huán)境規范不足
“沒(méi)有規矩，不成方圓”。第二個(gè)比較普遍的原因是Java EE中間件或者基礎架構不規范。在項目初始，新平臺上面沒(méi)有制定合理的規范，導致系統穩定性差。這會(huì )增加客戶(hù)成本，所以花時(shí)間去制定合理的Java EE中間件環(huán)境規范是必須的。這項工作應與初始容量規劃迭代相結合。
3.Java虛擬機垃圾回收過(guò)度
各位對“java.lang.OutOfMemoryError”這個(gè)錯誤信息是不是很熟悉呢?由于JVM的內存空間過(guò)度消耗(Java堆、本機堆等)而拋出的異常。
垃圾收集問(wèn)題并不一定會(huì )表現為一個(gè)OOM條件，過(guò)度的垃圾收集可以理解成是JVM GC線(xiàn)程在短時(shí)間里進(jìn)行輕微或超量收集集合數據而導致的JVM暫停時(shí)間很長(cháng)和性能下降�？赡苡幸韵聨讉�(gè)原因：
與JVM的負載量和應用程序內存占用量相比，Java堆可能選擇的太小。
JVM GC策略使用不合理。
應用程序靜態(tài)或動(dòng)態(tài)內存占用量太大，不適合在32位JVM上使用。
JVM OldGen隨著(zhù)時(shí)間推移，泄漏越來(lái)越嚴重，而GC在幾個(gè)小時(shí)或者幾天后才發(fā)現。
JVM PermGen空間(只有HotSpot VM)或本機堆隨著(zhù)時(shí)間推移會(huì )泄露是一個(gè)非常普遍的問(wèn)題;OOM的錯誤往往是觀(guān)察一段時(shí)間后，應用程序進(jìn)行動(dòng)態(tài)調動(dòng)。
YoungGen和OldGen的比例空間與你的應用程序不匹配。
Java堆在32位的VM上太大，導致本機堆溢出，具體可以表現為OOM試著(zhù)去鏈接一個(gè)新的Java EE應用程序、創(chuàng )建一個(gè)新的Java線(xiàn)程或者需要計算本地內存分配任務(wù)。
建議：
觀(guān)察和深入理解JVM垃圾回收。啟動(dòng)GC，根據健康合理的評估來(lái)提供所有的數據。
記住，GC方面的相關(guān)問(wèn)題不會(huì )在開(kāi)發(fā)中或者功能測試時(shí)發(fā)現，它需要在多用戶(hù)高負載的測試環(huán)境下發(fā)現。
4.與外部系統集成過(guò)多或過(guò)少
導致Java EE性能差的第四個(gè)原因是高分布式系統，典型案例是電信IT環(huán)境。在這個(gè)環(huán)境中，一個(gè)中間件領(lǐng)域(例如，服務(wù)總線(xiàn))很少會(huì )做所有的工作，而僅僅是把一些業(yè) 務(wù)“委托”給其他部分，例如產(chǎn)品質(zhì)量，客戶(hù)資料和訂單管理，到其他Java EE中間件平臺或遺留系統中，如支持各種不同的負載類(lèi)型和通信協(xié)議的大型機。
這樣的外部系統調用意味著(zhù)客戶(hù)端的Java EE應用程序觸發(fā)創(chuàng )建或重用套接字鏈接從外部系統中讀寫(xiě)數據。根據業(yè)務(wù)流程的實(shí)施和實(shí)現可以配置成同步調用或異步調用。需要注意的是，響應時(shí)間會(huì )根據外部 系統的穩定狀況進(jìn)行改變，所以通過(guò)適當的使用超時(shí)來(lái)保護Java EE應用程序和中間件也是非常重要的。
下面這3種情況是經(jīng)常出現問(wèn)題和性能降低的地方：
同步和相繼調用太多的外部系統。
在Java EE客戶(hù)端應用程序和外部系統之間鏈接超時(shí)，使數據丟失或者值太高導致客戶(hù)端線(xiàn)程被卡住，從而導致多米拉效應。
超時(shí)，但程序仍正常執行，可是中間件不處理這種奇怪的路徑。
最后，建議多進(jìn)行負面測試，這意味著(zhù)需要“人為”創(chuàng )造產(chǎn)生這些問(wèn)題的條件，用來(lái)測試應用程序和中間件之間是如何處理外部系統錯誤。
5.缺乏適當的數據庫SQL調優(yōu)和容量規劃
大家可能會(huì )對這一個(gè)感到驚奇：數據庫問(wèn)題。大多數Java EE企業(yè)系統是依賴(lài)關(guān)系型數據庫處理復雜的業(yè)務(wù)流程。一個(gè)基礎扎實(shí)穩固的數據庫環(huán)境可以確保IT環(huán)境有規模的增長(cháng)，來(lái)支持日益不斷擴大的業(yè)務(wù)。
在實(shí)際中，與數據庫相關(guān)的性能問(wèn)題是很常見(jiàn)的。由于多數數據庫事務(wù)處理都是由JDBC數據源執行的(包括關(guān)系持久化API，例如Hibernate)。而性能問(wèn)題最初都會(huì )表現為線(xiàn)程阻塞。
以下是我在10年的工作中，經(jīng)常出現的關(guān)于數據庫方面的問(wèn)題(以Oracle數據庫為例)：
孤立的，長(cháng)時(shí)間運行的SQL。主要表現為線(xiàn)程阻塞、SQL沒(méi)有進(jìn)行優(yōu)化、缺少索引、非最佳的執行計劃、返回大量數據集等等。
表或行級數據鎖定。當提交一個(gè)雙階段事務(wù)模型時(shí)(例如，臭名昭著(zhù)的Oracle可疑事務(wù))。Java EE容器可能會(huì )留下一些未處理的事務(wù)等待最后的提交或回滾，留下的數據鎖能觸發(fā)性能問(wèn)題，直到最后的鎖被移除。例如中間件斷電或者服務(wù)器崩潰都可能引起這些情況發(fā)生。
缺乏合理規范的數據庫管理工具。例如Oracle里面的REDO logs，數據庫數據文件等。磁盤(pán)空間不足，日志文件不旋轉等都會(huì )觸發(fā)較大的性能問(wèn)題和斷電情況。
建議：
合理的容量規劃，包括負載和性能測試都是必不可少的，優(yōu)化數據環(huán)境和及時(shí)發(fā)現問(wèn)題。
如果是使用Oracle數據庫，確保DBA團隊定期審查AWR報告，尤其是在上下關(guān)聯(lián)的事件和根源分析過(guò)程中。
使用JVM線(xiàn)程存儲和AWR報告查明SQL運行緩慢的原因或者使用監控工具來(lái)做。
加強“操作”方面的數據庫環(huán)境(磁盤(pán)空間、數據文件、重做日志、表空間等)以適當的監視和報警。如果不這么做，會(huì )讓客戶(hù)端IT環(huán)境出現較多的斷電情況和花許多時(shí)間進(jìn)行故障調修。
6.特定應用程序性能問(wèn)題
下面關(guān)注的是比較嚴重的Java EE應用程序問(wèn)題。關(guān)于特定應用程序性能問(wèn)題，總結了以下幾個(gè)點(diǎn)：
線(xiàn)程安全的代碼問(wèn)題
通信API缺少超時(shí)設置
I/O、JDBC或者關(guān)系型API資源管理問(wèn)題
缺乏適當的數據緩存
數據緩存過(guò)度
過(guò)多的日志記錄
7.Java EE中間件調優(yōu)問(wèn)題
一般Java EE中間件都已經(jīng)夠用了，只是缺少必要的優(yōu)化。大多數Java EE容器都能有多種方案供你的應用程序和業(yè)務(wù)進(jìn)程選擇。
如果沒(méi)有進(jìn)行適當的調整和實(shí)踐，那么Java EE容器可能會(huì )處于一種消極的狀態(tài)。下圖是視圖和檢查列表示例：
8.主動(dòng)監控不足
缺乏監控，并不會(huì )帶來(lái)實(shí)際性能問(wèn)題，但它會(huì )影響你對Java EE平臺性能和健康狀況的了解。最終，這個(gè)環(huán)境可以達到一個(gè)破發(fā)點(diǎn)，這可能會(huì )暴露出一些缺陷和問(wèn)題(JVM的內存泄漏，等等)。
以我的經(jīng)驗來(lái)看，如果一開(kāi)始不進(jìn)行監控，而是運行幾個(gè)月或者幾年后再進(jìn)行，平臺穩定性將大打折扣。
也就是說(shuō)，改善現有的環(huán)境永遠都不會(huì )晚。下面是一些建議：
復查現有Java EE環(huán)境監測能力和找到需改進(jìn)的地方。
監測方案應該盡可能的覆蓋整個(gè)環(huán)境。
監控方案應該符合容量規劃進(jìn)程。
9.公共基礎設施硬件飽和
這個(gè)問(wèn)題經(jīng)常在有太多的Java EE中間件環(huán)境隨著(zhù)JVM進(jìn)程被部署到現有硬件上面時(shí)看到。太多的JVM進(jìn)程對有限的物理CPU核心來(lái)說(shuō)是一個(gè)真正的程序性能殺手。另外，隨著(zhù)客戶(hù)端業(yè)務(wù)的增長(cháng)，硬件方面也需要再次考慮。
10.網(wǎng)絡(luò )延遲
最后一個(gè)影響性能問(wèn)題的是網(wǎng)絡(luò )，網(wǎng)絡(luò )問(wèn)題時(shí)不時(shí)的都會(huì )發(fā)生，如路由器、交換機和DNS服務(wù)器失敗。更常見(jiàn)的是在一個(gè)高度分散的IT環(huán)境中定期或間歇性延遲。下面圖片中的例子是一個(gè)位于同一區域的Weblogic集群通信與Oracle數據庫服務(wù)器之間的延遲。
間歇或定期的延遲會(huì )觸發(fā)一些重要的性能問(wèn)題，以不同的方式影響Java EE應用程序。
因為大量的fetch迭代(網(wǎng)絡(luò )傳入和傳出)，涉及大數據集的數據查詢(xún)問(wèn)題的應用會(huì )非常受網(wǎng)絡(luò )延遲的影響
應用程序在處理外部系統大數據負載(例如XML數據)時(shí)也會(huì )很受網(wǎng)絡(luò )延遲的影響，會(huì )在發(fā)送和接收響應時(shí)產(chǎn)生巨大的響應間隔。
Java EE容器復制過(guò)程(集群)也會(huì )受到影響，并且會(huì )讓故障轉移功能(如多播或單播數據包損失)處于風(fēng)險中。
JDBC行數據“預取”、XML數據壓縮和數據緩存可以減少網(wǎng)絡(luò )延遲。在設計一個(gè)新的網(wǎng)絡(luò )拓撲時(shí)，應該仔細檢查這種網(wǎng)絡(luò )延遲問(wèn)題。
【影響Java EE性能的因素】相關(guān)文章：
高性能J2EE應用的技巧03-22
影響素描的因素03-02
構建高性能J2EE應用的技巧03-20
Java Web開(kāi)發(fā)和J2EE的區別03-29
績(jì)效管理的影響因素03-16
影響績(jì)效管理的因素03-30
影響寶寶睡眠的因素03-31
影響狗狗毛發(fā)的因素06-24