java常見性能優化

Java性能是所有Java應用程序開發人員都關心的問題，因為快速使應用程序與使其正常運行同等重要。 史蒂文·海恩斯（Steven Haines）使用他在Java性能問題上的個人經驗得出的結論是， 大多數問題都有共同的根本原因 。 因此，作為績效分析師，Haines將基本績效問題分為三個基本類別：

數據庫問題 ，主要與持久性配置，緩存或數據庫連接線程池配置有關。

內存問題 ，通常是垃圾回收配置錯誤或內存泄漏。

并發問題 ，基本上是死鎖，網格鎖和線程池配置問題。

讓我們深入研究每個類別...

數據庫

由于數據庫是應用程序功能的基本組成部分，因此它也是性能問題的基本根源。 由于對數據庫的訪問使用錯誤，連接池大小錯誤或缺少調整，可能會出現問題。

持久性配置

即使今天Hibernate和其他JPA實現提供了對數據庫訪問的微調，但仍有一些其他選擇（例如急切或延遲獲取）可能會導致較長的響應時間和數據庫開銷。 渴望獲取使數據庫調用減少了，但是變得更加復雜，而懶惰獲取使數據庫調用變得更加簡單和快速。

當應用程序的負載增加并且會導致更大的數據庫負載時，就會出現問題。 因此，為了解決此問題，您可以查看業務事務計數器，數據庫計數器，但基本上是業務事務與數據庫調用之間的相關性。 為避免此類問題，您必須充分了解所使用的持久性技術，正確設置所有配置選項，以便將其功能與您的業務領域需求配對。

快取

緩存優化了應用程序的性能，因為內存中的數據比持久性的??數據訪問速度更快。 當不使用緩存時會引起問題，因此每次需要資源時都會從數據庫中檢索它。 使用緩存時，由于配置錯誤，會出現問題。 這里要注意的基本事項是緩存的固定大小和分布式緩存配置。 緩存的對象是有狀態的，與提供無狀態對象的池不同。 因此，必須正確配置緩存，以免耗盡內存。 但是，如果再次請求移除的對象怎么辦？ 必須在高速緩存設置以及內存中配置此“未命中”比率。

分布式緩存也可能會引起問題。 將緩存設置為多個服務器時，必須進行同步。 因此，緩存更新將傳播到所有服務器中的緩存。 這是實現一致性的方式，但這是一個非常昂貴的過程。 正確使用緩存時，應用程序負載增加不會增加數據庫負載，但是當緩存設置錯誤時，數據庫負載會增加，從而導致CPU開銷達到均勻的磁盤I / O速率。

為了解決此問題，您應該首先檢查數據庫性能，以確定是否需要緩存。 然后，您應該使用命中率和未命中率指標來確定緩存大小。 但是，通過在構建應用程序之前正確規劃應用程序，可以避免遇到緩存問題。 確保使用序列化和提供可伸縮應用程序的技術。

泳池連接

池連接通常在啟動應用程序之前創建，因為它們創建起來很昂貴。 連接池在事務之間共享，并且池大小限制了數據庫負載。

池大小很重要。 沒有足夠的連接使業務交易等待，數據庫使用不足。 另一方面，太多的連接會導致更長的響應時間和數據庫過載。 為了解決此問題，您必須檢查您的應用程序是在等待新的連接還是要執行數據庫查詢。 但是，您始終可以通過優化數據庫來避免這種情況，使用不同的池大小測試應用程序，以檢查哪種情況適合。

記憶

內存問題與垃圾收集器和內存泄漏有關。

垃圾收集器

垃圾回收可能會導致所有線程停止以回收內存。 當此過程花費太多時間或發生得太頻繁時，就會出現問題。 它的基本癥狀是CPU峰值和較大的響應時間。 為了解決這個問題，您可以配置-verbosegc參數，使用性能監視工具來查找發生主要GC的過程，并使用一種工具來監視堆使用情況和可能的CPU峰值。 盡管可以通過配置堆大小和循環JVM來限制它，但是幾乎不可能避免該問題。

內存泄漏

Java中的內存泄漏可能以不同于C或C ++的方式發生，因為它們更多地是參考管理問題。 在Java中，即使不再使用對象，也可以保留對對象的引用。 這可能會導致OutOfMemory錯誤，并要求重新啟動JVM。 當內存使用率增加且堆內存不足時，就會發生內存泄漏問題。 要解決此問題，可以正確配置JVM參數。 為避免必須處理內存泄漏，在對內存泄漏進行編碼時應注意-敏感的Java集合或會話管理。 您可以與同事共享內存泄漏避免技巧，讓專家查看您的應用程序代碼，并使用工具來避免內存泄漏和分析堆。

并發

并發發生在同時執行多個計算時。 Java使用同步和鎖來管理多線程。 但是同步可能會導致線程死鎖，網格鎖和線程池大小問題。

線程死鎖

當兩個或多個線程試圖訪問相同的資源，而一個線程正在等待另一個線程釋放資源時，則發生線程死鎖，反之亦然。 發生死鎖時，JVM耗盡了所有線程，并且應用程序變得越來越慢。 死鎖很難重現。 因此，解決死鎖問題的一種方法是在兩個線程死鎖時捕獲線程轉儲，并檢查線程的堆棧跟蹤。 為避免此問題，最好使您的應用程序及其資源盡可能不變，利用同步并檢查潛在的線程交互。

線程僵局

當使用太多同步并因此花費太多時間等待單個資源時，可能會發生線程僵局。 要注意這一點，您必須同時具有較慢的響應時間和較低的CPU使用率，因為許多線程嘗試訪問同一代碼部分，并且它們正在等待具有該代碼部分的代碼部分完成。 那么，您該如何解決呢？ 您必須首先檢查線程在哪里等待以及原因。 然后，您應該根據業務需求消除同步要求。

線程池配置鎖

當應用程序使用應用程序服務器或Web容器時，線程池用于控制并發處理的請求。 如果此線程池很小，則請求將等待很多，但是如果線程池太大，則處理資源將變得很忙。 因此，在較小的緩沖池中，CPU利用率不足，但線程池利用率為100％，而在較大的緩沖池中，CPU則非常繁忙。

您可以通過檢查線程池利用率和CPU利用率并確定是增加還是減小池大小來輕松解決此問題 。 為了避免這種情況，您必須調整線程池，而這并非易事。

最后，可能發生的兩個基本問題是事后考慮的性能問題，或者最終用戶會注意到的性能問題。

第一種情況是一個常見問題。 通常，開發人員會創建一個功能正常但在性能測試中失敗的應用程序。 為了解決這個問題，他們通常必須對應用程序進行體系結構審查，而性能分析工具似乎非常方便。 為避免此問題，請在開發應用程序時嘗試測試性能，因此持續集成是關鍵。

對于第二種情況，當應用程序的最終用戶通知您存在性能問題時會發生什么？ 有避免這種情況的工具，例如JMX來檢查服務器的行為。 商業交易績效結果與JMX結果結合在一起也可能會有所幫助。 方法級響應時間檢查業務事務中調用的所有方法，并找到應用程序的熱點。 因此，最好使用這些工具之一，以使最終用戶永遠不會警告您性能。

有興趣了解更多嗎？ 然后，您應該在此處下載相關的電子書。

翻譯自: https://www.javacodegeeks.com/2015/02/top-10-common-java-performance-problems.html

java常見性能優化

總結

以上是生活随笔為你收集整理的java常见性能优化_十大最常见的Java性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。