Android之内存泄漏

最新推荐文章于 2024-05-08 06:02:52 发布

Amengww

最新推荐文章于 2024-05-08 06:02:52 发布

阅读量192

点赞数 1

分类专栏： Android 内存文章标签： Android 内存泄漏

本文链接：https://blog.csdn.net/u013824180/article/details/89820651

版权

Android 内存专栏收录该内容

1 篇文章 0 订阅

订阅专栏

什么是内存泄漏

在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。（源自： https://www.ibm.com/developerworks/cn/java/l-JavaMemoryLeak/index.html ）

JAVA内存管理

为了判断Java中是否有内存泄露，我们首先必须了解Java是如何管理内存的。Java的内存管理就是对象的分配和释放问题。在Java中，程序员需要通过关键字new为每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的释放是由GC决定和执行的。在Java中，内存的分配是由程序完成的，而内存的释放是有GC完成的。GC为了能够正确释放对象，GC必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。

1、内存分配

运行时内存模型，分为线程私有和共享数据区两大类，其中线程私有的数据区包含程序计数器、虚拟机栈、本地方法区，所有线程共享的数据区包含Java堆、方法区（又称为静态存储区，方法区内还有一个常量池），如下图所示

java 运行时内存模型
在这里插入图片描述
有关程序计数器、虚拟机栈、本地方法栈、Java堆和方法区的详解可参考这篇文章 https://blog.csdn.net/qq_41701956/article/details/81664921

在这里插入图片描述 java一般内存申请有两种：静态内存和动态内存。很容易理解，编译时就能够确定的内存就是静态内存，即内存是固定的，系统一次性分配，比如int类型变量；动态内存分配就是在程序执行时才知道要分配的存储空间大小，比如java对象的内存空间。根据上面我们知道，虚拟机栈、程序计数器、本地方法栈都是线程私有的，线程生就生，线程灭就灭，栈中的栈帧随着方法的结束也会撤销，内存自然就跟着回收了。所以这几个区域的内存分配与回收是确定的，我们不需要管的。但是java堆和方法区则不一样，我们只有在程序运行期间才知道会创建哪些对象，所以这部分内存的分配和回收都是动态的。一般我们所说的垃圾回收也是针对的这一部分。总之Stack的内存管理是顺序分配的，而且定长，不存在内存回收问题；而Heap 则是为java对象的实例随机分配内存，不定长度，所以存在内存分配和回收的问题；

通常当我们创建一个对象后，它会按照以下流程放到对应的内存区域：
在这里插入图片描述（源自：https://blog.csdn.net/crazymo_/article/details/80210657 ）

堆和栈的区别

（摘自：https://www.jianshu.com/p/54b5da7c6816）

在方法体内定义的（局部变量）一些基本类型的变量和对象的引用变量都是在方法的栈内存中分配的。当在一段方法块中定义一个变量时，Java 就会在栈中为该变量分配内存空间，当超过该变量的作用域后，该变量也就无效了，分配给它的内存空间也将被释放掉，该内存空间可以被重新使用。

堆内存用来存放所有由new 创建的对象（包括该对象其中的所有成员变量）和数组。在堆中分配的内存，将由 Java 垃圾回收器来自动管理。在堆中产生了一个数组或者对象后，还可以在栈中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，这个特殊的变量就是我们上面说的引用变量。我们可以通过这个引用变量来访问堆中的对象或者数组。

举个栗子：
在这里插入图片描述 Sample 类的局部变量 s2 和引用变量 mSample2 都是存在于栈中，但 mSample2 指向的对象是存在于堆上的。

mSample3 指向的对象实体存放在堆上，包括这个对象的所有成员变量 s1 和 mSample1，而它自己存在于栈中。

结论：

局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中。—— 因为它们属于方法中的变量，生命周期随方法而结束。
成员变量全部存储于堆中（包括基本数据类型，引用和引用的对象实体）—— 因为它们属于类，类对象终究是要被new出来使用的。

