Android內(nèi)存優(yōu)化

Java內(nèi)存模型

運(yùn)行時(shí)數(shù)據(jù)區(qū)分為幾個(gè)部分

image

從上圖可以看到運(yùn)行時(shí)候分為：

• 方法區(qū)
• 堆棧區(qū)
• 虛擬機(jī)Java棧區(qū)
• 虛擬機(jī)Native棧區(qū)
• PC程序計(jì)數(shù)器

方法區(qū)

主要是存儲(chǔ)已被虛擬機(jī)加載的類信息孵滞、常量、靜態(tài)變量卵凑、即時(shí)編譯器編譯后的代碼等數(shù)據(jù)
特征是線程共享，生命周期與虛擬機(jī)相同昙衅，可以不使用連續(xù)的內(nèi)存地址
配置參數(shù)： -XX:PermSize:16M -XX:MaxPermSize: 64M
異常會(huì)報(bào) OutOfMemoryError 錯(cuò)誤

堆棧區(qū)

主要是保存對(duì)象實(shí)例刽肠，所有對(duì)象實(shí)例（包括數(shù)組）都要在堆上分配
特征是線程共享，生命周期與虛擬機(jī)相同算谈，可以不使用連續(xù)的內(nèi)存地址
配置參數(shù)：-Xms -Xsx -Xmn
異常會(huì)報(bào) OutOfMemoryError 錯(cuò)誤

虛擬機(jī)Java棧區(qū)

主要是Java 方法執(zhí)行的內(nèi)存模型嘉冒，存儲(chǔ)局部變量表曹货、操作棧、動(dòng)態(tài)鏈接讳推、方法出口等信息
特征是線程私有顶籽，生命周期與線程相同，使用連續(xù)的內(nèi)存空間
異常會(huì)報(bào) OutOfMemoryError 银觅、StackOverflowError錯(cuò)誤
配置參數(shù)：-Xss

虛擬機(jī)Native棧區(qū)

主要是Native方法執(zhí)行的內(nèi)存模型礼饱，存儲(chǔ)局部變量表、操作棧究驴、動(dòng)態(tài)鏈接镊绪、方法出口等信息
特征是線程私有，生命周期與線程相同纳胧，使用連續(xù)的內(nèi)存空間
異常會(huì)報(bào) OutOfMemoryError 镰吆、StackOverflowError錯(cuò)誤
配置參數(shù)：-Xss

PC程序計(jì)數(shù)器

大致為字節(jié)碼行號(hào)指示器
特征是占用內(nèi)存小，線程私有跑慕，生命周期與線程相同
不會(huì)報(bào)錯(cuò)無(wú)異常

運(yùn)行時(shí)常量池

方法區(qū)的一部分，具有動(dòng)態(tài)性
存放字面量及符號(hào)引用

為什么gc不能回收摧找？

分析完上面的運(yùn)行時(shí)候內(nèi)存情況比較清楚的知道除了PC程序計(jì)數(shù)器其他都會(huì)造成內(nèi)存泄露核行？
這里需要知道gc的回收原理下面一篇文章專門分析gc回收的情況，這里簡(jiǎn)單介紹下
gc回收一般是2種情況回收：
1 引用計(jì)數(shù)
原理:通過(guò)一個(gè)計(jì)數(shù)器對(duì)對(duì)象進(jìn)行計(jì)數(shù),對(duì)象被引用時(shí)+1,引用失效時(shí)-1;當(dāng)計(jì)數(shù)為0時(shí)則說(shuō)明可以被回收;
缺點(diǎn):很難解決對(duì)象的相互循環(huán)引用問(wèn)題
2 可達(dá)性分析算法
Java虛擬機(jī)所采用的算法;
原理:通過(guò)一些列稱為“GC Roots”的對(duì)象作為起始點(diǎn)蹬耘，從這些節(jié)點(diǎn)開始向下搜索芝雪，搜索所走過(guò)的路徑稱為引用鏈，當(dāng)一個(gè)對(duì)象到GC Roots沒(méi)有任何引用鏈相連時(shí)综苔，則證明此對(duì)象是不可用的惩系。
那么哪些對(duì)象可以被稱為gc roots呢----

