原文連結： 連結

背景

     在使用JavaCV做影象處理時，發現程式執行起來之後，處理了百來次的時候，就報了outofmemory的錯誤。因為javacv底層就是呼叫opencv的native方法，判斷是出現了記憶體洩漏問題，可能是呼叫了哪個方法之後沒有正確釋放資源。

1.用jconsole觀察

     首先是需要在測試機器上修改啟動命令，使得能夠支援jconsole遠端連線。

-Dcom.sun.management.jmxremote.port=8999 \  
-Dcom.sun.management.jmxremote.authenticate=false \  
-Dcom.sun
 
.management.jmxremote.ssl=false  

     這樣，啟動本地java安裝目錄bin下的jconsole.exe啟動介面，輸入遠端主機的IP和8999埠，就可以連線上了。

     這個圖是正常的垃圾回收。當時的圖是隻有上升，沒有下降的一個過程，然後到頂點就產生了outofmemory錯誤。

2.排查

     網上查詢了一下記憶體洩漏的分析工具，給eclipse安裝了MAT外掛用於分析檔案。為了生成hprof檔案,在測試機器上多次呼叫方法，直到根據jconsole發現快到頂點了，執行以下命令:

jmap -dump:format=b,file
 
=a.hprof  24957
//後面的24957是程序ID可用下面命令get
ps -ef|grep java
然後找到專案名對應的pid即可

     生成的檔案直接用裝了MAT外掛的eclipse開啟即可：

     可以看到圖中很明顯的第三方庫的類名，就可以判斷可能是在用該類的地方的資源沒釋放，然後對應地查詢。當然MAT和jconsole還有更強大的功能等著大家去使用。
     Objects ： 類的物件的數量，這個物件被建立了多少個
     shallowHeap是指一個物件記憶體的消耗大小，不包含對其他物件的引用。
     Retained Heap ：是shallow Heap的總和，也就是該物件被GC之後所能回收到記憶體的總和。

     該篇部落格中具體介紹了shallowheap和retainedHeap:
http://bjyzxxds.iteye.com/blog/1532937
     這裡說一句題外話，在使用這幾個類的地方，發現用完之後已經呼叫了釋放方法，很是奇怪，也沒頭緒。後面想到跟javacv給的sample code對比一下，發現網上流傳的釋放方法和樣例中的並不一致，也可能是因為使用的版本不同導致的。改成樣例中的方法之後，解決了該問題。得到的教訓是如果第三方庫有示例程式碼，還是得多參考示例程式碼。
     最終再用jconsole連線機器，觀察記憶體回收，就得到了上面那個圖。還有下面這個圖：

     這裡看到使用的回收演算法是新生代是parNew,老年代是CMS。老年代演算法中,CMS算是用的較多的演算法，而新生代演算法中，除了serial收集器，只有parNew能與CMS配合使用。parNew與serial相比，只是多執行緒，沒有其他創新之處。順勢複習了一波垃圾回收演算法，做了下面這樣一個幾種收集演算法對比：
     連結：https://www.processon.com/view/587a409de4b098bf4ca43bf7