JAVA虚拟机02---JAVA虚拟机运行时数据区域简介

 

JAVA虚拟机运行时数据区域

1.程序计数器

　1）它可以看做是当前线程执行的字节代码的行指示器，通过改变计数器的值来决定下一步执行的代码

　 2）它是线程私有的，每个线程都有自己的程序计数器(JAVA中多线程是通过线程轮流切换、分配处理器的执行时间的方式实现的)

　 3）它的生命周期和线程的生命周期一致

　3）对于JVM 来说，程序就是存储在方法区的字节码指令。如果执行的是JAVA方法，程序计数器记录的是正在执行的虚拟机字节码指令的地址，如果是native方法，计数器为空(Underfiend)

　 4）储蓄计数器内JAVA虚拟机内存区域中在<<JAVA虚拟机规范>>中规定任何OutOfMemoryError的内存区域

2.JAVA虚拟机栈

　1）每个方法被执行的时候，都会创建一个栈帧，用于存储局部变量表、操作数栈、动态连接、方法出口等信息(https://www.cnblogs.com/jthr/p/15762205.html)。每一个方法从调用到执行结束的过程就对应着栈帧在虚拟机栈中入栈到出栈的过程

　 2）它是线程私有的

　 3）它的生命周期和线程的生命周期一致

　 4）局部变量表

　　　　　存放了编译器的可知的各种JAVA虚拟机基本数据类型、对象引用(reference类型，它不等同与对象本身，可能是指向对象起始地址的引用指针或者指向对象的句柄或者其它的与此对象相关的位置[https://www.cnblogs.com/jthr/p/15484760.html 第三块内容])、returnAddress类型(对于 JVM 来说，程序就是存储在方法区的字节码指令，而 returnAddress 类型的值就是指向特定指令内存地址的指针。程序计数器的值就是当前指令所在的内存地址，即 returnAddress 类型的数据（java方法）)

　　　　　这些数据类型在局部变量表中的存储空间以局部变量槽来表示

　　　　　局部变量表的空间在编译完成分配(一个方法需要在栈帧中分配多大的空间是确定的)，在运行期间不会改变局部变量表的大小。这个大小指的是变量槽的数量。至于1个变量槽是占用32个比特、64个比特或者其它，看虚拟机的具体实现

　 5）虚拟机栈的容量可以动态扩充

　 6）<<JAVA虚拟机规范>>规定了两种异常。

　　　　StandOverfolwError：线程请求的栈的深度大于虚拟机栈的深度。也就是栈帧太多，入不了栈了。

　　　　OutOfMemeryError：JAVA虚拟机扩展时无法申请到足够的内存

3.本地方法栈

　　本地方法栈和虚拟机内存栈基本类似。区别是虚拟机内存栈执行的是JAVA方法，本地方法栈执行的是native方法。

　　 有的虚拟机(HotSpot)把两者合二为一

4.JAVA堆

　1）它的唯一目的就是存放对象实例，它是JAVA虚拟机管理的内存中最大的一块

　2）它是所有线程共享的,当然，也可以在里面分配出各个线程私有的区域，如本地线程分配换缓冲区TLAB(https://www.cnblogs.com/jthr/p/15484760.html中1.2.2.2)

　3）它在虚拟机启动时创建

　4）它是垃圾回收器主要管理的内存区域

　5）JAVA堆可以处于物理上不连续的内存空间，但在逻辑上是连续的

　6）它的大小可以是固定的也可以是可扩展的，主流的虚拟机都是设计的可扩展的

　7）但JAVA堆没有内存分配实例且堆无法扩展时，会报出OutOfMemoryError

5.方法区

　1）它用于存储被虚拟机加载的类信息(类的版本、字段、方法、接口等)。常量、静态变量、即时编译器编译后的代码缓存等数据。(关于class文件信息https://www.cnblogs.com/jthr/p/15621161.html)

　 2）它是线程共享的

　 3）它可以处于物理上不连续的内存空间，但在逻辑上是连续的

　 4）它的大小可以是固定的也可以是可扩展的，主流的虚拟机都是设计的可扩展的

5）它可以选择不实现垃圾收集。但是一般会进行回收，这个区域的回收目标主要是针对常量池的回收和类型的卸载。

　 6）它的内存空间无法满足分配需求且无法扩展时，会报出OutOfMemoryError

6.运行时常量池

　　1）在JDK1.7之前运行时常量池逻辑包含字符串常量池，存放在方法区。

　　2）在JDK1.7字符串常量池被从方法区拿到了堆中, ,运行时常量池还在方法区,。

　　3）在JDK1.8 hotspot移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace)

6.1字符串常量池

1）字符串常量池的数据结构
　　在HotSpot VM里实现的string pool功能的是一个StringTable类，它是一个Hash表，默认值大小长度是1009；StringTable在每个HotSpot VM的实例只有一份，被所有的类共享。字符串常量由一个一个字符组成，放在了StringTable上。
　　在JDK6.0中，StringTable的长度是固定的，长度就是1009，因此如果放入String Pool中的String非常多，就会造成hash冲突，导致链表过长，当调用String#intern()时会需要到链表上一个一个找，从而导致性能大幅度下降；

　　在JDK7.0中，StringTable的长度可以通过参数指定：-XX:StringTableSize=66666

2）字符串常量池里存放的内容

　　在JDK6.0及之前版本中，String Pool里放的都是字符串常量；

　　在JDK7.0中，由于String#intern()发生了改变，除了字符串常量，String Pool中也可以存放放于堆内的字符串对象的引用

6.2class常量池(Class Constant Pool静态常量池)

1）简介
　　我们写的每一个Java类被编译后，就会形成一份class文件；class文件中除了包含类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池表(constant pool table)，用于存放编译器生成的各种字面量(Literal)和符号引用(Symbolic References)；每个class文件都有一个class常量池。

2）字面量和符号引用
　　https://www.cnblogs.com/jthr/p/15484424.html

3）静态常量池其实就是class文件里的一部分内容

　　以下图片是编译后的class文件。

当类加载到内存中后，jvm就会将静态常量池中的内容存放到运行时常量池中

6.3运行时常量池

　　运行时常量池存在于内存中，也就是静态常量池被加载到内存之后的版本，不同之处是：它的字面量可以动态的添加(String#intern()),符号引用可以被解析为直接引用
　　JVM在执行某个类的时候，必须经过加载、连接、初始化，而连接又包括验证、准备、解析三个阶段。而当类加载到内存中后，jvm就会将静态常量池中的内容存放到运行时常量池中

　　运行时常量池是全局共享的，多个类共用一个运行时常量池。并且class文件中常量池多个相同的字符串在运行时常量池只会存在一份

　　关系小结：

　　　　编译好的class文件包含了Constant pool(静态常量池)

　　　　class文件被加载时，Constant pool的内容会被加载到运行时常量池

　　　　运行时处理池也就包含了类的一些信息(字面量、符号引用等等信息)

　　　　在jdk1.7以前，运行时常量池包括字符串常量池，不过1.7开始字符串处理池从运行时处理池移到堆了