栈也是JAVA虚拟机自动管理的，（不是由gc）栈类似一个集合（不过是有固定的容量），是由很多元素（专业术语：栈帧）组合起来的，在我们码代码的时候，每调用一个方法，在运行的时候，JAVA虚拟机就会自动在内存中分配对应的一块空间，那么这块空间就是一个栈帧，也就自然属于栈了，而当方法调用结束后，对应的栈帧就会被释放掉。C语言和c++对栈的管理也是如此，不过是由系统来管理的，也就是说其实很多语言对栈的管理都差不多，编译型语言是把对栈的管理交给操作系统，而解释型语言一般都是把对栈的管理给解释器的，大部分语言都是这样，JAVA也是。GC是释放的堆内存。

举个例子：
在这里插入图片描述

2、内存释放

Java中内存的释放是由GC（garbage collection）完成的。需要先了解一下GC的工作原理。（摘自 https://blog.csdn.net/tonytfjing/article/details/44278233）

垃圾收集器一般必须完成两件事：检测出垃圾；回收垃圾（回收算法和垃圾收集器）。怎么检测出垃圾？一般有以下几种方法：

垃圾检测

引用计数法：给一个对象添加引用计数器，每当有个地方引用它，计数器就加1；引用失效就减1。好了，问题来了，如果我有两个对象A和B，互相引用，除此之外，没有其他任何对象引用它们，实际上这两个对象已经无法访问，即是我们说的垃圾对象。但是互相引用，计数不为0，导致无法回收，所以还有另一种方法：

可达性分析算法：以根集对象为起始点进行搜索，如果有对象不可达的话，即是垃圾对象。这里的根集一般包括虚拟机栈中(栈中本地变量表)引用的对象、方法区常量池中引用的对象、方法区中静态属性的对象、本地方法栈中JNI引用的对象等。

总之，JVM在做垃圾回收的时候，会检查堆中的所有对象是否会被这些根集对象引用，不能够被引用的对象就会被垃圾收集器回收。一般回收算法也有如下几种：

回收算法

1.标记-清除（Mark-sweep）

算法和名字一样，分为两个阶段：标记和清除。标记所有需要回收的对象，然后统一回收。这是最基础的算法，后续的收集算法都是基于这个算法扩展的。
不足：效率低；标记清除之后会产生大量碎片。效果图如下
在这里插入图片描述

2.复制（Copying）

此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。此算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。效果图如下：
在这里插入图片描述

3.标记-整理（Mark-Compact）

此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。效果图如下：
在这里插入图片描述

4.分代收集算法

这是当前商业虚拟机常用的垃圾收集算法。分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。

为什么要运用分代垃圾回收策略？在java程序运行的过程中，会产生大量的对象，因每个对象所能承担的职责不同所具有的功能不同所以也有着不一样的生命周期，有的对象生命周期较长，比如Http请求中的Session对象，线程，Socket连接等；有的对象生命周期较短，比如String对象，由于其不变类的特性，有的在使用一次后即可回收。试想，在不进行对象存活时间区分的情况下，每次垃圾回收都是对整个堆空间进行回收，那么消耗的时间相对会很长，而且对于存活时间较长的对象进行的扫描工作等都是徒劳。因此就需要引入分治的思想，所谓分治的思想就是因地制宜，将对象进行代的划分，把不同生命周期的对象放在不同的代上使用不同的垃圾回收方式。

如何划分？将对象按其生命周期的不同划分成：年轻代(Young Generation)、年老代(Old Generation)、持久代(Permanent Generation)。其中持久代主要存放的是类信息，所以与java对象的回收关系不大，与回收息息相关的是年轻代和年老代。这里有个比喻很形象

“假设你是一个普通的 Java 对象，你出生在 Eden 区，在 Eden 区有许多和你差不多的小兄弟、小姐妹，可以把 Eden 区当成幼儿园，在这个幼儿园里大家玩了很长时间。Eden 区不能无休止地放你们在里面，所以当年纪稍大，你就要被送到学校去上学，这里假设从小学到高中都称为 Survivor 区。开始的时候你在 Survivor 区里面划分出来的的“From”区，读到高年级了，就进了 Survivor 区的“To”区，中间由于学习成绩不稳定，还经常来回折腾。直到你 18 岁的时候，高中毕业了，该去社会上闯闯了。于是你就去了年老代，年老代里面人也很多。在年老代里，你生活了
20 年 (每次 GC 加一岁)，最后寿终正寝，被 GC 回收。有一点没有提，你在年老代遇到了一个同学，他的名字叫爱德华 (慕光之城里的帅哥吸血鬼)，他以及他的家族永远不会死，那么他们就生活在永生代。”

