Android 性能优化之谈谈Java内存区域

绝地灬酷狼 2022-05-28 02:54 199阅读 0赞

# Android 性能优化 之谈谈Java内存区域 #

> **基础的扎实程度直接决定高度。**

最近一年副业主要在学习投资和技能学习，把以前学习内存分析的一些笔记总结发出来，写了很多笔记总结都没有写完就又忙着了，最近再次总结复习学习一遍，还有提醒各位同学一定要学会投资。。

> 了解Android 内存管理，就有必要了解Java GC机制，必须要理解JVM 内存区域，这里我们主要从概念上介绍Java虚拟机内存的各个区域。
> 
> Android 应用运行时大部分时间都用于处理内存数据，虽然很多开发者都意识到优化内存，但并不是所有人都知道内存使用对性能的影响，网上也有很多关于内存优化技术的文章，但大多都不够系统，没有贯通全局。在《Android 性能优化之String篇》文中我们理解了一个对象占用空间的大小以及String 字符串对我们性能的影响，而在本文中我们将学习一些Android的内存，主要是基础的java 的内存管理，Java程序在运行的过程中管理的内存的数据区，为后面的Android内存分析做为铺垫。  
> 在阅读过程中有任何问题，请及时联系。如需转载请注明 [fuchenxuan blog][]  
> 本章系[《Android 之美 从0到1 – 高手之路》][Android _ _0_1 _]Android 性能优化 之深入理解Java内存结构。

*  Android 性能优化 之谈谈Java内存区域
    
     *  Java 内存区域
        
         *  程序计数器
         *  虚拟机栈（JVM Stack）
         *  本地方法栈（Native Method Statck）
         *  堆区（Heap）
         *  方法区（Method Area）
         *  运行时常量池
         *  运行时常量池与Class文件常量池区别
     *  对象的创建
     *  对象的访问
        
         *  句柄方式
         *  直接指针方式
     *  总结

## Java 内存区域 ##

Java虚拟机在执行程序过程中会把管理的内存划分为不同的数据区域，包括方法区、堆、虚拟机栈、本地方法栈、程序计数器这5个部分的运行时数据区。如下图：  
![172815_vvql_567457.jpg][]

### 程序计数器 ###

在计算机组成原理里，CPU内部的寄存器中就包含一个程序计数器，存放程序执行的下一条指令地址。  
以下引自[wiki][]的一段介绍。

依照特定机器的细节而不同，他可能是保存着正在被运行的指令，也可能是下一个要运行指令的地址。程序计数器在每个指令周期会自动地增加，所以指令会正常地从寄存器中连续地被取出。某些指令，像是跳跃和子程序调用，会中断程序执行的序列，将新的数值内容存放到程序计数器中。  
在大部分的处理器，指令指针都是在提取程序指令后就被立即增加；也就是说跳跃指令的目的地址，是由跳跃指令的运算对象加上跳跃指令之后下一个指令的地址（比特或字节，视电脑形态而定）来获得目的地。

而我们的JVM内存中的程序计数器也是这样的作用，它储存JVM当前执行bytecode的地址。

Java虚拟机中的程序计数器是Java运行时数据区中的一小块内存区域，但是它的功能和通常的程序计数器是类似的，它指向虚拟机正在执行字节码指令的地址。具体点儿说，当虚拟机执行的方法不是native的时，程序计数器指向虚拟机正在执行字节码指令的地址；当虚拟机执行的方法是native的时，程序计数器中的值是未定义的。另外，程序计数器是线程私有的，也就是说，每一个线程都拥有仅属于自己的程序计数器

此内存区域是唯一一个在 Java 虚拟机规范  
中没有规定任何 OutOfMemoryError 情况的区域。

### 虚拟机栈（JVM Stack） ###

