JVM内存结构和Java内存模型（JMM）

Java程序具体执行的过程

在讨论JVM内存区域划分之前，先来看一下Java程序具体执行的过程：

Java源代码文件(.java后缀)首先会被Java编译器编译为字节码文件(.class后缀)，然后JVM中的类加载器加载各个类的字节码文件，加载完毕之后，交由JVM执行引擎执行。在整个程序执行过程中，JVM会用一段空间来存储程序执行期间需要用到的数据和相关信息，这段空间一般被称作为Runtime Data Area（运行时数据区），也就是我们常说的JVM内存。因此，在Java中我们常常说到的内存管理就是针对这段空间进行管理（如何分配和回收内存空间）。

JVM内存结构

1.程序计数器

• 程序计数器是一块较小的空间，它可以看作是当前线程执行的字节码的行号。因此它是唯一一个在java虚拟机规范中没有OOM的区域。
  至于为什么要存储这个行号？
  JVM的多线程是通过线程轮流切换并分配CPU执行时间片的方式来实现的，任何一个时刻，一个CPU都只会执行一条线程中的指令。为了保证线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程间的程序计数器独立存储，互不影响。
• 如果线程执行的是java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址（可以理解为上图所示的行号），如果正在执行的是native方法，这个计数器的值为undefined。

2.虚拟机栈

• 每个线程有一个私有的栈，随着线程的创建而创建，生命周期与线程相同。方法的调用到执行完毕，对应的就是栈帧的入栈和出栈的过程。

• 虚拟机栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表、操作数栈、动态链接、方法出口等信息。

  • 局部变量表存放了编译期可知的各种基本数据类型和对象引用类型。通常我们所说的“栈内存”指的就是局部变量表这一部分。
    
  • 64位的long和double类型的数据会占用2个局部变量空间，其余的数据类型只占用1个。
  • 局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧分配多少内存是固定的，运行期间不会改变局部变量表的大小。

• 栈的大小可以固定也可以动态扩展。

  • 在固定大小的情况下，当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError异常。
  • 在动态扩展的情况下，若扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。
    

3.本地方法栈

• 和虚拟机栈类似，两者的区别就是虚拟机栈是为虚拟机执行java方法服务，本地方法栈为虚拟机执行native方法服务 。
• HotSpot虚拟机不区分虚拟机栈和本地方法栈，两者是一块的。
• 与虚拟机栈一样，本地方法栈也会抛StackOverflowError和OutOfMemoryError异常。

4.堆

Java虚拟机所管理的内存中最大的一块，因为该内存区域的唯一目的就是存放对象实例。几乎所有的对象实例度在这里分配内存，也就是通常我们说的new对象，该对象就会在堆中开辟一块内存来存放对象中的一些信息，比如属性呀什么的。同时堆也是垃圾收集器管理的主要区域。因此这部分空间也是Java垃圾收集器管理的主要区域。另外，堆是被所有线程共享的，在JVM中只有一个堆。
从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以Java堆还可以细分为：新生代和老年代：其中新生代又分为：Eden空间、From Survivor、To Survivor空间。进一步划分的目的是更好地回收内存，或者更快地分配内存。“分代回收”是基于这样一个事实：对象的生命周期不同，所以针对不同生命周期的对象可以采取不同的回收方式，以便提高回收效率。从内存分配的角度来看，线程共享的java堆中可能会划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB）。

如图所示，JVM内存主要由新生代、老年代、永久代构成。

① 新生代（Young Generation）：大多数对象在新生代中被创建，其中很多对象的生命周期很短。每次新生代的垃圾回收（又称Minor GC）后只有少量对象存活，所以选用复制算法，只需要少量的复制成本就可以完成回收。

