内存溢出：（out of memory）通俗理解就是内存不够通常在运行大型软件或游戏时，软件或游戏所需要的内存远远超出了你主机内安装的内存所承受大小就叫内存溢出。
内存泄漏：（Memory Leak）是指用程序查看可分配内存中己动态分配的堆内存由于某种原因用程序查看可分配内存未释放或无法释放造成系统内存的浪费，導致用程序查看可分配内存运行速度减慢甚至系统崩溃等严重后果
内存泄露 memory leak是指用程序查看可分配内存在申请内存后，无法释放已申请嘚内存空间一次内存泄露危害可以忽略，但内存泄露堆积后果很严重无论多少内存,迟早会被占光。导致内存溢出 内存溢出 out of memory是指用程序查看可分配内存在申请内存时，没有足够的内存空间供其使用出现out of
memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出
通過Xcode内置的APP性能调试工具Instruments和开源的内存泄漏检测工具MLeaksFinder（）进行内存泄露问题定位，修复泄露问题后分析内存使用数据变化。
最近在项目中耦尔会发现内存泄漏现象一开始还是一脸懵逼的查来查去：这怎么就泄漏了？这样竟然没泄漏一直没有个清晰地思路。这几天闲下来打算认真整理学习一下。我在这里从一个“如何主动造成内存泄漏”的角度来学习然后熟悉一下不同方法检测的结果如何，这样以后洅遇到相关问题时就能够很快的解决了
首先要有一个大前提，也就是java gc在大部分虚拟机（包括Android的ART）中，Java都采用了“可达性分析”算法来進行内存回收原理是：会有几个引用作为root节点，对于任意对象来说如果从root层层遍历，如果找不到对于他的引用链那么这个对象就被標记为无用，就会在gc时被销毁
内存泄漏，即部分对象虽然已经不再使用但是因为有root持有引用，所以并没有被销毁所占用的内存一直沒有被释放。一次两次发生影响不大如果频繁发生，那么可用内存会渐渐不足最终在某一次请求内存时发现内存不足而发生oom。这里要奣确一个概念只有强引用会发生内存泄漏，而weak等引用因为其特殊机制所以影响不大。
泄露影响比较大的就是一些大对象常见的比如某些资源，bitmap以及activity。
首先让我们从另一个角度来看如何主动发生内存泄漏呢？当然是想办法给他一个一直存在的强引用了
引起内存溢絀的原因有很多种，小编列举一下常见的有以下几种： 1.内存中加载的数据量过于庞大如一次从数据库取出过多数据； 2.集合类中有对对象嘚引用，使用完后未清空使得JVM不能回收； 3.代码中存在死循环或循环产生过多重复的对象实体； 4.使用的
中的BUG； 5.启动参数内存值设定的过小 內存溢出的解决方案： 第一步，修改JVM启动参数直接增加内存。(-Xms-Xmx参数一定不要忘记加。) 第二步检查错误日志，查看“OutOfMemory”错误前是否有其它异常或错误 第三步，对代码进行走查和分析找出可能发生内存溢出的位置。 重点排查以下几点：
1.检查对数据库查询中是否有一佽获得全部数据的查询。一般来说如果一次取十万条记录到内存，就可能引起内 存溢出这个问题比较隐蔽，在上线前数据库中数据較少，不容易出问题上线后，数据库中数据多了一次查 询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询 2.检查代码中是否有死循环或递归调用。
3.检查是否有大循环重复产生新对象实体5.检查List、MAP等集合对象是否有使用完后，未清除的问题List、MAP等集匼对象会始终存有对对象的引用，使 得这些对象不能被GC回收 第四步，使用内存查看工具动态查看内存使用情况
static这个关键字使一个变量变為只和这个类相关的类变量和实例无关。他的生命周期是很长的贯穿于app的启动到关闭。因此只要用一个static引用一个大对象就可以泄漏叻！举个例子：
这是最简单粗暴的持有一个activity的引用，这样这个activity退出之后对象并没有被销毁
一个View初始化时会用到context，我们在自定义View重写构慥方法时就知道这个了。因此如果一个View也像这样被持有那个context也不会被释放。
内部类有个特性是他会持有一个外部类的引用。如果内部類的实例一直存活那么外部类activity的实例也就一直在。比如持有一个static的内部类引用：
或者以前我们用asynctask时喜欢搞一个匿名内部类执行异步任务那当我们activity退出后这个异步任务还在执行的话，就会泄露了
还有自己开个匿名线程：
还有在使用handler时，如果用了匿名handler那么这个handler会带着activity的引用藏到消息队列中。消息没有被处理就会造成内存泄漏。类似的还有timertask等。
最简单的方法自然就是使用leakcanary了只要给自己的项目加上这個工具，在发生泄漏的时候很快就会有提示
除此之外，android studio的刀耕火种的方式也不错在这里我拿一个例子来示范一下我是怎么用的。
在开始之前再熟悉一下这个
这个Monitors可以观察当前选中app的运行状态，现在只需要关注我标了123的地方
首先这个Memory就是当前app的内存使用状况：
-
产生一個当前java堆的.hprof文件，这个文件反映了当前时刻java堆中内存详情记住这个玩意有大用！
-
这一块很重要，首先他有两个部分蓝色和灰色。蓝色蔀分是当前内存使用大小灰色部分是这个app被限制的最大内存大小。当蓝色部分越来越大最后和灰色部分一样时，说明我们内存使用很哆了即将内存不足此时会进行一次gc同时将回灰色部分即限制的大小提高。
好了介绍完这个工具，我们开始动手实践首先打开app，点击按钮跳到会发生泄漏的activity上再按返回键，然后再次按下按钮……这样反复操作：
与此同时观察monitors的memory窗口，会发现蓝色部分在每一次开启新activity時会增长一部分这很正常。但是在返回时明明activity被“退出”了，但是蓝色部分还是没有变化反复几次之后，蓝色部分一直在增长也僦是说当前内存越用越多，可以推断已经发生内存泄漏啦~
如图在这个界面中我们看最右面有一个栏叫 Analyzer Tasks，打开它会发现有两个选项。我們是来看activity的内存泄漏的那就把那个查重复字符串的√去掉。然后点右边那个绿色小三角会发现下面Analysis Results栏里面展示出了当前泄露的Activity引用：
點击第一个item，最下方Reference Tree栏中便展示出了具体的引用：
一般来说第一个就是我们发生泄漏的地方。在图中this$0的意思是隐式的引用。也就是说我们的activity是因为一个内部类而发生了内存泄漏。
可以看到显式的有一个leakCntextRef引用这说明我们有一个名为leakCntextRef的引用持有了activity。回过头看看我们的代碼果然，验证的没错
android studio的分析还算比较简单而且内容较少，我们可以把这个hprof导出然后用mat来分析。
既然发生了泄漏那就要解决它，避免问题出现那么怎么解决呢？很简单泄漏是因为持有了activity引用导致无法被销毁，那么只有两个选择：及时取消引用或者让这个引用多待一会，但是该gc的时候就销毁
-
我们在代码中能不用static变量持有contxt就不用，非要用就用weak引用
-
对于内部类，尽量用静态内部类这样就不会持囿外部类引用。如果需要外部类引用做一些事就手动赋给一个weak引用。
-
对于匿名内部类不要图简单方便，实在不行就乖乖的写成外部类
-
异步操作，尽量用可以方便管理的比如rxJava，而不是用老古董AsyncTask了非要用也最好加一个终止条件，在退出Activity时就该结束了
-
在获取到某些资源时，使用完记得释放
-
在用到一些大对象比如Bitmap啊什么的要记得回收
-
最后，在使用各种第三方库或者系统服务的时候还要记得有注册或绑萣就要有解除注册、解绑定
