Android内存优化

Java内存模型

运行时数据区分为几个部分

image

从上图可以看到运行时候分为：

• 方法区
• 堆栈区
• 虚拟机Java栈区
• 虚拟机Native栈区
• PC程序计数器

方法区

主要是存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据
特征是线程共享，生命周期与虚拟机相同，可以不使用连续的内存地址
配置参数： -XX:PermSize:16M -XX:MaxPermSize: 64M
异常会报 OutOfMemoryError 错误

堆栈区

主要是保存对象实例，所有对象实例（包括数组）都要在堆上分配
特征是线程共享，生命周期与虚拟机相同，可以不使用连续的内存地址
配置参数：-Xms -Xsx -Xmn
异常会报 OutOfMemoryError 错误

虚拟机Java栈区

主要是Java 方法执行的内存模型，存储局部变量表、操作栈、动态链接、方法出口等信息
特征是线程私有，生命周期与线程相同，使用连续的内存空间
异常会报 OutOfMemoryError 、StackOverflowError错误
配置参数：-Xss

虚拟机Native栈区

主要是Native方法执行的内存模型，存储局部变量表、操作栈、动态链接、方法出口等信息
特征是线程私有，生命周期与线程相同，使用连续的内存空间
异常会报 OutOfMemoryError 、StackOverflowError错误
配置参数：-Xss

PC程序计数器

大致为字节码行号指示器
特征是占用内存小，线程私有，生命周期与线程相同
不会报错无异常

运行时常量池

方法区的一部分，具有动态性
存放字面量及符号引用

为什么gc不能回收？

分析完上面的运行时候内存情况比较清楚的知道除了PC程序计数器其他都会造成内存泄露？
这里需要知道gc的回收原理下面一篇文章专门分析gc回收的情况，这里简单介绍下
gc回收一般是2种情况回收：
1 引用计数
原理:通过一个计数器对对象进行计数,对象被引用时+1,引用失效时-1;当计数为0时则说明可以被回收;
缺点:很难解决对象的相互循环引用问题
2 可达性分析算法
Java虚拟机所采用的算法;
原理:通过一些列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。
那么哪些对象可以被称为gc roots呢----

• 虚拟机栈(栈中的本地变量列表)
• 方法区静态属性/方法区常量引用
• 本地方法栈中JNI 所引用的的对象(全局对象)
• 活着的线程
• 正在被用于同步的各种锁对象
• 通过System Class Loader或者Boot Class Loader加载的class对象，通过自定义类加载器加载的class不一定是GC Root

这样就可以解决循环引用的问题

那造成内存泄露就是堆栈区里面有引用上面这些可以到底gc root对象的地方，我们调查内存泄露只需要切断到达gc root的地方则可以避免内存泄露

volatile和synchronization

这里需要讲一下线程的3特性

• 原子性：就是操作一步完成，不可中断（说白了就是一条汇编指令搞定）
• 可见性：就是保证它的修改会立刻刷新到主存，当其它线程需要读取该变量时，会去内存中读取新值。而普通变量则不能保证这一点。
• 有序性：JMM是允许编译器和处理器对指令重排序的，但是规定了as-if-serial语义，即不管怎么重排序，程序的执行结果不能改变。
  以下出处是： https://juejin.im/post/5a2b53b7f265da432a7b821c 我直接复制过来的，请注意

JMM具备一些先天的有序性,即不需要通过任何手段就可以保证的有序性，通常称为happens-before原则。<<JSR-133：Java Memory Model and Thread Specification>>定义了如下happens-before规则：

1. 程序顺序规则： 一个线程中的每个操作，happens-before于该线程中的任意后续操作
2. 监视器锁规则：对一个线程的解锁，happens-before于随后对这个线程的加锁
3. volatile变量规则： 对一个volatile域的写，happens-before于后续对这个volatile域的读
4. 传递性：如果A happens-before B ,且 B happens-before C, 那么 A happens-before C
5. start()规则： 如果线程A执行操作ThreadB_start()(启动线程B) , 那么A线程的ThreadB_start()happens-before 于B中的任意操作
6. join()原则： 如果A执行ThreadB.join()并且成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
7. interrupt()原则： 对线程interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否有中断发生
8. finalize()原则：一个对象的初始化完成先行发生于它的finalize()方法的开始

第1条规则程序顺序规则是说在一个线程里，所有的操作都是按顺序的，但是在JMM里其实只要执行结果一样，是允许重排序的，这边的happens-before强调的重点也是单线程执行结果的正确性，但是无法保证多线程也是如此。

第2条规则监视器规则其实也好理解，就是在加锁之前，确定这个锁之前已经被释放了，才能继续加锁。

第3条规则，就适用到所讨论的volatile，如果一个线程先去写一个变量，另外一个线程再去读，那么写入操作一定在读操作之前。

第4条规则，就是happens-before的传递性。

volatile 只能保证可见性和有序性， 针对简单赋值等操作可以完成多线程的保证，但是针对i++ 之类的也不能保证多线程安全需要用synchronization和lock保证

synchronization 可以保证3个特性，缺点就是效率比较慢

面试官：volatile关键字如何满足并发编程的三大特性的？

那就要重提volatile变量规则： 对一个volatile域的写，happens-before于后续对这个volatile域的读。 这条再拎出来说，其实就是如果一个变量声明成是volatile的，那么当我读变量时，总是能读到它的最新值，这里最新值是指不管其它哪个线程对该变量做了写操作，都会立刻被更新到主存里，我也能从主存里读到这个刚写入的值。也就是说volatile关键字可以保证可见性以及有序性。