新生代内又分三个区：一个Eden区，两个Survivor区（一般而言），大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到From Survivor区。当From Survivor区满时，此区的存活且不满足“晋升”条件的对象将被复制到To Survivor区(注意：From Survivor 和 To Survivor会相互转换)。对象每经历一次Minor GC，年龄加1，达到“晋升年龄阈值”（默认是15）后，被放到老年代，这个过程也称为“晋升”。显然，“晋升年龄阈值”的大小直接影响着对象在新生代中的停留时间，在Serial和ParNew GC两种回收器中，“晋升年龄阈值”通过参数MaxTenuringThreshold设定，默认值为15。

② 老年代（Old Generation）：在新生代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代，该区域中对象存活率高。老年代的垃圾回收（又称Major GC）通常使用“标记-清理”或“标记-整理”算法。整堆包括新生代和老年代的垃圾回收称为Full GC（HotSpot VM里，除了CMS之外，其它能收集老年代的GC都会同时收集整个GC堆，包括新生代）。

③ 永久代（Perm Generation）：主要存放元数据，例如Class、Method的元信息，与垃圾回收要回收的Java对象关系不大。相对于新生代和年老代来说，该区域的划分对垃圾回收影响比较小。

在 JDK 1.8中移除整个永久代，取而代之的是一个叫元空间（Metaspace）的区域（永久代使用的是JVM的堆内存空间，而元空间使用的是物理内存，直接受到本机的物理内存限制）。

5.方法区

• 方法区也是线程共享区，用于存储【虚拟机加载的类信息（类的版本、字段、方法、接口），常量，静态变量，即时编译器编译后的代码等数据】

• 方法区逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。

• HotSpot虚拟机使用永久代来实现方法区，使得HotSpot虚拟机的垃圾收集器可以像管理堆内存一样来管理这部分内存，能省去专门为方法区编写内存管理代码工作。所以开发者喜欢将方法区称为永久代，本质上两者并不等价，对于其他虚拟机来说不存在永久代的概念。

• 方法区可选择不实现垃圾收集，一般来说，这个区域对内存回收的条件较为苛刻，但是这部分区域的回收确实是必要的。

• 当方法区无法满足内存分配需求时，将会抛OutOfMemoryError异常

运行时常量池

• 运行时常量池是方法区的一部分，用来存储编译期间生成的字面量和符号引用。

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

• 运行时常量池相于class文件中的常量池所不同的是其具备了动态性。class文件中常量池中的常量在编译期间就已经定义好了，而运行时常量池在程序运行期间也可以将常量放入该常量池中，最常见的做法就是调用String类的intern()方法。

JDK1.7及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。同时在 jdk 1.8中移除整个永久代，取而代之的是一个叫元空间（Metaspace）的区域

6.直接内存

直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用。而且也可能导致OutOfMemoryError异常出现。

JDK1.4中新加入的NIO(New Input/Output)类，引入了一种基于通道（Channel） 与缓存区（Buffer） 的I/O方式，它可以直接使用Native函数库直接分配堆外内存，然后通过一个存储在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样就能在一些场景中显著提高性能，因为避免了在Java堆和Native堆之间来回复制数据。

本机直接内存的分配不会收到Java堆的限制，但是，既然是内存就会受到本机总内存大小以及处理器寻址空间的限制。

Java内存模型

Java内存模型(Java Memory Model，JMM)JMM主要是为了规定了线程和内存之间的一些关系。根据JMM的设计，系统存在一个主内存(Main Memory)，Java中所有变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作都是在工作内存中进行，线程之间无法相互直接访问，变量传递均需要通过主存完成。

内存模型解决并发问题主要采用两种方式: 限制处理器优化和使用内存屏障。

另外，线程在栈区，不能共享数据，只能通过复制共享区的数据作为一块缓存，所有多线程写会有bug，voliate使得取到的数据不做缓存，是实时更新的。关键字 volatile 是轻量级的同步机制。
Volatile 变量对于all线程的可见性，指当一条线程修改了这个变量的值，新值对于其他 线程来说是可见的、立即得知的。 Volatile 变量在多线程下不一定安全，因为他只有可见性、有序性，但是没有原子性。

对象创建过程

