使用Java監(jiān)視器查找資源泄漏

查找緩慢的資源泄漏是使應(yīng)用程序服務(wù)器長時(shí)間保持正常運(yùn)行的關(guān)鍵。 在這里，我解釋了如何使用Java監(jiān)視器來發(fā)現(xiàn)緩慢的資源泄漏，以及如何驗(yàn)證它們是實(shí)際的泄漏，而不僅僅是額外的預(yù)分配到某些HTTP連接器或數(shù)據(jù)庫池中。 如果執(zhí)行這些步驟，則可以擺脫定期重新啟動，并真正開始依賴服務(wù)器。

緩慢的資源泄漏是一個問題，因?yàn)樗鼈兤仁鼓ㄆ谥匦聠討?yīng)用程序服務(wù)器。 反過來，這意味著您始終必須密切注意服務(wù)器，因?yàn)樗鼈冸S時(shí)可能崩潰。 最終，您不能依賴遭受緩慢資源泄漏的服務(wù)器。 跟蹤和解決緩慢的資源泄漏需要時(shí)間和耐心。 一旦完成幾次，這并不是很難做到的。

您還需要一個監(jiān)視工具，該工具可以顯示過去幾周甚至幾個月內(nèi)來自服務(wù)器的統(tǒng)計(jì)信息。 如果在服務(wù)器上啟用了更長的數(shù)據(jù)存儲，則可以使用Java監(jiān)視器來執(zhí)行此操作。 要在Java監(jiān)視器中啟用此功能，請首先開始對服務(wù)器使用Java監(jiān)視器 。 在帶有服務(wù)器圖形的頁面上，可以通過切換到“ 1周”或“ 1個月”視圖來啟用更長的數(shù)據(jù)，如下所示。

第一步是查看過去一周中服務(wù)器的數(shù)據(jù)。 為了發(fā)現(xiàn)資源泄漏，我發(fā)現(xiàn)繪制一周的數(shù)據(jù)比查看Java監(jiān)視器標(biāo)準(zhǔn)的兩天的數(shù)據(jù)要好。 峰平滑了，這些圖讓我看看例如內(nèi)存使用隨時(shí)間如何發(fā)展。

為了預(yù)測即將發(fā)生的中斷和緩慢的資源泄漏，我尋找兩種模式。 首先要檢查的模式是，資源使用量不會隨時(shí)間增加，而會隨著每日流量的增加和減少而增加和減少。 當(dāng)一天的流量減少后，我預(yù)計(jì)資源使用量將回落到名義水平。 我檢查資源使用率是否每次都回落到同一水平。

請注意，我故意使用模糊的術(shù)語，例如“資源”。 在實(shí)踐中，我查看所有內(nèi)存，文件描述符以及HTTP連接器和數(shù)據(jù)庫連接池的圖形。 所有這些都是緩慢的資源泄漏的候選者。

當(dāng)我看到資源似乎在增長的時(shí)候，我切換到數(shù)據(jù)的每月視圖，甚至年度視圖。 這將壓縮圖中的數(shù)據(jù)，并使緩慢的資源泄漏更容易發(fā)現(xiàn)。

這是資源使用情況可疑更改的示例。 在這種情況下，系統(tǒng)上的垃圾收集器突然變得更加活躍。 此時(shí)，系統(tǒng)或系統(tǒng)負(fù)載沒有變化。

我要注意的第二種模式是服務(wù)器重啟重啟后資源分配急劇下降。 重新啟動應(yīng)用程序服務(wù)器時(shí)，如果資源使用量顯著下降，則可能表明資源泄漏緩慢。 重新啟動之后，通常會像重新啟動之前那樣降低資源使用量，因?yàn)樗谐睾途彺娑奸_始為空。

這是一個與重啟相關(guān)的資源使用變化的示例，該變化并不表示有問題。 重新啟動后一段時(shí)間（甚至幾天），資源使用情況已更改，但隨后又恢復(fù)到正常水平并停留在該水平。

這是另一個。 甚至更加可疑，因?yàn)橹匦聠雍筚Y源使用率并未恢復(fù)。 它只是掉下來并停留下來。 這幾乎肯定是一個問題。

一旦確定資源使用模式可疑，就必須確認(rèn)這實(shí)際上是一個緩慢的泄漏。 很有可能是緩存或池中填充了更多緩存，從而隨著時(shí)間的推移提高了資源使用率，而沒有實(shí)際的泄漏。 在這一步中，我將遍歷線程和數(shù)據(jù)庫池的圖以及HTTP會話的圖。 我試圖從那里的圖表來解釋提高的資源使用情況。

例如，在這里我們看到JVM中活動的線程，但線程數(shù)量有些奇怪的下降。 這些下降表明系統(tǒng)重新啟動。

但是，如果將該圖與同一臺服務(wù)器上的HTTP連接器池圖進(jìn)行比較，我會發(fā)現(xiàn)HTTP連接器池中預(yù)分配的線程數(shù)同樣會上下波動。

