1.Java記憶體分配策略

2.堆與堆疊的區別

3.Java管理記憶體的機制

4.Java中的記憶體泄露

5.Android中常見的記憶體泄露

6.Android中記憶體泄露的排查與分析

7.總結

1.Java記憶體分配策略

Java程式運行時的記憶體分配策略有三種：靜態分配、堆疊式分配和堆式分配，對應的存盤區域如下：

靜態存盤區(方法區)：主要存放靜態資料、全域static資料和常量，這塊記憶體在程式編譯時就已經分配好，并且在程式整個運行期間都存在，
堆疊區：方法體內的區域變數都在堆疊上創建，并在方法執行結束時這些區域變數所持有的記憶體都會自動被釋放，
堆區：又稱動態記憶體分配，通常就是指在程式運行時直接new出來的記憶體，這部分記憶體在不使用時將會由Java垃圾回收器來負責回收，

2.堆與堆疊的區別

堆疊記憶體：在方法體內定義的區域變數(一些基本型別的變數和物件的參考變數)都是在方法的堆疊記憶體中分配的，當在一段方法塊中定義一個變數時，Java就會在堆疊中為該變數分配記憶體空間，當超過該變數的作用域后，分配給它的記憶體空間將被釋放掉，該記憶體空間可以被重新使用，

堆記憶體：用來存放所有由new創建的物件(包括該物件其中的所有成員變數)和陣列，在堆中分配的記憶體，將由Java垃圾回收器來自動管理，在堆中產生了一個陣列或者物件后，還可以在堆疊中定義一個特殊的變數，這個變數的取值等于陣列或者物件在堆記憶體中的首地址，這個特殊的變數就是我們上面說的參考變數，我們可以通過這個參考變數來訪問堆中的物件或者陣列，

例子：

public class A{
        int a=0;
        B b = new B();
        public void test(){
            int a1 = 1;
            B b1 = new B();
        }
}
A object = new A();

A類內的區域變數都存在堆疊中，包括基本的資料型別a1和參考變數b1，b1指向的B物件物體存于在堆中；
參考變數object存在于堆疊中，而object指向的物件物體存在于堆中，包括這個物件的所有成員變數a和b，而參考變數b指向的B型別物件物體存在于堆中；

3.Java管理記憶體的機制

Java的記憶體管理就是物件的分配和釋放問題，記憶體的分配是由程式員來完成，記憶體的釋放由GC（垃圾回收器）完成，GC為了能夠正確釋放物件，必須監控每一個物件的運行狀態，包括物件申請、參考、被參考、賦值等，這是Java程式運行較慢的原因之一，

釋放物件的原則：該物件不再被參考，

GC的作業用原理：

將物件考慮為有向圖的頂點，將參考關系考慮為有向圖的有向邊，有向邊從參考者指向被引物件，另外，每個執行緒物件可以作為一個圖的起始頂點，例如大多程式從main行程開始執行，那么該圖就是以main行程為頂點開始的一顆根樹，在有向圖中，根頂點可達的物件都是有效物件，GC將不回收這些物件，如果某個物件與這個跟頂點不可達，那么我們認為這個物件不再被參考，可以被GC回收，

下面舉一個例子說明如何用有向圖表示記憶體管理，對于程式的每一個時刻，我們都有一個有向圖表示JVM的記憶體分配情況，以下右圖，就是左右程式運行到第6行的示意圖，

另外：Java使用有向圖的方式進行記憶體管理，可以消除參考回圈的問題，例如有三個物件相互參考，但是只要他們和跟行程不可達，那么GC也是可以回收他們的，當然，除了有向圖的方式，還有一些別的記憶體管理技術，不同記憶體管理技術各有優缺點，這里就不詳細展開了，

4.Java中的記憶體泄露

如果一個物件滿足以下兩個條件：

(1)這些物件是可達的，即在有向圖中，存在通路可以與其相連；

(2)這些物件是無用的，即程式以后不會再使用這些物件；

就可以判斷為Java中的記憶體泄漏，這些物件不會被GC所回收，繼續占用著記憶體，

在C++中，記憶體泄漏的范圍更大一些，有些物件被分配了記憶體空間，然后卻不可達，由于C++中沒有GC，這些記憶體將將永遠收不回來，在Java中，這些不可達的物件都有GC負責回收，因此程式員不需要考慮這部分的記憶體泄漏，

5.Android中常見的記憶體泄露

(1)單例造成的記憶體泄漏