1、类加载检查
　　虚拟机遇到一条new指令时，首先将去检查这个指令的参数能否在常量池中定位到一个类的符号引用，并检查这个符号引用代表的类是否已经被加载、解析和初始化过，如果没有，那么必须先执行相应的类加载过程。

2、分配内存
　　在类加载检查通过后，接下来虚拟机将会为新生的对象分配内存。对象所需要的内存大小在类加载完成后便可完全确定，为对象分配空间等同于把一块确定大小的内存从java堆中划分出来。分配方式有 “指针碰撞” 和 “空闲列表” 两种，选择那种分配方式由 Java 堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。

• （1）指针碰撞法
  假设Java堆中内存是完整的，已分配的内存和空闲内存分别在不同的一侧，通过一个指针作为分界点，需要分配内存时，仅仅需要把指针往空闲的一端移动与对象大小相等的距离。使用的GC收集器：Serial、ParNew，适用堆内存规整（即没有内存碎片）的情况下。

• （2）空闲列表法
  事实上，Java堆的内存并不是完整的，已分配的内存和空闲内存相互交错，JVM通过维护一个空闲列表，记录可用的内存块信息，当分配操作发生时，从列表中找到一个足够大的内存块分配给对象实例，并更新列表上的记录。使用的GC收集器：CMS，适用堆内存不规整的情况下。

Java 堆内存是否规整，取决于 GC 收集器的算法是”标记-清除”，还是”标记-整理”（也称作”标记-压缩”），值得注意的是，复制算法内存也是规整的。在使用Serial、ParNew等待整理过程的收集器时，采用的是指针碰撞，在使用CMS这种mark-sweep算法的收集器时，使用的是空闲列表。

内存分配并发问题

在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，例如正在给A对象分配内存，但是指针还没修改，这时候对象B可能使用原来的指针来分配内存的情况。作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全：

• CAS+失败重试： CAS 是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。
• TLAB： 为每一个线程预先在 Eden 区分配一块内存。JVM 在给线程中的对象分配内存时，首先在各个线程的TLAB 分配，当对象大于TLAB 中的剩余内存或 TLAB 的内存已用尽时，再采用上述的 CAS 进行内存分配。虚拟机是否启用TLAB，可以通过-XX:+/-UseTLAB参数来设定。

3、初始零值
　　内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。如果使用TLAB，这一工作过程也可以提前到TLAB分配时进行。

4、设置对象头
　　接下来，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例，如何才能找到类的元数据信息，对象的哈希吗，对象的GC分代年龄等信息，这些信息存放在对象的对象头中。根据虚拟机当前的运行状态的不同，对象头会有不同的设置方式。

5、执行init方法
　　在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始，init 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后会接着执行 init方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

对象的内存布局

在HotSpot虚拟机中，对象在内存中存储的布局分为3个区域，如下图所示：

对象头（Header）：

• MarkWord：存储对象自身的运行时数据，例如：哈希码HashCode、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID等。考虑空间效率，MarkWord设计为非固定的数据结构，它根据对象的不同状态复用自己的空间，如下图所示：　　　
  在32位系统下，对象头8字节，64位则是16个字节【未开启压缩指针，开启后12字节】

• Klass Point(指向Class的指针)：即对象指向它的类的元数据的指针，虚拟机通过这个指针来确定是哪个类的实例

• 如果对象是Java数组，对象头中还需要一块记录数组长度的数据

实例数据（Instance Data）：对象真正存储的有效信息，也是程序代码中定义的各种类型字段的内容
对齐填充（Padding）：起占位符的作用。因为HotSpot VM的要求对象起始地址必须是8字节的整数倍，也就是对象的大小必须是8字节的整数倍。当对象实例数据部分没有对齐时，需要对齐填充来补充

参考：

https://blog.csdn.net/kagurawill/article/details/86644212
https://www.cnblogs.com/aiqiqi/p/10770864.html
https://www.cnblogs.com/butterfly100/p/9175673.html