JVM

JAVA内存模型

Java虚拟机规范中试图定义一种Java内存模型（Java Memory Model，JMM）来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。 image.png

JMM描述了Java程序中各种变量（线程共享变量）的访问规则，以及在JVM中将变量存储到内存中读取出变量这样的底层细节。所有的变量都存储在主内存中，每个线程都有自己独立的工作内存，里面保存该线程使用到的变量的副本（主内存中变量的一份拷贝）。JMM的两条规定：

  • 线程对共享变量的所有操作都必须在自己的工作内存中进行，不能直接从主内存中读写
  • 不同的线程之间无法直接访问其他线程工作内存中的变量，线程变量值的传递需要通过主内存来完成

Java 内存模型（下文简称 JMM）就是在底层处理器内存模型的基础上，定义自己的多线程语义。它明确指定了一组排序规则，来保证线程间的可见性。这一组规则被称为 Happens-Before, JMM 规定，要想保证 B 操作能够看到 A 操作的结果（无论它们是否在同一个线程），那么 A 和 B 之间必须满足 Happens-Before 关系：

  • 单线程规则：一个线程中的每个动作都 happens-before 该线程中后续的每个动作
  • 监视器锁定规则：监听器的解锁动作 happens-before 后续对这个监听器的锁定动作
  • volatile 变量规则：对 volatile 字段的写入动作 happens-before 后续对这个字段的每个读取动作
  • 线程 start 规则：线程 start() 方法的执行 happens-before 一个启动线程内的任意动作
  • 线程 join 规则：一个线程内的所有动作 happens-before 任意其他线程在该线程 join() 成功返回之前
  • 传递性：如果 A happens-before B, 且 B happens-before C, 那么 A happens-before C

JVM内存结构

JVM包含堆、元空间、Java虚拟机栈、本地方法栈、程序计数器等内存区域，其中堆是占用内存最大的，如下图所示：

image.png

JVM常量池

JVM常量池主要分为Class文件常量池、运行时常量池、全局字符串常量池、以及基本类型包装类对象常量池。

  • Class文件常量池：class文件是一组以字节为单位的二进制数据流，在java代码的编译期间，我们编写的java文件就被编译为.class文件格式的二进制数据存放在磁盘中，其中就包括class文件常量池。
  • 运行时常量池：运行时常量池相对于class常量池一大特征就是具有动态性，java规范并不要求常量只能在运行时才产生，也就是说运行时常量池的内容并不全部来自class常量池，在运行时可以通过代码生成常量并将其放入运行时常量池中，这种特性被用的最多的就是String.intern()。
  • 全局字符串常量池：字符串常量池是JVM所维护的一个字符串实例的引用表，在HotSpot VM中，它是一个叫做StringTable的全局表。在字符串常量池中维护的是字符串实例的引用，底层C++实现就是一个Hashtable。这些被维护的引用所指的字符串实例，被称作”被驻留的字符串”或”interned string”或通常所说的”进入了字符串常量池的字符串”。
  • 基本类型包装类对象常量池：java中基本类型的包装类的大部分都实现了常量池技术，这些类是Byte,Short,Integer,Long,Character,Boolean,另外两种浮点数类型的包装类则没有实现。另外上面这5种整型的包装类也只是在对应值小于等于127时才可使用对象池，也即对象不负责创建和管理大于127的这些类的对象。

JVM内存模型

JVM试图定义一种统一的内存模型，能将各种底层硬件以及操作系统的内存访问差异进行封装，使Java程序在不同硬件以及操作系统上都能达到相同的并发效果。它分为工作内存和主内存，线程无法对主存储器直接进行操作，如果一个线程要和另外一个线程通信，那么只能通过主存进行交换。如下图所示：

image.png image.png image.png

线程隔离数据区：

  • 程序计数器： 一块较小的内存空间，存储当前线程所执行的字节码行号指示器
  • 虚拟机栈： 里面的元素叫栈帧，存储 局部变量表、操作栈、动态链接、方法返回地址 等
  • 本地方法栈： 为虚拟机使用到的本地Native方法服务时的栈帧，和虚拟机栈类似

