內存泄漏：
簡單粗俗的講，就是該被釋放的對象沒有釋放，一直被某個或某些實例所持有卻不再被使用導致 GC 不能回收。
從基本的來講
Java 內存分配策略
Java 程序運行時的內存分配策略有三種,分別是靜態分配,棧式分配,和堆式分配，對應的，三種存儲策略使用的內存空間主要分別是靜態存儲區（也稱方法區）、棧區和堆區。
- 靜態存儲區（方法區）：主要存放靜態數據、全局 static 數據和常量。這塊內存在程序編譯時就已經分配好，並且在程序整個運行期間都存在。
- 棧區 ：當方法被執行時，方法體內的局部變量都在棧上創建，並在方法執行結束時這些局部變量所持有的內存將會自動被釋放。因爲棧內存分配運算內置於處理器的指令集中，效率很高，但是分配的內存容量有限。
- 堆區 ： 又稱動態內存分配，通常就是指在程序運行時直接 new 出來的內存。這部分內存在不使用時將會由 Java 垃圾回收器來負責回收。
棧與堆的區別：
在方法體內定義的（局部變量）一些基本類型的變量和對象的引用變量都是在方法的棧內存中分配的。當在一段方法塊中定義一個變量時，Java 就會在棧中爲該變量分配內存空間，當超過該變量的作用域後，該變量也就無效了，分配給它的內存空間也將被釋放掉，該內存空間可以被重新使用。
堆內存用來存放所有由 new 創建的對象（包括該對象其中的所有成員變量）和數組。在堆中分配的內存，將由 Java 垃圾回收器來自動管理。在堆中產生了一個數組或者對象後，還可以在棧中定義一個特殊的變量，這個變量的取值等於數組或者對象在堆內存中的首地址，這個特殊的變量就是我們上面說的引用變量。我們可以通過這個引用變量來訪問堆中的對象或者數組。
Java是如何管理內存
Java的內存管理就是對象的分配和釋放問題。在 Java 中，程序員需要通過關鍵字 new 爲每個對象申請內存空間 (基本類型除外)，所有的對象都在堆 (Heap)中分配空間。另外，對象的釋放是由 GC 決定和執行的。在 Java 中，內存的分配是由程序完成的，而內存的釋放是由 GC 完成的，這種收支兩條線的方法確實簡化了程序員的工作。但同時，它也加重了JVM的工作。這也是 Java 程序運行速度較慢的原因之一。因爲，GC 爲了能夠正確釋放對象，GC 必須監控每一個對象的運行狀態，包括對象的申請、引用、被引用、賦值等，GC 都需要進行監控。
監視對象狀態是爲了更加準確地、及時地釋放對象，而釋放對象的根本原則就是該對象不再被引用。
爲了更好理解 GC 的工作原理，我們可以將對象考慮爲有向圖的頂點，將引用關係考慮爲圖的有向邊，有向邊從引用者指向被引對象。另外，每個線程對象可以作爲一個圖的起始頂點，例如大多程序從 main 進程開始執行，那麼該圖就是以 main 進程頂點開始的一棵根樹。在這個有向圖中，根頂點可達的對象都是有效對象，GC將不回收這些對象。如果某個對象 (連通子圖)與這個根頂點不可達(注意，該圖爲有向圖)，那麼我們認爲這個(這些)對象不再被引用，可以被 GC 回收。
Android中常見的內存泄漏彙總
- 集合類泄漏
集合類如果僅僅有添加元素的方法，而沒有相應的刪除機制，導致內存被佔用。如果這個集合類是全局性的變量 (比如類中的靜態屬性，全局性的 map 等即有靜態引用或 final 一直指向它)，那麼沒有相應的刪除機制，很可能導致集合所佔用的內存只增不減。比如上面的典型例子就是其中一種情況，當然實際上我們在項目中肯定不會寫這麼 2B 的代碼，但稍不注意還是很容易出現這種情況，比如我們都喜歡通過 HashMap 做一些緩存之類的事，這種情況就要多留一些心眼。 - 單例造成的內存泄漏
由於單例的靜態特性使得其生命週期跟應用的生命週期一樣長，所以如果使用不恰當的話，很容易造成內存泄漏。比如下面一個典型的例子，
public class AppManager {
private static AppManager instance;
private Context context;
private AppManager(Context context) {
this.context = context;
}
public static AppManager getInstance(Context context) {
if (instance != null) {
instance = new AppManager(context);
}
return instance;
}
}
這是一個普通的單例模式，當創建這個單例的時候，由於需要傳入一個Context，所以這個Context的生命週期的長短至關重要：
1、如果此時傳入的是 Application 的 Context，因爲 Application 的生命週期就是整個應用的生命週期，所以這將沒有任何問題。
2、如果此時傳入的是 Activity 的 Context，當這個 Context 所對應的 Activity 退出時，由於該 Context 的引用被單例對象所持有，其生命週期等於整個應用程序的生命週期，所以當前 Activity 退出時它的內存並不會被回收，這就造成泄漏了。
- 匿名內部類/非靜態內部類和異步線程
- 非靜態內部類創建靜態實例造成的內存泄漏
有的時候我們可能會在啓動頻繁的Activity中，爲了避免重複創建相同的數據資源，可能會出現這種寫法：
public class MainActivity extends AppCompatActivity { - private static TestResource mResource = null;
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_main);
- if(mManager == null){
- mManager = new TestResource();
- }
- //...
- }
- class TestResource {
- //...
- }
- }
- 非靜態內部類創建靜態實例造成的內存泄漏
這樣就在Activity內部創建了一個非靜態內部類的單例，每次啓動Activity時都會使用該單例的數據，這樣雖然避免了資源的重複創建，不過這種寫法卻會造成內存泄漏，因爲非靜態內部類默認會持有外部類的引用，而該非靜態內部類又創建了一個靜態的實例，該實例的生命週期和應用的一樣長，這就導致了該靜態實例一直會持有該Activity的引用，導致Activity的內存資源不能正常回收。正確的做法爲：
- 匿名內部類
android開發經常會繼承實現Activity/Fragment/View，此時如果你使用了匿名類，並被異步線程持有了，那要小心了，如果沒有任何措施這樣一定會導致泄露
public class MainActivity extends Activity { - ...
- Runnable ref1 = new MyRunable();
- Runnable ref2 = new Runnable() {
- @Override
- public void run() {
- }
- };
- ...
- }
ref1和ref2的區別是，ref2使用了匿名內部類。我們來看看運行時這兩個引用的內存：
可以看到，ref1沒什麼特別的。
但ref2這個匿名類的實現對象裏面多了一個引用：
this$0這個引用指向MainActivity.this，也就是說當前的MainActivity實例會被ref2持有，如果將這個引用再傳入一個異步線程，此線程和此Acitivity生命週期不一致的時候，就造成了Activity的泄露。
Handler 造成的內存泄漏Handler 的使用造成的內存泄漏問題應該說是最爲常見了，很多時候我們爲了避免 ANR 而不在主線程進行耗時操作，在處理網絡任務或者封裝一些請求回調等api都藉助Handler來處理，但 Handler 不是萬能的，對於 Handler 的使用代碼編寫一不規範即有可能造成內存泄漏。另外，我們知道 Handler、Message 和 MessageQueue 都是相互關聯在一起的，萬一 Handler 發送的 Message 尚未被處理，則該 Message 及發送它的 Handler 對象將被線程 MessageQueue 一直持有。
由於 Handler 屬於 TLS(Thread Local Storage) 變量, 生命週期和 Activity 是不一致的。因此這種實現方式一般很難保證跟 View 或者 Activity 的生命週期保持一致，故很容易導致無法正確釋放。
前面所說的，創建一個靜態Handler內部類，然後對 Handler 持有的對象使用弱引用，這樣在回收時也可以回收 Handler 持有的對象，但是這樣做雖然避免了 Activity 泄漏，不過 Looper 線程的消息隊列中還是可能會有待處理的消息，所以我們在 Activity 的 Destroy 時或者 Stop 時應該移除消息隊列 MessageQueue 中的消息。
下面幾個方法都可以移除 Message：
public final void removeCallbacks(Runnable r);
public final void removeCallbacks(Runnable r, Object token);
public final void removeCallbacksAndMessages(Object token);
public final void removeMessages(int what);
public final void removeMessages(int what, Object object);
如果成員變量被聲明爲 static，那我們都知道其生命週期將與整個app進程生命週期一樣。
這會導致一系列問題，如果你的app進程設計上是長駐內存的，那即使app切到後臺，這部分內存也不會被釋放。按照現在手機app內存管理機制，佔內存較大的後臺進程將優先回收，yi'wei如果此app做過進程互保保活，那會造成app在後臺頻繁重啓。當手機安裝了你參與開發的app以後一夜時間手機被消耗空了電量、流量，你的app不得不被用戶卸載或者靜默。
總結
- 對 Activity 等組件的引用應該控制在 Activity 的生命週期之內； 如果不能就考慮使用 getApplicationContext 或者 getApplication，以避免 Activity 被外部長生命週期的對象引用而泄露。
- 儘量不要在靜態變量或者靜態內部類中使用非靜態外部成員變量（包括context )，即使要使用，也要考慮適時把外部成員變量置空；也可以在內部類中使用弱引用來引用外部類的變量。
- 對於生命週期比Activity長的內部類對象，並且內部類中使用了外部類的成員變量，可以這樣做避免內存泄漏：
- 將內部類改爲靜態內部類
- 靜態內部類中使用弱引用來引用外部類的成員變量
- Handler 的持有的引用對象最好使用弱引用，資源釋放時也可以清空 Handler 裏面的消息。比如在 Activity onStop 或者 onDestroy 的時候，取消掉該 Handler 對象的 Message和 Runnable.
- 在 Java 的實現過程中，也要考慮其對象釋放，最好的方法是在不使用某對象時，顯式地將此對象賦值爲 null，比如使用完Bitmap 後先調用 recycle()，再賦爲null,清空對圖片等資源有直接引用或者間接引用的數組（使用 array.clear() ; array = null）等，最好遵循誰創建誰釋放的原則。
- 正確關閉資源，對於使用了BraodcastReceiver，ContentObserver，File，遊標 Cursor，Stream，Bitmap等資源的使用，應該在Activity銷燬時及時關閉或者註銷。
- 保持對對象生命週期的敏感，特別注意單例、靜態對象、全局性集合等的生命週期。