public class MainActivity extends Actvity implements View.OnClickListener{
    @Override
    protected void onCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Bitmap bitmap = ImageUtils.getInstance(this).getBitmap(R.drawable.arrow);
    }
}

public class ImageUtils{
    private static ImageUtils imageUtils;
    private Context context;
    private ImageUtils(Context context){
        this.context = context;
    }
    public static ImageUtils getInstance(Context context){
        if(imageUtils == null){
            imageUtils = new ImageUtils(context);
        }
        return imageUtils;
    }    
}

這是一個普通的單例模式，當創建這個單例的時候，由于需要傳入一個Context，所有這個Context的生命周期的長短至關重要：

1.如果此時傳入的是Application的Context，因為Application的生命周期就是整個應用的生命周期，所以沒有任何問題，

2.如果此時傳入的是Activity的Context，當這個Context所對應Activity退出時，由于該Context的參考被單例物件所參考，其生命周期等于整個應用程式的生命周期，所以當前Activity退出時他的記憶體并不會被回收，他就造成泄露了，

當然，Application的Context不是萬能的，所以不能隨便亂用，例如Dialog必須使用Activity的Context，對于這部分有興趣的讀者可以自行搜索相關資料，

(2)非靜態內部類創建靜態實體造成的記憶體泄漏

public class MainActivity extends AppCompatActivity{
   private static TestResource mResource = null;
   @Override
   protected void onCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
        if(mManager == null){
            mManger = new TestResource();
        }
        //...
   } 
   class TestResource{
       //... 
   }
}

(3)匿名內部類造成的記憶體泄漏

匿名內部類默認也會持有外部類的參考，如果在Activity/Fragment中使用了匿名類，并被異步執行緒持有，如果沒有任何措施這樣一定會導致記憶體泄漏，

public class MainActivity extends AppCompatActivity implements View.OnClickListener{
    private static final String TAG = "MainActivity";
    private Runnable ref1 = new MyRunnable();
    private Runnable ref2 = new MyRunnable(){
        public void run(){}
    };
    public static class MyRunnable extends Thread{
        public void run(){}
    }
    @Override
   protected void onCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
   }
}

ref1和ref2的區別是，ref2使用了匿名內部類，我們來看看運行時這個兩個參考的記憶體：

可以看到，ref1沒有什么特別的，但是ref2這個匿名類的實作物件多了一個參考:

this$0這個參考執行MainActivity.this，也就是說當前的MainActivity實體會被ref2持有，如果將這個參考再傳入一個異步執行緒，此執行緒和此Activity生命周期不一致的時候，就會造成Activity的泄漏，

例子：Handler造成的記憶體泄漏

public class MainActivity extends Activity implements View.OnClickListener{
    private static final String TAG = "MainActivity";
    private final Handler mHandler = new Handler(){
        @Override
        public void handleMessage(Message msg){    
            //...
        }
    }

    @Override 
    protected void onCreate(Bundle savedIntanceState){
        super.onCreate(savedInstanceState);
        setContextView(R.layout.activity_main);
        mHandler.postDelayed(new Runnable(){
            public void run(){}
        }, 1000*60*10L);
    }
}

在該MainActivity中宣告一個延遲10分鐘執行的訊息Message，mHandler將其push進了訊息佇列MessageQueue里，當該Activity被finish()掉時，延遲執行任務的Message還會繼續存在于主執行緒中，它持有該Activity的Handler參考，然后又因為Handler為匿名內部類，它會持有外部類的參考(在這里就是MainActivity)，此時finish()掉Activity就不會被回收了，從而造成記憶體泄漏，

修復方法：在Activity中避免使用非靜態內部類或匿名內部類，比如將Handler宣告為靜態的，則其存活期跟Activity生命周期就無關了，如果需要則用到Activity，就通過弱參考的方式引入Activity，避免直接將Activity作為context傳進去，另外，Looper執行緒的訊息佇列中還是可能會有待處理的訊息，所以我們在Activity的Destroy或者Stop中應該移除訊息佇列MessageQueue中的訊息，見下面代碼：

public class MainActivity extends AppCompatActivity implements View.OnClickListener {

    private StaticHandler staticHandler = new StaticHandler(this);

    private static class StaticHandler extends Handler{

        private WeakReference<MainActivityNew> weakReference;

        public StaticHandler(MainActivityNew activity){
            weakReference = new WeakReference<MainActivityNew>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
//            super.handleMessage(msg);
            MainActivityNew activity = weakReference.get();
            if(activity != null){

            }
        }
    }

