java 性能調(diào)優(yōu)

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

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

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

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

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

重現(xiàn)問(wèn)題。

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

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

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

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

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

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

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

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

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

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

此階段使用的大量工具肯定超出了我們的期望。 在收集足夠的證據(jù)之前，普通用戶(hù)至少使用了四個(gè)工具 。

實(shí)際根本原因

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

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

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

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

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

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

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

java 性能調(diào)優(yōu)

總結(jié)

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

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