Java虚拟机 运行时数据区

Java在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途、创建和销毁的时间，有一些是随虚拟机的启动而创建，随虚拟机的退出而销毁，有些则是与线程一一对应，随线程的开始和结束而创建和销毁。

Java虚拟机所管理的内存将会包括以下几个运行时数据区域

程序计数器（Program Counter Register）

它是一块较小的内存空间，它的作用可以看做是当先线程所执行的字节码的信号指示器。

每一条JVM线程都有自己的PC寄存器，各条线程之间互不影响，独立存储，这类内存区域被称为“线程私有”内存。

在任意时刻，一条JVM线程只会执行一个方法的代码。该方法称为该线程的当前方法（Current Method）。

如果该方法是java方法，那PC寄存器保存JVM正在执行的字节码指令的地址。

如果该方法是native，那PC寄存器的值是undefined。

此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

Java虚拟机栈（Java Virtual Machine Stack）

与PC寄存器一样，Java虚拟机栈也是线程私有的。每一个JVM线程都有自己的java虚拟机栈，这个栈与线程同时创建，它的生命周期与线程相同。

虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

JVM stack 可以被实现成固定大小，也可以根据计算动态扩展。

如果采用固定大小的JVM stack设计，那么每一条线程的JVM Stack容量应该在线程创建时独立地选定。JVM实现应该提供调节JVM Stack初始容量的手段；如果采用动态扩展和收缩的JVM Stack方式，应该提供调节最大、最小容量的手段。

如果线程请求的栈深度大于虚拟机所允许的深度将抛出StackOverflowError；

如果JVM Stack可以动态扩展，但是在尝试扩展时无法申请到足够的内存时抛出OutOfMemoryError。

本地方法栈（Native Method Stack）

本地方法栈与虚拟机栈作用相似，后者为虚拟机执行Java方法服务，而前者为虚拟机用到的Native方法服务。

虚拟机规范对于本地方法栈中方法使用的语言，使用方式和数据结构没有强制规定，甚至有的虚拟机（比如HotSpot）直接把二者合二为一。

这玩意儿抛出的异常跟上面的虚拟机栈一样。

Java堆（Java Heap）

虚拟机管理的内存中最大的一块，同时也是被所有线程所共享的，它在虚拟机启动时创建，这货存在的意义就是存放对象实例，几乎所有的对象实例以及数组都要在这里分配内存。这里面的对象被自动管理，也就是俗称的GC（Garbage Collector）所管理。用就是了，有GC扛着呢，不用操心销毁回收的事儿。

Java堆的容量可以是固定大小，也可以随着需求动态扩展（-Xms和-Xmx），并在不需要过多空间时自动收缩。

Java堆所使用的内存不需要保证是物理连续的，只要逻辑上是连续的即可。

JVM实现应当提供给程序员调节Java 堆初始容量的手段，对于可动态扩展和收缩的堆来说，则应当提供调节其最大和最小容量的手段。

如果堆中没有内存完成实例分配并且堆也无法扩展，就会抛OutOfMemoryError。

方法区（Method Area）

跟堆一样是被各个线程共享的内存区域，用于存储以被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然这个区域被虚拟机规范把方法区描述为堆的一个逻辑部分，但是它的别名叫非堆，用来与堆做一下区别。

方法区在虚拟机启动的时候创建。

方法区的容量可以是固定大小的，也可以随着程序执行的需求动态扩展，并在不需要过多空间时自动收缩。

方法区在实际内存空间中可以是不连续的。

Java虚拟机实现应当提供给程序员或者最终用户调节方法区初始容量的手段，对于可以动态扩展和收缩方法区来说，则应当提供调节其最大、最小容量的手段。

当方法区无法满足内存分配需求时就会抛OutOfMemoryError。

这里有一个小例子，来说明堆，栈和方法区之间的关系的