• 虛擬機(jī)棧(棧中的本地變量列表)
• 方法區(qū)靜態(tài)屬性/方法區(qū)常量引用
• 本地方法棧中JNI 所引用的的對(duì)象(全局對(duì)象)
• 活著的線程
• 正在被用于同步的各種鎖對(duì)象
• 通過(guò)System Class Loader或者Boot Class Loader加載的class對(duì)象，通過(guò)自定義類加載器加載的class不一定是GC Root

這樣就可以解決循環(huán)引用的問(wèn)題

那造成內(nèi)存泄露就是堆棧區(qū)里面有引用上面這些可以到底gc root對(duì)象的地方如筛，我們調(diào)查內(nèi)存泄露只需要切斷到達(dá)gc root的地方則可以避免內(nèi)存泄露

volatile和synchronization

這里需要講一下線程的3特性

• 原子性：就是操作一步完成堡牡，不可中斷（說(shuō)白了就是一條匯編指令搞定）
• 可見性：就是保證它的修改會(huì)立刻刷新到主存，當(dāng)其它線程需要讀取該變量時(shí)杨刨，會(huì)去內(nèi)存中讀取新值晤柄。而普通變量則不能保證這一點(diǎn)。
• 有序性：JMM是允許編譯器和處理器對(duì)指令重排序的妖胀，但是規(guī)定了as-if-serial語(yǔ)義芥颈，即不管怎么重排序惠勒，程序的執(zhí)行結(jié)果不能改變。
  以下出處是： https://juejin.im/post/5a2b53b7f265da432a7b821c 我直接復(fù)制過(guò)來(lái)的爬坑，請(qǐng)注意

JMM具備一些先天的有序性,即不需要通過(guò)任何手段就可以保證的有序性纠屋，通常稱為happens-before原則。<<JSR-133：Java Memory Model and Thread Specification>>定義了如下happens-before規(guī)則：

1. 程序順序規(guī)則： 一個(gè)線程中的每個(gè)操作盾计，happens-before于該線程中的任意后續(xù)操作
2. 監(jiān)視器鎖規(guī)則：對(duì)一個(gè)線程的解鎖售担，happens-before于隨后對(duì)這個(gè)線程的加鎖
3. volatile變量規(guī)則： 對(duì)一個(gè)volatile域的寫，happens-before于后續(xù)對(duì)這個(gè)volatile域的讀
4. 傳遞性：如果A happens-before B ,且 B happens-before C, 那么 A happens-before C
5. start()規(guī)則： 如果線程A執(zhí)行操作ThreadB_start()(啟動(dòng)線程B) , 那么A線程的ThreadB_start()happens-before 于B中的任意操作
6. join()原則： 如果A執(zhí)行ThreadB.join()并且成功返回闯估，那么線程B中的任意操作happens-before于線程A從ThreadB.join()操作成功返回灼舍。
7. interrupt()原則： 對(duì)線程interrupt()方法的調(diào)用先行發(fā)生于被中斷線程代碼檢測(cè)到中斷事件的發(fā)生，可以通過(guò)Thread.interrupted()方法檢測(cè)是否有中斷發(fā)生
8. finalize()原則：一個(gè)對(duì)象的初始化完成先行發(fā)生于它的finalize()方法的開始

第1條規(guī)則程序順序規(guī)則是說(shuō)在一個(gè)線程里涨薪，所有的操作都是按順序的骑素，但是在JMM里其實(shí)只要執(zhí)行結(jié)果一樣，是允許重排序的刚夺，這邊的happens-before強(qiáng)調(diào)的重點(diǎn)也是單線程執(zhí)行結(jié)果的正確性献丑，但是無(wú)法保證多線程也是如此。

第2條規(guī)則監(jiān)視器規(guī)則其實(shí)也好理解侠姑，就是在加鎖之前创橄，確定這個(gè)鎖之前已經(jīng)被釋放了，才能繼續(xù)加鎖莽红。

第3條規(guī)則妥畏，就適用到所討論的volatile，如果一個(gè)線程先去寫一個(gè)變量安吁，另外一個(gè)線程再去讀醉蚁，那么寫入操作一定在讀操作之前。

第4條規(guī)則鬼店，就是happens-before的傳遞性网棍。

volatile 只能保證可見性和有序性， 針對(duì)簡(jiǎn)單賦值等操作可以完成多線程的保證妇智，但是針對(duì)i++ 之類的也不能保證多線程安全需要用synchronization和lock保證

