Android碎碎念2：Java内存区域、内存模型、GC相关知识

一、Java内存区域

内存区域是指 Jvm 运行时将数据分区域存储，强调对内存空间的划分。

 1、JDK8 之后的 JVM 内存布局图

2、JDK7 和之前的JVM内存布局图 

 （1）、程序计数器

程序计数器（Program Counter Register）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。

由于 Java 虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器内核都只会执行一条线程中的指令。

因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

如果线程正在执行的是一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器值则为空（Undefined）。此内存区域是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域。

（2）、虚拟机栈

虚拟机栈描述的是Java方法执行的内存模型，方法在执行的时候会创建栈帧，和程序计数器一样，也是线程私有，它的生命周期与线程相同。

栈帧用于存储方法执行时所需的局部变量表、操作数栈、动态链接、方法出口等信息。方法的执行伴随着栈帧在虚拟机栈中的入栈及出栈

局部变量表存储了基本数据类型、对象引用、返回地址

在活动线程中，只有位栈顶的帧才是有效的，称为当前栈帧。正在执行的方法称为当前方法，栈帧是方法运行的基本结构。在执行引擎运行时，所有指令都只能针对当前栈帧进行操作。

虚拟机栈规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异常；如果虚拟机栈可以动态扩展（当前大部分的 Java 虚拟机都可动态扩展），如果扩展时无法申请到足够的内存，就会抛出 OutOfMemoryError 异常。

（2.1）. 局部变量表

局部变量表是存放方法参数和局部变量的区域。 局部变量没有准备阶段， 必须显式初始化。如果是非静态方法，则在 index[0] 位置上存储的是方法所属对象的实例引用，一个引用变量占 4 个字节，随后存储的是参数和局部变量。字节码指令中的 STORE 指令就是将操作栈中计算完成的局部变呈写回局部变量表的存储空间内。

（2.2）. 操作栈

操作栈是个初始状态为空的桶式结构栈。在方法执行过程中， 会有各种指令往
栈中写入和提取信息。JVM 的执行引擎是基于栈的执行引擎， 其中的栈指的就是操
作栈。字节码指令集的定义都是基于栈类型的，栈的深度在方法元信息的 stack 属性中。

i++ 和 ++i 的区别：

1. i++：从局部变量表取出 i 并压入操作栈(load memory)，然后对局部变量表中的 i 自增 1(add&store memory)，将操作栈栈顶值取出使用，如此线程从操作栈读到的是自增之前的值。
2. ++i：先对局部变量表的 i 自增 1(load memory&add&store memory)，然后取出并压入操作栈(load memory)，再将操作栈栈顶值取出使用，线程从操作栈读到的是自增之后的值。

之前之所以说 i++ 不是原子操作，即使使用 volatile 修饰也不是线程安全，就是因为，可能 i 被从局部变量表（内存）取出，压入操作栈（寄存器），操作栈中自增，使用栈顶值更新局部变量表（寄存器更新写入内存），其中分为 3 步，volatile 保证可见性，保证每次从局部变量表读取的都是最新的值，但可能这 3 步可能被另一个线程的 3 步打断，产生数据互相覆盖问题，从而导致 i 的值比预期的小。

（2.3）. 动态链接

每个栈帧中包含一个在常量池中对当前方法的引用， 目的是支持方法调用过程的动态连接。

(2.4)  .方法返回地址

方法执行时有两种退出情况：

1. 正常退出，即正常执行到任何方法的返回字节码指令，如 RETURN、IRETURN、ARETURN 等；
2. 异常退出。

无论何种退出情况，都将返回至方法当前被调用的位置。方法退出的过程相当于弹出当前栈帧，退出可能有三种方式：

1. 返回值压入上层调用栈帧。
2. 异常信息抛给能够处理的栈帧。
3. PC计数器指向方法调用后的下一条指令。

（3）、native栈

本地方法栈与虚拟机栈作用类似，区别在于虚拟机栈用于Java方法执行，而本地方法栈用于本地方法（C/C++）执行

有些虚拟机甚至不区分本地方法栈和虚拟机栈，而是将它们合二为一