public class Test2 {    public static void main(String[] args) {        public Test2 t2 = new Test2();        //JVM将Test2类信息加载到方法区,new Test2()实例保存在堆区,Test2引用保存在栈区      }}  

运行时常量池（Runtime Constant Pool）

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

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

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

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

符号引用和直接引用

先看Class文件里的“符号引用”。

考虑这样一个Java类：

public class X {  public void foo() {    bar();  }  public void bar() { }}

它编译出来的Class文件的文本表现形式如下：

Classfile /private/tmp/X.class  Last modified Jun 13, 2015; size 372 bytes  MD5 checksum 8abb9cbb66266e8bc3f5eeb35c3cc4dd  Compiled from "X.java"public class X  SourceFile: "X.java"  minor version: 0  major version: 51  flags: ACC_PUBLIC, ACC_SUPERConstant pool:   #1 = Methodref          #4.#16         //  java/lang/Object."<init>":()V   #2 = Methodref          #3.#17         //  X.bar:()V   #3 = Class              #18            //  X   #4 = Class              #19            //  java/lang/Object   #5 = Utf8               <init>   #6 = Utf8               ()V   #7 = Utf8               Code   #8 = Utf8               LineNumberTable   #9 = Utf8               LocalVariableTable  #10 = Utf8               this  #11 = Utf8               LX;  #12 = Utf8               foo  #13 = Utf8               bar  #14 = Utf8               SourceFile  #15 = Utf8               X.java  #16 = NameAndType        #5:#6          //  "<init>":()V  #17 = NameAndType        #13:#6         //  bar:()V  #18 = Utf8               X  #19 = Utf8               java/lang/Object{  public X();    flags: ACC_PUBLIC    Code:      stack=1, locals=1, args_size=1         0: aload_0                1: invokespecial #1                  // Method java/lang/Object."<init>":()V         4: return              LineNumberTable:        line 1: 0      LocalVariableTable:        Start  Length  Slot  Name   Signature               0       5     0  this   LX;  public void foo();    flags: ACC_PUBLIC    Code:      stack=1, locals=1, args_size=1         0: aload_0                1: invokevirtual #2                  // Method bar:()V         4: return              LineNumberTable:        line 3: 0        line 4: 4      LocalVariableTable:        Start  Length  Slot  Name   Signature               0       5     0  this   LX;  public void bar();    flags: ACC_PUBLIC    Code:      stack=0, locals=1, args_size=1         0: return              LineNumberTable:        line 6: 0      LocalVariableTable:        Start  Length  Slot  Name   Signature               0       1     0  this   LX;}

可以看到Class文件里有一段叫做“常量池”，里面存储的该Class文件里的大部分常量的内容。

来考察foo()方法里的一条字节码指令：

1: invokevirtual #2  // Method bar:()V

这在Class文件中的实际编码为：

[B6] [00 02]

其中0xB6是invokevirtual指令的操作码（opcode），后面的0x0002是该指令的操作数（operand），用于指定要调用的目标方法。
这个参数是Class文件里的常量池的下标。那么去找下标为2的常量池项，是：

#2 = Methodref          #3.#17         //  X.bar:()V

这在Class文件中的实际编码为（以十六进制表示，Class文件里使用高位在前字节序（big-endian））：

[0A] [00 03] [00 11]

其中0x0A是CONSTANT_Methodref_info的tag，后面的0x0003和0x0011是该常量池项的两个部分：class_index和name_and_type_index。这两部分分别都是常量池下标，引用着另外两个常量池项。
顺着这条线索把能传递引用到的常量池项都找出来，会看到（按深度优先顺序排列）：

 #2 = Methodref          #3.#17         //  X.bar:()V   #3 = Class              #18            //  X  #18 = Utf8               X  #17 = NameAndType        #13:#6         //  bar:()V  #13 = Utf8               bar   #6 = Utf8               ()V

把引用关系画成一棵树的话：

 #2 Methodref X.bar:()V     /                     \#3 Class X       #17 NameAndType bar:()V    |                /             \#18 Utf8 X    #13 Utf8 bar     #6 Utf8 ()V

标记为Utf8的常量池项在Class文件中实际为CONSTANT_Utf8_info，是以略微修改过的UTF-8编码的字符串文本。
样就清楚了对不对？
由此可以看出，Class文件中的invokevirtual指令的操作数经过几层间接之后，最后都是由字符串来表示的。这就是Class文件里的“符号引用”的实态：带有类型（tag） / 结构（符号间引用层次）的字符串。

---

然后再看JVM里的“直接引用”的样子。
这里就不拿HotSpot VM来举例了，因为它的实现略复杂。让我们看个更简单的实现，Sun的元祖JVM——Sun JDK 1.0.2的32位x86上的做法。
请先参考另一个回答里讲到Sun Classic VM的部分：为什么bs虚函数表的地址（int*）(&bs)与虚函数地址（int*）(int)(&bs) 不是同一个？ - RednaxelaFX 的回答
Sun Classic VM:（以32位Sun JDK 1.0.2在x86上为例）