与程序计数器一样，Java 虚拟机栈(Java Virtual Machine Stacks)也是线程私有的，它的生命周期与 线程相同。虚拟机栈描述的是 Java 方法执行的内存模型:每个方法被执行的时候都会同时创建一个栈帧(Stack Frame)用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，  
就对应着一个栈帧在 虚拟机栈中从入栈到出栈的过程。

局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、 double)、对象引用(reference 类型)，它不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向 4 / 31  
对象起始地址的引用指针，也可能指向一个代表对象的句柄或者其他与此对象相关的位置)和 returnAddress  
类型(指向了一条字节码指令的地址)。  
其中 64 位长度的 long 和 double 类型的数据会占用 2 个局部变量空间(Slot)，其余的数据类型只占 用 1 个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大 的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。 在 Java 虚拟机规范中，对这个 区域规定了两种异常状况:如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异  
常;如果虚拟机栈可以动态扩展(当前大部分的 Java 虚拟机都可动态扩展，只不过 Java 虚拟机规范中也允许  
固定长度的虚拟机栈)，当扩展时无法申请到足够的内存时会抛出 OutOfMemoryError 异常。

### 本地方法栈（Native Method Statck） ###

本地方法栈(Native Method Stacks)与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为  
虚拟机执行 Java 方法(也就是字节码)服务，而本地方法栈则是为虚拟机使用到的 Native 方法服务。虚拟机 规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实 现它。甚至有的虚拟机(譬如 Sun HotSpot 虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一  
样，本地方法栈区域也会抛出 StackOverflowError 和 OutOfMemoryError 异常。

### 堆区（Heap） ###

对于大多数应用来说，Java 堆(Java Heap)是 Java 虚拟机所管理的内存中最大的一块。Java 堆是被所 有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存 放对象实例 ，几乎所有的对象 实例都在这里分配内存。这一点在 Java 虚拟机规范中的描述是:所有的对象实例以及数组都要在堆上分配，但 是随着 JIT 编译器的发展与逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发 生，所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。  
Java 堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC 堆”(Garbage Collected Heap，幸  
好国内没翻译成“垃圾堆”)。如果从内存回收的角度看，由于现在收集器基本都是采用的分 代 收 集 算法，所以 Java 堆中还可以细分为:新生代和老年代;再细致一点的有 Eden 空间、From Survivor 空间、To Survivor 空间等。如果从内存分配的角度看，线程共享的 Java 堆中可能划分出多个线程私有的分配缓冲区(Thread  
Local Allocation Buffer，TLAB)。不过，无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然 是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。在本章中，我们仅仅针对内存区  
域的作用进行讨论，Java 堆中的上述各个区域的分配和回收等细节将会是下一章的主题。  
根据 Java 虚拟机规范的规定，Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可， 就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都  
是按照可扩展来实现的(通过-Xmx 和-Xms 控制)。如果在堆中没有内存完成实例分配，并且堆也无法再扩展 时，将会抛出 OutOfMemoryError 异常。

堆内存唯一目的就是存放创建的对象实例，所有对象实例和数组都要在这里分配内存，因此也是垃圾回收的主要区域。根据虚拟机规范，java堆可以在物理空间上不连续，只要逻辑上连续即可，当堆内存无法继续分配时会抛出OutOfMemery异常。

### 方法区（Method Area） ###

方法区(Method Area)与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类  
信息、常量、静态变量、即时编译器编译后的代码等数据。虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑 部分，但是它却有一个别名叫做 Non-Heap(非堆)，目的应该是与 Java 堆区分开来。

对于习惯在 HotSpot 虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久 代”Permanent Generation)，本质上两者并不等价，仅仅是因为 HotSpot 虚拟机的设计团队选择把 GC 分  
代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机(如 BEA JRockit、IBM J9 等) 来说是不存在永久代的概念的。即使是 HotSpot 虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久 代并“搬家”至 Native Memory 来实现方法区的规划了。  
Java 虚拟机规范对这个区域的限制非常宽松，除了和 Java 堆一样不需要连续的内存和可以选择固定大小  
或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据  
进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标 主要是针对常量池的回收和对类型 的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区  
域的回收确实是有必要的。在 Sun 公司的 BUG 列表中， 曾出现过的若干个严重的 BUG 就是由于低版本的  
HotSpot 虚拟机对此区域未完全回收而导致内存泄漏。 根据 Java 虚拟机规范的规定，当方法区无法满足内存 分配需求时，将抛出 OutOfMemoryError 异常。