线程共享数据区：

  • 方法区： 存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据
  • 堆： 唯一目的就是存放对象的实例，是垃圾回收管理器的主要区域
  • 元数据区：常量池、方法元信息、

程序计数器

程序计数器（Program Counter Register）也叫PC寄存器。程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。JVM支持多个线程同时运行，每个线程都有自己的程序计数器。倘若当前执行的是 JVM 的方法，则该寄存器中保存当前执行指令的地址；倘若执行的是native 方法，则PC寄存器中为空(undefined)。

  • 当前线程私有
  • 当前线程所执行的字节码的行号指示器
  • 不会出现OutOfMemoryError情况
  • 以一种数据结构的形式放置于内存中

注意：程序计数器是唯一一个不会出现 OutOfMemoryError 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。

JAVA虚拟机栈

image.png JAVA虚拟机栈（Java Virtual Machine Stacks）是每个线程有一个私有的栈，随着线程的创建而创建，其生命周期与线程同进同退。栈里面存着的是一种叫“栈帧”的东西，每个Java方法在被调用的时候都会创建一个栈帧，一旦完成调用，则出栈。所有的的栈帧都出栈后，线程也就完成了使命。栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、动态链接(指向当前方法所属的类的运行时常量池的引用等)、方法出口(方法返回地址)、和一些额外的附加信息。栈的大小可以固定也可以动态扩展。当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError的错误，不过这个深度范围不是一个恒定的值。

  • 线程私有，生命周期与线程相同
  • java方法执行的内存模型，每个方法执行的同时都会创建一个栈帧，存储局部变量表(基本类型、对象引用)、操作数栈、动态链接、方法出口等信息
  • StackOverflowError：当线程请求的栈深度大于虚拟机所允许的深度
  • OutOfMemoryError：如果栈的扩展时无法申请到足够的内存

相关参数：

-Xss：设置方法栈的最大值

本地方法栈

本地方法栈（Native Method Stacks）与Java栈的作用和原理非常相似。区别只不过是Java栈是为执行Java方法服务的，而本地方法栈则是为执行本地方法（Native Method）服务的。在JVM规范中，并没有对本地方法栈的具体实现方法以及数据结构作强制规定，虚拟机可以自由实现它。在HotSopt虚拟机中直接就把本地方法栈和Java栈合二为一。

方法区

方法区（Method Area）用于存放虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

  • 又称之为：非堆（Non-Heap）或 永久区
  • 线程共享
  • 主要存储：类的类型信息、常量池（Runtime Constant Pool）、字段信息、方法信息、类变量和Class类的引用等
  • Java虚拟机规范规定：当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常

相关参数：

-XX:PermSize：设置Perm区的初始大小

-XX:MaxPermSize：设置Perm区的最大值

堆内存

堆内存（JAVA Heap）。是被线程共享的一块内存区域，创建的对象和数组都保存在 Java 堆内存中，也是垃圾收集器进行垃圾收集的最重要的内存区域。由于现代 VM 采用分代收集算法, 因此 Java 堆从 GC 的角度还可以细分为: 新生代(Eden区、From Survivor 区和 To Survivor 区)和老年代。

  • 线程共享
  • 主要用于存储JAVA实例或对象
  • GC发生的主要区域
  • 是Java虚拟机所管理的内存中最大的一块
  • 当堆中没有内存能完成实例分配，且堆也无法再扩展，则会抛出OutOfMemoryError异常

相关参数：

-Xms：设置堆内存初始大小

-Xmx：设置堆内存最大值

-XX:MaxTenuringThreshold：设置对象在新生代中存活的次数

-XX:PretenureSizeThreshold：设置超过指定大小的大对象直接分配在旧生代中

新生代相关参数（注意：当新生代设置得太小时，也可能引发大对象直接分配到旧生代）：

-Xmn：设置新生代内存大小

-XX:SurvivorRatio：设置Eden与Survivor空间的大小比例

