內存泄露排查

http://www.javashuo.com/article/p-nthaviyi-mu.html

• 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對象，卻沒有釋放過。