用于存储被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码数据等。Java虚拟机规范把方法区描述为堆的一个逻辑部分。  
运行时常量池是方法区的一部分，Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项就是常量池，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

### 运行时常量池 ###

运行时常量池(Runtime Constant Pool)是方法区的一部分。Class 文件中除了有类的版本、字段、 方法、接口等描述等信息外，还有一项信息是常量池(Constant Pool Table)，用于存放编译期生成的各种字 面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。 Java 虚拟机对 Class 文件的每 一部分(自然也包括常量池)的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求， 这样才会被虚拟机认可、装载和执行。但对于运行时常量池，Java 虚拟机规范没有做任何细节的要求，不同的 提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过，一般来说，除了保存 Class 文件中描述 的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。 运行时常量池相对于 Class 文件常量池  
的另外一个重要特征是具备动态性，Java 语言并不要求常量一定只能在编译期产生，也就是并非预置入 Class 文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员  
利用得比较多的便是 String 类的 intern()方法。 既然运行时常量池是方法区的一部分，自然会受到方法区内 存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常。

### 运行时常量池与Class文件常量池区别 ###

*  JVM对Class文件中每一部分的格式都有严格的要求，每一个字节用于存储那种数据都必须符合规范上的要求才会被虚拟机认可、装载和执行；但运行时常量池没有这些限制，除了保存Class文件中描述的符号引用，还会把翻译出来的直接引用也存储在运行时常量区
 *  相较于Class文件常量池，运行时常量池更具动态性，在运行期间也可以将新的变量放入常量池中，而不是一定要在编译时确定的常量才能放入。最主要的运用便是String类的intern()方法

## 对象的创建 ##

以上我们介绍了5个数据区域，三个是线程隔离的，它们有：Java虚拟机栈，本地方法栈，程序计数器。另外还有两个数据区域是线程共享的，这两个区域是垃圾回收发生的地方，它们分别是：堆，方法区。

我们最常见的也是最简单的创建对象有以下几种方式：

**通过这种方式我们可以调用任意的构造函数（无参的和有参的）去创建对象。**

Object object = new Object();

**使用Class类的newInstance方法(反射机制)**  
　  
`Student stu = Student.class.newInstance();`

new 指令时主要涉及一些一个过程：

*  检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过
 *  类加载检查通过
 *  虚拟机java堆为新主对象分配内存，对象所需内存的大小在类加载完成后确定
 *  虚拟机将分配到的内存空间都初始化为零值
 *  设置对象头，对象头中存储了该对象是拿了类的实例等信息
 *  执行 init 方法，把对象初始化

![这里写图片描述][70]

## 对象的访问 ##

介绍完 Java 虚拟机的运行时数据区之后，我们就可以来探讨一个问题:在 Java 语言中，对象访问是如何 进行的?对象访问在 Java 语言中无处不在，是最普通的程序行为，但即使是最简单的访问，也会却涉及 Java  
栈、Java 堆、方法区这三个最重要内存区域之间的关联关系，如下面的这句代码: Object obj = new Object();  
假设这句代码出现在方法体中，那“Object obj”这部分的语义将会反映到 Java 栈的本地变量表中，作为一个 reference 类型数据出现。而“new Object()”这部分的语义将会反映到 Java 堆中，形成一块存储了 Object 类型所有实例数据值(Instance Data，对象中各个实例字段的数据)的结构化内存，根据具体类型以及虚拟机 实现的对象内存布局(Object Memory Layout)的不同，这块内存的长度是不固定的。另外，在 Java 堆中  
还必须包含能查找到此对象类型数据(如对象类型、父类、实现的接口、方法等)的地址信息，这些类型数据则 存储在方法区中。

