JVM及JMM内存模型

最新推荐文章于 2024-08-05 14:32:10 发布

yangcun_88

最新推荐文章于 2024-08-05 14:32:10 发布

阅读量335

点赞数

分类专栏： Java JVM 文章标签： jvm java

本文链接：https://blog.csdn.net/weixin_43846235/article/details/103781310

版权

Java 同时被 2 个专栏收录

9 篇文章 0 订阅

订阅专栏

JVM

7 篇文章 0 订阅

订阅专栏

JVM及JMM内存模型

JVM内存模型
JMM内存模型
- JMM保证

JVM内存模型

在这里插入图片描述

栈（方法栈）

栈区也叫方法栈，它的线程是私有的，生命周期与线程相同。

每个方法执行都会创建一个栈帧，用于存放局部变量表，操作栈，动态链接，方法出口等信息。每个方法从调用完成到执行完成的过程，就对应一个栈帧在虚拟机栈中的入栈和出栈过程。通俗来说，调用方法时执行入栈，方法返回时执行出栈。

栈帧中的局部变量表，存放了编译器可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向对象起始地址的引用指针，也可能指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。其中64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个。局部变量所需的内存空间在编译时已完成分配。当进入一个方法时，这个方法在帧中分配多大的局部变量内存空间是完全确定的。在运行期间不会改变局部变量表的大小。

会出现的异常情况有两种：

如果线程请求的栈的深度，大于虚拟机所允许的深度，将会抛出StackOverflowError错误。
虚拟机栈动态扩展，当扩展无法申请到足够的内存空间时，抛出OutOfMemoneyError错误。

本地方法栈

本地方法栈与栈类似，也是用来保存线程执行方法时的信息，不同的是，执行 Java 方法（也就是字节码）使用栈，而执行 native 方法使用本地方法栈（Navtive 方法是 Java 通过 JNI 直接调用本地 C/C++ 库，可以认为是 Native 方法相当于 C/C++ 暴露给 Java 的一个接口，Java 通过调用这个接口从而调用到 C/C++ 方法。），虚拟机规范中，对本地方法栈中的方法使用的语言、使用方式与数据结构，并没有强制要求，因此具体虚拟机可以自由实现它。本地方法栈去也会抛出OutOfMemoneyError异常。

堆

堆是 JVM 管理的内存中最大的一块，堆被所有线程共享，目的是为了存放对象实例，几乎所有的对象实例都在这里分配，这一点在Java虚拟机规范中的描述是：所有的对象实例以及数组都要在堆上分配[插图]，但是随着JIT编译器的发展与逃逸分析技术的逐渐成熟，栈上分配、标量替换[插图]优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。（什么是对象数据：排除法，排除基本类型以及引用类型以外的数据都放在堆空间中）。

堆区是gc的主要区域，根据对象存活周期不同，JVM把堆内存进行分代管理，通常情况下分为两个区域年轻代和老年代。（更细一点年轻代又分为Eden区存放新创建对象，From survivor和 To survivor保存gc后幸存下来的对象，默认情况下格子占比8:1:1）

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

在JDK1.8版本废弃了永久代，替代的是元空间（MetaSpace），元空间与永久代上类似，都是方法区的实现，他们最大区别是：元空间并不在JVM中，而是使用本地内存。
元空间有注意有两个参数：

MetaspaceSize ：初始化元空间大小，控制发生GC阈值
MaxMetaspaceSize ：限制元空间大小上限，防止异常占用过多物理内存

方法区

方法去也是被线程共享区，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

Java虚拟机规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。垃圾回收很少光顾方法区，不过也有需要回收的，主要针对常量池回收和类型卸载。常量池用于存放编译后生产的各种字节码和符号引用，常量池具有一定的动态性，里面可以存放编译期生产的常量，运行期间常量也可以加入常量池。

运行时常量池

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

Java虚拟机对Class文件的每一部分（自然也包括常量池）的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可、装载和执行。但对于运行时常量池，Java虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过，一般来说，除了保存Class文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。

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

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

程序计数器

程序计数器是一个线程私有的较小的内存空间，用于存储所属线程所执行的字节码和行号指示器（所执行字节码的位置）；字节码解释器工作时，通过改变程序计数器的值来选取下一条需要执行的字节码指令（分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成）。

在多线程中，就会存在线程上下文切换（CPU 时间片）执行，为了线程切换后能恢复正确的执行位置，所以需要从程序计数器中获取该线程需要执行的字节码的偏移地址（简单来说，可以先理解为执行的代码行号）。每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。程序计数器为执行 Java 方法服务，执行 native 方法时，程序计数器为空。

JMM内存模型

在这里插入图片描述
JMM是Java内存模型，不同于JVM内存模型。JMM主要是定义程序中变量的访问规则（如上图）。所有共享变量都存储在主内存中共享。每个线程有自己的工作内存，工作内存中保存的主要是主内存中变量的副本，线程对变量的读写只能在自己的工作内存中进行，而不能读写主内存中的变量。

在多线程进行数据交互时，例如线程A给一个共享变量赋值后，由线程B来进行读取这个值，A修改完变量是在自己的工作内存中进行的，B是不可见的，只有A从工作内存回主内存，B在从主内存读取到自己的工作区才能进行进步一操作。由于指令重拍的存在，这个写/读的顺序可能会被打乱。因此JMM需要提供原子性、有序性、可见性的保证。