新聞資訊

1. Java EE 中間件環(huán)境規(guī)范不足

“沒有規(guī)矩，不成方圓”。第二個(gè)比較普遍的原因是 Java EE 中間件或者基礎(chǔ)架構(gòu)不規(guī)范。在項(xiàng)目初始，新平臺(tái)上面沒有制定合理的規(guī)范，導(dǎo)致系統(tǒng)穩(wěn)定性差。這會(huì)增加客戶成本，所以花時(shí)間去制定合理的 Java EE 中間件環(huán)境規(guī)范是必須的。這項(xiàng)工作應(yīng)與初始容量規(guī)劃迭代相結(jié)合。

2. Java 虛擬機(jī)垃圾回收過度由于 JVM 的內(nèi)存空間過度消耗（Java 堆、本機(jī)堆等）而拋出的異常。

垃圾收集問題并不一定會(huì)表現(xiàn)為一個(gè) OOM 條件，過度的垃圾收集可以理解成是 JVM GC 線程在短時(shí)間里進(jìn)行輕微或超量收集集合數(shù)據(jù)而導(dǎo)致的 JVM 暫停時(shí)間很長和性能下降。可能有以下幾個(gè)原因：與 JVM 的負(fù)載量和應(yīng)用程序內(nèi)存占用量相比，Java 堆可能選擇的太小。JVM GC 策略使用不合理。應(yīng)用程序靜態(tài)或動(dòng)態(tài)內(nèi)存占用量太大，不適合在 32 位 JVM 上使用。JVM OldGen 隨著時(shí)間推移，泄漏越來越嚴(yán)重，而 GC 在幾個(gè)小時(shí)或者幾天后才發(fā)現(xiàn)。JVM PermGen 空間(只有 HotSpot VM）或本機(jī)堆隨著時(shí)間推移會(huì)泄露是一個(gè)非常普遍的問題；OOM 的錯(cuò)誤往往是觀察一段時(shí)間后，應(yīng)用程序進(jìn)行動(dòng)態(tài)調(diào)動(dòng)。建議：觀察和深入理解 JVM 垃圾回收。啟動(dòng) GC，根據(jù)健康合理的評(píng)估來提供所有的數(shù)據(jù)。記住，GC 方面的相關(guān)問題不會(huì)在開發(fā)中或者功能測試時(shí)發(fā)現(xiàn)，它需要在多用戶高負(fù)載的測試環(huán)境下發(fā)現(xiàn)。

3. 與外部系統(tǒng)集成過多或過少

導(dǎo)致 Java EE 性能差的第四個(gè)原因是高分布式系統(tǒng)，典型案例是電信 IT 環(huán)境。在這個(gè)環(huán)境中，一個(gè)中間件領(lǐng)域（例如，服務(wù)總線）很少會(huì)做所有的工作，而僅僅是把一些業(yè)務(wù)“委托”給其他部分，例如產(chǎn)品質(zhì)量，客戶資料和訂單管理， 到其他 Java EE 中間件平臺(tái)或遺留系統(tǒng)中，如支持各種不同的負(fù)載類型和通信協(xié)議的大型機(jī)。    這樣的外部系統(tǒng)調(diào)用意味著客戶端的 Java EE 應(yīng)用程序觸發(fā)創(chuàng)建或重用套接字鏈接從外部系統(tǒng)中讀寫數(shù)據(jù)。合肥網(wǎng)站建設(shè)公司根據(jù)業(yè)務(wù)流程的實(shí)施和實(shí)現(xiàn)可以配置成同步調(diào)用或異步調(diào)用。需要注意的是，響應(yīng)時(shí)間會(huì)根據(jù)外部系統(tǒng) 的穩(wěn)定狀況進(jìn)行改變，所以通過適當(dāng)?shù)氖褂贸瑫r(shí)來保護(hù) Java EE 應(yīng)用程序和中間件也是非常重要的。

4. 特定應(yīng)用程序性能問題下面關(guān)注的是比較嚴(yán)重的 Java EE 應(yīng)用程序問題。

關(guān)于特定應(yīng)用程序性能問題，總結(jié)了以下幾個(gè)點(diǎn)：

1.線程安全的代碼問題

2.通信 API 缺少超時(shí)設(shè)置

3.JDBC 或者關(guān)系型 API 資源管理問題

4.缺乏適當(dāng)?shù)臄?shù)據(jù)緩存

5.數(shù)據(jù)緩存過度過多的日志記錄。

希望本文能夠幫助您理解一些常見的性能問題和壓力點(diǎn)，