### 句柄方式 ###

如果使用句柄访问方式，Java 堆中将会划分出一块内存 来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据和类型数据各自的具体地址信息

![这里写图片描述][70 1]

### 直接指针方式 ###

如果使用的是直接指针访问方式，Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，  
reference 中直接存储的就是对象地址

![这里写图片描述][70 2]

这两种对象的访问方式各有优势，使用句柄访问方式的最大好处就是 reference 中存储的是稳定的句柄地 址，在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针，而 reference  
本 身 不 需要被修改。 使用直接指针访问方式的最大好处就 是速度更快，它节省了一次指针定位 的时间开销，由 于对象的访问在 Java 中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。就本书讨论的主  
要虚拟机 Sun HotSpot 而言，它是使用第二种方式进行对象访问的，但从整个软件开发的范围来看，各种语言 和框架使用句柄来访问的情况也十分常见。

## 总结 ##

上面说了那么说，下面来个简单的概括：

*  **方法区**：方法区存放的是类信息、常量、静态变量，所有线程共享区域。
 *  **虚拟机栈**：它的生命周期与 线程相同，每个方法在执行的同时都会创建一个栈帧（Stack Frame）用存储局部变量表、操作数栈、动态链接、方法出口等信息，线程私有区域。
 *  **本地方法栈**：与虚拟机栈类似，区别是虚拟机栈为虚拟机执行Java方法服务，本地方法栈为虚拟机使用到的Native方法。
 *  **堆**：线程共享；用来存放对象实例，几乎所有的对象实例都在堆上分配内存；此区域也是垃圾回收器（Garbage Collection）主要的作用区域，内存泄漏就发生在这个区域。
 *  **程序计数器**：用于指示当前线程所执行的字节码执行到了第几行，可以理解为是当前线程的行号指示器。如果线程在执行Java方法，这个计数器记录的是正在执行的虚拟机字节码指令地址。

通过上面的学习，我们了解了JVM的内存区域，和java 对象的基本创建和访问方式。为我们后面线上OOM 分析、Dalvik内存管理学习做铺垫，以及分析线上各种OOM 的原因以及如何去解决。

后面几篇文章：

1.Android 性能优化 之谈谈Java内存区域  
2.Android 性能优化 之了解Dalvik内存分配策略  
3.Android 性能优化 之内存泄漏分析  
4.Android 性能优化 之Dalvik内存管理、线上OOM分析总结

更多Android 之美，请阅读[《Android 之美 从0到1 – 高手之路》][Android _ _0_1 _]系列文章

> 水平有限，若有错漏，欢迎指正，批评，如需转载，请注明出处–[http://blog.csdn.net/vfush][fuchenxuan blog]，谢谢！

[![Android 之美 从0到1][Android _ _0_1]][Android _ _0_1 _]

[fuchenxuan blog]: http://blog.csdn.net/vfush
[Android _ _0_1 _]: /images/20220528/b8b01af1744b439abe2abd3fb773f4c0.png
[172815_vvql_567457.jpg]: /images/20220528/05ec8eb8926a4530bd6c24520f88c83e.png
[wiki]: https://zh.wikipedia.org/wiki/%E7%A8%8B%E5%BC%8F%E8%A8%88%E6%95%B8%E5%99%A8
[70]: /images/20220528/fbd71b899c644160bc5506455fc791f6.png
[70 1]: /images/20220528/c5012ec589db4adfbc9f7a67fd14ef28.png
[70 2]: /images/20220528/5175ed5ecad24729b3cdf03dbece356c.png
[Android _ _0_1]: https://img-blog.csdn.net/20160608234402229