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

本調(diào)查部分的背景：意識(shí)到性能問題并了解其對(duì)最終用戶的影響足以采取行動(dòng)后，請(qǐng)執(zhí)行以下過程：

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

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

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

重現(xiàn)問題。

因此，正如我們所見，為了獲得證據(jù)，您首先需要重現(xiàn)問題（最好隨意）。 當(dāng)我們問這個(gè)問題時(shí)，受訪者說：

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

用于收集證據(jù)的工具和技術(shù)

當(dāng)您能夠重現(xiàn)問題時(shí)，下一步的目標(biāo)是收集更多證據(jù)。 為此，存在各種各樣的工具和技術(shù)。 在我們的調(diào)查中，我們要求受訪者列出其武器庫。 284位受訪者列出了以下1,101個(gè)選項(xiàng)：

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

證據(jù)收集的第二種最常用的技術(shù)是使用JVM內(nèi)置工具 （例如jconsole，jmc，jstat，jmap等）。 60％的受訪者正在使用這些工具來尋找實(shí)際的根本原因。 如果我們?cè)俅位貞浧鸫蠖鄶?shù)受訪者是工程師，那么這又再次變得有意義-JVM嵌入式工具對(duì)于工程師來說是眾所周知的，因此比OS內(nèi)置工具可能更喜歡使用。

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

接下來，是時(shí)候分析堆轉(zhuǎn)儲(chǔ)和線程轉(zhuǎn)儲(chǔ)了。 分別有39％和36％的響應(yīng)列出了轉(zhuǎn)儲(chǔ)分析作為使用的技術(shù)之一。 考慮到該領(lǐng)域中的底層工具，多少使這些工具最終被使用是令人驚訝的。

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

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

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

實(shí)際根本原因

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

在本節(jié)中，我們必須承認(rèn)，由以內(nèi)存泄漏檢測(cè)功能聞名的公司發(fā)起的調(diào)查肯定會(huì)使結(jié)果歪曲。 根據(jù)我們的結(jié)果，內(nèi)存泄漏是迄今為止最常見的性能瓶頸，我們實(shí)際上拒絕相信自己。

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

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

接下來列出了緩存不良和GC效率低下的問題，分別有22％和21％的受訪者將這些問題視為根本原因。 確實(shí)可以將這兩者一起看待，因?yàn)榍罢呓?jīng)常觸發(fā)第二個(gè)-構(gòu)建不良的緩存往往會(huì)浪費(fèi)大量時(shí)間，從而引發(fā)惡性循環(huán)，使GC難以應(yīng)對(duì)。

解釋其余的根本原因?qū)⑹孤毼坏拈L度超出合理的長度。 還有一件值得注意的事情是，可觀的數(shù)量（10％）的受訪者誠實(shí)地說他們不知道是什么原因?qū)е铝丝冃уe(cuò)誤。 這再次證實(shí)了以下事實(shí)：根本原因檢測(cè)是一個(gè)復(fù)雜的領(lǐng)域，迫切需要改進(jìn)工具。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。