用MAT分析OOM
很多OOM看似發生在bitmap 分配得時候，但它一般不是rootcause。根本原因都在於本應該自動釋放的資源，因爲代碼的錯誤，而導致某些對象一直被引用（Reference），例如 Android 內存優化，如何避免OOM 文章中提到的Activity 的mContext 引用。
當代碼量很龐大的時候，單靠讀代碼查找錯誤是很困難的，所以必須藉助於工具，這裏介紹一款很好用的分析工具MAT。
1、下載MAT
http://www.eclipse.org/mat/downloads.php
一般我們的開發環境都選擇了Eclipse，所以直接安裝插件版的就可以了。
2、使用方法，可以看這篇博文：
http://www.cnblogs.com/Android-and-android/archive/2013/03/05/2943863.html
3、重點理解 Retained Heap、GC Root
http://blog.csdn.net/hhww0101/article/details/8133219
4、如何定位
首 先要知道復現OOM的操作步驟，如果是隨機測試出的，也需要找到一個有效的復現步驟才行。然後分別取操作前的 .hprof，和操作後，內存增長後的 .hprof。如果內存不斷增長，可取3，4次。然後分別打開 直方圖（Histogram）視圖，在對象列表中，對比每個對象的 Retained size的變化。
排在第一位的不一定是泄露對象，有可能它本身正常情況就很消耗內存。
泄露的對象是那個突然排名上升的。區分方法是看每個對象的內存地址，地址相同的是同一對象（前提是進程一直運行，沒有重啓過，重啓後內存地址就都變了）。
出 現懷疑對象後，右鍵 List Objects > with incoming references，可以排除WeakReference 等引用，順着樹節點向下找，如果出現程序中的 Activity，或者某個全局對象，基本就可以確定是它沒釋放造成的。要更深一步分析爲什麼沒釋放，如果邏輯複雜，難於捋清，可以直接做 workaround，想辦法釋放這個對象就可以了 (set object = null)。
java靜態代碼分析工具
寫代碼過程中難免會有疏漏，我們也可以藉助工具分析，這裏是常用的java靜態代碼分析工具：
http://www.oschina.net/question/129540_23043
個人覺得Find Bugs 和 PMD就可以了，只是輔助，不必過分依賴，他並不是萬能的，不是所有錯誤都能找出來。
歡迎轉載：http://www.yinqisen.cn/blog-315.html