這是該系列文章的第三篇，我們將分析2014年10月進行的調查的結果。如果您尚未這樣做，我建議從該系列的前兩篇文章開始： 問題嚴重性分析和監視域分析 。 這篇文章著重于故障排除/根本原因檢測。

本調查部分的背景：意識到性能問題并了解其對最終用戶的影響足以采取行動后，請執行以下過程：

• 重現問題。 您很少從足夠的信息開始，因此第一步通常涉及重現問題以開始收集更多證據。
• 收集證據。 要了解實際情況，您需要收集更多信息（例如，通過日志記錄，線程/堆轉儲等）來了解情況。
• 解釋證據。 在收集了證據之后，對其進行任何理解可能仍然很棘手。 查看您的第一個堆轉儲并嘗試找出導致內存泄漏的實際原因是一個很好的示例，其中解釋部分可能會花費很多時間。
• 將證據與實際根本原因聯系起來。 在最終弄清證據之后，您可以開始查找導致實際問題的實際代碼或配置項的鏈接。

上述過程通常是完全非正式的，但是在大多數情況下還是存在的。 為了了解情況，我們通過詢問受訪者以下問題來分析當前狀況：

• 您能夠重現該問題嗎？
• 您如何收集證據以找到根本原因？
• 您使用了哪些工具來收集證據？
• 真正的根本原因是什么？

重現問題。

因此，正如我們所見，為了獲得證據，您首先需要重現問題（最好隨意）。 當我們問這個問題時，受訪者說：

我們可以看到9％的受訪者甚至不需要重現該問題，這可能是因為已經有足夠的證據。 但是，有27％的聽眾無法重現該問題 ，這為解決問題的道路設置了一個非常討厭的障礙–無法重現該問題，大多數故障排除工具會讓您空手而歸。 在這種情況下，整個過程常常成為痛苦的反復試驗的噩夢。

用于收集證據的工具和技術

當您能夠重現問題時，下一步的目標是收集更多證據。 為此，存在各種各樣的工具和技術。 在我們的調查中，我們要求受訪者列出其武器庫。 284位受訪者列出了以下1,101個選項：

最常見的證據來源顯然是申請日志-71％的受訪者確認這是使用的來源之一。 這不會讓任何人感到驚訝，尤其是當您回想起大多數受訪者具有工程背景時。 畢竟，應用程序日志是由開發人員自己編寫的，因此這是一個相當熟悉的領域，可以開始解決任何問題。

證據收集的第二種最常用的技術是使用JVM內置工具 （例如jconsole，jmc，jstat，jmap等）。 60％的受訪者正在使用這些工具來尋找實際的根本原因。 如果我們再次回憶起大多數受訪者是工程師，那么這又再次變得有意義-JVM嵌入式工具對于工程師來說是眾所周知的，因此比OS內置工具可能更喜歡使用。

分析器聲稱在領獎臺上排名第三-答案中有46％列出了諸如Yourkit和JProfiler之類的工具。 的確，如果您能忍受它們構成的開銷，則分析器在許多情況下都是適合該工作的工具，因此該職位應有充分的理由。

接下來，是時候分析堆轉儲和線程轉儲了。 分別有39％和36％的響應列出了轉儲分析作為使用的技術之一。 考慮到該領域中的底層工具，多少使這些工具最終被使用是令人驚訝的。

查找根本原因所涉及的下一組工具和技術包括GC日志，調試器，數據庫日志和OS級工具。 在25％至32％的案例中提到了這些工具。 特別是OS工具出人意料地不受歡迎–考慮到您可以通過sar，top，iostat等獲得的信息，它一定程度上與響應調查的人員數量少有關。

在另一端，我們有七位受訪者誠實地說他們轉向了外部幫助。 在使用APM工具設法找到根本原因的受訪者中，有 31位，即11％ 。 這與我們的經驗相符–當前的APM工具擅長于評估性能事件的影響，尤其是根據用戶體驗來衡量時。 大多數APM提供程序還擅長在基礎架構中定位故障節點。 但是，在此級別上，APM提供的見解通常會停止，而其他各種工具也將接管。

此階段使用的大量工具肯定超出了我們的期望。 一個普通用戶在設法收集足夠的證據之前使用了不少于四種不同的工具 。

實際根本原因

我們要問的最后一個問題是找出觸發性能事件的真正根本原因。 我們收到的778個回復分為以下幾類：

在本節中，我們必須承認，由以內存泄漏檢測功能聞名的公司發起的調查肯定會使結果歪曲。 根據我們的結果，內存泄漏是迄今為止最常見的性能瓶頸，我們實際上拒絕相信自己。

接下來的兩個根本原因是一致的-創建太多數據庫查詢或效率低下的數據庫查詢實際上符合許多人的期望。 36％的受訪者將這些問題之一列為當前性能問題的根本原因。

同步問題非常普遍，其中有24％的受訪者認為同步不良是造成性能瓶頸的根本原因。 正如我們最近在該領域發布的解決方案一樣，它很好地證明了我們自己的測量結果。 除此之外，考慮到大多數Java EE開發人員應該與并發算法完全隔離，這仍然是一個令人驚訝的結果。

接下來列出了緩存不良和GC效率低下的問題，分別有22％和21％的受訪者將這些問題視為根本原因。 確實可以將這兩者一起看待，因為前者經常觸發第二個-構建不良的緩存往往會浪費大量時間，從而引發惡性循環，使GC難以應對。

解釋其余的根本原因將使職位的長度超出合理的長度。 還有一件值得注意的事情是，可觀的數量（10％）的受訪者誠實地說他們不知道是什么原因導致了績效錯誤。 這再次證實了以下事實：根本原因檢測是一個復雜的領域，迫切需要改進工具。

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

總結

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

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