首先阐述一下写这个系列的目的，主要是受到一些启发，发现很多同学在平常工作过程中是为了编码而编码，一到跳槽季就急急忙忙的地进行亡羊补牢式的恶补，可能在短期来看，应试型的学习方式能获得较为不错的成效。但是随着工作年龄的增长这种学习方式就会漏洞百出，最常见的就是知其然不知其所以然，没有形成一个完整的知识体系，导致很多内容无法连贯起来，渐渐的就感受到了所谓的技术瓶颈。

技术从来不是一蹴而就的，技术的积累靠的是坚持和精益求精的的态度。在鼠年的年末，大家一定有很多感悟和收获，不管是年初想要跳一跳的同学，还是想在现有级别上更进一步的同学，我想和大家一起抓住鼠年的小尾巴，重温你必须知道的java虚拟机。

这块的内容主要的难点就是概念多，内容较为枯燥，但是脑壳兄会尽量通过自己的理解来更加形象化的表述方式来使大家增加记忆，希望能给大家带来一点点的帮助。

本章提要

本章主要围绕运行时数据区域展开，主要是一器一区一堆两栈。

程序计数器

字面意思就是一个计数的工具，确实他就是个计数的，他记的是线程各自字节码执行的位置。怎么理解这句话呢，打个不恰当的比方，我们每个人就可以看作一个线程，每个人口袋里面的钱每天都会变化，程序计数器的功能就相当于记录每天我们钱变化。既然这个钱每个人都是不一样的，那么程序计数器记录的就只能是一个人的钱的变化，所以具有隔离性，也就是线程私有。

较为官方的话语解释就是：程序计数器（Program Counter Register）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。

分两部分来理解这句话

内存较小很容易理解，既然是我们每个人每天的一个钱的变化，作为一个打工人，日常生活正常来说除了交通、一日三餐和理财，也没别的变化了，所以程序计数器占用空间小很好理解，毕竟只是一个行号指示器。

行号指示器又是什么，我们通过javap -c来看一下字节码文件的指令就一清二楚了

!