年轻代：

是所有新对象产生的地方。年轻代被分为3个部分——Enden区和两个Survivor区（From和to）当Eden区被对象填满时，就会执行Minor GC。并把所有存活下来的对象转移到其中一个survivor区（假设为from区）。Minor GC同样会检查存活下来的对象，并把它们转移到另一个survivor区（假设为to区）。这样在一段时间内，总会有一个空的survivor区。经过多次GC周期后，仍然存活下来的对象会被转移到年老代内存空间。通常这是在年轻代有资格提升到年老代前通过设定年龄阈值来完成的。需要注意，Survivor的两个区是对称的，没先后关系，from和to是相对的。

年老代：

在年轻代中经历了N次回收后仍然没有被清除的对象，就会被放到年老代中，可以说他们都是久经沙场而不亡的一代，都是生命周期较长的对象。对于年老代和永久代，就不能再采用像年轻代中那样搬移腾挪的回收算法，因为那些对于这些回收战场上的老兵来说是小儿科。通常会在老年代内存被占满时将会触发Full GC,回收整个堆内存。

持久代：

用于存放静态文件，比如java类、方法等。持久代对垃圾回收没有显著的影响。

分代回收的效果图如下：
在这里插入图片描述这里之所以最后讲分代，是因为分代里涉及了前面几种算法。年轻代：涉及了复制算法；年老代：涉及了“标记-整理（Mark-Sweep）”的算法。

垃圾收集器

（摘自：https://blog.csdn.net/java2000_wl/article/details/8030172 、
http://wuzhangyang.com/2019/01/17/java-garbage-collector/）

下面有7种收集器，分为两块，上面为新生代收集器，下面是老年代收集器。如果两个
收集器之间存在连线，就说明它们可以搭配使用。
在这里插入图片描述

Serial(串行GC)收集器

Serial收集器是一个新生代收集器，单线程执行，使用复制算法。它在进行垃圾收集时，必须暂停其他所有的工作线程(用户线程)。是Jvm client模式下默认的新生代收集器。对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
在这里插入图片描述

ParNew(并行GC)收集器

ParNew收集器其实就是serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为与Serial收集器一样。默认开启的线程数量与 CPU 数量相同。在单 CPU 的环境，ParNew 收集器不会比 Serial 收集器更优秀。
在这里插入图片描述

Parallel Scavenge(并行回收GC)收集器

Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行多线程收集器。parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。吞吐量= 程序运行时间/(程序运行时间 + 垃圾收集时间)，虚拟机总共运行了100分钟。其中垃圾收集花掉1分钟，那吞吐量就是99%。高吞吐量可以高效率地利用 CPU 时间，尽快完成程序地运行任务，适合在后台运行不需要太多交互的任务。

-XX:GCTimeRatio : 设置吞吐量大小。
-XX:MaxGCPauseMillis : 设置最大垃圾收集停顿时间。

Serial Old(串行GC)收集器

Serial Old是Serial收集器的老年代版本，它同样使用一个单线程执行收集，使用“标记-整理”算法。主要使用在Client模式下的虚拟机。

在这里插入图片描述

Parallel Old(并行GC)收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

在这里插入图片描述

CMS(并发GC)收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器是基于“标记-清除”算法实现的，整个收集过程大致分为4个步骤：

①.初始标记(CMS initial mark)：仅仅标记一下 GC Roots 能关联到的对象，速度很快。

②.并发标记(CMS concurrenr mark)：GC Roots Tracing 过程。

③.重新标记(CMS remark)：修正并发标记期间引用变化那一部分对象

④.并发清除(CMS concurrent sweep)

其中，初始标记、重新标记需要“Stop The World”。并发标记和并发清除时收集器线程可以与用户线程一起工作。

在这里插入图片描述