    private static class StaticRunnable extends Thread{
        @Override
        public void run() {
//            super.run();
        }
    }



    @Override
    public void onClick(View v) {

    }

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        staticHandler.postDelayed(new StaticRunnable(), 1000*60*10L);
    }

    @Override
    protected void onDestroy() {
        staticHandler.removeCallbacksAndMessages(null);
        super.onDestroy();
    }
}

(4)資源未關閉造成的記憶體泄漏

對于使用BroadcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等資源的使用，應該在Activity銷毀時及時關倍訓者注銷，否則這些資源將不會被回收，造成記憶體泄漏，

(5)一些不良代碼造成的記憶體壓力

有些代碼并不造成記憶體泄漏，但是他們，或者對沒使用的記憶體沒進行有效性的釋放，或者沒有有效利用已有的物件而是頻繁的申請新記憶體，比如：Adapter里沒有復用convertView等，

6.Android中記憶體泄露的排查與分析

(1)利用Android Studio的Memory Monitor來檢測記憶體情況

先來看一下Android Studio的Memory Monitor界面：

最原始的記憶體泄漏排查方式如下：

重復多次操作關鍵的可疑的路徑，從記憶體監測工具中觀察記憶體曲線，看是否存在不斷上升的趨勢，且退出一個界面后，程式記憶體遲遲不降低的話，可能就發生了嚴重的記憶體泄漏，

這種方式可以發現最基本，也是最明顯的記憶體泄漏問題，對用戶價值最大，操作難度小，性價比極高，

下面就開始用一個簡單的例子來說明一下如何排查記憶體泄漏：

首先創建一個TestActivity類，里面的測驗代碼如下：

protected void processBiz(){
    mHandler = new Handler();
    mHandler.postDelayed(new Runnable(){
        public void run(){
            Log.d("MainActivity","----postDelayed-----");
        }
    },800000L);
}

運行專案，并執行以下操作：進入TestActivity，然后退出，再重新進入，如此操作幾次后，最后退出TestActivity，這是發現，記憶體持續增高，如圖所示(不斷打開關閉TestActivity查看Total總記憶體大小會緩慢的增高)：

好了，這時我們可以假設，這里可能出現了記憶體泄漏的情況，那么，如何繼續定位到記憶體泄漏的地方呢？這是就得點擊“Dump Java heap”按鈕來收集具體的資訊了，

(2)使用Android Studio生成Java Heap檔案來分析記憶體情況

注意，再點擊Dump Java heap按鈕之前，一定要先點擊GC按鈕強制GC，建議點擊后等待幾秒后再次點擊，嘗試多次，讓GC更加充分，然后在點擊Dump Java heap按鈕，

這個時候會生成一個Java heap檔案并在新的視窗打開：

舊版可能需要點擊“Analyzer Task”，再點擊出現的綠色按鈕，讓Android Studio幫我們自動分析可能出現的潛在記憶體泄漏的地方，新版本不需要自動幫我們分析了記憶體泄漏(4.1.2)：

如上圖所示，Android Studio提示有四個TestActivity物件可能存在記憶體泄漏，而且下面（Reference Tree）參考樹，也大概列出了該物體類的參考路徑，如果是一些比較簡單的記憶體泄漏情況，僅僅看這里就可以大概能猜到是哪里導致了記憶體泄漏，

(3)使用Memory Analyzer(MAT)來分析記憶體泄漏

MAT是Eclipse出品的一個插件，當然也有獨立的版本，下載鏈接：MAT下載地址

在這里先提醒一下：MAT并不會準確的告訴你我們哪里可能發生記憶體泄漏，而是會提供一大堆的資料和線索，我們需要根據自己的實際的代碼和業務邏輯去分析這些資料，判斷到底是不是真的發生了記憶體泄漏，

MAT支持對標準格式hprof檔案進行記憶體分析，所以，我們要現在Android Studio里先把Java heap檔案轉換成標準格式的hprof檔案，具體步驟如下：

選擇對應Heap Dump檔案，右鍵點擊選擇Export匯出的hprof檔案：

匯出的hprof檔案需要轉換成標準的hprof格式檔案：

hprof-conv.exe memory-20210808T201824.hprof memory.hprof(標準格式的)