   HObject             ClassObject                       -4 [ hdr            ]--> +0 [ obj     ] --> +0 [ ... fields ... ]    +4 [ methods ] \                    \         methodtable            ClassClass                     > +0  [ classdescriptor ] --> +0 [ ... ]                       +4  [ vtable[0]       ]      methodblock                       +8  [ vtable[1]       ] --> +0 [ ... ]                       ... [ vtable...       ]

（请留心阅读上面链接里关于虚方法表与JVM的部分。Sun的元祖JVM也是用虚方法表的喔。）

元祖JVM在做类加载的时候会把Class文件的各个部分分别解析（parse）为JVM的内部数据结构。例如说类的元数据记录在ClassClass结构体里，每个方法的元数据记录在各自的methodblock结构体里，等等。
在刚加载好一个类的时候，Class文件里的常量池和每个方法的字节码（Code属性）会被基本原样的拷贝到内存里先放着，也就是说仍然处于使用“符号引用”的状态；直到真的要被使用到的时候才会被解析（resolve）为直接引用。

假定我们要第一次执行到foo()方法里调用bar()方法的那条invokevirtual指令了。
此时JVM会发现该指令尚未被解析（resolve），所以会先去解析一下。
通过其操作数所记录的常量池下标0x0002，找到常量池项#2，发现该常量池项也尚未被解析（resolve），于是进一步去解析一下。
通过Methodref所记录的class_index找到类名，进一步找到被调用方法的类的ClassClass结构体；然后通过name_and_type_index找到方法名和方法描述符，到ClassClass结构体上记录的方法列表里找到匹配的那个methodblock；最终把找到的methodblock的指针写回到常量池项#2里。

也就是说，原本常量池项#2在类加载后的运行时常量池里的内容跟Class文件里的一致，是：

[00 03] [00 11]

（tag被放到了别的地方；小细节：刚加载进来的时候数据仍然是按高位在前字节序存储的）
而在解析后，假设找到的methodblock*是0x45762300，那么常量池项#2的内容会变为：

[00 23 76 45]

（解析后字节序使用x86原生使用的低位在前字节序（little-endian），为了后续使用方便）
这样，以后再查询到常量池项#2时，里面就不再是一个符号引用，而是一个能直接找到Java方法元数据的methodblock*了。这里的methodblock*就是一个“直接引用”。

解析好常量池项#2之后回到invokevirtual指令的解析。
回顾一下，在解析前那条指令的内容是：

[B6] [00 02]

而在解析后，这块代码被改写为：

[D6] [06] [01]

其中opcode部分从invokevirtual改写为invokevirtual_quick，以表示该指令已经解析完毕。
原本存储操作数的2字节空间现在分别存了2个1字节信息，第一个是虚方法表的下标（vtable index），第二个是方法的参数个数。这两项信息都由前面解析常量池项#2得到的methodblock*读取而来。
也就是：

invokevirtual_quick vtable_index=6, args_size=1

这里例子里，类X对应在JVM里的虚方法表会是这个样子的：

[0]: java.lang.Object.hashCode:()I[1]: java.lang.Object.equals:(Ljava/lang/Object;)Z[2]: java.lang.Object.clone:()Ljava/lang/Object;[3]: java.lang.Object.toString:()Ljava/lang/String;[4]: java.lang.Object.finalize:()V[5]: X.foo:()V[6]: X.bar:()V

所以JVM在执行invokevirtual_quick要调用X.bar()时，只要顺着对象引用查找到虚方法表，然后从中取出第6项的methodblock*，就可以找到实际应该调用的目标然后调用过去了。

假如类X还有子类Y，并且Y覆写了bar()方法，那么类Y的虚方法表就会像这样：

[0]: java.lang.Object.hashCode:()I[1]: java.lang.Object.equals:(Ljava/lang/Object;)Z[2]: java.lang.Object.clone:()Ljava/lang/Object;[3]: java.lang.Object.toString:()Ljava/lang/String;[4]: java.lang.Object.finalize:()V[5]: X.foo:()V[6]: Y.bar:()V

于是通过vtable_index=6就可以找到类Y所实现的bar()方法。

所以说在解析/改写后的invokevirtual_quick指令里，虚方法表下标（vtable index）也是一个“直接引用”的表现。

关于这种“_quick”指令的设计，可以参考远古的JVM规范第1版的第9章。这里有一份拷贝：http://www.cs.miami.edu/~burt/reference/java/language_vm_specification.pdf

在现在的HotSpot VM里，围绕常量池、invokevirtual的解析（再次强调是resolve）的具体实现方式跟元祖JVM不一样，但是大体的思路还是相通的。

HotSpot VM的运行时常量池有ConstantPool和ConstantPoolCache两部分，有些类型的常量池项会直接在ConstantPool里解析，另一些会把解析的结果放到ConstantPoolCache里。以前发过一帖有简易的图解例子，可以参考：请问，jvm实现读取class文件常量池信息是怎样呢？

---

由此可见，符号引用通常是设计字符串的——用文本形式来表示引用关系。

而直接引用是JVM（或其它运行时环境）所能直接使用的形式。它既可以表现为直接指针（如上面常量池项#2解析为methodblock*），也可能是其它形式（例如invokevirtual_quick指令里的vtable index）。
关键点不在于形式是否为“直接指针”，而是在于JVM是否能“直接使用”这种形式的数据。

直接内存（Direct Memory）

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError异常出现。

JDK1.4加的NIO中，ByteBuffer有个方法是allocateDirect(int capacity) ，这是一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

显然，本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存（包括RAM及SWAP区或者分页文件）的大小及处理器寻址空间的限制。服务器管理员配置虚拟机参数时，一般会根据实际内存设置-Xmx等参数信息，但经常会忽略掉直接内存，使得各个内存区域的总和大于物理内存限制（包括物理上的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常。

本文转自

Java虚拟机 运行时数据区

部分转自

JVM里的符号引用如何存储？