•写在前面

Java虚拟机运行时数据区是我们深入了解JVM的必经之路，那这是什么样的一个区域呢？Java虚拟机在执行Java程序的过程中，会把它所管理的内存划分若干个不同的数据区域，这些区域被赋予不同的用途，它们有着各自创建和销毁时间，有的区域是随着虚拟机进程启动而存在的，有的区域则是依赖用户线程的启动和结束而建立和销毁的。它是类似一种模型规范，Java虚拟机的构建需要依照这个进行。我们可以把它大致的画成一个图，大概是长这样的。

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70

关于线程隔离和线程共享的部分，接下来对几个数据区单独讲解的时候会详细说到，这里你只要大概了解他们存在隶属的单个线程的还是整个区域的。

•程序计数器

首先我们来谈一谈程序计数器，程序计数器这东西，它其实在不同的虚拟机中有不同的实现，毕竟相对于对程序独立计数的算法，往往有很多更加优化高效的算法可以使用，所以我们在这里提到的程序计数器的概念，是在虚拟机的内存模型中的，具体实现因不同虚拟机而异。在概念模型中，程序计数器是一块较小的内存空间，它可以看做是当前线程所执行的字节码的行号指示器，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

为了方便理解，我这里打开一个编译后的字节码文件，贴出来，你就会发现十六进制下，他们是一个寻址执行的过程（自己也可以去找一个class文件看看，记得别直接用记事本啥的打开哦会乱码的，可以使用winhex这个小工具打开）。

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0RCQ18xMjE_size_16_color_FFFFFF_t_70 1

由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器只能执行一条线程中的指令，因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立储存，所以说程序计数器是“线程私有”的内存区。

要强调一下的是，线程在执行一个java方法，这个程序计数器记录的是正在执行的虚拟机字节码指令地址，就是上图我标记的内存偏移地址（指令地址），但如果执行的是一个native方法，则程序计数器为空，也就是undefined。而且程序计数器这块内存是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

•java虚拟机栈和本地方法栈

和程序计数器一样，java虚拟机栈同样也是线程私有的，它的生命周期和线程相同，虚拟机栈描述的是java方法执行的内存模型，这个模型大概这么描述：每个方法在执行的同时都会创建一个栈帧用于储存局部变量表、操作数栈、动态链接、方法出口等信息，每个方法从条用直至执行完成的过程，就是对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

进一步了解，局部变量表存放了编译期可知的各种基本数据类型（就是boolean、int、float之类的这些）、对象引用（就是我们所说的reference类型，它是指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置）、returnAddress类型（指向了一条字节码指令的地址）。

基本数据类型中，long和double类型是64位长度，所以在局部变量表中占用2个空间，其余的数据只占一个。局部变量变所需的内存空间在编译期间就完成了分配，当进入一个方法是，这个方法需要在帧中分配多大的局部变量空间是确定的，方法运行期间不会改变局部变量表的大小。

对于java虚拟机栈，规定了两种异常状况，第一种是如果线程请求的栈深度大于虚拟机所允许的深度，将抛出Stack OverflowError异常。第二种是如果虚拟机栈可以动态扩展，而扩展是无法申请足够的内存，就会抛出OutOfMemoryError异常。

本地方法栈，之所以和虚拟机栈放在一起讲，是因为两个发挥的作用非常相似，它们之间的差别不过是虚拟机栈为虚拟机执行的java方法工作，而本地方发展执行的是Native方法工作（java方法和native方法东西挺多了，有兴趣看我另一篇文章，专门讲这两个东西）

•java堆

java堆应该是我们打交道最大的一块内存，和目前为止上面讲到的区域不同的是，java堆是一块所有线程共享的一块内存区域。在虚拟机启动时创建。这个内存的唯一目的就是用来存放对象实例，几乎所有的对象实例都放在这里分配内存，我们翻阅java虚拟机规范的时候，里面是这样描述的：所有对象的实例以及数组都要在堆上分配，但随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都是分配在堆上也渐渐变得不那么绝对。

正因为我们创建的所有实例都放在堆上分配，所以，虚拟机在进行垃圾回收的时候，主要也是针对java堆进行的，所以java堆也被成为GC堆。从内存回收的角度来看，由于现在收集器基本都采用分带收集算法，所以java堆还可以细分为新生代和老年代，更进一步就是一个E区和两个S区，关于分代涉及到GC算法，可以查阅我的另一篇文章，专门对GC算法进行详细的讲解。从内存分配的角度来看，线程共享的java堆中可能划分出多个线程私有的分配缓冲区，不过无论如何划分，都与存放内容没有关系，无论哪个区域，存放的都是对象实例

•方法区

同java堆一样，方法区也是线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。你去查案java虚拟机规范的时候会发现，里面把方法区描述为堆的一个逻辑部分，但它却又一个别名叫做Non-Heap（非堆），目的就是和java堆区分开。特别说明的是，方法区和java堆一样不需要连续的内存和可以选择固定大小或者可以扩展外，还可以不识闲垃圾回收。换一种确切的说法就是垃圾回收行为在这个区域是比较少出现的，但并非数据进入方法区就永久存在了（方法区已经被用来做永久代），这区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收效果很难达到预期，毕竟里面存的都是些“老东西”，尤其是类型的卸载，条件相当的苛刻，但不管怎么说，还是需要进行垃圾回收的。

在方法区中有一个特别的部分，叫做运行时常量池。我们编译出来的Class文件中，除了有类的版本、字段、方法、接口等描述信息外，还有一项信息就叫做常量池，用来存放编译器生成的各种字面量和符号引用，这部分内容将在类加载进入方法区的运行时常量池中存放。

我们知道的，java虚拟机对Class文件的每一部分的格式都有严格的规定，每一个字节用于储存哪种数据都必须符合规范上的要求才能被虚拟机认可、装载和执行（上面的那个class文件的内容，你不要觉得它乱，其实它有着严格的格式）。但对于运行时常量池，java虚拟机规范中没有做任何细节的要求，不同的提供商的虚拟机有着不同的实现方式。不过一般来说，除了保存Class文件中描述的符号引用外，还会把翻译出来的直接引用也储存在运行时常量池中。运行时常量池相对于Class文件常量的另一个重要特征是具备动态性，java语言并不要求常量一定只要编译器才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性用到比较多的是String类的intern()方法。