Compiled from "add.java"public class day1.Add {  public day1.Add();    Code:       0: aload_0       1: invokespecial #1                  // Method java/lang/Object."<init>":()V       4: return  public static void main(java.lang.String[]);    Code:       0: iconst_1       1: istore_1       2: iconst_2       3: istore_2       4: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;       7: iload_1       8: iload_2       9: iadd      10: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V      13: return}

这是一个很简单的两数相加的程序，我们通过javap指令工具看到的字节码前面的那一列数字就是我们这里所说的程序计数器所要记录的字节码行号了。别的看不懂不要紧，这里的字节码指令我们不会展开讲，当然同学们如果感兴趣可以提前学习学习。

需要注意的是程序计数器记录的内容是根据方法类型来记录的，如果是java方法那么记录的就是字节码指令的地址，如果是本地方法也就是我们常见的Native方法，那么这个计数器的值就是空。此内存区域是唯一一个在《Java虚拟机规范》中没有规定任何OutOfMemoryError情况的区域。

总结一下：程序计数器特点是占用内存小，线程私有，正常情况下没有OutOfMemoryError，作用是记录当前线程所执行的字节码的行号指示器。

实在记不住就想想自己口袋里面的money，每个人的口袋都是自己的也就是线程私有，即使是首富也不会数不清有多少钱也就不会OutOfMemoryError，相信大家现在一定不会忘记了。

Java虚拟机栈

与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stack）也是线程私有的，它的生命周期与线程生命周期相同，线程生命周期还说不出来的同学注意了，赶紧偷偷点击连接去瞅一眼了。

但是和程序计数器不一样的是，在《Java虚拟机规范》中，对这个内存区域规定了两类异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果Java虚拟机栈容量可以动态扩展，当栈扩展时无法申请到足够的内存会抛出OutOfMemoryError异常。

局部变量表

说到虚拟机栈，很多情况下我们关注的是其中的局部变量表部分。

⚠️注意了，虚拟机栈就考这个，具体的局部变量表如何看，我们之后会单独起一章来讲。

局部变量表存放了编译期可知的各种Java虚拟机基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它并不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。

这些数据类型在局部变量表中的存储空间以局部变量槽（Slot）来表示，其中64位长度的long和 double类型的数据会占用两个变量槽，其余的数据类型只占用一个。局部变量表所需的内存空间在编 译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间是完全确定 的，在方法运行期间不会改变局部变量表的大小。请读者注意，这里说的“大小”是指变量槽的数量， 虚拟机真正使用多大的内存空间（譬如按照1个变量槽占用32个比特、64个比特，或者更多）来实现一 个变量槽，这是完全由具体的虚拟机实现自行决定的事情。

上面两段话总结来说就是3点

1.局部变量表里面放3样东西，基本数据类型，对象引用和returnAddress类型。

这里稍微扩展一下，前面两样大家应该很熟悉，但是returnAddress类型这个东西可能有些同学不太清楚是什么，我们简单来讲一下。

returnAddress类型

在 JVM 中，数据分为两大类：primitive types （原生类型）和 reference types（引用类型）。returnAddress就属于其中的原生类型，只存在于字节码层面，也就是我们正常编码过程中是看不到也无法改变的，他所存储的就是指向特定指令内存地址的指针。

2.局部变量表内部的存储单位是局部变量槽（Slot），其中64位长度的long和 double类型的数据会占用两个变量槽，其余的数据类型只占用一个。但是具体的局部变量槽的实现方式完全是取决于虚拟机实现。

3.局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间是完全确定的，也就是局部变量槽的数量是确定的。为了加深这一点的印象，我们通过javap -c -v add来查看下add.java的字节码文件。

​ 我们关注一下箭头所指的这一行，也就是我们的main方法，一共是三个参数需要大家记住的

stack：最大操作数栈，JVM运行时会根据这个值来分配栈帧(Frame)中的操作栈深度,此处为3

locals: 局部变量所需的存储空间，单位为Slot, Slot是虚拟机为局部变量分配内存时所使用的最小单位，为4个字节大小。

args_size: 方法参数的个数，这里是1，因为每个实例方法都会有一个隐藏参数this

本地方法栈

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别只是虚拟机 栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的本地（Native） 方法服务。

《Java虚拟机规范》对本地方法栈中方法使用的语言、使用方式与数据结构并没有任何强制规 定，因此具体的虚拟机可以根据需要自由实现它，甚至有的Java虚拟机（譬如Hot-Spot虚拟机）直接 就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈也会在栈深度溢出或者栈扩展失 败时分别抛出StackOverflowError和OutOfMemoryError异常。

Java堆

相信大家都用过-Xmx和—Xms来启动我们的springboot项目，如果不做限制我们会发现我们的微服务会占用很大的内存,合适的堆大小对我们程序的影响至关重要。所以这块是很关键需要大家都清楚的内容，必考划重点了。

对于Java应用程序来说，Java堆（Java Heap）是虚拟机所管理的内存中最大的一块。Java堆是被所 有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，Java 世界里“几乎”所有的对象实例都在这里分配内存。

java是一个面向对象的强类型语言，那么多对象需要生成，对象的管理一定是重中之重，所以内存最大毫无疑问。对象是可以被线程共享的，所以线程共享也是情理之中。

既然说到了对象管理，那一定不能避免的就是GC了。java堆也被称为“GC堆”。

从回收内存的角度看，由于现代垃圾收集器大部分都是基于分代收集理论设计的，所以Java堆中经常会出现新生代、老年代、永久代、Eden空间、From Survivor空间、To Survivor空间”等名词。当然永久代在jdk8开始已经完全被元空间所替换，其缘由我们之后会详细说明。

如果从分配内存的角度看，所有线程共享的Java堆中可以划分出多个线程私有的分配缓冲区 （Thread Local Allocation Buffer，TLAB），以提升对象分配时的效率。不过无论从什么角度，无论如 何划分，都不会改变Java堆中存储内容的共性，无论是哪个区域，存储的都只能是对象的实例，将Java 堆细分的目的只是为了更好地回收内存，或者更快地分配内存。

这块是我们最常见的oom的区域，当堆内存不够或者无法扩展的时候，就会抛出OutOfMemoryError异常

总结一下：java堆的特点是消耗内存大，线程共享，作用是存储对象的实例，最常见的问题就是GC问题，堆内存不足以分配对象时会发生OOM问题

方法区

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载 的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。虽然《Java虚拟机规范》中把 方法区描述为堆的一个逻辑部分，但是它却有一个别名叫作“非堆”（Non-Heap），目的是与Java堆区 分开来。

PS: 如果大家还不清楚自己使用的虚拟机是哪个版本的可以使用java -version来查看一下

​

为什么有“非堆”（Non-Heap）这么奇葩的别名呢？

其原由就是在JDK8之前我们在HotSpot上部署开发的时候常常把永久代和方法区混为一谈，因为当时在HotSpot的收集器分代设计的时候把堆的回收策略扩展至方法区，或者说使用永久代来实现方法区而已，使得这两个使用同样的方式来管理这部分内存，省去专门为方法区编写内存管理代码的工作。

但是永久代有-XX：MaxPermSize的上限，即使不设置也有默认大小，会更容易导致方法区和永久代出现OOM的问题，所以在后续在JDK8开始我们就使用元空间来代替了原来的永久代的概念，同时使用本地内存来实现方法区。

《Java虚拟机规范》对方法区的约束是非常宽松的，除了和Java堆一样不需要连续的内存和可以选 择固定大小或者可扩展外，甚至还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域的 确是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这区域的内存回 收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列 表中，曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存 泄漏。

根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出 OutOfMemoryError异常。

总结一下：方法区于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据，根据他存储的信息可以推断出特点是线程共享，垃圾回收效果较差。

运行时常量池

为了更加形象的看得到什么叫常量池，还是利用上面我们使用过的那张图片

​ 这一块就是我们所说的常量池了，具体如何一字一句地看懂我们之后会详细来说，这里我们只关注运行时数据区域所包含的内容来展开叙述。

运行时常量池（Runtime Constant Pool）是方法区的一部分，用于存放编译期生 成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

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

直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中 定义的内存区域。

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

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

避免直接内存OOM最好的方式就是在设置-Xmx的时候要有预见性地设计，特别是在一台服务器上部署多个微服务项目的时候，-Xmx的总和不能把内存吃死，不然会导致系统卡顿，如果gc效果不好的话很有可能会导致直接内存出现OOM的问题。

总结一下

最后看着图片一起总结回忆一下各个区域的作用和特点。

​

一器一区一堆两栈，除了一器不会出现OOM其他都会出现各种异常。一区一堆线程共享，其他都是线程私有，但是堆中有Thread Local可供单个线程考屁属于自己的私有缓冲区。会发生GC的区域是一区一堆，主要是java堆的GC效果相对比较显著。最后千万不要让堆把内存吃太死，不然直接内存很容易发生OOM异常。

作者|敲脑壳呀敲脑壳|掘金