java 性能調優

這是本系列中的最后一篇文章，我們將分析我們在2014年10月進行的Java Performance Tuning Survey的結果。如果您尚未閱讀第一篇文章，建議您首先閱讀以下內容：

• 性能問題的頻率和嚴重性
• 最受歡迎的監控解決方案
• 查找根本原因的工具和技術

這篇文章打開了一些有趣的相關數據并總結了結果。

復制是快速成功的關鍵

當您負責解決性能問題時，您需要證據來找到根本原因。 為了獲得證據，您通常需要重現問題。 在調查中，我們詢問了受訪者是否能夠重現該問題 ：

• 9％不需要復制，已經有足夠的證據
• 27％無法重現該問題
• 64％設法重現該問題

在另一個問題中，我們問“ 找到并解決您遇到的問題需要花費多長時間”。 平均而言，這花費了80個小時 。 我們分析了是否有27％無法重現該問題的人是否還在苦苦掙扎。 結果很明顯：

• 如果受訪者能夠重現問題，則平均需要65個小時
• 如果響應者無法重現該問題，則 需要花費 113個小時或74％的時間才能找到根本原因并加以解決。

區別清晰可見。 造成這種差異的原因隱藏在故障排除過程中。 要解決問題，您需要證據，通常是從各種來源收集的證據，例如日志文件，線程轉儲或堆轉儲。 但是，只有在能夠重現案件的情況下（最好是隨心所欲），您才能獲得證據。 如果您無法重現問題，那么您將沒有證據，而武庫中唯一的工具往往是良好的舊嘗試和錯誤。 面對超過100,000行代碼，您注定會在此過程中面臨許多失敗的嘗試。

有些問題比其他問題難。

受訪者還向我們提供了他們正在解決的性能問題的根本原因。 我們研究了不同的問題，以了解某些問題是否比其他問題更難解決

讓我們再次回顧一下，發現和解決問題的平均時間為80個小時。 在按問題類型進行分類時，我們發現了以下內容：

• 查找和修復最簡單的問題與網絡IO有關：平均花費51個小時。
• 內存泄漏按所花費的時間準確地排在平均水平：平均發現并修復一個泄漏所花費的時間為80小時24分鐘。
• 另一方面是架構問題–根本原因與整體架構和HTTP會話膨脹有關，分別花費了98 和105個小時。 查找和解決原因的時間增加了大約100％ 。

從極端來看，這實際上并不奇怪。 當您的體系結構引起性能問題時，修復程序本身往往很復雜且耗時，因此需要更多的時間來修復。 而且當您傾向于濫用網絡時，它通常可以歸結為一個惡意呼叫，您可以輕松地對其進行隔離和修復。

隨機工具幫助

接下來，我們分析了用于解決某些潛在根本原因的工具和技術。 我們注意到，平均而言，用戶不會嘗試使用不少于四種不同的工具來收集證據并找到根本原因 。 最流行的工具和技術涉及日志分析，堆/線程轉儲和分析器。

當我們研究工具在各種潛在問題中的使用時，我們感到非常驚訝。 根本的問題和用于進行故障排除的工具之間幾乎沒有關聯-列出了相同的工具，而頻率與出現的問題無關。

最好的例子可能是線程轉儲分析。 這是收集有關并發問題的證據的好方法。 實際上，解決并發問題的受訪者中有52％使用線程轉儲分析作為根本原因分析來源之一。 但是例如，當眼前的問題是內存泄漏時，則有42％的情況列出了相同的線程轉儲分析。

或者，從工具的角度看–與問題類型無關，有41-53％的受訪者使用探查器收集證據，而與癥狀和潛在問題無關。

從這些數據得出結論是很棘手的，但是看來證據收集和分析過程是非常非正式的，涉及使用該特定人員以前使用或聽說過的工具和技術。

結論

進行這項調查是為了指導Plumbr的進一步發展。 對我們而言，主要結論基于調查的四個關鍵結果：

• 查找和解決性能問題的平均時間為80小時
• 對于76％的案件，大部分時間都花在了惡性的“試圖復制-收集證據-解釋證據”周期中。
• 27％的情況無法復制。 在這種情況下，查找和解決問題所花費的時間增加了73％。
• 證據收集過程是完全非正式的，平均涉及四個隨機選擇的工具

我們承諾從這里開始，并為上述問題提供解決方案。 使用Plumbr監視系統，可以立即將您準確定位到根本的根本原因，從而完全跳過“嘗試復制-收集證據-解釋證據”的周期：

我們當前的產品允許線程鎖定，低效率的GC和內存泄漏，但是我們一直在擴展我們的產品，因此您將擁有一個安全網來應對影響JVM的所有性能問題。

翻譯自: https://www.javacodegeeks.com/2014/12/java-performance-tuning-survey-results-part-iv.html

java 性能調優

總結

以上是生活随笔為你收集整理的java 性能调优_Java性能调优调查结果（第四部分）的全部內容，希望文章能夠幫你解決所遇到的問題。

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