JVM运行时内存

JVM运行时内存又称堆内存(Heap)。Java 堆从 GC 的角度还可以细分为: 新生代(Eden 区、From Survivor 区和 To Survivor 区)和老年代。

image.png

image.png

当代主流虚拟机（Hotspot VM）的垃圾回收都采用“分代回收”的算法。“分代回收”是基于这样一个事实：对象的生命周期不同，所以针对不同生命周期的对象可以采取不同的回收方式，以便提高回收效率。Hotspot VM将内存划分为不同的物理区，就是“分代”思想的体现。

一个对象从出生到消亡

image.png

一个对象产生之后首先进行栈上分配，栈上如果分配不下会进入伊甸区，伊甸区经过一次垃圾回收之后进入surivivor区，survivor区在经过一次垃圾回收之后又进入另外一个survivor，与此同时伊甸区的某些对象也跟着进入另外一个survivot，什么时候年龄够了就会进入old区，这是整个对象的一个逻辑上的移动过程。

新生代（Young Generation）

主要是用来存放新生的对象。一般占据堆的1/3空间。由于频繁创建对象，所以新生代会频繁触发MinorGC进行垃圾回收。新生代又分为 Eden区、ServivorFrom、ServivorTo三个区。

  • Eden区：Java新对象的出生地（如果新创建的对象占用内存很大，则直接分配到老年代）。当Eden区内存不够的时候就会触发MinorGC，对新生代区进行一次垃圾回收
  • ServivorTo：保留了一次MinorGC过程中的幸存者
  • ServivorFrom：上一次GC的幸存者，作为这一次GC的被扫描者

MinorGC流程

  • MinorGC采用复制算法
  • 首先把Eden和ServivorFrom区域中存活的对象复制到ServicorTo区域（如果有对象的年龄以及达到了老年的标准，则复制到老年代区），同时把这些对象的年龄+1（如果ServicorTo不够位置了就放到老年区）
  • 然后清空Eden和ServicorFrom中的对象
  • 最后ServicorTo和ServicorFrom互换，原ServicorTo成为下一次GC时的ServicorFrom区

为什么 Survivor 分区不能是 0 个？

如果 Survivor 是 0 的话，也就是说新生代只有一个 Eden 分区，每次垃圾回收之后，存活的对象都会进入老生代，这样老生代的内存空间很快就被占满了，从而触发最耗时的 Full GC ，显然这样的收集器的效率是我们完全不能接受的。

为什么 Survivor 分区不能是 1 个？

如果 Survivor 分区是 1 个的话，假设我们把两个区域分为 1:1，那么任何时候都有一半的内存空间是闲置的，显然空间利用率太低不是最佳的方案。

但如果设置内存空间的比例是 8:2 ，只是看起来似乎“很好”，假设新生代的内存为 100 MB（ Survivor 大小为 20 MB ），现在有 70 MB 对象进行垃圾回收之后，剩余活跃的对象为 15 MB 进入 Survivor 区，这个时候新生代可用的内存空间只剩了 5 MB，这样很快又要进行垃圾回收操作，显然这种垃圾回收器最大的问题就在于，需要频繁进行垃圾回收。

为什么 Survivor 分区是 2 个？

如果Survivor分区有2个分区，我们就可以把 Eden、From Survivor、To Survivor 分区内存比例设置为 8:1:1 ，那么任何时候新生代内存的利用率都 90% ，这样空间利用率基本是符合预期的。再者就是虚拟机的大部分对象都符合“朝生夕死”的特性，所以每次新对象的产生都在空间占比比较大的Eden区，垃圾回收之后再把存活的对象方法存入Survivor区，如果是 Survivor区存活的对象，那么“年龄”就+1，当年龄增长到15（可通过 -XX:+MaxTenuringThreshold 设定）对象就升级到老生代。

总结

根据上面的分析可以得知，当新生代的 Survivor 分区为 2 个的时候，不论是空间利用率还是程序运行的效率都是最优的，所以这也是为什么 Survivor 分区是 2 个的原因了。