synchronization 可以保證3個(gè)特性滥玷，缺點(diǎn)就是效率比較慢

面試官：volatile關(guān)鍵字如何滿足并發(fā)編程的三大特性的？

那就要重提volatile變量規(guī)則： 對(duì)一個(gè)volatile域的寫巍棱，happens-before于后續(xù)對(duì)這個(gè)volatile域的讀惑畴。 這條再拎出來(lái)說(shuō)，其實(shí)就是如果一個(gè)變量聲明成是volatile的拉盾，那么當(dāng)我讀變量時(shí)桨菜，總是能讀到它的最新值，這里最新值是指不管其它哪個(gè)線程對(duì)該變量做了寫操作，都會(huì)立刻被更新到主存里倒得，我也能從主存里讀到這個(gè)剛寫入的值泻红。也就是說(shuō)volatile關(guān)鍵字可以保證可見性以及有序性。

繼續(xù)拿上面的一段代碼舉例：

int a = 0;
bool flag = false;

public void write() {
   a = 2;              //1
   flag = true;        //2
}

public void multiply() {
   if (flag) {         //3
       int ret = a * a;//4
   }

}
復(fù)制代碼

這段代碼不僅僅受到重排序的困擾霞掺，即使1谊路、2沒(méi)有重排序。3也不會(huì)那么順利的執(zhí)行的菩彬。假設(shè)還是線程1先執(zhí)行write操作缠劝，線程2再執(zhí)行multiply操作，由于線程1是在工作內(nèi)存里把flag賦值為1骗灶，不一定立刻寫回主存惨恭，所以線程2執(zhí)行時(shí)，multiply再?gòu)闹鞔孀xflag值耙旦，仍然可能為false脱羡，那么括號(hào)里的語(yǔ)句將不會(huì)執(zhí)行。

如果改成下面這樣：

int a = 0;
volatile bool flag = false;

public void write() {
   a = 2;              //1
   flag = true;        //2
}

public void multiply() {
   if (flag) {         //3
       int ret = a * a;//4
   }
}
復(fù)制代碼

那么線程1先執(zhí)行write,線程2再執(zhí)行multiply免都。根據(jù)happens-before原則锉罐，這個(gè)過(guò)程會(huì)滿足以下3類規(guī)則：

1. 程序順序規(guī)則：1 happens-before 2; 3 happens-before 4; (volatile限制了指令重排序，所以1 在2 之前執(zhí)行)
2. volatile規(guī)則：2 happens-before 3
3. 傳遞性規(guī)則：1 happens-before 4

從內(nèi)存語(yǔ)義上來(lái)看

當(dāng)寫一個(gè)volatile變量時(shí)绕娘，JMM會(huì)把該線程對(duì)應(yīng)的本地內(nèi)存中的共享變量刷新到主內(nèi)存

當(dāng)讀一個(gè)volatile變量時(shí)脓规，JMM會(huì)把該線程對(duì)應(yīng)的本地內(nèi)存置為無(wú)效，線程接下來(lái)將從主內(nèi)存中讀取共享變量险领。

面試官：volatile的兩點(diǎn)內(nèi)存語(yǔ)義能保證可見性和有序性侨舆，但是能保證原子性嗎？

首先我回答是不能保證原子性绢陌，要是說(shuō)能保證态罪，也只是對(duì)單個(gè)volatile變量的讀/寫具有原子性，但是對(duì)于類似volatile++這樣的復(fù)合操作就無(wú)能為力了下面，比如下面的例子：

public class Test {
    public volatile int inc = 0;

    public void increase() {
        inc++;
    }

    public static void main(String[] args) {
        final Test test = new Test();
        for(int i=0;i<10;i++){
            new Thread(){
                public void run() {
                    for(int j=0;j<1000;j++)
                        test.increase();
                };
            }.start();
        }

        while(Thread.activeCount()>1)  //保證前面的線程都執(zhí)行完
            Thread.yield();
        System.out.println(test.inc);
    }
復(fù)制代碼

按道理來(lái)說(shuō)結(jié)果是10000，但是運(yùn)行下很可能是個(gè)小于10000的值绩聘。有人可能會(huì)說(shuō)volatile不是保證了可見性啊沥割，一個(gè)線程對(duì)inc的修改，另外一個(gè)線程應(yīng)該立刻看到霸淦小机杜！可是這里的操作inc++是個(gè)復(fù)合操作啊，包括讀取inc的值衅谷，對(duì)其自增椒拗，然后再寫回主存。

假設(shè)線程A，讀取了inc的值為10蚀苛，這時(shí)候被阻塞了在验，因?yàn)闆](méi)有對(duì)變量進(jìn)行修改，觸發(fā)不了volatile規(guī)則堵未。

