内存的分配策略概述
程序运行时的内存分配有三种策略,分别是静态的,栈式的,和堆式的，对应的，三种存储策略使用的内存空间主要分别是静态存储区（也称方法区）、堆区和栈区。
静态存储区（方法区）：内存在程序编译的时候就已经分配好，这块内存在程序整个运行期间都存在。它主要存放静态数据、全局static数据和常量。
栈区：在执行函数时，函数内局部变量的存储单元都可以在栈上创建，函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。
堆区：亦称动态内存分配。程序在运行的时候用malloc或new申请任意大小的内存，程序员自己负责在适当的时候用free或delete释放内存（Java则依赖垃圾回收器）。动态内存的生存期可以由我们决定，如果我们不释放内存，程序将在最后才释放掉动态内存。 但是，良好的编程习惯是：如果某动态内存不再使用，需要将其释放掉。
堆和栈的区别：
在函数中（说明是局部变量）定义的一些基本类型的变量和对象的引用变量都是在函数的栈内存中分配。当在一段代码块中定义一个变量时，java就在栈中为这个变量分配内存空间，当超过变量的作用域后，java会自动释放掉为该变量分配的内存空间，该内存空间可以立刻被另作他用。
堆内存用于存放所有由new创建的对象（内容包括该对象其中的所有成员变量）和数组。在堆中分配的内存，由java虚拟机自动垃圾回收器来管理。在堆中产生了一个数组或者对象后，还可以在栈中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，在栈中的这个特殊的变量就变成了数组或者对象的引用变量，以后就可以在程序中使用栈内存中的引用变量来访问堆中的数组或者对象，引用变量相当于为数组或者对象起的一个别名，或者代号
堆是不连续的内存区域（因为系统是用链表来存储空闲内存地址，自然不是连续的），堆大小受限于计算机系统中有效的虚拟内存（32bit系统理论上是4G），所以堆的空间比较灵活，比较大。栈是一块连续的内存区域，大小是操作系统预定好的，windows下栈大小是2M（也有是1M，在编译时确定，VC中可设置）。
对于堆，频繁的new/delete会造成大量内存碎片，使程序效率降低。对于栈，它是先进后出的队列，进出一一对应，不产生碎片，运行效率稳定高。
image.png
所以我们可以得出结论：
1.局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中。因为它们属于方法中的变量，生命周期随方法而结束。
2.成员变量全部存储与堆中（包括基本数据类型，引用和引用的对象实体），因为它们属于类，类对象终究是要被new出来使用的。
3.我们所说的内存泄露，只针对堆内存，他们存放的就是引用指向的对象实体。
内存泄露产生的原因
在Java中，内存的分配是由程序完成的，而内存的释放是由垃圾收集器(Garbage Collection，GC)完成的，程序员不需要通过调用函数来释放内存，但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间。
Java的内存垃圾回收机制是从程序的主要运行对象(如静态对象/寄存器/栈上指向的堆内存对象等)开始检查引用链，当遍历一遍后得到上述这些无法回收的对象和他们所引用的对象链，组成无法回收的对象集合，而其他孤立对象（集）就作为垃圾回收。GC为了能够正确释放对象，必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。
在Java中，这些无用的对象都由GC负责回收，因此程序员不需要考虑这部分的内存泄露。虽然，我们有几个函数可以访问GC，例如运行GC的函数System.gc()，但是根据Java语言规范定义，该函数不保证JVM的垃圾收集器一定会执行。因为不同的JVM实现者可能使用不同的算法管理GC。通常GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。
但是我们仍然可以去监听系统的GC过程，以此来分析我们应用程序当前的内存状态。那么怎样才能去监听系统的GC过程呢？其实非常简单，系统每进行一次GC操作时，都会在LogCat中打印一条日志，我们只要去分析这条日志就可以了，日志的基本格式如下所示：
D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <Pause_time>
首先第一部分GC_Reason，这个是触发这次GC操作的原因，一般情况下一共有以下几种触发GC操作的原因：
GC_CONCURRENT: 当我们应用程序的堆内存快要满的时候，系统会自动触发GC操作来释放内存。
GC_FOR_MALLOC: 当我们的应用程序需要分配更多内存，可是现有内存已经不足的时候，系统会进行GC操作来释放内存。
GC_HPROF_DUMP_HEAP: 当生成HPROF文件的时候，系统会进行GC操作，关于HPROF文件我们下面会讲到。
GC_EXPLICIT: 这种情况就是我们刚才提到过的，主动通知系统去进行GC操作，比如调用System.gc()方法来通知系统。或者在DDMS中，通过工具按钮也是可以显式地告诉系统进行GC操作的。
接下来第二部分Amount_freed，表示系统通过这次GC操作释放了多少内存。
然后Heap_stats中会显示当前内存的空闲比例以及使用情况（活动对象所占内存 / 当前程序总内存）。
最后Pause_time表示这次GC操作导致应用程序暂停的时间。关于这个暂停的时间，Android在2.3的版本当中进行过一次优化，在2.3之前GC操作是不能并发进行的，也就是系统正在进行GC，那么应用程序就只能阻塞住等待GC结束。虽说这个阻塞的过程并不会很长，也就是几百毫秒，但是用户在使用我们的程序时还是有可能会感觉到略微的卡顿。而自2.3之后，GC操作改成了并发的方式进行，就是说GC的过程中不会影响到应用程序的正常运行，但是在GC操作的开始和结束的时候会短暂阻塞一段时间，不过优化到这种程度，用户已经是完全无法察觉到了。
我们来看看Java中需要被回收的垃圾：
｛
Person p1 = new Person();
……
｝
引用句柄p1的作用域是从定义到“｝”处，执行完这对大括号中的所有代码后，产生的Person对象就会变成垃圾，因为引用这个对象的句柄p1已超过其作用域，p1失效，在栈中被销毁，因此堆上的Person对象不再被任何句柄引用了。 因此person变为垃圾，会被回收。
这里我们需要讲述一个关键词：引用，通过A能调用并访问到Ｂ，那就说明Ａ持有Ｂ的引用，或A就是B的引用，Ｂ的引用计数＋１.
（１）比如 Person p1 = new Person();通过Ｐ１能操作Person对象，因此Ｐ１是Person的引用；
（２）比如类O中有一个成员变量是I类对象，因此我们可以使用o.i的方式来访问I类对象的成员，因此o持有一个i对象的引用。
GC过程与对象的引用类型是严重相关的，我们来看看Java对引用的分类Strong reference, SoftReference, WeakReference, PhatomReference
image.png
在Android应用的开发中，为了防止内存溢出，在处理一些占用内存大而且声明周期较长的对象时候，可以尽量应用软引用和弱引用技术。
软/弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。利用这个队列可以得知被回收的软/弱引用的对象列表，从而为缓冲器清除已失效的软/弱引用。
假设我们的应用会用到大量的默认图片，比如应用中有默认的头像，默认游戏图标等等，这些图片很多地方会用到。如果每次都去读取图片，由于读取文件需要硬件操作，速度较慢，会导致性能较低。所以我们考虑将图片缓存起来，需要的时候直接从内存中读取。但是，由于图片占用内存空间比较大，缓存很多图片需要很多的内存，就可能比较容易发生OutOfMemory异常。这时，我们可以考虑使用软/弱引用技术来避免这个问题发生。以下就是高速缓冲器的雏形：
首先定义一个HashMap，保存软引用对象。
1.private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>();
再来定义一个方法，保存Bitmap的软引用到HashMap
public class CacheSoftRef {
//首先定义一个HashMap,保存引用对象
private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>();
//再来定义一个方法，保存Bitmap的软引用到HashMap
public void addBitmapToCache(String path) {
//强引用的Bitmap对象
Bitmap bitmap = BitmapFactory.decodeFile(path);
//软引用的Bitmap对象
SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
//添加该对象到Map中使其缓存
imageCache.put(path, softBitmap);
}
//获取的时候，可以通过SoftReference的get()方法得到Bitmap对象
public Bitmap getBitmapByPath(String path) {
//从缓存中取软引用的Bitmap对象
SoftReference<Bitmap> softBitmap = imageCache.get(path);
//判断是否存在软引用
if (softBitmap == null) {
return null;
}
//通过软引用取出Bitmap对象，如果由于内存不足Bitmap被回收，将取得空，如果未被回收，
//则可重复使用，提高速度。
Bitmap bitmap = softBitmap.get();
return bitmap;
}
}
使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。
如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。
另外可以根据对象是否经常使用来判断选择软引用还是弱引用。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。
所以我们得出内存泄漏的原因：堆内存中的长生命周期的对象持有短生命周期对象的强/软引用，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是Java中内存泄露的根本原因。
内存泄漏的检测
说了那么多关于内存分配的知识，接下来我们就看看Android给我们提供了哪些工具来解决内存泄漏的问题
Allocation Tracker(Device Monitor)
Allocation Tracker位于Android Device Monitor中
image.png
Allocation Tracker面板
image.png
各名称的含义如下:
image.png
Allocation Tracker操作
1.首先进入你要追踪的界面
2.点击Start Tracking按钮，开始跟踪内存分配轨迹
3.操作你的界面，尽量时间短点
4.点击Get Allocations按钮，抓去内存分配轨迹信息，显示在右边的面板中，默认以内存大小排序，你可以以分配顺序排序或者仍以列排序。
5.logcat中会显示出这次的轨迹共抓到内存分配轨迹记录数，可以简单的理解分配了多少次内存，这个数值和Alloc order的最大值是相等的
6.如果你不想看那么多乱七八糟的，你可以使用Filter来过滤，输入包名就可以了。
跟踪内存轨迹
如果这个时候我们想单独获取某次操作的内存轨迹，首先一定要记得Stop Tracking再Start Tracking一下，让追踪点初始化一下，然后就进行我们需要观察内存变化的操作，然后点击Get Allocations，这个时候我们从首页进入一个详情页,看一下我们的内存分配轨迹：
image.png
追踪到的内存分配20293次，看着是不是有点无从下手，没关系，用Filter过滤下:
image.png
过滤后，就剩下了跟我们App源码有关系的分配轨迹，我们随便选择一栏，可以看到其trace信息:
image.png
上图中，我们可以看出来，在第635次内存分配中，分配的是IntroduceFragment对象，占用内存224字节，处理线程Id为3245，在java.lang.Class的newInstance方法中分配的。从trace信息可以看出来该方法一步一步被调用的信息。
DDMS的Heap Viewer
Heap Viewer能做什么？
实时查看App分配的内存大小和空闲内存大小
发现Memory Leaks
在Devices 中，点击要监控的程序。
点击Devices视图界面中最上方一排图标中的“Update Heap”
点击Heap视图
点击Heap视图中的“Cause GC”按钮
到此为止需检测的进程就可以被监视。
image.png
按上图的标记顺序按下，我们就能看到内存的具体数据，右边面板中数值会在每次GC时发生改变，包括App自动触发或者你来手动触发。
ok，现在来解释下面板中的名词
总览
image.png
image.png
详情
image.png
image.png
下面是每一个对象都有的列名含义：
image.png
当我们点击某一行时，可以看到如下的柱状图：
image.png
横坐标是对象的内存大小，这些值随着不同对象是不同的，纵坐标是在某个内存大小上的对象的数量
Heap Viewer的使用
我们说Heap Viewer适合发现内存泄漏的问题，那么如何检测呢？
那么如何检测呢？
进入某应用，不断的操作该应用，同时注意观察data object的Total Size值，正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。
所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落。随着操作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被杀掉。
MAT工具
那么通过上面DDMS工具，现在我们已经可以比较轻松地发现应用程序中是否存在内存泄露的现象了。
我们应该怎么定位到具体是哪里出的内存泄露呢？这就需要借助一个内存分析工具了，叫做Eclipse Memory Analyzer（MAT）。
为了使用该工具，我们需要hprof文件。但是该文件不能直接被MAT使用，需要进行一步转化，可以使用hprof-conv命令来转化，但是Android Studio可以直接转化,转化方法如下：
1.选择一个hprof文件，点击右键选择Export to standard .hprof选项。
image.png
2.填写更改后的文件名和路径:
image.png
点击OK按钮后，MAT工具所需的文件就生成了，下面我们用MAT来打开该工具:
1.打开MAT后选择File->Open File选择我们刚才生成的doctorq.hprof文件
2.选择该文件后，MAT会有几秒种的时间解析该文件，有的hprof文件可能过大，会有更长的时间解析，解析后，展现在我们的面前的界面如下:
image.png
上图最中央的那个饼状图展示了最大的几个对象所占内存的比例，这张图中提供的内容并不多，我们可以忽略它。在这个饼状图的下方就有几个非常有用的工具了，我们来学习一下。
Histogram可以列出内存中每个对象的名字、数量以及大小。
Dominator Tree会将所有内存中的对象按大小进行排序，并且我们可以分析对象之间的引用结构。
现在点击Dominator Tree，结果如下图所示：
image.png
首先Retained Heap表示这个对象以及它所持有的其它引用（包括直接和间接）所占的总内存，因此从上图中看，前两行的Retained Heap是最大的，我们分析内存泄漏时，内存最大的对象也是最应该去怀疑的。
在每一行的最左边都有一个文件型的图标，这些图标有的左下角带有一个点，有的则没有。带点的对象就表示是可以被GC Roots访问到的，可以被GC Root访问到的对象都是无法被回收的。那么这就说明所有带红色的对象都是泄漏的对象吗？当然不是，因为有些对象系统需要一直使用，本来就不应该被回收。我们可以注意到，上图当中所有带点的对象最右边都有写一个System Class，说明这是一个由系统管理的对象，并不是由我们自己创建并导致内存泄漏的对象。
上图当中，除了带有System Class的行之外，最大的就是第二行的Bitmap对象了，虽然Bitmap对象现在不能被GC Roots访问到，但不代表着Bitmap所持有的其它引用也不会被GC Roots访问到。现在我们可以对着第二行点击右键 -> Path to GC Roots -> exclude weak references，为什么选择exclude weak references呢？因为弱引用是不会阻止对象被垃圾回收器回收的，所以我们这里直接把它排除掉
可以看到，Bitmap对象经过层层引用之后，到了MainActivityLeakClass这个对象，然后在图标的左下角有个点，就说明在这里可以被GCRoots访问到了，并且这是由我们自己创建的Thread，并不是SystemClass了，那么由于MainActivityLeakClass这个对象，然后在图标的左下角有个点，就说明在这里可以被GCRoots访问到了，并且这是由我们自己创建的Thread，并不是SystemClass了，那么由于MainActivityLeakClass能被GC Roots访问到导致不能被回收，导致它所持有的其它引用也无法被回收了，包括MainActivity，也包括MainActivity中所包含的图片。
通过这种方式，我们就成功地将内存泄漏的原因找出来了。
Histogram的用法
用的最多的功能是 Histogram,点击 Actions下的 Histogram项将得到 Histogram结果：
image.png
它按类名将所有的实例对象列出来，可以点击表头进行排序,在表的第一行可以输入正则表达式来匹配结果 :
image.png
在某一项上右键打开菜单选择 list objects ->with incoming refs 将列出该类的实例：
image.png
它展示了对象间的引用关系，比如展开后的第一个子项表示这个 HomePage(0x420ca5b0)被HomePageContainer(0x420c9e40)中的 mHomePage属性所引用.
快速找出某个实例没被释放的原因，可以右健 Path to GC Roots–>exclue all phantom/weak/soft etc. reference :
image.png
得到的结果是：
image.png
从表中可以看出 PreferenceManager -> … ->HomePage这条线路就引用着这个 HomePage实例。用这个方法可以快速找到某个对象的 GC Root,一个存在 GC Root的对象是不会被 GC回收掉的.
Histogram 对比
为查找内存泄漏，通常需要两个 Dump结果作对比，打开 Navigator History面板，将两个表的 Histogram结果都添加到 Compare Basket中去 :
image.png
添加好后，打开 Compare Basket面板，得到结果：
image.png
点击右上角的 ! 按钮，将得到比对结果：
image.png
注意，上面这个对比结果不利于查找差异，可以调整对比选项：
image.png
再把对比的结果排序，就可得到直观的对比结果：
image.png
也可以对比两个对象集合，方法与此类似，都是将两个 Dump结果中的对象集合添加到Compare Basket中去对比。找出差异后用 Histogram查询的方法找出 GC Root，定位到具体的某个对象上。
LeakCanary
有别于MAT和AndroidStudio中Monitors的实时内存占用图，使用LeakCanary分析内存泄露就简单多了LeakCanary是Square开源了一个内存泄露自动探测神器 。这是项目的github仓库地址：https://github.com/square/leakcanary 。使用非常简单，在build.gradle中引入包依赖
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'
在Application中的onCreate方法中增加初始化代码：
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for
// heap analysis.
// You should not init your app in this process.
return;
}
LeakCanary.install(this);
image.png
很明显，WebSiteQueryActivity泄露了。首先，static 的MaskHeadView.fLayout变量引用了FrameLayout.mContext对象，这个对象的引用就是指向了WebSiteQueryActivity的实例，导致了它的泄漏，在第二节中我们说过static对象是内部的static对象是比较容易造成内存泄漏的，检查代码发现，MaskHeadView直接在WebSiteQueryActivity的xml文件中使用了，因此持有WebSiteQueryActivity的实例，因为fLayout对象是静态的，因此它的生命周期与Application同样长，因此WebSiteQueryActivity退出后，它的实例引用依然被fLayout持有，导致它无法被回收从而内存泄露了。仔细检查代码，发现fLayout并没有被外部使用到，应该是之前的开发者手抖加了个static字段上去或者是现在不用了，但是没有去掉，在这里我直接去掉了这个修饰符，在此build代码，这个内存泄漏的现象消失了。
/去掉static修饰符，避免static对象引起的内存泄漏
private static FrameLayout fLayout;
public MaskHeadView(Context context, AttributeSet attrs) {
super(context, attrs);
this.context=context;
initView(context);
}
private void initView(Context context2) {
view = LayoutInflater.from(context).inflate(R.layout.
mask_head_view, this);
fLayout=(FrameLayout) view.findViewById(R.id.
mask_container);
}
这只是个极简单的例子，但方法是一样的。顺便提一句，其实无论是MAT工具的内存分析，还是AndroidStudio中自带的分析工具亦或是LeakCanary，原理都是一样的，都是dump java heap出来进行分析，找到泄漏的问题，只是LeakCanary帮我们把分析的工作做了。但值得一提的是，LeakCanary并不是万能的，有些内存泄漏，它也无法检测出来。
好了，关于内存泄露的相关内容就介绍到这，后期将持续更新，可以关注一下查看后续。
本文转自csdn一位博主[伯努力不努力]
网友评论