初始标记、重新标记这两个步骤任然需要停顿其他用户线程。初始标记仅仅只是标记出GC ROOTS能直接关联到的对象，速度很快，并发标记阶段是进行GC ROOTS 根搜索算法阶段，会判定对象是否存活。而重新标记阶段则是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会被初始标记阶段稍长，但比并发标记阶段要短。由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以整体来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。CMS收集器的优点：并发收集、低停顿，但是CMS还远远达不到完美，器主要有三个显著缺点：CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会占用CPU资源而导致引用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是：(CPU数量+3) / 4。CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure“，失败后而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随程序的运行自热会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理它们，只好留待下一次GC时将其清理掉。这一部分垃圾称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分内存空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间时就会被激活，也可以通过参数-XX:CMSInitiatingOccupancyFraction的值来提供触发百分比，以降低内存回收次数提高性能。要是CMS运行期间预留的内存无法满足程序其他线程需要，就会出现“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置的过高将会很容易导致“Concurrent Mode Failure”失败，性能反而降低。最后一个缺点，CMS是基于“标记-清除”算法实现的收集器，使用“标记-清除”算法收集后，会产生大量碎片。空间碎片太多时，将会给对象分配带来很多麻烦，比如说大对象，内存空间找不到连续的空间来分配不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数，用于在Full GC之后增加一个碎片整理过程，还可通过-XX:CMSFullGCBeforeCompaction参数设置执行多少次不压缩的Full GC之后，跟着来一次碎片整理过程。

优势：
并发收集、低停顿。
缺陷：
1、对 CPU 资源敏感。多线程导致占用一部分 CPU 资源而导致应用程序变慢。
2、无法处理浮动垃圾。并发清理过程中用户线程还在运行，会产生新的垃圾，CMS 无法在当次收集中处理它们，只好等待下一次 GC 时再清理掉。这一部分垃圾称为浮动垃圾。
3、CMS 采取的标记清除算法会产生大量空间碎片。往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象，不得不提前触发一次 Full GC。

G1收集器

G1(Garbage First)收集器是JDK1.7提供的一个新收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。还有一个特点之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆(包括新生代，老年代)。

Region
上述的 GC 收集器将连续的内存空间划分为新生代、老生代和永久代（JDK 8 去除了永久代，引入了元空间 Metaspace），这种划分的特点是各代的存储地址（逻辑地址）是连续的。G1 (Garbage First) 的各代存储地址是不连续的，每一代都使用了 n 个不连续的大小相同的 region，每个 region 占有一块连续的虚拟内存地址。
在这里插入图片描述 G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region。

避免全堆扫描
多个 Region 之前的对象可能会有引用关系，在做可达性分析时需要扫描整个堆才能保证准确性，这显然降低了 GC 效率。

为避免全堆扫描，虚拟机为 G1 中每个 Region 维护了一个与之对应的 Remembered Set。虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier 暂时中断写操作，检查 Reference 引用的对象是否处于不同的 Region 之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过 CardTable 把相关引用信息记录到被引用对象所属的Region的 Remembered Set 之中。当进行内存回收时，在GC根节点的枚举范围中加入 Remembered Set 即可保证不对全堆扫描也不会有遗漏。

G1 的运作步骤：
1、初始标记（Initial Marking）
2、并发标记（Concurrent Marking）
3、最终标记（Final Marking）
4、筛选回收（Live Data Counting and Evacuation）

在这里插入图片描述
特点：
1、空间整合：整体来看是基于“标记 - 整理”算法实现的收集器，从局部（两个 Region 之间）上来看是基于“复制”算法实现的，这意味着运行期间不会产生内存空间碎片。

2、可预测的停顿：能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在 GC 上的时间不得超过 N 毫秒。

在这里插入图片描述

好了，那么了解了GC的工作原理，那什么情况下会触发GC呢？

1、GC_FOR_MALLOC 表示内存垃圾回收过程是因为在分配内存空间如（创建对象）时，内存不够而引发的。系统会杀死应用的进程并且回收所有内存。当堆内存已满，系统需要更多内存的时候触发。这条日志出现后意味着JVM要暂停你的程序进行垃圾回收操作。