這可能意味著沒有緩慢的資源泄漏。 最有可能的是，池中的額外線程保持狀態(tài)，從而導(dǎo)致其他資源也增加。 我可能會記下具體注意此服務(wù)器的信息，但我還沒有開始深入研究資源泄漏。

只有當(dāng)我無法解釋池中分配的額外資源和活動HTTP會話的數(shù)量時(shí)，我才真正開始挖掘。 如下所述： 如何找到資源泄漏緩慢的根本原因 。

解決緩慢的資源泄漏

我們研究了如何較早發(fā)現(xiàn)緩慢的內(nèi)存泄漏。 在那里，我們看到了如何找到緩慢的資源泄漏，以及如何將其與預(yù)期的池增長行為區(qū)分開。

在這里，我想解釋一下如何確定緩慢的資源泄漏的根本原因，以及最終如何解決它們。 修復(fù)緩慢的資源泄漏幾乎總是需要更改代碼，因此，如果您無法更改代碼，則無法修復(fù)緩慢的資源泄漏。 在這種情況下，您將必須找到可以的人。

確定緩慢的資源泄漏的根本原因的過程類似于發(fā)現(xiàn)快速泄漏的過程。 主要的區(qū)別是時(shí)間對您不利。 對于快速泄漏，您可以輕松地進(jìn)行幾次迭代，而緩慢的泄漏則可能需要數(shù)周或數(shù)月的時(shí)間才能顯現(xiàn)出來。 迭代可能是一年的四分之一。 為了加快泄漏速度，您可以快速更改代碼并“實(shí)時(shí)查看其運(yùn)行狀況”。 對于較慢的泄漏，這僅意味著您將永遠(yuǎn)找不到真正的問題。

要遵循的步驟是：

識別泄漏的資源（完成，是的！）

收集有關(guān)該資源的證據(jù)

撰寫有關(guān)問題所在的論文，看看證據(jù)是否支持您

向您認(rèn)識的人展示您的分析結(jié)果，從而將您的證據(jù)撕成碎片

設(shè)計(jì)并實(shí)施修復(fù)

請注意，我們通常通常只快速地執(zhí)行步驟3，然后將所有精力花在步驟5上，卻發(fā)現(xiàn)真正的問題是其他問題。 我應(yīng)該知道，因?yàn)槲曳稿e的次數(shù)比我愿意承認(rèn)的還要多。

一旦知道泄漏了哪些資源（例如內(nèi)存，文件描述符，CPU周期，線程），便開始收集有關(guān)泄漏的證據(jù)。 該證據(jù)來自多個來源。 如果泄漏的資源僅在您的代碼中很少使用，則應(yīng)用程序源代碼是開始收集的好地方。 如果這是在各處（例如內(nèi)存）使用的東西，那么查看源代碼通常很耗時(shí)，并且效率不高。 因此，這是我要尋找證據(jù)的備忘單：

• 記憶
  --->堆轉(zhuǎn)儲
• 文件描述符
  ---> Java監(jiān)視器的線程池圖以及l(fā)sof或sockstat
• 中央處理器
  --->線程轉(zhuǎn)儲
• 線程數(shù)
  ---> Java監(jiān)視器的線程池圖和線程轉(zhuǎn)儲
• 數(shù)據(jù)庫連接
  --->在JDBC驅(qū)動程序上啟用資源泄漏檢測

收集證據(jù)時(shí)，保持開放的態(tài)度非常重要。 得出關(guān)于正在發(fā)生的事情的結(jié)論是非常誘人的。 相反，只需查看很酷的證據(jù)并消除可能的問題。

至關(guān)重要的一步是向不懼怕挑戰(zhàn)您的人提供您的證據(jù)和思路。 此步驟是為了防止您在分析中犯錯誤，并且必須等待幾周才能發(fā)現(xiàn)自己是錯誤的。 在這個階段，只是點(diǎn)頭和鼓掌的人可能弊大于利，不管這個人的意圖多么好。 找到合適的人，并告訴該人您需要嚴(yán)格的審查。

一旦分析克服了這一挑戰(zhàn)，您就可以最終開始考慮解決方案。 該解決方案需要包括兩個部分：1）它需要以使系統(tǒng)為您提供有關(guān)剛剛發(fā)現(xiàn)的問題的證據(jù)的方式來改進(jìn)日志記錄和監(jiān)視，以及2）它需要實(shí)際解決該問題。

如果您的解決方案不正確，改進(jìn)的日志記錄將為您提供新的新證據(jù)，以供您進(jìn)行第二次（可能是最終的！）迭代。

參考：在Java-Monitor博客上，我們的JCG合作伙伴 Kees Jan Koster處理緩慢的資源泄漏。

翻譯自: https://www.javacodegeeks.com/2013/09/dealing-with-slow-resource-leaks.html

總結(jié)

以上是生活随笔為你收集整理的处理缓慢的资源泄漏的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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