JVM的内存模型

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

JVM的内存模型几乎是每次面试必问的内容，由于结构复杂，并且平时开发的使用场景其实非常有限，所以即使学习很多次依然会有混淆的情况，这里主要通过介绍JDK1.8的内存模型，来对比1.8和之前几个JDK版本的区别

1.JDK8的整体结构

五大部分：本地方法栈，虚拟机栈，程序计数器，堆，以及元数据空间

1.虚拟机栈：

线程私有，它的生命周期与线程相同。描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、

操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，对应着一个栈帧在虚拟机中入栈到出栈的过程。

1）局部变量表

就是用来存储方法中的局部变量（包括在方法中声明的非静态变量以及函数形参）。对于基本数据类型的变量，则直接存储它的值，对于引用类型的变量，则存的是指向对象的引用。局部变量表的大小在编译器就可以确定其大小了，因此在程序执行期间局部变量表的大小是不会改变的。

2）操作数栈

想必学过数据结构中的栈的朋友想必对表达式求值问题不会陌生，栈最典型的一个应用就是用来对表达式求值。想想一个线程执行方法的过程中，实际上就是不断执行语句的过程，而归根到底就是进行计算的过程。因此可以这么说，程序中的所有计算过程都是在借助于操作数栈来完成的。

3）动态链接

因为在方法执行的过程中有可能需要用到类中的常量，所以必须要有一个引用指向运行时常量。

4）方法出口信息

当一个方法执行完毕之后，要返回之前调用它的地方，因此在栈帧中必须保存一个方法返回地址。由于每个线程正在执行的方法可能不同，因此每个线程都会有一个自己的Java栈，互不干扰。也就解释了栈是线程私有的。

 在java虚拟机规范中，对这个区域定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出一个StackOverflowError异常；

如果虚拟机栈可以动态扩展而在扩展时无法申请到足够的内存，就会抛出一个OutOfMemoryError异常。

StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度。

OutOfMemoryError：如果虚拟机栈可以动态扩展，而扩展时无法申请到足够的内存。

2.本地方发栈：

本地方法栈和虚拟机栈所发挥的作用是很相似的，它们之间的区别不过是 虚拟机栈为虚拟机执行Java方法（字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。Sun HotSpot 直接就把本地方法栈和虚拟机栈合二为一。本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常。

3.程序计数器

　　程序计数器是一个记录着当前线程所执行的字节码的行号指示器。

　　JAVA代码编译后的字节码在未经过JIT（实时编译器）编译前，其执行方式是通过“字节码解释器”进行解释执行。简单的工作原理为解释器读取装载入内存的字节码，按照顺序读取字节码指令。读取一个指令后，将该指令“翻译”成固定的操作，并根据这些操作进行分支、循环、跳转等流程。

　　从上面的描述中，可能会产生程序计数器是否是多余的疑问。因为沿着指令的顺序执行下去，即使是分支跳转这样的流程，跳转到指定的指令处按顺序继续执行是完全能够保证程序的执行顺序的。假设程序永远只有一个线程，这个疑问没有任何问题，也就是说并不需要程序计数器。但实际上程序是通过多个线程协同合作执行的。

　　首先我们要搞清楚JVM的多线程实现方式。JVM的多线程是通过CPU时间片轮转（即线程轮流切换并分配处理器执行时间）算法来实现的。也就是说，某个线程在执行过程中可能会因为时间片耗尽而被挂起，而另一个线程获取到时间片开始执行。

当被挂起的线程重新获取到时间片的时候，它要想从被挂起的地方继续执行，就必须知道它上次执行到哪个位置，在JVM中，通过程序计数器来记录某个线程的字节码执行位置。因此，程序计数器是具备线程隔离的特性，也就是说，每个线程工作时都有属于自己的独立计数器。

在JVM规范中规定，如果线程执行的是非native方法，则程序计数器中保存的是当前需要执行的指令的地址；如果线程执行的是native方法，则程序计数器中的值是undefined。由于程序计数器中存储的数据所占空间的大小不会随程序的执行而发生改变，因此，此内存区域是唯一一个在JVM规范中没有规定任何OutOfMemoryError情况的区域。

4.堆

JDK8和之前的版本主要的区别就是移除了持久代，加入metaData space

1） 堆是JVM中所有线程共享的，因此在其上进行对象内存的分配均需要进行加锁，这也导致了new对象的开销是比较大的

2） Sun Hotspot JVM为了提升对象内存分配的效率，对于所创建的线程都会分配一块独立的空间TLAB（Thread Local Allocation Buffer），其大小由JVM根据运行的情况计算而得，在TLAB上分配对象时不需要加锁，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则仍然是直接使用堆空间分配

3） TLAB仅作用于新生代的Eden Space，因此在编写Java程序时，通常多个小的对象比大的对象分配起来更加高效。由于TLAB的存在，所以实际上说堆内存是线程完全共享的是并不准确的，

4） 所有新创建的Object 都将会存储在新生代Yong Generation中。如果Young Generation的数据在一次或多次GC后存活下来，那么将被转移到OldGeneration。新的Object总是创建在Eden Space。

5.meta space

在JDK8中，永久代已经不存在，存储的类信息、编译后的代码数据等已经移动到了元空间（MetaSpace）中，元空间并没有处于堆内存上，而是直接占用的本地内存（NativeMemory）。

元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小： 
　　-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。 
　　-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。 
　　除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性： 
　　-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集 
　　-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集 

注意：如果不设置JVM将会根据一定的策略自动增加本地元内存空间。
如果你设置的元内存空间过小，你的应用程序可能得到以下错误：
java.lang.OutOfMemoryError: Metadata space

6.方法区，永久代以及元空间

方法区不能等同于永久代，方法区只是一种逻辑上的概念，永久代指物理上的堆内存的一块空间，这块实际的空间完成了方法区存储字节码、静态变量、常量的功能等等。所以，实际上现在元空间也可以认为是实现了方法区的功能。

为什么移除永久代，网上找到的主要说法为：

 

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

一篇非常好的文章：https://github.com/doocs/jvm/blob/master/README.md

 



 

以上是 JVM的内存模型 的全部内容， 来源链接： utcz.com/z/518732.html

回到顶部