2、GC_CONCURRENT 表明GC是在内存使用率达到一定的警戒线时，自动触发的。

3、GC_EXPLICIT 表明GC是被显式请求触发的。当程序中调用System.gc()方法触发。这个方法应避免出现在程序中调用。因为JVM有足够的能力来控制垃圾回收。

4、GC_EXTERNAL_ALLOC在API版本10(Android3.0)以下的时候的垃圾回收机制。3.0以上版本所有的内存都在Dalvik堆中分配。它是用来回收dalvik虚拟机以外的内存（例如Bitmap中的内存或者NIObuffer中的内存）。

5、 GC_HPROF_DUMP_HEAP 当请求生成HPROF文件来分析内存的时候会触发此类垃圾回收

详细可了解GC的源码过程分析：https://www.kancloud.cn/alex_wsc/androids/473628

内存泄漏

分类（摘自：https://blog.csdn.net/ccj659/article/details/53032683）

堆引用内存泄漏（Heap leak）：

关联对象的生命周期不一样

1.静态变量持有已经没有用的对象,导致对象无法被回收.例如静态集合类引起内存泄露

2.单例中持有的引用,当activity重新构建后,单例持有的是上一个activity实例.导致上一个无法被回收.

3.事件监听器和回调.如果一个类注册了监听器，但当该类不再被使用后没有注销监听器，可能会发生内存泄漏。

4.非静态内部类和匿名内部类会持有外部类的引用，而静态内部类则不会持有外部类的引用。

5.Handler 内存泄漏

系统资源泄露（Resource Leak）

1.bitmap资源未释放

2.IO流未关闭

3.Cursor使用完后未释放

4.各种连接(网络,数据库,socket等)

举几个例子：

（摘自：https://www.cnblogs.com/zhaoyanjun/p/5981386.html）
（摘自：https://www.cnblogs.com/ldq2016/p/6636317.html）
（摘自：https://blog.csdn.net/qq_35373333/article/details/74909811）

1、新建线程引起的Activity内存泄漏

public class Activity6 extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_6);
 
        findViewById( R.id.finish).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {                
                    Thread.sleep( 15000 );     //模拟耗时操作
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

运行上面的代码后，点击finish按钮,过一会儿发生了内存泄漏的问题。为什么Activity6会发生内存泄漏？进入Activity6 界面，然后点击finish按钮，Activity6销毁，但是Activity6里面的线程还在运行，匿名内部类Runnable对象引用了Activity6的实例，导致Activity6所占用的内存不能被GC及时回收。

更改：Runnable改为静态非匿名内部类即可。

public class Activity6 extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_6);
 
        findViewById( R.id.finish).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
        new Thread( new MyRunnable()).start();
    }
 
    private static class MyRunnable implements Runnable {
 
        @Override
        public void run() {
            try {
                Thread.sleep( 15000 );
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

2、Activity添加监听器造成Activity内存泄漏

public class LeakActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        NastyManager.getInstance().addListener(this);
    }
}

这个是在开发中经常会犯的错误，NastyManager.getInstance() 是一个单例，当我们通过 addListener(this) 将 Activity 作为 Listener 和 NastyManager 绑定起来的时候，不好的事情就发生了。

改进：在你的 Acitivity 被销毁的时候，将他和 NastyManager 取消掉绑定就好了。

public class LeakActivity extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        NastyManager.getInstance().addListener(this);
    }
    @Override
    protected void onDestroy() {
        super.onDestroy();
        NastyManager.getInstance().removeListener(this);
    }
}

3、Handler 匿名内部类造成内存溢出

public class HandlerActivity extends AppCompatActivity {

    private final static int MESSAGECODE = 1 ;
 
    private final Handler handler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            Log.d("mmmmmmmm" , "handler " + msg.what ) ;
        }
    };
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
 
        findViewById( R.id.finish ).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
        new Thread(new Runnable() {
            @Override
            public void run() {
                handler.sendEmptyMessage( MESSAGECODE ) ;
                try {
                    Thread.sleep( 8000 );
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                handler.sendEmptyMessage( MESSAGECODE ) ;
            }
        }).start() ;
    }
}