继续拿上面的一段代码举例：

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
   }

}
复制代码

这段代码不仅仅受到重排序的困扰，即使1、2没有重排序。3也不会那么顺利的执行的。假设还是线程1先执行write操作，线程2再执行multiply操作，由于线程1是在工作内存里把flag赋值为1，不一定立刻写回主存，所以线程2执行时，multiply再从主存读flag值，仍然可能为false，那么括号里的语句将不会执行。

如果改成下面这样：

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
   }
}
复制代码

那么线程1先执行write,线程2再执行multiply。根据happens-before原则，这个过程会满足以下3类规则：

1. 程序顺序规则：1 happens-before 2; 3 happens-before 4; (volatile限制了指令重排序，所以1 在2 之前执行)
2. volatile规则：2 happens-before 3
3. 传递性规则：1 happens-before 4

从内存语义上来看

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存

当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。

面试官：volatile的两点内存语义能保证可见性和有序性，但是能保证原子性吗？

首先我回答是不能保证原子性，要是说能保证，也只是对单个volatile变量的读/写具有原子性，但是对于类似volatile++这样的复合操作就无能为力了，比如下面的例子：

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)  //保证前面的线程都执行完
            Thread.yield();
        System.out.println(test.inc);
    }
复制代码

按道理来说结果是10000，但是运行下很可能是个小于10000的值。有人可能会说volatile不是保证了可见性啊，一个线程对inc的修改，另外一个线程应该立刻看到啊！可是这里的操作inc++是个复合操作啊，包括读取inc的值，对其自增，然后再写回主存。

假设线程A，读取了inc的值为10，这时候被阻塞了，因为没有对变量进行修改，触发不了volatile规则。

线程B此时也读读inc的值，主存里inc的值依旧为10，做自增，然后立刻就被写回主存了，为11。

此时又轮到线程A执行，由于工作内存里保存的是10，所以继续做自增，再写回主存，11又被写了一遍。所以虽然两个线程执行了两次increase()，结果却只加了一次。

有人说，volatile不是会使缓存行无效的吗？但是这里线程A读取到线程B也进行操作之前，并没有修改inc值，所以线程B读取的时候，还是读的10。

又有人说，线程B将11写回主存，不会把线程A的缓存行设为无效吗？但是线程A的读取操作已经做过了啊，只有在做读取操作时，发现自己缓存行无效，才会去读主存的值，所以这里线程A只能继续做自增了。

综上所述，在这种复合操作的情景下，原子性的功能是维持不了了。但是volatile在上面那种设置flag值的例子里，由于对flag的读/写操作都是单步的，所以还是能保证原子性的。

要想保证原子性，只能借助于synchronized,Lock以及并发包下的atomic的原子操作类了，即对基本数据类型的 自增（加1操作），自减（减1操作）、以及加法操作（加一个数），减法操作（减一个数）进行了封装，保证这些操作是原子性操作。

面试官：说的还可以，那你知道volatile底层的实现机制？

如果把加入volatile关键字的代码和未加入volatile关键字的代码都生成汇编代码，会发现加入volatile关键字的代码会多出一个lock前缀指令。

lock前缀指令实际相当于一个内存屏障，内存屏障提供了以下功能：

1 . 重排序时不能把后面的指令重排序到内存屏障之前的位置 2 . 使得本CPU的Cache写入内存 3 . 写入动作也会引起别的CPU或者别的内核无效化其Cache，相当于让新写入的值对别的线程可见。

面试官： 你在哪里会使用到volatile，举两个例子呢？

1. 状态量标记，就如上面对flag的标记，我重新提一下：

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
    }
}
复制代码

这种对变量的读写操作，标记为volatile可以保证修改对线程立刻可见。比synchronized,Lock有一定的效率提升。

2.单例模式的实现，典型的双重检查锁定（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;
    }
}
复制代码

这是一种懒汉的单例模式，使用时才创建对象，而且为了避免初始化操作的指令重排序，给instance加上了volatile。

面试官： 来给我们说说几种单例模式的写法吧，还有上面这种用法，你再详细说说呢？

好吧，这又是一个话题了，volatile的问题终于问完了。。。看看你掌握了没
以上出处是： https://juejin.im/post/5a2b53b7f265da432a7b821c 我直接复制过来的，请注意

强引用/弱引用/软引用/虚引用

Android内存泄露工具

内存泄露有很多工具可以查看，但是Android里面用的最多的就是MAT，需要抓到相关hprof文件，hprof能看到申请对象的情况
这里有个问题就是native申请的内存虚拟机可能统计不到从而导致内存泄露也没有报oom
另外Android Studio的Memory Profiler工具
另外还有LeakCanary工具

首先先介绍LeakCanary工具
这个工具就是大名鼎鼎的Square 公司出品（https://www.jianshu.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中调用

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);
  }
}

以上就可以检测activity泄漏的情况了，如果要检测其他类型的泄漏需要借助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 简书里面的例子

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存在内存泄漏，原因就是非静态内部类LeakThread持有外部类MainActivity的引用，LeakThread中做了耗时操作，导致MainActivity无法被释放。
它用于自动监控Activity执行onDestroy方法之后是否发生内存泄露,当前此例onDestroy加是多余的，这里只是为了方便举例，如果想要监控Fragment，在Fragment中添加如上的onDestroy方法是有用的。
原理请参考https://www.jianshu.com/p/70de36ea8b31

Android内存泄露实例

Android内存泄露总结

参考文章

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