内存泄漏，内存溢出（OOM），GC

内存泄漏:有些内存无法回收；内存溢出：泄漏到一定值导致内存溢出

-------------------------------------------------------

前言

先通俗理解下内存泄漏，内存溢出（OOM），GC回收这几个概念。
把app的堆内存空间想成了一个杯子，内存就是里面的水。
当你的app启动后，系统会分配给app一个堆空间，起始不会很大比如是32M（根据你的app启动时的内存申请为准）

 

image.png

• 随着程序的运行对象的创建越来越多，系统不断加内存分配：32M -> 64M -> ...
• 而GC回收则会定时扫描内存，发现不被引用的对象即可回收。
  正常来说你的app堆内存会有升有降。
  此时如果有某个Activity持有某个引用，在onDestroy时还不把这个引用设为null，那么返回进入退出这个界面，Activity就会创建很多次从而存在多个实例，导致堆内存直升不降！这就叫做内存泄漏。

当用户重复这个操作或者有多个不同Activity内存泄漏时，app运行一段时间堆内存超过系统规定的最大值 heapSize，杯子满了就会发现内存溢出（OOM），app崩溃。

关键点

通过上面这个例子，我们知道查找内存泄漏有如下几点关键点：

1. 如何知道你的app上限值heapSize是多少
2. 什么情况导致无法GC
3. 怎么复现是哪个界面内存泄漏
   下面通过一个实例来演示，如何借助AndroidStudio查找内存泄漏：

内存泄漏实例

当你的app在使用中莫名崩溃，如果是OOM那么会有如下日志：

 

image.png

 

接下来我们用下面的代码获取heapsize：

ActivityManager manager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
int heapSize = manager.getMemoryClass();
int maxHeapSize = manager.getLargeMemoryClass();  // manafest.xml   android:largeHeap="true"

• heapSize是设备分配给app的最大堆内存

• maxHeapSize 是当配置了android:largeHeap="true" 才有的最大堆内存，一般是heapSize的2-3倍
  以HTC ONE为例，两个值分别是： 192M和512M。这里我只关注192M，maxHeapSize放到后面再说。然后尝试复现问题，手机连接AndroidStudio打开monitor，反复进入/退出怀疑内存泄漏的界面：

   

  

  image.png

   

  如果发现内存一直上升，并且到接近192M的时候不动了，此时已经OOM只不过不一定会崩溃（oom异常可以try catch）

• 接着，用AndroidStudio自带的内存分析工具分析，点击Dump Java Heap:

   

  

  image.png

（备注：ViewDefectPhotoActivity是我的app里面一个界面，用ViewPager展示，ImageLoader加载很多照片）

会在代码区 生成当前时间点的 .hprof格式文件，里面当前的每个对象 内存占用情况，我们现在怀疑ViewDefectPhotoActivity 可能内存泄漏 看一下：ViewDefectPhotoActivity 确实占用了很高的内存 而且有8个实例化对象,足以证明它有内存泄漏，随便点击其中一个，发现都和EditDefectActivity的内部类 ShowEditDefectHelper有关。而且ShowEditDefectHelpe前面带有 黄蓝三角树 这个图标表示，他可以被GC访问到，也就是无法回收：

 

image.png

 

接下来看看ShowEditDefectHelper这个对象持有什么引用，右键点击 Go To Instance:

 

image.png

发现这个内部类也被实例化多次，随便点击一个，发现属于EventBus的引用 ，并且EventBus带有黄蓝图标，那么问题就大概找到了，因为EventBus一直持有这个内部类的引用，导致这个内部类无法被回收，而这个内部类持有ViewDefectPhotoActivity引用，导致ViewDefectPhotoActivity无法被回收 这个界面有很多图片资源 当实例化7,8次之后 出现了OOM。
！

EventBus是用于事件通知的开源库，应该很多人都了解。它需要在某个类里面绑定和解绑定，我这里是在ShowEditDefectHelper注册的，看下Activity的内部类ShowEditDefectHelper：

 

image.png

解释下这里的逻辑：进入这个activity我会显示一个进度条，请求网络数据，用户可以随时取消进度条。然后onCancel里面对EventBus解绑定：
但是这里有个低级错误：EventBus.getDefult().unregister(this)传入的this是onCancelled()的匿名内部类而不是ShowEditDefectHelper.class导致EventBus无法解绑！
!
所以应该这么解绑：

EventBus.getDefult().unregister(ShowEditDefectHelper.Class);