这段代码运行起来后，立即点击 finish 按钮，通过检测，发现 HandlerActivity 出现了内存泄漏。当Activity finish后，延时消息会继续存在主线程消息队列中8秒钟，然后处理消息。而该消息引用了Activity的Handler对象，然后这个Handler又引用了这个Activity。这些引用对象会保持到该消息被处理完，这样就导致该Activity对象无法被回收，从而导致了上面说的 Activity泄露。Handler 是个很常用也很有用的类，异步，线程安全等等。如果有下面这样的代码，会发生什么呢？ handler.postDeslayed ，假设 delay 时间是几个小时… 这意味着什么？意味着只要 handler 的消息还没有被处理结束，它就一直存活着，包含它的 Activity 就跟着活着。我们来想办法修复它，修复的方案是 WeakReference ，也就是所谓的弱引用。垃圾回收器在回收的时候，是会忽视掉弱引用的，所以包含它的 Activity 会被正常清理掉。

改进
1、使用静态内部类 ----非静态内部类会持有外部类的引用
2、使用弱引用

public class HandlerActivity extends AppCompatActivity {

    private final static int MESSAGECODE = 1 ;
    private static Handler handler ;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
 
        findViewById( R.id.finish ).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
        handler = new MyHandler( this ) ;
 
        new Thread(new Runnable() {
            @Override
            public void run() {
                handler.sendEmptyMessage( MESSAGECODE ) ;
                try {
                    Thread.sleep( 8000 );
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                handler.sendEmptyMessage( MESSAGECODE ) ;
            }
        }).start() ;
    }
 
    private static class MyHandler extends Handler {
        WeakReference<HandlerActivity> weakReference ;
 
        public MyHandler(HandlerActivity activity ){
            weakReference  = new WeakReference<HandlerActivity>( activity) ;
        }
 
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if ( weakReference.get() != null ){
                // update android ui
                Log.d("mmmmmmmm" , "handler " + msg.what ) ;
            }
        }
    }
}

这个Handler已经使用了静态内部类，并且使用了弱引用。但是这个并没有完全解决 HandlerActivity 内存泄漏的问题，罪魁祸首是线程创建的方式出了问题，就像本文的第一个例子一样。改进的方式，是把Runnable类写成静态内部类。

public class HandlerActivity extends AppCompatActivity {

    private final static int MESSAGECODE = 1 ;
    private static Handler handler ;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
 
        findViewById( R.id.finish ).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
        //创建Handler
        handler = new MyHandler( this ) ;
 
        //创建线程并且启动线程
        new Thread( new MyRunnable() ).start();
    }
 
    private static class MyHandler extends Handler {
        WeakReference<HandlerActivity> weakReference ;
 
        public MyHandler(HandlerActivity activity ){
            weakReference  = new WeakReference<HandlerActivity>( activity) ;
        }
 
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if ( weakReference.get() != null ){
                // update android ui
                Log.d("mmmmmmmm" , "handler " + msg.what ) ;
            }
        }
    }
 
    private static class MyRunnable implements Runnable {
 
        @Override
        public void run() {
            handler.sendEmptyMessage( MESSAGECODE ) ;
            try {
                Thread.sleep( 8000 );
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            handler.sendEmptyMessage( MESSAGECODE ) ;
        }
    }
}

还没完。上面这个代码已经有效的解决了Handler，Runnable 引用Activity实例从而导致内存泄漏的问题，但是这不够。因为内存泄漏的核心原因就是这个某个对象应该被系统回收内存的时候，却被其他对象引用，造成该内存无法回收。所以我们在写代码的时候，要始终绷着这个弦。再回到上面这个问题，当当前Activity调用finish销毁的时候，在这个Activity里面所有线程是不是应该在OnDestory()方法里，取消线程。当然是否取消异步任务，要看项目具体的需求，比如在Activity销毁的时候，启动一个线程，异步写log日志到本地磁盘，针对这个需求却需要在OnDestory()方法里开启线程。所以根据当前环境做出选择才是正解。

所以我们还可以修改代码为：在onDestroy() 里面移除所有的callback 和 Message 。

