Java是垃圾回收語言的一種，開發者無需特意管理內存分配。但是JAVA中還是存在着許多內存泄露的可能性，如果不好好處理內存泄露，會導致APP內存單元無法釋放被浪費掉，最終導致內存全部佔據堆棧(heap)擠爆進而程序崩潰。
內存泄露
說到內存泄露，就不得不提到內存溢出，這兩個比較容易混淆的概念，我們來分析一下。
-
內存泄露：程序在向系統申請分配內存空間後(new)，在使用完畢後未釋放。結果導致一直佔據該內存單元，我們和程序都無法再使用該內存單元，直到程序結束，這是內存泄露。
-
內存溢出：程序向系統申請的內存空間超出了系統能給的。比如內存只能分配一個int類型，我卻要塞給他一個long類型，系統就出現oom。又比如一車最多能坐5個人，你卻非要塞下10個，車就擠爆了。
大量的內存泄露會導致內存溢出(oom)。
內存
想要了解內存泄露，對內存的瞭解必不可少。
JAVA是在JVM所虛擬出的內存環境中運行的，JVM的內存可分爲三個區：堆(heap)、棧(stack)和方法區(method)。
-
棧(stack)：是簡單的數據結構，但在計算機中使用廣泛。棧最顯著的特徵是：LIFO(Last In, First Out, 後進先出)。比如我們往箱子裏面放衣服，先放入的在最下方，只有拿出後來放入的才能拿到下方的衣服。棧中只存放基本類型和對象的引用(不是對象)。
-
堆(heap)：堆內存用於存放由new創建的對象和數組。在堆中分配的內存，由java虛擬機自動垃圾回收器來管理。JVM只有一個堆區(heap)被所有線程共享，堆中不存放基本類型和對象引用，只存放對象本身。
-
方法區(method)：又叫靜態區，跟堆一樣，被所有的線程共享。方法區包含所有的class和static變量。
內存的概念大概理解清楚後，要考慮的問題來了：
到底是哪裏的內存會讓我們造成內存泄露？
內存泄露原因分析
在JAVA中JVM的棧記錄了方法的調用，每個線程擁有一個棧。在線程的運行過程當中，執行到一個新的方法調用，就在棧中增加一個內存單元，即幀(frame)。在frame中，保存有該方法調用的參數、局部變量和返回地址。然而JAVA中的局部變量只能是基本類型變量(int)，或者對象的引用。所以在棧中只存放基本類型變量和對象的引用。引用的對象保存在堆中。
當某方法運行結束時，該方法對應的frame將會從棧中刪除，frame中所有局部變量和參數所佔有的空間也隨之釋放。線程回到原方法繼續執行，當所有的棧都清空的時候，程序也就隨之運行結束。
而對於堆內存，堆存放着普通變量。在JAVA中堆內存不會隨着方法的結束而清空，所以在方法中定義了局部變量，在方法結束後變量依然存活在堆中。
綜上所述，棧(stack)可以自行清除不用的內存空間。但是如果我們不停的創建新對象，堆(heap)的內存空間就會被消耗盡。所以JAVA引入了垃圾回收(garbage collection，簡稱GC)去處理堆內存的回收，但如果對象一直被引用無法被回收，造成內存的浪費，無法再被使用。所以對象無法被GC回收就是造成內存泄露的原因！
垃圾回收機制
垃圾回收(garbage collection，簡稱GC)可以自動清空堆中不再使用的對象。在JAVA中對象是通過引用使用的。如果再沒有引用指向該對象，那麼該對象就無從處理或調用該對象，這樣的對象稱爲不可到達（unreachable）。垃圾回收用於釋放不可到達的對象所佔據的內存。
實現思想：我們將棧定義爲root，遍歷棧中所有的對象的引用，再遍歷一遍堆中的對象。因爲棧中的對象的引用執行完畢就刪除，所以我們就可以通過棧中的對象的引用，查找到堆中沒有被指向的對象，這些對象即爲不可到達對象，對其進行垃圾回收。
如果持有對象的強引用，垃圾回收器是無法在內存中回收這個對象。
引用類型
在JDK 1.2以前的版本中，若一個對象不被任何變量引用，那麼程序就無法再使用這個對象。也就是說，只有對象處於可觸及(reachable)狀態，程序才能使用它。從JDK 1.2版本開始，把對象的引用分爲4種級別，從而使程序能更加靈活地控制對象的生命週期。這4種級別由高到低依次爲：強引用、軟引用、弱引用和虛引用。
Java/Android引用類型及其使用分析
1. 強引用(Strong reference)
實際編碼中最常見的一種引用類型。常見形式如：A a = new A();等。強引用本身存儲在棧內存中，其存儲指向對內存中對象的地址。一般情況下，當對內存中的對象不再有任何強引用指向它時，垃圾回收機器開始考慮可能要對此內存進行的垃圾回收。如當進行編碼：a = null，此時，剛剛在堆中分配地址並新建的a對象沒有其他的任何引用，當系統進行垃圾回收時，堆內存將被垃圾回收。
2. 軟引用(Soft Reference)
軟引用的一般使用形式如下：
A a = new A();
SoftReference<A> srA = new SoftReference<A>(a);
軟引用所指示的對象進行垃圾回收需要滿足如下兩個條件：
1.當其指示的對象沒有任何強引用對象指向它；
2.當虛擬機內存不足時。
因此，SoftReference變相的延長了其指示對象佔據堆內存的時間，直到虛擬機內存不足時垃圾回收器纔回收此堆內存空間。
3. 弱引用(Weak Reference)
同樣的，軟引用的一般使用形式如下：
A a = new A();
WeakReference<A> wrA = new WeakReference<A>(a);
WeakReference不改變原有強引用對象的垃圾回收時機，一旦其指示對象沒有任何強引用對象時，此對象即進入正常的垃圾回收流程。
4. 虛引用(Phantom Reference)
與SoftReference或WeakReference相比，PhantomReference主要差別體現在如下幾點：
1.PhantomReference只有一個構造函數
PhantomReference(T referent, ReferenceQueue<? super T> q)
2.不管有無強引用指向PhantomReference的指示對象，PhantomReference的get()方法返回結果都是null。
因此，PhantomReference使用必須結合ReferenceQueue；
與WeakReference相同，PhantomReference並不會改變其指示對象的垃圾回收時機。
內存泄露原因
如果持有對象的強引用，垃圾回收器是無法在內存中回收這個對象。
內存泄露的真因是：持有對象的強引用，且沒有及時釋放，進而造成內存單元一直被佔用，浪費空間，甚至可能造成內存溢出！
其實在Android中會造成內存泄露的情景無外乎兩種：
- 全局進程(process-global)的static變量。這個無視應用的狀態，持有Activity的強引用的怪物。
- 活在Activity生命週期之外的線程。沒有清空對Activity的強引用。
檢查一下你的項目中是否有以下幾種情況：
- Static Activities
- Static Views
- Inner Classes
- Anonymous Classes
- Handler
- Threads
- TimerTask
- Sensor Manager
詳解見該文章《Android內存泄漏的八種可能》
最後推薦一個可檢測app內存泄露的項目：LeakCanary（可以檢測app的內存泄露）
總結
雖然現在手機內存在不停的提升，內存泄露興許不會像dalvik時代由於虛擬機內存過小造成各種花樣oom。但是過量的內存泄露依然會造成內存溢出，影響用戶體驗，在如今定製系統層出不窮、機型花樣越來越多的情況下解決好內存泄露的問題會讓適配和穩定性進一步提高！
原文鏈接：http://www.jianshu.com/p/bf159a9c391a
著作權歸作者所有，轉載請聯繫作者獲得授權，並標註“簡書作者”。