本文介紹了Java Heap dump：如何通過(guò)1.io.netty.Buffer.ByteBufUtil 2.byte[]數(shù)組查找占用內(nèi)存的對(duì)象/類的處理方法，對(duì)大家解決問(wèn)題具有一定的參考價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)吧！
問(wèn)題描述
我發(fā)現(xiàn)我的一個(gè)Spring Boot項(xiàng)目的內(nèi)存(RAM消耗)每天都在增加。當(dāng)我將JAR文件上傳到AWS服務(wù)器時(shí)，它占用了582MB的RAM(最大分配的RAM是1500MB)，但是每天的RAM都在增加50MB到100MB，5天后的今天，它占用了835MB。目前項(xiàng)目用戶規(guī)模為100-150人，睡覺(jué)API使用正常。
由于RAM的增加，應(yīng)用程序多次關(guān)閉，并出現(xiàn)以下錯(cuò)誤(從日志中發(fā)現(xiàn)錯(cuò)誤)：
Exception in thread "http-nio-3384-ClientPoller" java.lang.OutOfMemoryError: Java heap space
因此，為了解決這個(gè)問(wèn)題，我發(fā)現(xiàn)通過(guò)使用Java Heap轉(zhuǎn)儲(chǔ)，我可以找到占用內(nèi)存的對(duì)象/類。因此，通過(guò)在命令行中使用Jmap，我已經(jīng)創(chuàng)建了一個(gè)堆轉(zhuǎn)儲(chǔ)，并將其上傳到Heap Hero和Eclipse Memory Analyzer Tool。在這兩個(gè)文件中，我發(fā)現(xiàn)了以下內(nèi)容：
1.總浪費(fèi)內(nèi)存為：64.69MB(73%)(查看下面的截圖)
2。其中34.06MB被Byte [] array和LinkedHashmap[]占用(請(qǐng)查看下面的截圖)，這是我在整個(gè)項(xiàng)目中從未使用過(guò)的。我在我的項(xiàng)目中搜索了它，但沒(méi)有找到。
3。以下兩個(gè)大對(duì)象分別占用32MB和20MB。
1. Java Static io.netty.buffer.ByteBufUtil.DEFAULT_ALLOCATOR
2. Java Static com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.connectionFinalizerPhantomRefs`
所以我試圖找到這個(gè)netty.buffer。在我的項(xiàng)目中，但我找不到任何與netty或Buffer匹配的內(nèi)容。
現(xiàn)在我的問(wèn)題是如何減少此內(nèi)存泄漏或如何找到確切的內(nèi)存消耗對(duì)象/類/變量以便減小堆大小。
我知道很少有專家會(huì)要求提供源代碼或類似的東西，但我相信從堆轉(zhuǎn)儲(chǔ)中可以找到內(nèi)存中可用的內(nèi)存泄漏或活動(dòng)對(duì)象。我正在尋找該選項(xiàng)或任何可以減少此堆轉(zhuǎn)儲(chǔ)的選項(xiàng)！
我在過(guò)去的3周里一直在處理這個(gè)問(wèn)題。任何幫助都將不勝感激。
謝謝！
推薦答案
首先啟用JVM native memory tracker，通過(guò)添加標(biāo)志-XX:NativeMemoryTracking=summary了解內(nèi)存的哪個(gè)部分在增加。根據(jù)文檔，存在一些性能開銷(5-10%)，但如果這不是問(wèn)題，我建議即使在生產(chǎn)中也啟用此標(biāo)志來(lái)運(yùn)行JVM。
然后您可以使用jcmd <PID> VM.native_memory檢查這些值(此答案中有一個(gè)很好的記錄：Java native memory usage)
如果確實(shí)分配了很大的本機(jī)內(nèi)存塊，則很可能是由Netty分配的。
您如何在AWS中運(yùn)行您的應(yīng)用程序？如果它在Docker映像中運(yùn)行，您可能會(huì)遇到這個(gè)問(wèn)題：What would cause a java process to greatly exceed the Xmx or Xss limit?
在這種情況下，如果您的應(yīng)用程序使用本機(jī)內(nèi)存(Netty就是這樣)并在具有大量?jī)?nèi)核的服務(wù)器上運(yùn)行，則可能需要設(shè)置環(huán)境變量MALLOC_ARENA_MAX。完全有可能的是，JVM為Netty分配了這個(gè)內(nèi)存，但是沒(méi)有看到任何釋放它的理由，因此它看起來(lái)只會(huì)繼續(xù)增長(zhǎng)。
如果您想控制Netty可以分配多少本機(jī)內(nèi)存，您可以為此使用JVM標(biāo)志-XX:MaxDirectMemorySize(我相信默認(rèn)值與Xmx相同)，并在您的應(yīng)用程序不需要那么多內(nèi)存的情況下降低它。
JVM內(nèi)存調(diào)優(yōu)是一個(gè)復(fù)雜的過(guò)程，當(dāng)涉及到本機(jī)內(nèi)存時(shí)，它會(huì)變得更加復(fù)雜-正如鏈接的答案所示，它不像簡(jiǎn)單地設(shè)置Xms和Xmx標(biāo)志并期望不再使用內(nèi)存那么簡(jiǎn)單。
這篇關(guān)于Java Heap dump：如何通過(guò)1.io.netty.Buffer.ByteBufUtil 2.byte[]數(shù)組查找占用內(nèi)存的對(duì)象/類的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，