public class HandlerActivity extends AppCompatActivity {

    private final static int MESSAGECODE = 1 ;
    private static Handler handler ;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
 
        findViewById( R.id.finish ).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
        //创建Handler
        handler = new MyHandler( this ) ;
 
        //创建线程并且启动线程
        new Thread( new MyRunnable() ).start();
    }
 
    private static class MyHandler extends Handler {
        WeakReference<HandlerActivity> weakReference ;
        
        public MyHandler(HandlerActivity activity ){
            weakReference  = new WeakReference<HandlerActivity>( activity) ;
        }
 
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if ( weakReference.get() != null ){
                // update android ui
                Log.d("mmmmmmmm" , "handler " + msg.what ) ;
            }
        }
    }
 
    private static class MyRunnable implements Runnable {
 
        @Override
        public void run() {
            handler.sendEmptyMessage( MESSAGECODE ) ;
            try {
                Thread.sleep( 8000 );
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            handler.sendEmptyMessage( MESSAGECODE ) ;
        }
    }
 
    @Override
    protected void onDestroy() {
        super.onDestroy();
       //如果参数为null的话，会将所有的Callbacks和Messages全部清除掉。
        handler.removeCallbacksAndMessages( null );
    }
}

![在这里插入图片描述](https://img-blog.csdnimg.cn/20190506103609513.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTM4MjQxODA=,size_16,color_FFFFFF,t_70

4、AsyncTask造成内存泄漏

public class Activity2 extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_2);
 
        findViewById( R.id.finish2).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
 
        new AsyncTask<String,Integer,String>(){
 
            @Override
            protected String doInBackground(String... params) {
                try {
                    Thread.sleep( 6000 );
                } catch (InterruptedException e) {
                }
                return "ssss";
            }
 
            @Override
            protected void onPostExecute(String s) {
                super.onPostExecute(s);
                Log.d( "mmmmmm activity2 " , "" + s ) ;
            }
 
        }.executeOnExecutor( AsyncTask.THREAD_POOL_EXECUTOR , "" ) ;
         
    }
}

上面代码在activity中创建了一个匿名类AsyncTask，匿名类和非静态内部类相同，会持有外部类对象，这里也就是activity，因此如果你在Activity里声明且实例化一个匿名的AsyncTask对象，则可能会发生内存泄漏，如果这个线程在Activity销毁后还一直在后台执行，那这个线程会继续持有这个Activity的引用从而不会被GC回收，直到线程执行完成。

改进：
1、自定义静态AsyncTask类
2、AsyncTask的周期和Activity周期保持一致。也就是在Activity生命周期结束时要将AsyncTask cancel掉。

public class AsyncTaskActivity extends AppCompatActivity {

    private static MyTask myTask ;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_asynctask);
 
        findViewById( R.id.finish).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
        myTask = new MyTask() ;
        myTask.executeOnExecutor( AsyncTask.THREAD_POOL_EXECUTOR , "") ;
 
    }
 
    private static class MyTask extends AsyncTask{
 
        @Override
        protected Object doInBackground(Object[] params) {
            try {
                //模拟耗时操作
                Thread.sleep( 15000 );
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return "";
        }
    }
 
    @Override
    protected void onDestroy() {
        super.onDestroy();
 
        //取消异步任务
        if ( myTask != null ){
            myTask.cancel(true ) ;
        }
    }
}

5、Timer Tasks 造成内存泄漏

public class TimerActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_2);
 
        findViewById( R.id.finish2).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
        //开始定时任务
        timer();
    }
 
    void timer(){
        new Timer().schedule(new TimerTask() {
            @Override
            public void run() {
                while(true);
            }
        },1000 );  // 1秒后启动一个任务
    }
}

原因：这里内存泄漏在于Timer和TimerTask没有进行Cancel，从而导致Timer和TimerTask一直引用外部类Activity。

解决
1、在适当的时机进行Cancel。
2、TimerTask用静态内部类

public class TimerActivity extends AppCompatActivity {