！
通过这个示例，我们回答了上面前两个关键点：

1. 如何知道你的app上限值heapSize是多少

2. 什么情况导致无法GC
   第三个关键点：3. 怎么复现是哪个界面内存泄漏。内存泄漏不是一眼就能看出来了，需要测试人员配合。当然还有一个办法就是facebook的开源库：leakcanary，具体使用我不多介绍了。它是一个apk安装在手机上可以直接列出内存泄漏的Activity，但是有一定误报几率：

    

   

   image.png

我更喜欢leakcanary + AndroidStudio的方式，精确无误地找出问题。

怎么避免内存

一句话归纳：（生命周期比Activity长的类不要去强引用Activity）

1. 内部类请使用static，因为非静态内部类默认持有外部类的引用，比如在Activity里面直接放一个自定义的Adapter

2. 静态类（比如Application，单例类，其他static类）请不要持有Activity引用，因为静态类生命周期比Activity长。解决办法：在需要的地方用BaseApplication.getTopActivity。或者Activity作为弱引用传入

3. 注意Handler会默认持有当前Activity，用的时候最好不要直接new Handler().post(new Runnable...),除非你确定这个runnable会在Activity销毁前执行完

OK，假设你的项目比较紧急，想暂时规避内存泄漏问题怎么办？可以在manifest.xml加入本文开头给的那个设置：

android:largeHeap="true"

此时heapsize会增大2-3倍，缓解OOM的发生，但是技术债终究要还的。希望大家认真揣摩本文用AndroidStudio分析泄漏的方法，而不是过分依赖leakcanary这个开源库。

 

-------------------------------------------------- 文章二 

Shallow Size、Retained Size、Heap Size 和 Allocated

Shallow Size：
Shallow size就是对象本身占用内存的大小，不包含其引用的对象。

常规对象（非数组）的 Shallow size 由其成员变量的数量和类型决定。
数组的shallow size有数组元素的类型（对象类型、基本类型）和数组长度决定。
在32位系统上，

对象头占用 8 字节
int 占用4字节
不管 成员变量（对象或数组）是否引用了其他对象（实例）或者赋值为null它始终占用4字节。
故此，对于String对象实例来说，它有三个 int 成员（3*4=12字节）、一个 char[] 成员（1*4=4字节）以及一个对象头（8字节），总共3*4 +1*4+8=24字节。 
根据这一原则，对 String mStr=”rosen jiang”来说，实例 mStr的shallow size也是24字节。（注意：上述String是jdk1.5的，代码如下：）

public final class String
    implements java.io.Serializable, Comparable<String>, CharSequence
{
    /** The value is used for character storage. */
    private final char value[];

    /** The offset is the first index of the storage that is used. */
    private final int offset;

    /** The count is the number of characters in the String. */
    private final int count;

    /** Cache the hash code for the string */
    private int hash; // Default to 0
    .....

    }

Retained Size:
对象的Retained Size = 对象本身的Shallow Size + 对象能直接或间接访问到的对象的Shallow Size 
也就是说 Retained Size 就是该对象被 Gc 之后所能回收内存的总和。

为了更好地理解Retained Size，看下图对象的引用对象可以归纳为：该对象到其他对象有引用关系并且该引用对象到 Gc Root 节点是不可达的，所以有

左图 obj1 的 Retained Size = obj1 + obj2 + obj4 +obj3 的 Shallow size
右图 obj1 的 Retained Size = obj1 + obj2 + obj4 +obj3 的 Shallow size
总之，Retained size是一个整体度量，能反映内存结构和对象图的依赖关系，还可以找到根节点。

在进行垃圾回收时，如果实例对象到 Gc Root 是不可达的，那么该对象会被回收，如下图的 Object F 和 Object I

Heap Size:
堆的大小，当资源增加，当前堆的空间不够时，系统会增加堆的大小，若超过上限（如64M，阈值视平台而定）则会被杀掉 。

Allocated:
堆中已分配的大小，即 App 应用实际占用的内存大小，资源回收后，此项数据会变小。

建议:若单一操作反复进行，堆大小一直增加，则有内存泄露的隐患，可采用MAT进一步查看。
--------------------- 

 

文章一 作者：08_carmelo
链接：https://www.jianshu.com/p/ed88b12cc65e
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

文章二 作者：Strange_Monkey 
来源：CSDN 
原文：https://blog.csdn.net/strange_monkey/article/details/81746232 
版权声明：本文为博主原创文章，转载请附上博文链接！