同样本地方法栈也会触发StackOverflowError和OutOfMemoryError

（4）、堆内存

对于大多数应用来说，Java 堆（Java Heap）是 Java 虚拟机所管理的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。

堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”（Garbage Collected Heap）。从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以 Java 堆中还可以细分为：新生代和老年代；再细致一点的有 Eden 空间、From Survivor 空间、To Survivor 空间等。从内存分配的角度来看，线程共享的 Java 堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer,TLAB）。

Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，当前主流的虚拟机都是按照可扩展来实现的（通过 -Xmx 和 -Xms 控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出 OutOfMemoryError 异常。

（5）、方法区

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

Java 虚拟机规范对方法区的限制非常宽松，除了和 Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。垃圾收集行为在这个区域是比较少出现的，其内存回收目标主要是针对常量池的回收和对类型的卸载。当方法区无法满足内存分配需求时，将抛出 OutOfMemoryError 异常。

（5.1）Java8中的常量池所处于内存区域

• 类文件中常量池（The Constant Pool）：所处区域：堆
• 运行时常量池（The Run-Time Constant Pool）：存在于内存的元空间中
• String常量池：存在于堆中

运行时常量池在元空间，类文件中常量池和字符串常量池在堆中

（5.1.1）Java8中类文件中常量池 ---- 存在于Class文件中

所处区域：堆

诞生时间：编译时

内容概要：符号引用和字面量

class常量池是在编译的时候每个class都有的，在编译阶段，存放的是常量的符号引用。

常量池中存放的是符号信息，java虚拟机在执行指令的时候会依赖这些信息。

（5.1.2） Java8中运行时常量池 ---- 存在于内存的元空间中

诞生时间：JVM运行时

内容概要：class文件元信息描述，编译后的代码数据，引用类型数据，类文件常量池。

所谓的运行时常量池其实就是将编译后的类信息放入运行时的一个区域中，用来动态获取类信息。

运行时常量池是在类加载完成之后，将每个class常量池中的符号引用值转存到运行时常量池中，也就是说，每个class都有一个运行时常量池，类在解析之后，将符号引用替换成直接引用，与全局常量池中的引用值保持一致。

（5.1.3）Java8中字符串常量池 ---- 存在于堆中

从上述结果可以看出，JDK 1.6下，会出现“PermGen Space”的内存溢出，而在 JDK 1.7和 JDK 1.8 中，会出现堆内存溢出，并且 JDK 1.8中 PermSize 和 MaxPermGen 已经无效。因此，可以大致验证 JDK 1.7 和 1.8 将字符串常量由永久代转移到堆中，并且 JDK 1.8 中已经不存在永久代的结论。

字符串池里的内容是在类加载完成，经过验证，准备阶段之后在堆中生成字符串对象实例，然后将该字符串对象实例的引用值存到string pool中（记住：string pool中存的是引用值而不是具体的实例对象，具体的实例对象是在堆中开辟的一块空间存放的）。 在HotSpot VM里实现的string pool功能的是一个StringTable类，它是一个哈希表，里面存的是驻留字符串(也就是我们常说的用双引号括起来的)的引用（而不是驻留字符串实例本身），也就是说在堆中的某些字符串实例被这个StringTable引用之后就等同被赋予了”驻留字符串”的身份。这个StringTable在每个HotSpot VM的实例只有一份，被所有的类共享。

（5.2）Java8中元空间取代永久代的原因

JDK8 之前，Hotspot 中方法区的实现是永久代（Perm），JDK8 开始使用元空间（Metaspace），以前永久代所有内容的字符串常量移至堆内存，其他内容移至元空间，元空间直接在本地内存分配。

为什么要使用元空间取代永久代的实现？

1. 字符串存在永久代中，容易出现性能问题和内存溢出。
2. 类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
3. 永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
4. 将 HotSpot 与 JRockit 合二为一。

（5.3）java7和之前的运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

一般来说，除了保存 Class 文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。

运行时常量池相对于 Class 文件常量池的另外一个重要特征是具备动态性，Java 语言并不要求常量一定只有编译期才能产生，也就是并非预置入 Class 文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是 String 类的 intern() 方法。