運行cmd打開命令列，cd到\ android-sdk-windows\tools所在目錄，并輸入命令hprof-conv xxxxx.hprof yyyyy.hprof，其中xxxxx.hprof為原始檔案，yyyyy.hprof為轉換過后的檔案，轉換過后的檔案自動放在android-sdk-windows\tools 目錄下，

匯出標準的hprof檔案后，在MAT工具里匯入，則看到以下界面：

MAT提供了非常多的功能，這里我們只學習幾個常用的就可以了，上圖那個餅狀圖展示了最大的幾個物件所占記憶體的比例，這張圖中提供的內容并不多，我們可以忽略它，在這個餅狀圖的下方就有幾個非常有用的工具了，

Histogram：直方圖，可以列出記憶體中每個物件的名字、數量以及大小，

Dominator Tree：會將所有記憶體中的物件按照大小進行排序，并且我們可以分析物件之間的參考結構；

(1)Dominator Tree

從上圖可以看到右邊存在3個引數，Retained Heap表示這個物件以及它所持有的其他參考(包括直接和間接)所占的總記憶體，因此從上圖中看，前兩行的Retained Heap是最大的，分析記憶體泄漏時，記憶體最大的物件也是最應該懷疑的，

另外大家應該可以注意到，在每一行的最左邊都有一個檔案型別的圖示，這些圖示有的左下角帶有一個紅色的點，有的則沒有，帶有紅色的物件就表示可以被GC Roots訪問到，可以被GC Roots訪問到的物件都是無法被回收的，那么這就可以說明所有帶紅色的物件都是泄露的物件嗎？當然不是，因為有些物件系統需要一直使用，本來就不應該被回收，

如果發現有的物件右邊有寫著System Class，那么說明這是一個由系統管理的物件，并不是由我們自己創建并導致記憶體泄漏的物件，

根據我們在Android studio的Java heap檔案的提示，TestActivity物件有可能發生了記憶體泄漏，于是我們直接在上面搜TestActivity（這個搜索功能也是很強大的）：

左邊的inspector可以查看物件內部的各種資訊：

當然，如果你覺得按照默認的排序方式來查看不方便，你還可以自行設定排序的方式：

Group by class
Group by class loader
Group by package

從上圖可以看出，我們搜到了4個TestActivity物件，一般退出某個activity后，就結束一個activity的生命周期，應該被GC正常回收才對的，通常情況下，一個activity應該只有1個實體物件，但是現在居然有四個TestActivity物件，說明之前的操作，產生了4個TestActivity物件，并且無法被系統回收掉，

接下來繼續查看參考路徑：

對于TestActivity物件右鍵 -> Merge Shortest Paths to GC Roots（當然，這里也可以選擇Path To GC Roots） -> exclude all phantom/weak/soft etc. references；

為什么選擇exclude all phantom/weak/soft etc. references呢？因為弱參考等是不會阻止物件被垃圾回收器回收的，所以我們這里直接把它排除掉：

接下來就能看到參考路徑關系圖了：

從上圖可以看出，TestActivity是被this$0所參考的，它實際上是匿名類對當前類的參考，this$0又被callback所參考，接著它又被Message中一串的next多參考...，到這里，我們就已經分析出記憶體泄漏的原因了，接下來就是去改善存在問題的代碼了，

(2)Histogram

這里是當前應用程式中所有的物件的名字、數量和大小全部都列出來了，那么Shallow Heap有什么意思呢？就是當前物件自己所占記憶體的大小，不包含參考關系的，

上圖當中，byte[]物件Shallow Heap最高，說明我們應用程式中用了很多byte[]型別的數量，比如說圖片，可以通過右鍵->List objects->with incoming references來查看具體是誰在使用這些byte[].

當然，除了一般的物件，我們還可以專門查看執行緒物件的資訊：

Histogram中可以顯示物件的數量，比如說我們懷疑TestActivity中有可能存在記憶體泄漏，就可以在主執行緒上右鍵->List objects ->with incoming references查看TestActivity實體，如下所示：

接下來對著TestActivity右鍵->List objects ->with incoming references查看具體的TestActivity實體

注釋：

List objects ->with incoming references：表示該物件入接點(被該物件參考的物件)

List objects ->with outgoing references: 表示該物件出接點(參考該物件的物件)

如果想要查看內容記憶體泄漏的具體原因，可以通過任意一個TestActivity的實體右鍵->Merge Shortest Paths to GC Roots(當然，這是也可以選擇Path To GC Roots) ->exclude all phantom/weak/soft etc. references,如下圖所示：