Android内存监控与分析（三）：内存分析及原理

Android内存监控与分析（三）：内存分析及原理

APP测试中难免会有各种显式或者隐式的内存泄漏（Memory Leak）问题，如果不及时发现处理，可能会因为内存泄漏导致各种奇怪的问题（如，卡顿和闪退），甚至可能出现因内存不足（Out of Memory，简称OOM）而导致APP崩溃。
本文将通过实战分析内存泄漏和内存溢出问题，并在必要时说明原理或机制。结构分为四个模块，如图1：

图1 内存监控与分析

三、内存分析及原理

针对hprof文件，看下到底是哪些对象更多，占用的内存更大；这块需要和开发一起分析，也是最难的部分。要分析内存泄漏的原因，我们可以从代码分析内存泄漏的根本原因：因为引用未释放。即，内存泄漏：
当一个对象已经不需要再使用了，本该被回收时，而有另外一个正在使用的对象持有它的引用从而就导致对象不能被回收。这种情况导致了本该被回收的对象不能被回收而停留在堆内存中，这样就可能出现内存泄漏。
说到引用与回收，需要谈谈Java内存管理、垃圾回收（GC）机制和Android的内存管理，从而知道其内在的联系。

（一）Java内存管理机制
Java虚拟机在执行程序时把它管理的内存分为若干数据区域，这些数据区域分布情况如图11所示：

图11 Java虚拟机运行时数据区

程序计数器：一块较小内存区域，指向当前所执行的字节码。如果线程正在执行一个Java方法，这个计数器记录正在执行的虚拟机字节码指令的地址，如果执行的是Native方法，这个计算器值为空。

Java虚拟机栈：线程私有的，其生命周期和线程一致，每个方法执行时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。

本地方法栈：与虚拟机栈功能类似，只不过虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则为使用到的Native方法服务。

Java堆： 是虚拟机管理内存中最大的一块，被所有线程共享，该区域用于存放对象实例，几乎所有的对象都在该区域分配。Java堆是内存回收的主要区域，因此很多时候也被称作“GC堆”。从内存回收角度看，由于现在的收集器大都采用分代收集算法，所以Java堆还可以细分为：新生代和老年代，再细分一点的话可以分为Eden空间、From Survivor空间、To Survivor空间等。根据Java虚拟机规范规定，Java堆可以处于物理上不连续的空间，只要逻辑上是连续的就行。 如果在堆中没有内存完成实例分配，并且也无法再扩展时，将会抛出OutofMemoryError异常。

方法区：与Java堆一样，是各个线程所共享的内存区域，用于存储已被虚拟机加载类信息、常亮、静态变量、即时编译器编译后的代码等数据。

运行时常量池：运行时常量池是方法区的一部分，Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池，用于存放编译期生成的各种字面量和符号引用。

（二）Java垃圾回收（GC）机制
从所周知，内存管理一直是编程的一大难题。例如，C/C++语言，内存管理是显式的，也就是说程序猿自己申请内存，自己释放内存。如果程序猿忘记或疏忽没有释放内存，那么就会产生内存泄漏。所以，Java语言引入了内存自动管理机制，即垃圾回收机制（GC，就是Garbage Collection的缩写）。但是，内存自动回收机制可以解决大部分问题，