線程B此時(shí)也讀讀inc的值腋舌，主存里inc的值依舊為10，做自增渗蟹，然后立刻就被寫回主存了块饺，為11。

此時(shí)又輪到線程A執(zhí)行雌芽，由于工作內(nèi)存里保存的是10授艰，所以繼續(xù)做自增，再寫回主存世落，11又被寫了一遍淮腾。所以雖然兩個(gè)線程執(zhí)行了兩次increase()，結(jié)果卻只加了一次岛心。

有人說(shuō)来破，volatile不是會(huì)使緩存行無(wú)效的嗎？但是這里線程A讀取到線程B也進(jìn)行操作之前忘古，并沒(méi)有修改inc值徘禁，所以線程B讀取的時(shí)候，還是讀的10髓堪。

又有人說(shuō)送朱，線程B將11寫回主存，不會(huì)把線程A的緩存行設(shè)為無(wú)效嗎干旁？但是線程A的讀取操作已經(jīng)做過(guò)了啊驶沼，只有在做讀取操作時(shí)，發(fā)現(xiàn)自己緩存行無(wú)效争群，才會(huì)去讀主存的值回怜，所以這里線程A只能繼續(xù)做自增了。

綜上所述换薄，在這種復(fù)合操作的情景下玉雾，原子性的功能是維持不了了。但是volatile在上面那種設(shè)置flag值的例子里轻要，由于對(duì)flag的讀/寫操作都是單步的复旬，所以還是能保證原子性的。

要想保證原子性冲泥，只能借助于synchronized,Lock以及并發(fā)包下的atomic的原子操作類了驹碍，即對(duì)基本數(shù)據(jù)類型的 自增（加1操作）壁涎，自減（減1操作）、以及加法操作（加一個(gè)數(shù)）志秃，減法操作（減一個(gè)數(shù)）進(jìn)行了封裝怔球，保證這些操作是原子性操作。

面試官：說(shuō)的還可以洽损，那你知道volatile底層的實(shí)現(xiàn)機(jī)制庞溜？

如果把加入volatile關(guān)鍵字的代碼和未加入volatile關(guān)鍵字的代碼都生成匯編代碼，會(huì)發(fā)現(xiàn)加入volatile關(guān)鍵字的代碼會(huì)多出一個(gè)lock前綴指令碑定。

lock前綴指令實(shí)際相當(dāng)于一個(gè)內(nèi)存屏障流码，內(nèi)存屏障提供了以下功能：

1 . 重排序時(shí)不能把后面的指令重排序到內(nèi)存屏障之前的位置 2 . 使得本CPU的Cache寫入內(nèi)存 3 . 寫入動(dòng)作也會(huì)引起別的CPU或者別的內(nèi)核無(wú)效化其Cache，相當(dāng)于讓新寫入的值對(duì)別的線程可見延刘。

面試官： 你在哪里會(huì)使用到volatile漫试，舉兩個(gè)例子呢？

1. 狀態(tài)量標(biāo)記碘赖，就如上面對(duì)flag的標(biāo)記驾荣，我重新提一下：

int a = 0;
volatile bool flag = false;

public void write() {
    a = 2;              //1
    flag = true;        //2
}

public void multiply() {
    if (flag) {         //3
        int ret = a * a;//4
    }
}
復(fù)制代碼

這種對(duì)變量的讀寫操作，標(biāo)記為volatile可以保證修改對(duì)線程立刻可見普泡。比synchronized,Lock有一定的效率提升播掷。

2.單例模式的實(shí)現(xiàn)，典型的雙重檢查鎖定（DCL）

class Singleton{
    private volatile static Singleton instance = null;

    private Singleton() {

    }

