JVM之内存结构分析

版权声明:未经本人允许,严禁转载 https://blog.csdn.net/lmh_19941113/article/details/85723343

 JVM在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途,以及创建和销毁的时间,有的区域随着虚拟机进程的启动而存在,有些区域则依赖用户线程的启动和结束而建立和销毁。JVM所管理的内存主要包括程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区、运行时常量这几块运行时数据区域,但随着Java版本的迭代,这几块数据区域就有了一些小变化,先来看一下这些变化。
 在Java 1.6中,运行时常量在方法区中。

 在Java 1.7及以后,运行时常量在堆中。

 在Java 1.8及以后,使用了元空间代替方法区。

 上面就是不同版本中,内存结构的变化,下面就来详细了解一下每块区域都干了什么。

程序计数器

 程序计数器是一块较小的内存空间,它可以看做是当前线程所执行的字节码的行号指示器,在虚拟机的概念模型里,字节码解释器工作时就说通过改变这个计数器的值来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
 因此,为了线程切换后能恢复到正确的执行的位置,每条线程需要有一个独立的程序计数器,所以程序计数器是线程私有的。如果线程执行的一个Java方法,程序计数器记录的是正在执行的虚拟机字节码指令的地址;如果是Native方法,则这个程序计数器值为空。
此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域

Java虚拟机栈

 与程序计数器一样,Java虚拟机栈也是线程私有的,它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型:每个方法在执行时都会创建一个帧栈,用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个帧栈在虚拟机中入栈到出栈的过程。
 局部变量表存放了编译器可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference类型,它不等同于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或者其他于此对象相关的位置)和returnAddress类型(指向了一条字节码指令的地址)。
 其中64位长度的long和double类型的数据会占用2个局部变量空间,其余的数据类型只占用一个。局部变量表所需的内存空间在编译器完成分配,当进入一个方法时,这个方法需要在帧栈中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。
 在Java虚拟机规范中,对这个区域规定了两种异常状况:如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常;如果虚拟机栈可以动态扩展,但扩展时无法申请到足够的内存,将会抛出OutOfMemoryError异常。

本地方法栈

 本地方法栈与虚拟机栈所发挥的作用是非常相似的,它们之间的区别不过是虚拟机栈为虚拟机执行Java方法(就是字节码)服务,而本地方法栈则为虚拟机使用的native方法服务。与虚拟机栈一样,本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常,且本地方法栈也是线程私有的
 Java开发者不需要过多的关注,了解一下即可。在有些虚拟机中(如HotSpot),本地方法栈与Java虚拟机栈是合二为一了的。

Java堆

 Java堆是JVM所管理的内存中最大的一块,也是被所有线程共享的一块内存区域,在虚拟机启动时创建。该内存区域唯一的目的就是存放对象实例,几乎所有的对象实例都在这里分配内存
 Java堆是垃圾回收器管理的主要区域,因此很多时候也被称为GC堆。从垃圾回收的角度来看,Java堆还可以细分为:新生代和老年代;在细致一点的有Eden空间、From Survivor空间、To Survivor空间等。从内存分配角度来看,Java堆可能划分出多个线程私有的分配缓冲区。
 Java堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可。在实现时,如果堆中没有内存完成实例分配且堆也无法再扩展时,将会抛出OutOfMemoryError异常。

方法区

 方法区与Java堆一样,是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。当方法区无法满足内存分配需求时,将抛出OutOfMemoryError异常。
 但在Java 1.8中,方法区被元空间取代。为什么尼?

  • 由于在方法区中垃圾回收效果很不理想,方法区的常量、静态变量等数据不容易被回收,所以很容易遇到内存溢出问题。在Java 1.8的实现中将类的元数据放入了native memory(元空间属于native memory),将字符串池和类的静态变量放入了Java堆中。
  • 对方法区调优是很困难的,同时将元空间与堆的垃圾回收进行了隔离,避免方法区引发Full GC和OOM等问题。

运行时常量池

 Class文件除了有类的版本、字段、方法、接口等描述信息外,还有一项信息是常量池,用于存放编译器生成的各种字面量(文本字符串、被申明为final的的常量、基本数据类型的值等)和符号引用(类和结构的完全限定名、字段名称和描述符、方法名称和描述符等),这部分内容将在类加载后进入方法区的运行时常量池中存放。
 由于运行时常量时方法区的一部分,自然受到方法区内存的限制,当常量池无法再申请到内存时会抛出OutOfMemoryError异常。
在Java 1.7及以后,运行时常量不再属于方法区,属于堆的一部分。

直接内存

 直接内存不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域。
 在NIO中,有一种基于通道与缓冲区的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作,这样能在一下场景中显著提高性能,因为避免了在Java堆和Native堆中来回复制数据。Java 1.8中,元空间也属于直接内存

总结

 最后再来两张图总结一下全文,在Java 1.7及以前版本,内存逻辑结构如下(这里的永久代指的是方法区):

 在Java 1.8及以后版本,内存逻辑结构如下:

【参考资料】
《深入理解Java虚拟机》

猜你喜欢

转载自blog.csdn.net/lmh_19941113/article/details/85723343