之所以撰寫這篇文章是因為前段時間花費了很大的精力在已經成熟的**上再去處理memory leak問題。寫此的目的是希望我們應該養成良好的編碼習慣，盡可能的避免這樣的問題，因為當你對著一大片的**再去處理此類的問題，此時無疑增加了解決的成本和難度。準確的說屬於補救措施了。
指由於疏忽或錯誤造成程式未能釋放已經不再使用的記憶體的情況。記憶體洩漏並非指內存在物理上的消失，而是應用程式
分配某段記憶體後，由於設計錯誤，失去了對該段記憶體的控制，因而造成了記憶體的浪費。
堆記憶體洩漏（heap leak）。對記憶體指的是程式執行中根據需要分配通過malloc,realloc new等從堆中分配的一塊記憶體，再是完成後必須通過呼叫對應的 free或者delete 刪掉。如果程式的設計的錯誤導致這部分記憶體沒有被釋放，那麼此後這塊記憶體將不會被使用，就會產生heap leak.
系統資源洩露（resource leak）.主要指程式使用系統分配的資源比如 bitmap,handle ,socket等沒有使用相應的函式釋放掉，導致系統資源的浪費，嚴重可導致系統效能降低，系統執行不穩定。
記憶體洩露的問題其困難在於1.編譯器不能發現這些問題。2.執行時才能捕獲到這些錯誤，這些錯誤沒有明顯的症狀，時隱時現。3.對於手機等終端開發使用者來說，尤為困難。下面從三個方面來解決記憶體洩露：
第一，良好的編碼習慣，盡量在涉及記憶體的程式段，檢測出記憶體洩露。當程式穩定之後，在來檢測記憶體洩露時，無疑增加了排除的困難和複雜度。
使用了記憶體分配的函式，要記得要使用其想用的函式釋放掉，一旦使用完畢。
heap memory：
malloc\realloc ------ free
new \new ---------- delete \delete
globalalloc------------globalfree
要特別注意陣列物件的記憶體洩漏
mypointex *pointarray =new mypointex [100];
其刪除形式為：
delete pointarray
resource leak :對於系統資源使用之前要仔細看起使用方法，防止錯誤使用或者忘記釋放掉系統資源。
所謂記憶體溢位就是你要求分配的記憶體超出了系統能給你的，系統不能滿足需求，於是會產生記憶體溢位的問題。
常見的溢位主要有：
記憶體分配未成功，卻使用了它。常用解決辦法是，在使用記憶體之前檢查指標是否為null。如果指標p 是函式的引數，那麼在函式的入口處用assert(p!=null)進行檢查。如果是用malloc 或new 來申請記憶體，應該用if(p==null)或if(p!=null)進行防錯處理。
記憶體分配雖然成功，但是尚未初始化就引用它。記憶體分配成功並且已經初始化，但操作越過了記憶體的邊界。
例如在使用陣列時經常發生下標「多1」或者「少1」的操作。特別是在for 迴圈語句中，迴圈次數很容易搞錯，導致陣列操作越界。
使用free 或delete 釋放了記憶體後，沒有將指標設定為null。導致產生「野指標」。
程式中的物件呼叫關係過於複雜，實在難以搞清楚某個物件究竟是否已經釋放了記憶體，此時應該重新設計資料結構，從根本上解決物件管理的混亂局面。（這點可是深有感受，呵呵）
不要忘記為陣列和動態記憶體賦初值。防止將未被初始化的記憶體作為右值使用。
記憶體洩漏的常見原因和解決方法
1.記憶體中載入的資料量過於龐大，如一次從資料庫取出過多資料 2.集合類中有對物件的引用，使用完後未清空，使得jvm不能 3.中存在死迴圈或迴圈產生過多重複的物件實體 4.使用的第三方軟體中的bug 5.啟動引數記憶體值設定的過小 解決方案 第一步，修改jvm啟動引數，直接增加記憶體。xms，xmx...
WebView記憶體洩漏解決方法
webview記憶體洩漏解決方法前言 在專案的開發過程中，由於對記憶體要求較高，最近對應用的記憶體分析比較在意，前段時間監控記憶體，對bitmap造成的記憶體洩漏進行了分析，並解決了問題。但是在記憶體洩漏之後，發現在訪問網頁的時候，webview竟然也會有記憶體洩漏，雖然記憶體占用很小，但是使用者多...
Handler引起的記憶體洩漏及解決方法
在進行非同步操作時，我們經常會使用到handler類。常見的寫法如下。public class mainactivity extends activity 當使用內部類或匿名內部類的方式建立handler時，handler物件會隱式地持有乙個外部類物件的引用 這裡的外部類是activity 一般在乙...