    public static Singleton getInstance() {
        if(instance==null) {
            synchronized (Singleton.class) {
                if(instance==null)
                    instance = new Singleton();
            }
        }
        return instance;
    }
}
復(fù)制代碼

這是一種懶漢的單例模式撼班，使用時(shí)才創(chuàng)建對(duì)象歧匈，而且為了避免初始化操作的指令重排序，給instance加上了volatile砰嘁。

面試官： 來(lái)給我們說(shuō)說(shuō)幾種單例模式的寫法吧件炉，還有上面這種用法，你再詳細(xì)說(shuō)說(shuō)呢矮湘？

好吧斟冕，這又是一個(gè)話題了，volatile的問(wèn)題終于問(wèn)完了缅阳。磕蛇。∈欤看看你掌握了沒(méi)
以上出處是： https://juejin.im/post/5a2b53b7f265da432a7b821c 我直接復(fù)制過(guò)來(lái)的孤里，請(qǐng)注意

強(qiáng)引用/弱引用/軟引用/虛引用

Android內(nèi)存泄露工具

內(nèi)存泄露有很多工具可以查看，但是Android里面用的最多的就是MAT橘洞，需要抓到相關(guān)hprof文件，hprof能看到申請(qǐng)對(duì)象的情況
這里有個(gè)問(wèn)題就是native申請(qǐng)的內(nèi)存虛擬機(jī)可能統(tǒng)計(jì)不到從而導(dǎo)致內(nèi)存泄露也沒(méi)有報(bào)oom
另外Android Studio的Memory Profiler工具
另外還有LeakCanary工具

首先先介紹LeakCanary工具
這個(gè)工具就是大名鼎鼎的Square 公司出品（http://www.reibang.com/p/70b8c87ea877
）
使用很方便

1. 在app build.gradle 中加入引用：

dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
}

2. 在Application中調(diào)用

public class LeakApplication extends Application {
    @Override public void onCreate() {
    super.onCreate();
    if (LeakCanary.isInAnalyzerProcess(this)) {//1
      // This process is dedicated to LeakCanary for heap analysis.
      // You should not init your app in this process.
      return;
    }
    LeakCanary.install(this);
  }
}

以上就可以檢測(cè)activity泄漏的情況了说搅，如果要檢測(cè)其他類型的泄漏需要借助RefWatcher炸枣。

public class MyApplication extends Application {
    private RefWatcher refWatcher;
    @Override
    public void onCreate() {
        super.onCreate();
        refWatcher= setupLeakCanary();
    }

    private RefWatcher setupLeakCanary() {
        if (LeakCanary.isInAnalyzerProcess(this)) {
            return RefWatcher.DISABLED;
        }
        return LeakCanary.install(this);
    }

    public static RefWatcher getRefWatcher(Context context) {
        MyApplication leakApplication = (MyApplication) context.getApplicationContext();
        return leakApplication.refWatcher;
    }
}

借助@ZHTo0 簡(jiǎn)書里面的例子

public class OtherActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        LeakThread leakThread = new LeakThread();
        leakThread.start();
    }

    class LeakThread extends Thread {
        @Override
        public void run() {
            try {
                CommonUtils.getInstance(OtherActivity.this);
                Thread.sleep(6 * 60 * 1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = MyApplication.getRefWatcher(this);//1
        refWatcher.watch(this);
    }
}

MainActivity存在內(nèi)存泄漏，原因就是非靜態(tài)內(nèi)部類LeakThread持有外部類MainActivity的引用，LeakThread中做了耗時(shí)操作适肠，導(dǎo)致MainActivity無(wú)法被釋放霍衫。
它用于自動(dòng)監(jiān)控Activity執(zhí)行onDestroy方法之后是否發(fā)生內(nèi)存泄露,當(dāng)前此例onDestroy加是多余的，這里只是為了方便舉例侯养，如果想要監(jiān)控Fragment敦跌，在Fragment中添加如上的onDestroy方法是有用的。
原理請(qǐng)參考http://www.reibang.com/p/70de36ea8b31

Android內(nèi)存泄露實(shí)例

Android內(nèi)存泄露總結(jié)

參考文章

http://www.reibang.com/p/017009abf0cf
https://blog.csdn.net/qq_34964197/article/details/80937147
https://juejin.im/post/5a2b53b7f265da432a7b821c
http://www.reibang.com/p/70b8c87ea877