既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常。

（5.4）java8 内存区域图

（5.5）直接内存

直接内存并非Java虚拟机规范中定义的内存区域，但是在大量使用NIO的程序中有可能触发OutOfMemoryError异常

NIO基于Channel和Buffer，可以直接使用本地方法分配堆外内存，然后通过存储在堆中的DirectByteBuffer对象作为这块堆外内存的引用进行操作。虽然堆外内存不会受到Java堆大小的限制，但是仍然会受制于物理内存以及操作系统的限制。当各内存区域总和大于物理内存或者达到操作系统限制，从而导致动态扩展时触发OutOfMemoryError

二、对象探秘

不同的虚拟机，对于对象的创建、布局和访问会有所差异，下面仅以HotSpot的堆内存为例进行介绍

1.对象的创建

（1）类检查及类加载

虚拟机在遇到new指令的时候，首先会去常量池检查类的符号引用，如果发现没有对此类进行加载、解析、初始化，那么首先会对该类进行加载

（2）内存分配

之后虚拟机会为该对象分配内存。由于对象所需内存在类加载后就可以确定，因此分配内存实际上就是从未使用的堆内存中划分出一块确定大小的存储空间。此过程有两种方式：

1）对于规整的堆内存，直接将指针向空闲一侧移动所需的大小，这种方式叫做“指针碰撞”

2）对于不规整对堆内存，虚拟机会维护一个空闲内存列表，当需要分配内存时，划分出一块足够的空间并且更新空闲列表，这种方式叫做“空闲列表”

至于堆内存是否规整连续，取决于具体的垃圾收集器（主要取决于是否带有compact功能）

由于对象的创建是一个十分频繁的过程，在并发情况下会有并发安全的问题。解决的方式有两种：

1）对内存分配进行同步处理，实际上虚拟机采用CAS的方式保证原子性

2）另一种方式是把内存分配的动作按照线程进行隔离，即每个线程会预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB）。只有在TLAB用完需要新分配的时候在采取同步处理

（3）初始化零值

内存分配完毕后，虚拟机会对该内存区域初始化零值，如果是TLAB方式，这一步可以提前到TLAB阶段。这一步保证了对象实例属性的初始化。这也就是为什么对象的实例属性可以不赋初值就能够直接访问

（4）对象头设置

接下来，虚拟机需要将对象进行一些设置，将类的元数据、哈希码、GC分代信息等设置到对象头中

（5）对象初始化

执行完上述步骤后，对象的实例属性还都是零值，下面会执行<init>方法，按照程序的意图对对象进行初始化（我的理解是执行构造方法）。之后在将对象的引用入栈。至此，对象的创建过程结束

2.对象的内存布局

在HotSpot虚拟机当中，对象的内存布局分为三个区域：对象头、实例数据、对齐填充

（1）对象头

对象头主要存储两部分信息，一部分是对象的运行时数据（如哈希码、GC分代信息、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等），另一部分是类型指针（即指向类元数据的指针，代表该对象是哪个类的实例。当然类的元数据也并不一定要存储在对象头，这个后续再讨论）

（2）实例数据

实例数据部分用于存储对象实例的数据，即实例属性的内容，父类的属性也会记录下来。存储顺序会受到虚拟机的分配策略以及字段的定义顺序的影响。默认的分配策略大致有几点规则：

1）会将相同宽度的属性分配在一起

2）满足1的前提下，父类中的属性出现在子类前

3）CompactFields参数为true的时候，会将子类中宽度较窄的属性插入到父类属性的空隙之中

（3）对齐填充

由于HotSpot虚拟机要求对象的其实地址必须是8字节的整数倍，因此对于对象大小不是8字节整数倍的对象，会被对齐填充

3.对象的访问定位

对象的访问解决的是如何通过栈中对象的引用访问到堆中实际对象的问题，目前主流的方式有两种：

1）句柄访问，栈中对象的引用存储的是对象的句柄地址（句柄在句柄池中维护），句柄存储了堆中对象实例的地址以及方法区中对象的类型数据的地址。

