https://blog.csdn.net/fishinhouse/article/details/80781673

• jps -l
  • 檢視虛擬機器屬於哪個程序
• jstat -gcutil 20954 1000
  • 每1000毫秒查詢一次，一直查。
  • gcutil的意思是已使用空間站總空間的百分比。
  • 
  • 查詢結果表明：這臺伺服器的
    • 新生代Eden區（E，表示Eden）使用了28.30%（最後）的空間，
    • 兩個Survivor區（S0、S1，表示Survivor0、Survivor1）分別是0和8.93%，
    • 老年代（O，表示Old）使用了87.33%。
      • 程式執行以來共發生Minor GC（YGC，表示Young GC）101次，總耗時1.961秒，
      • 發生Full GC（FGC，表示Full GC）7次，Full GC總耗時3.022秒，
      • 總的耗時（GCT，表示GC Time）為4.983秒。
• jmap -histo:live 20954
  • live 是可選引數，代表存活的物件
  • 
  • 紅線部分：
    • 可以看出HashTable中的元素有5000多萬，佔用記憶體大約1.5G的樣子。這肯定不正常。

• MAT 分析工具

  • 補充jmap線上分析

    • jmap比較籠統，明顯的問題能檢查出來

  • 修改MAT配置

    • MemoryAnalyzer.ini檔案
    • Xmx引數，該引數表示最大記憶體佔用量，預設為1024m
  • 從jmap獲取 .hprof 檔案
    • jmap -dump:format=b,file=<dumpfile.hprof> <pid>
  • 選擇Leak Suspects Report, Finish就可以進入MAT分析頁面的首頁
    • 
  • 在首頁上比較有用的是Histogram和Leak Suspects
    • 
  • 點選Leak Suspects會在堆轉儲檔案同目錄內生成一個Leak Suspects.zip檔案，
    • 同時也會從首頁跳轉到Leak Suspects頁面
    • 
  • 解壓該檔案後可以通過瀏覽器開啟分析結果
    • 
  • Leak Suspects頁面
    • 
    • 從中找你熟悉的程式碼
    • 
  • 點選Details進入詳情頁面
    • Shortest Paths To the Accumulation Point表示GC root到記憶體消耗聚集點的最短路徑
      • 
    • All Accumulated Objects by Class列舉了該物件所儲存的所有內容
      • 
    • 為了找到記憶體洩露，我獲取了兩個堆轉儲檔案，兩個檔案獲取時間間隔是一天
      • 對比兩個檔案的物件，通過對比後的結果可以很方便定位記憶體洩露。
      • MAT同時開啟兩個堆轉儲檔案，分別開啟Histogram
      • 在下圖中方框1按鈕用於對比兩個Histogram，對比後在方框2處選擇Group By package，然後對比各物件的變化
      • 
      • -64的意思是，倆檔案中該物件比對，前者比後者少了64個
      • 我記憶體洩露位置是一個list，這個list只在這裡一直不停的往裡新增eventInfo物件，卻沒有釋放過。
  相關推薦

  Netty堆外記憶體洩露排查與總結

  導讀 Netty 是一個非同步事件驅動的網路通訊層框架，用於快速開發高可用高效能的服務端網路框架與客戶端程式，它極大地簡化了 TCP 和 UDP 套接字伺服器等網路程式設計。 Netty 底層基於 JDK 的 NIO，我們為什麼不直接基於 JDK 的 NIO 或者其他NIO框架： 使用 JDK 自

  記一次尷尬的Java應用記憶體洩露排查

  這星期被線上JVM記憶體佔用不斷增大的問題所困擾,自己提出了一些假設,然後去實施驗證都一一失敗了,有一些經驗和教訓在這裡分享下. 之所以是尷尬,是最後因為偶爾出現修復了另一個問題導致記憶體不再上升,但這之間的關係還未明瞭,還需要繼續追蹤. 這裡講述一下這次排查的過程. 直接記憶體的錯誤判斷 伺服器的JVM配

  一次記憶體洩露排查

  018-04-20 11:36:01:ERROR http-bio-8888-exec-8 cn.shibei.feixia.handler.ControllerExceptionHandler.handledException(ControllerExceptionHan

  疑案追蹤：Spring Boot記憶體洩露排查記

  在專案遷移到Spring Boot之後，發生記憶體使用量過高的問題。本文介紹了整個排查過程以及使用到的工具，也非常適用於其他堆外記憶體排查。 背景 為了更好地實現對專案的管理，我們將組內一個專案遷移到MDP框架（基於Spring Boot），隨後我們就發現系統會頻繁報出Swap

  JS記憶體洩露排查方法

  1、使用工具Heap Profiling①、Heap Profiling可以記錄當前的堆記憶體（heap）的快照，並生成物件的描述檔案，該描述檔案給出了當時JS執行所用的所有物件，以及這些物件所佔用的記憶體大小、引用的層級關係等等。②、JS執行的時候，會有棧記憶體（stack

  記憶體洩露排查

  https://blog.csdn.net/fishinhouse/article/details/80781673 jp

  排查Java 記憶體洩露-藉助排查工具

  轉自：https://juejin.im/entry/57fb07255bbb50005b2f20ac java記憶體洩露典型特徵 現象一: 堆/Perm 區不斷增長, 沒有下降趨勢(回收速度趕不上增長速度), 最後不斷觸發FullGC, 甚至crash(如下**兩張圖是同一

  通過windbg排查程式記憶體洩露

  1.設定windbg工具記憶體跟蹤gflags  -i memtest.exe +ust 2.執行一段時間通過偵錯程式windbg attach中斷 輸入命令 !heap -s輸出類似： 0:001> !heap -s 3.過段時間再次中斷輸入!heap -s,檢視

  一次關於Netty+Gson造成記憶體洩露的分析排查

  最近做了一個內部系統之間的資料同步伺服器，client端通過socket傳送經過壓縮的json資料到server端，server完成資料解碼和儲存。server架構：netty+Gson解碼 在做壓力測試的時候，竟然發現server記憶體洩露。分析記憶體洩露的時候，其實我

  循序漸進學用MAT排查Android Activity記憶體洩露

  一、先磨刀再砍柴，記憶體洩露相關介紹   我們先來簡單重溫一下Java GC 的概念：GC即為Garbage Collection，垃圾回收機制。Java GC實質上也就是一個執行在Java虛擬機器（JVM）上的一個程式，它自動地管理著記憶體的使用，在適當的時

  使用ReferenceQueue實現對ClassLoader垃圾回收過程的觀察、以及由此引發的ClassLoader記憶體洩露的場景及排查過程

  1 使用Reference/ReferenceQueue觀察Class和ClassLoader的解除安裝在java中，存在著強引用(=)，軟引用(SoftReference)，弱引用(WeakReference)，虛引用(PhantomReference)這4種引用型別。如果

  記憶體洩露從入門到精通三部曲之排查方法篇

  一、最原始的記憶體洩露測試 重複多次操作關鍵的可疑的路徑，從記憶體監控工具中觀察記憶體曲線，是否存在不斷上升的趨勢且不會在程式返回時明顯回落。 這種方式可以發現最基本，也是最明顯的記憶體洩露問題，對使用者價值最大，操作難度小，價效比極高。 二、MAT記憶體分析工具 2.1

  hadoop1.0 TaskTracker因為分散式快取導致記憶體洩露的一次問題排查

         上週五同事到公司說凌晨的時候有值班同事打電話給他，有部分job卡住了，運行了很長時間都沒執行完成，由於是凌晨，他沒來得及詳細的檢視日誌，簡單的把有問題的tasktracker重啟了一下，只有一個節點的TaskTracker程序停掉，讓我查一下具體是什麼問題。以

  JVM 常見線上問題 → CPU 100%、記憶體洩露 問題排查

  開心一刻 明明是個小 bug，但就是死活修不好，我特麼心態崩了...... 前言 　　後文會從 Windows、Linux 兩個系統來做示例展示，有人會有疑問了：為什麼要說 Windows 版的 ？ 目前市面上還是有很多 Windows 伺服器的，應用於傳統行業、政府結構、醫療行業 等等

  tsync堆外記憶體溢位排查經過

  一、發生得問題 tsync服務總是莫名得宕機，java程序被莫名其妙的消失了。 二、查詢問題 當時看了系統日誌： sudo -u admin dmesg|grep -A20 kill screenshot 發現是oom了，記憶體不足被系統kill掉了。 當時懷疑有可能是堆內記憶體溢位，

  jQuery清空標籤內容--防止記憶體洩露

  　　寫jQuery程式碼是，經常會做清空一個標籤內容的操作。那麼你是怎麼做的呢？比如 <div id="box"> <p>星期一</p> <p>星期二</p> <p>星期三</p> &l

  9、【C++】記憶體洩露

  記憶體洩露 1、記憶體洩露的定義     一般我們常說的記憶體洩漏是指堆記憶體的洩漏。堆記憶體是指程式從堆中分配的，大小任意的（記憶體塊的大小可以在程式執行期決定），使用完後必須顯示釋放的記憶體。     應用程式一般使用malloc，realloc，new等函式從堆中分配到一塊

  Android記憶體洩露分析

  一，記憶體洩露 記憶體洩露：一個不在被使用的物件被另一個存活著的物件引用，在這種情況下垃圾回收器會跳過他，因為這種引用關係足以讓該物件駐留在記憶體中，記憶體洩露是在組織垃圾回收器為未來的記憶體分配提供空間，這些洩露的物件一直佔據著記憶體，導致我們的堆記憶體空間變得更小。也加劇了垃圾回

  使用 GC、Objgraph 幹掉 Python 記憶體洩露與迴圈引用

  Python使用引用計數和垃圾回收來做記憶體管理，前面也寫過一遍文章《Python記憶體優化》，介紹了在python中，如何profile記憶體使用情況，並做出相應的優化。本文介紹兩個更致命的問題：記憶體洩露與迴圈引用。記憶體洩露是讓所有程式設計師都聞風喪膽的問題，輕則導致程式執行速度減慢，重則導致

  Android開發：詳解Handler的記憶體洩露

  原文:https://blog.csdn.net/carson_ho/article/details/52693211 前言 記憶體洩露在Android開發中非常常見 記憶體洩露的定義：本該被回收的物件不能被回收而停留在堆記憶體中