    private TimerTask timerTask ;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_2);
 
        findViewById( R.id.finish2).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
 
        //开始定时任务
        timer();
    }
 
    void timer(){
        timerTask = new MyTimerTask() ;
        new Timer().schedule( timerTask ,1000 );  // 1秒后启动一个任务
    }
 
    private static class MyTimerTask extends TimerTask{
 
        @Override
        public void run() {
            while(true){
                Log.d( "ttttttttt" , "timerTask" ) ;
            }
        }
    }
 
    @Override
    protected void onDestroy() {
        super.onDestroy();
 
        //取消定时任务
        if ( timerTask != null ){
            timerTask.cancel() ;
        }
    }
}

6、静态Activities（static Activities）

public class MainActivity extends AppCompatActivity {

    private static MainActivity activity;
    TextView saButton;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        saButton = (TextView) findViewById(R.id.text);
        saButton.setOnClickListener(new View.OnClickListener() {
            @Override public void onClick(View v) {
                setStaticActivity();
                nextActivity();
            }
        });
    }
    
    void setStaticActivity() {
        activity = this;
    }

    void nextActivity(){
        startActivity(new Intent(this,RegisterActivity.class));
        SystemClock.sleep(1000);
        finish();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        //使用LeakCanary观察是否有内存泄漏
        MyApplication.getRefWatcher().watch(this);
    }
}

原因：在上面代码中，我们声明了一个静态的Activity变量并且在TextView的OnClick事件里引用了当前正在运行的Activity实例，所以如果在activity的生命周期结束之前没有清除这个引用，则会引起内存泄漏。因为声明的activity是静态的，会常驻内存，如果该对象不清除，则垃圾回收器无法回收变量。

改进：最简单的方法是在onDestory方法中将静态变量activity置空，这样垃圾回收器就可以将静态变量回收。

@Override
protected void onDestroy() {
    super.onDestroy();
    activity = null;
    //使用LeakCanary观察是否有内存泄漏
    MyApplication.getRefWatcher().watch(this);
}

7、静态View引起的内存泄漏

...
private static View view;
TextView saButton;
@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    saButton = (TextView) findViewById(R.id.text);
    saButton.setOnClickListener(new View.OnClickListener() {
        @Override public void onClick(View v) {
            setStaticView();
            nextActivity();
        }
    });
}

void setStaticView() {
    view = findViewById(R.id.sv_view);
}
...

原因：上面代码看似没有问题，在Activity里声明一个静态变量view，然后初始化，当Activity生命周期结束了内存也释放了，但是LeakCanary却显示出现了内存泄漏，为什么？问题出在这里，View一旦被加载到界面中将会持有一个Context对象的引用，在这个例子中，这个context对象是我们的Activity，声明一个静态变量引用这个View，也就引用了activity，所以当activity生命周期结束了，静态View没有清除掉，还持有activity的引用，因此内存泄漏了。

改进：在onDestroy方法里将静态变量置空。

@Override
protected void onDestroy() {
    super.onDestroy();
    view = null;
    MyApplication.getRefWatcher().watch(this);
}

8、单例设计模式造成的内存泄漏

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

上面的代码是一个最普通的单例模式，但是需要注意两个问题：

1、如果我们传入的Context是Application的Context的话，就没有任何问题，因为Application的Context生命周期和应用程序生命周期一样长。
2、如果我们传入的Context是Activity的Context的话，这时如果我们因为需求销毁了该Activity的话，Context也会随着Activity被销毁，但是单例还在持有对该类对象的引用，这时就会造成内存泄漏。

改进：

public class AppManager {

    private static AppManager instance;
    private Context context;
    
    private AppManager(Context context) {
        this.context = context.getApplicationContext();
    }
    
    public static AppManager getInstance(Context context) {
        if (instance != null) {
            instance = new AppManager(context);
        }
        return instance;
    }
}

这样的话不管我们传入什么样的Context，最终使用的都是Application的Context，单例的生命周期和应用一样长，这样就不会造成内存泄漏了。

9、使用系统服务引发的内存泄漏

https://www.jianshu.com/p/db272d939687

（多数内容来源于网络，侵删）

Amengww

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Android之内存泄漏

什么是内存泄漏在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。（源自： https://www.ibm.com/developerworks/cn/j...
复制链接

扫一扫