这种方式的优点是引用中存储的是稳定的句柄，当对象地址变化的时候（GC过程中可能会移动对象实例），只需要更新句柄，不需要更新引用；缺点也显而易见，访问对象时多一次指针操作

 

二、Java内存模型

Java内存模型是共享内存的并发模型，线程之间主要通过读-写共享变量（堆内存中的实例域，静态域和数组元素）来完成隐式通信。

Java 内存模型（JMM）控制 Java 线程之间的通信，决定一个线程对共享变量的写入何时对另一个线程可见。

1、计算机高速缓存和缓存一致性

计算机在高速的 CPU 和相对低速的存储设备之间使用高速缓存，作为内存和处理器之间的缓冲。将运算需要使用到的数据复制到缓存中，让运算能快速运行，当运算结束后再从缓存同步回内存之中。

在多处理器的系统中(或者单处理器多核的系统)，每个处理器内核都有自己的高速缓存，它们有共享同一主内存(Main Memory)。

当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致。

为此，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议进行操作，来维护缓存的一致性。

2、JVM主内存与工作内存

Java 内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量（线程共享的变量）存储到内存和从内存中取出变量这样底层细节。

Java内存模型中规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。

这里的工作内存是 JMM 的一个抽象概念，也叫本地内存，其存储了该线程以读 / 写共享变量的副本。

就像每个处理器内核拥有私有的高速缓存，JMM 中每个线程拥有私有的本地内存。

不同线程之间无法直接访问对方工作内存中的变量，线程间的通信一般有两种方式进行，一是通过消息传递，二是共享内存。Java 线程间的通信采用的是共享内存方式，线程、主内存和工作内存的交互关系如下图所示：

 

 这里所讲的主内存、工作内存与 Java 内存区域中的 Java 堆、栈、方法区等并不是同一个层次的内存划分，这两者基本上是没有关系的，如果两者一定要勉强对应起来，那从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。

重排序和happens-before规则

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。重排序分三种类型：

1. 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
2. 指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
3. 内存系统的重排序。由于处理器使用缓存和读 / 写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从 java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序：

 

JMM 属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

java 编译器禁止处理器重排序是通过在生成指令序列的适当位置会插入内存屏障（重排序时不能把后面的指令重排序到内存屏障之前的位置）指令来实现的。

happens-before

从 JDK5 开始，java 内存模型提出了 happens-before 的概念，通过这个概念来阐述操作之间的内存可见性。

如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在 happens-before 关系。这里提到的两个操作既可以是在一个线程之内，也可以是在不同线程之间。

这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。

如果 A happens-before B，那么 Java 内存模型将向程序员保证—— A 操作的结果将对 B 可见，且 A 的执行顺序排在 B 之前。

重要的 happens-before 规则如下：

1. 程序顺序规则：一个线程中的每个操作，happens- before 于该线程中的任意后续操作。
2. 监视器锁规则：对一个监视器锁的解锁，happens- before 于随后对这个监视器锁的加锁。
3. volatile 变量规则：对一个 volatile 域的写，happens- before 于任意后续对这个 volatile 域的读。
4. 传递性：如果 A happens- before B，且 B happens- before C，那么 A happens- before C。

下图是 happens-before 与 JMM 的关系

volatile关键字

volatile 可以说是 JVM 提供的最轻量级的同步机制，当一个变量定义为volatile之后，它将具备两种特性：

1. 保证此变量对所有线程的可见性。而普通变量不能做到这一点，普通变量的值在线程间传递均需要通过主内存来完成。

注意，volatile 虽然保证了可见性，但是 Java 里面的运算并非原子操作，导致 volatile 变量的运算在并发下一样是不安全的。而 synchronized 关键字则是由“一个变量在同一个时刻只允许一条线程对其进行 lock 操作”这条规则获得线程安全的。

1. 禁止指令重排序优化。普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。

文章参考：https://www.cnblogs.com/czwbig/p/11127124.html

                  https://www.cnblogs.com/dennyzhangdd/p/6770188.html

                 https://www.jianshu.com/p/9c845e4cb8a2

                《深入理解Java虚拟机》