详解JVM对象内存布局以及内存分配规则

一叶飘舟

已于 2024-02-18 19:19:10 修改

阅读量199

点赞数

文章标签： jvm

于 2024-02-18 18:20:46 首次发布

原文链接：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzkyODMwNDYzOA==&action=getalbum&album_id=3005548079720185865&scene=173&subscene=&sessionid=svr_45ae2346ee0&enterid=1708251143&from_msgid=2247487354&from_itemidx=1&count=3&nolastread=1#wechat_redirect

版权

JVM 内存结构

Java 虚拟机的内存空间分为 5 个部分：

程序计数器
Java 虚拟机栈
本地方法栈
堆
方法区

JDK 1.8 同 JDK 1.7 比，最大的差别就是：元数据区取代了永久代。元空间的本质和永久代类似，都是对 JVM 规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元数据空间并不在虚拟机中，而是使用本地内存。

程序计数器（PC 寄存器）

程序计数器的定义

程序计数器是一块较小的内存空间，是当前线程正在执行的那条字节码指令的地址。若当前线程正在执行的是一个本地方法，那么此时程序计数器为Undefined。

程序计数器的作用

字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制。
在多线程情况下，程序计数器记录的是当前线程执行的位置，从而当线程切换回来时，就知道上次线程执行到哪了。

程序计数器的特点

是一块较小的内存空间。
线程私有，每条线程都有自己的程序计数器。
生命周期：随着线程的创建而创建，随着线程的结束而销毁。
是唯一一个不会出现 OutOfMemoryError 的内存区域。

Java 虚拟机栈（Java 栈）

Java 虚拟机栈的定义

Java 虚拟机栈是描述 Java 方法运行过程的内存模型。

Java 虚拟机栈会为每一个即将运行的 Java 方法创建一块叫做“栈帧”的区域，用于存放该方法运行过程中的一些信息，如：

局部变量表
操作数栈
动态链接
方法出口信息
......

压栈出栈过程

当方法运行过程中需要创建局部变量时，就将局部变量的值存入栈帧中的局部变量表中。

Java 虚拟机栈的栈顶的栈帧是当前正在执行的活动栈，也就是当前正在执行的方法，PC 寄存器也会指向这个地址。只有这个活动的栈帧的本地变量可以被操作数栈使用，当在这个栈帧中调用另一个方法，与之对应的栈帧又会被创建，新创建的栈帧压入栈顶，变为当前的活动栈帧。

方法结束后，当前栈帧被移出，栈帧的返回值变成新的活动栈帧中操作数栈的一个操作数。如果没有返回值，那么新的活动栈帧中操作数栈的操作数没有变化。

由于 Java 虚拟机栈是与线程对应的，数据不是线程共享的（也就是线程私有的)，因此不用关心数据一致性问题，也不会存在同步锁的问题。

局部变量表

定义为一个数字数组，主要用于存储方法参数、定义在方法体内部的局部变量，数据类型包括各类基本数据类型，对象引用，以及 return address 类型。

局部变量表容量大小是在编译期确定下来的。最基本的存储单元是 slot，32 位占用一个 slot，64 位类型（long 和 double）占用两个 slot。

对于 slot 的理解：

JVM 虚拟机会为局部变量表中的每个 slot 都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值。
如果当前帧是由构造方法或者实例方法创建的，那么该对象引用 this，会存放在 index 为 0 的 slot 处，其余的参数表顺序继续排列。
栈帧中的局部变量表中的槽位是可以重复的，如果一个局部变量过了其作用域，那么其作用域之后申明的新的局部变量就有可能会复用过期局部变量的槽位，从而达到节省资源的目的。

在栈帧中，与性能调优关系最密切的部分，就是局部变量表，方法执行时，虚拟机使用局部变量表完成方法的传递局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。

操作数栈

栈顶缓存技术：由于操作数是存储在内存中，频繁的进行内存读写操作影响执行速度，将栈顶元素全部缓存到物理 CPU 的寄存器中，以此降低对内存的读写次数，提升执行引擎的执行效率。
每一个操作数栈会拥有一个明确的栈深度，用于存储数值，最大深度在编译期就定义好。32bit 类型占用一个栈单位深度，64bit 类型占用两个栈单位深度操作数栈。
并非采用访问索引方式进行数据访问，而是只能通过标准的入栈、出栈操作完成一次数据访问。

方法的调用

静态链接：当一个字节码文件被装载进 JVM 内部时，如果被调用的目标方法在编译期可知，且运行时期间保持不变，这种情况下降调用方的符号引用转为直接引用的过程称为静态链接。
动态链接：如果被调用的方法无法在编译期被确定下来，只能在运行期将调用的方法的符号引用转为直接引用，这种引用转换过程具备动态性，因此被称为动态链接。
方法绑定
- 早期绑定：被调用的目标方法如果在编译期可知，且运行期保持不变。
- 晚期绑定：被调用的方法在编译期无法被确定，只能够在程序运行期根据实际的类型绑定相关的方法。
非虚方法：如果方法在编译期就确定了具体的调用版本，则这个版本在运行时是不可变的，这样的方法称为非虚方法静态方法。私有方法，final 方法，实例构造器，父类方法都是非虚方法，除了这些以外都是虚方法。
虚方法表：面向对象的编程中，会很频繁的使用动态分配，如果每次动态分配的过程都要重新在类的方法元数据中搜索合适的目标的话，就可能影响到执行效率，因此为了提高性能，JVM 采用在类的方法区建立一个虚方法表，使用索引表来代替查找。
- 每个类都有一个虚方法表，表中存放着各个方法的实际入口。
- 虚方法表会在类加载的链接阶段被创建，并开始初始化，类的变量初始值准备完成之后，JVM 会把该类的方法也初始化完毕。
方法重写的本质
- 找到操作数栈顶的第一个元素所执行的对象的实际类型，记做 C。如果在类型 C 中找到与常量池中描述符和简单名称都相符的方法，则进行访问权限校验。
- 如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回 java.lang.IllegalAccessError 异常。
- 否则，按照继承关系从下往上依次对 C 的各个父类进行上一步的搜索和验证过程。
- 如果始终没有找到合适的方法，则抛出 java.lang.AbstractMethodError 异常。

Java 中任何一个普通方法都具备虚函数的特征（运行期确认，具备晚期绑定的特点），C++ 中则使用关键字 virtual 来显式定义。如果在 Java 程序中，不希望某个方法拥有虚函数的特征，则可以使用关键字 final 来标记这个方法。

Java 虚拟机栈的特点

运行速度特别快，仅仅次于 PC 寄存器。
局部变量表随着栈帧的创建而创建，它的大小在编译时确定，创建时只需分配事先规定的大小即可。在方法运行过程中，局部变量表的大小不会发生改变。
Java 虚拟机栈会出现两种异常：StackOverFlowError 和 OutOfMemoryError。
- StackOverFlowError 若 Java 虚拟机栈的大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度时，抛出 StackOverFlowError 异常。
- OutOfMemoryError 若允许动态扩展，那么当线程请求栈时内存用完了，无法再动态扩展时，抛出 OutOfMemoryError 异常。
Java 虚拟机栈也是线程私有，随着线程创建而创建，随着线程的结束而销毁。
出现 StackOverFlowError 时，内存空间可能还有很多。

常见的运行时异常有：

NullPointerException - 空指针引用异常
ClassCastException - 类型强制转换异
IllegalArgumentException - 传递非法参数异常
ArithmeticException - 算术运算异常
ArrayStoreException - 向数组中存放与声明类型不兼容对象异常
IndexOutOfBoundsException - 下标越界异常
NegativeArraySizeException - 创建一个大小为负数的数组错误异常
NumberFormatException - 数字格式异常
SecurityException - 安全异常
UnsupportedOperationException - 不支持的操作异常

本地方法栈（C 栈）

本地方法栈的定义

本地方法栈是为 JVM 运行 Native 方法准备的空间，由于很多 Native 方法都是用 C 语言实现的，所以它通常又叫 C 栈。它与 Java 虚拟机栈实现的功能类似，只不过本地方法栈是描述本地方法运行过程的内存模型。

栈帧变化过程

本地方法被执行时，在本地方法栈也会创建一块栈帧，用于存放该方法的局部变量表、操作数栈、动态链接、方法出口信息等。

方法执行结束后，相应的栈帧也会出栈，并释放内存空间。也会抛出 StackOverFlowError 和 OutOfMemoryError 异常。

如果 Java 虚拟机本身不支持 Native 方法，或是本身不依赖于传统栈，那么可以不提供本地方法栈。如果支持本地方法栈，那么这个栈一般会在线程创建的时候按线程分配。

堆

堆的定义

堆是用来存放对象的内存空间，几乎所有的对象都存储在堆中。

堆的特点

线程共享，整个 Java 虚拟机只有一个堆，所有的线程都访问同一个堆。而程序计数器、Java 虚拟机栈、本地方法栈都是一个线程对应一个。
在虚拟机启动时创建。
是垃圾回收的主要场所。
堆可分为新生代（Eden 区：From Survior，To Survivor）、老年代。
Java 虚拟机规范规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
关于 Survivor s0，s1 区: 复制之后有交换，谁空谁是 to。

不同的区域存放不同生命周期的对象，这样可以根据不同的区域使用不同的垃圾回收算法，更具有针对性。

堆的大小既可以固定也可以扩展，但对于主流的虚拟机，堆的大小是可扩展的，因此当线程请求分配内存，但堆已满，且内存已无法再扩展时，就抛出 OutOfMemoryError 异常。

Java 堆所使用的内存不需要保证是连续的。而由于堆是被所有线程共享的，所以对它的访问需要注意同步问题，方法和对应的属性都需要保证一致性。

新生代与老年代

老年代比新生代生命周期长。
新生代与老年代空间默认比例 1:2：JVM 调参数，XX:NewRatio=2，表示新生代占 1，老年代占 2，新生代占整个堆的 1/3。
HotSpot 中，Eden 空间和另外两个 Survivor 空间缺省所占的比例是：8:1:1。
几乎所有的 Java 对象都是在 Eden 区被 new 出来的，Eden 放不了的大对象，就直接进入老年代了。

对象分配过程

new 的对象先放在 Eden 区，大小有限制
如果创建新对象时，Eden 空间填满了，就会触发 Minor GC，将 Eden 不再被其他对象引用的对象进行销毁，再加载新的对象放到 Eden 区，特别注意的是 Survivor 区满了是不会触发 Minor GC 的，而是 Eden 空间填满了，Minor GC 才顺便清理 Survivor 区
将 Eden 中剩余的对象移到 Survivor0 区
再次触发垃圾回收，此时上次 Survivor 下来的，放在 Survivor0 区的，如果没有回收，就会放到 Survivor1 区
再次经历垃圾回收，又会将幸存者重新放回 Survivor0 区，依次类推
默认是 15 次的循环，超过 15 次，则会将幸存者区幸存下来的转去老年区 jvm 参数设置次数 : -XX:MaxTenuringThreshold=N 进行设置
频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间搜集

Full GC /Major GC 触发条件

显示调用System.gc()，老年代的空间不够，方法区的空间不够等都会触发 Full GC，同时对新生代和老年代回收，FUll GC 的 STW 的时间最长，应该要避免
在出现 Major GC 之前，会先触发 Minor GC，如果老年代的空间还是不够就会触发 Major GC，STW 的时间长于 Minor GC

逃逸分析

标量替换
- 标量不可在分解的量，java 的基本数据类型就是标量，标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。而在 JAVA 中对象就是可以被进一步分解的聚合量
- 替换过程，通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM 不会创建该对象，而会将该对象成员变量分解若干个被这个方法使用的成员变量所代替。这些代替的成员变量在栈帧或寄存器上分配空间。
对象和数组并非都是在堆上分配内存的
《深入理解 Java 虚拟机中》关于 Java 堆内存有这样一段描述：随着 JIT 编译期的发展与逃逸分析技术逐渐成熟，栈上分配,标量替换优化技术将会导致一些变化，所有的对象都分配到堆上也渐渐变得不那么"绝对"了。
这是一种可以有效减少 Java 内存堆分配压力的分析算法，通过逃逸分析，Java Hotspot 编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。
当一个对象在方法中被定义后，它可能被外部方法所引用，如作为调用参数传递到其他地方中，称为方法逃逸。
再如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸
使用逃逸分析，编译器可以对代码做如下优化：
- 同步省略：如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
- 将堆分配转化为栈分配：如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
- 分离对象或标量替换：有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在 CPU 寄存器中。

public static StringBuffer createStringBuffer(String s1, String s2) {

    StringBuffer s = new StringBuffer();

    s.append(s1);

    s.append(s2);

    return s;
}

s 是一个方法内部变量，上边的代码中直接将 s 返回，这个 StringBuffer 的对象有可能被其他方法所改变，导致它的作用域就不只是在方法内部，即使它是一个局部变量，但还是逃逸到了方法外部，称为方法逃逸。

还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。

在编译期间，如果 JIT 经过逃逸分析，发现有些对象没有逃逸出方法，那么有可能堆内存分配会被优化成栈内存分配。
jvm 参数设置，-XX:+DoEscapeAnalysis ：开启逃逸分析，-XX:-DoEscapeAnalysis ：关闭逃逸分析
从 jdk 1.7 开始已经默认开始逃逸分析。

TLAB

TLAB 的全称是 Thread Local Allocation Buffer，即线程本地分配缓存区，是属于 Eden 区的，这是一个线程专用的内存分配区域，线程私有，默认开启的（当然也不是绝对的，也要看哪种类型的虚拟机）
堆是全局共享的，在同一时间，可能会有多个线程在堆上申请空间，但每次的对象分配需要同步的进行（虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性）但是效率却有点下降
所以用 TLAB 来避免多线程冲突，在给对象分配内存时，每个线程使用自己的 TLAB，这样可以使得线程同步，提高了对象分配的效率
当然并不是所有的对象都可以在 TLAB 中分配内存成功，如果失败了就会使用加锁的机制来保持操作的原子性
-XX:+UseTLAB 使用 TLAB，-XX:+TLABSize 设置 TLAB 大小

四种引用方式

强引用：创建一个对象并把这个对象赋给一个引用变量，普通 new 出来对象的变量引用都是强引用，有引用变量指向时永远不会被垃圾回收，jvm 即使抛出 OOM，可以将引用赋值为 null，那么它所指向的对象就会被垃圾回收。
软引用：如果一个对象具有软引用，内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。
弱引用：非必需对象，当 JVM 进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。
虚引用：虚引用并不会决定对象的生命周期，如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。

方法区

方法区的定义

Java 虚拟机规范中定义方法区是堆的一个逻辑部分。方法区存放以下信息：

已经被虚拟机加载的类信息
常量
静态变量
即时编译器编译后的代码

方法区的特点

线程共享。方法区是堆的一个逻辑部分，因此和堆一样，都是线程共享的。整个虚拟机中只有一个方法区。
永久代。方法区中的信息一般需要长期存在，而且它又是堆的逻辑分区，因此用堆的划分方法，把方法区称为“永久代”。
内存回收效率低。方法区中的信息一般需要长期存在，回收一遍之后可能只有少量信息无效。主要回收目标是：对常量池的回收；对类型的卸载。
Java 虚拟机规范对方法区的要求比较宽松。和堆一样，允许固定大小，也允许动态扩展，还允许不实现垃圾回收。

运行时常量池

方法区中存放：类信息、常量、静态变量、即时编译器编译后的代码。常量就存放在运行时常量池中。

当类被 Java 虚拟机加载后， .class 文件中的常量就存放在方法区的运行时常量池中。而且在运行期间，可以向常量池中添加新的常量。如 String 类的 intern() 方法就能在运行期间向常量池中添加字符串常量。

直接内存（堆外内存）

直接内存是除 Java 虚拟机之外的内存，但也可能被 Java 使用。

操作直接内存

在 NIO 中引入了一种基于通道和缓冲的 IO 方式。它可以通过调用本地方法直接分配 Java 虚拟机之外的内存，然后通过一个存储在堆中的DirectByteBuffer对象直接操作该内存，而无须先将外部内存中的数据复制到堆中再进行操作，从而提高了数据操作的效率。

直接内存的大小不受 Java 虚拟机控制，但既然是内存，当内存不足时就会抛出 OutOfMemoryError 异常。

直接内存与堆内存比较

直接内存申请空间耗费更高的性能
直接内存读取 IO 的性能要优于普通的堆内存
直接内存作用链：本地 IO -> 直接内存 -> 本地 IO
堆内存作用链：本地 IO -> 直接内存 -> 非直接内存 -> 直接内存 -> 本地 IO

服务器管理员在配置虚拟机参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制，从而导致动态扩展时出现OutOfMemoryError异常。

JVM对象内存布局以及内存分配规则

面试题：
1. 请解释一下对象的创建过程？
1. class loading
2. class linking (verification, preparation, resolution)
3. class initializing
4. 申请对象内存
5. 成员变量赋默认值
6. 调用构造方法<init>
1. 成员变量顺序赋初始值
2. 执行构造方法语句
2. 对象在内存中的存储布局？
64位机器
普通对象
1. 对象头：markword 8
2. ClassPointer指针：-XX:+UseCompressedClassPointers 为4字节不开启为8字节
3. 实例数据
1. 引用类型：-XX:+UseCompressedOops 为4字节不开启为8字节
Oops Ordinary Object Pointers
4. Padding对齐，8的倍数
数组对象
1. 对象头：markword 8
2. ClassPointer指针同上
3. 数组长度：4字节
4. 数组数据
5. 对齐 8的倍数
3. 对象头具体包括什么？
4. 对象怎么定位？
1.句柄池:T t=new T(); -->一个指针指向t,一个指针指向T.class
2.直接指针T t=new T(); -->一个指针直接指向t,t再直接指向T.class：(HotSpot使用)
5. 对象怎么分配？
6. Object o = new Object在内存中占用多少字节？

对象的内存布局

在 HotSpot 虚拟机中，对象（普通对象）的内存布局分为以下 3 块区域：

对象头（Header）
实例数据（Instance Data）
对齐填充（Padding）

数组对象

对象头

在64位系统上各状态的格式如下：

在32位系统上各状态的格式如下：

对象头记录了对象在运行过程中所需要使用的一些数据：

哈希码
GC 分代年龄
锁状态标志
线程持有的锁
偏向线程 ID
偏向时间戳

对象头可能包含类型指针，通过该指针能确定对象属于哪个类。如果对象是一个数组，那么对象头还会包括数组长度。

对象标记（Mark Word）

对象标记主要存放锁信息和GC标记，Java的synchronized锁不是一加锁就是重量锁，有一个锁的升级过程（无锁态->偏向锁->轻量锁->重量锁），锁信息中存放的就是这个过程所需要的信息，而GC标记就是GC分代信息，用于标记对象的年龄和存活状态，以便进行垃圾回收。

类型指针（Klass Point）

类型指针比较好理解，是表示指向该对象类元数据的地址，JDK1.8的类元信息存储在元空间中，那么这个类型指针指向的就是元空间中类信息的地址。

数组长度（Length）

如果是数组对象，在对象头还会存储一个数组长度值。

实例数据

实例数据部分就是成员变量的值，其中包括父类成员变量和本类成员变量。

对齐填充

用于确保对象的总长度为 8 字节的整数倍。

HotSpot VM 的自动内存管理系统要求对象的大小必须是 8 字节的整数倍。而对象头部分正好是 8 字节的倍数（1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

对齐填充并不是必然存在，也没有特别的含义，它仅仅起着占位符的作用。

指针压缩

同一个对象，不开启指针压缩，类型指针（Klass Point）占用8字节，开启指针压缩占用4字节，如果不开启指针压缩，会占用更多内存，使用较大指针在主内存和缓存之间移动数据，占用较大宽带，所以为了减少64位平台下内存的消耗和避免GC压力过大，JDK1.6以后默认启用指针压缩功能。

JDK1.6 update14开始，在64位操作系统中，JVM支持指针压缩，并且是默认开启的。
启用指针压缩 -XX:+UseCompressedOops(默认开启)，禁止指针压缩:-XX:-UseCompressedOops

代码分析对象结构和占用内存大小

我这里使用的是64位系统，JDK1.8，要查看对象结构和占用内存大小还需要引入jol-core包。

        <dependency>
            <groupId>org.openjdk.jol</groupId>
            <artifactId>jol-core</artifactId>
            <version>0.10</version>
        </dependency>

分析Object对象

    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }

默认开启指针压缩

这里可以看到一个Java的Object空对象需要占用16个字节，其中Mark Word 和 Klass Point 合计占用12个字节，因为不满足8的倍数这里会进行对齐填充4个字节，也就是说一个最小的对象要占用16个字节。

关闭指针压缩

# 加上关闭指针压缩启动参数
-XX:-UseCompressedOops

关闭指针压缩后 Klass Point 占用8个字节，Mark Word 和 Klass Point 合计占用16个字节满足8的倍数不需要对齐填充。

自定义对象分析

自定义User类

public class User {
    private Long id;
    private Integer age;
    private String nickName;
}

打印User对象内存结构

    public static void main(String[] args) {
        User user = new User();
        System.out.println(ClassLayout.parseInstance(user).toPrintable());
    }

开启指针压缩

在开启指针压缩的情况下实例数据合计占用24个字节，基本类型和包装类型占用字节数是有区别的，可以。

关闭指针压缩

关闭指针压缩后实例数据合计占用36个字节，并且还有对齐填充的4个字节，占用内存比开启指针压缩多了16个字节。

JVM堆内存最好不要超过32G

JDK1.6 update14开始，在64位操作系统中，JVM堆内存小于32G的时候会默认开启一个内存对象指针压缩技术。在java中，所有的对象都分配在堆上，然后有一个指针引用它。指向这些对象的指针大小通常是CPU的字长的大小，不是32bit就是64bit，这取决于你的处理器，指针指向了你的值的精确位置。
对于32位系统，你的内存最大可使用4G。对于64系统可以使用更大的内存。但是64位的指针意味着更大的浪费，因为你的指针本身大了。浪费内存不算，更糟糕的是，更大的指针在主内存和缓存器（例如LLC, L1等）之间移动数据的时候，会占用更多的带宽。
Java 使用一个叫内存指针压缩的技术来解决这个问题。它的指针不再表示对象在内存中的精确位置，而是表示偏移量。这意味着32位的指针可以引用40亿个对象，而不是40亿个字节。最终，也就是说堆内存长到32G的物理内存，也可以用32bit的指针表示。
一旦越过那个神奇的30-32G的边界，指针就会切回普通对象的指针，每个对象的指针都变长了，就会使用更多的CPU内存带宽，也就是说你实际上失去了更多的内存。事实上当内存到达40-50GB的时候，有效内存才相当于使用内存对象指针压缩技术时候的32G内存。
即便有足够的内存，也尽量不要超过32G，因为它浪费了内存，降低了CPU的性能，还会让GC应对大内存。

对象的创建过程

类加载检查

虚拟机在解析.class文件时，若遇到一条 new 指令，首先它会去检查常量池中是否有这个类的符号引用，并且检查这个符号引用所代表的类是否已被加载、解析和初始化过。如果没有，那么必须先执行相应的类加载过程。

为新生对象分配内存

对象所需内存的大小在类加载完成后便可完全确定，接下来从堆中划分一块对应大小的内存空间给新的对象。分配堆中内存有两种方式：

指针碰撞
如果 Java 堆中内存绝对规整（说明采用的是“复制算法”或“标记整理法”），空闲内存和已使用内存中间放着一个指针作为分界点指示器，那么分配内存时只需要把指针向空闲内存挪动一段与对象大小一样的距离，这种分配方式称为“指针碰撞”。
空闲列表
如果 Java 堆中内存并不规整，已使用的内存和空闲内存交错（说明采用的是标记-清除法，有碎片），此时没法简单进行指针碰撞， VM 必须维护一个列表，记录其中哪些内存块空闲可用。分配之时从空闲列表中找到一块足够大的内存空间划分给对象实例。这种方式称为“空闲列表”。

初始化

分配完内存后，为对象中的成员变量赋上初始值，设置对象头信息，调用对象的构造函数方法进行初始化。

至此，整个对象的创建过程就完成了。

对象的访问方式

所有对象的存储空间都是在堆中分配的，但是这个对象的引用却是在堆栈中分配的。也就是说在建立一个对象时两个地方都分配内存，在堆中分配的内存实际建立这个对象，而在堆栈中分配的内存只是一个指向这个堆对象的指针（引用）而已。那么根据引用存放的地址类型的不同，对象有不同的访问方式。

句柄访问方式

堆中需要有一块叫做“句柄池”的内存空间，句柄中包含了对象实例数据与类型数据各自的具体地址信息。

引用类型的变量存放的是该对象的句柄地址（reference）。访问对象时，首先需要通过引用类型的变量找到该对象的句柄，然后根据句柄中对象的地址找到对象。

在Java堆中划分出一块内存作为句柄池，虚拟机中reference据中存储的是对象的句柄地址，程序通过访问栈中的reference数据获取的句柄地址，句柄中的每条记录包含对象实例数据的指针和对象类型数据的指针，再通过句柄定位和访问对象。

优点:

·reference存储稳定的句柄地址，对象移动(垃圾收集)时只会改变句柄中实例数据指针，reference不需要做改变，

缺点:

增加了指针定位的开销

场景:

适合频繁移动对象地址

直接指针访问方式

引用类型的变量直接存放对象的地址，从而不需要句柄池，通过引用能够直接访问对象。但对象所在的内存空间需要额外的策略存储对象所属的类信息的地址。

栈中reference数据存储的是对象地址，放在对象头中，程序通过方问栈中reference数据获取对象的地址，直接访问对象实例数据，再通过对象类型数据的指针访问对象类型数据。
优点:
速度快，节省了一次指针定位的开销。
缺点:
·对象移动时需要重新定位。
场景:
适合频繁访问对象。

需要说明的是，HotSpot 采用第二种方式，即直接指针方式来访问对象，只需要一次寻址操作，所以在性能上比句柄访问方式快一倍。但像上面所说，它需要额外的策略来存储对象在方法区中类信息的地址。

内存分配与回收策略

对象的内存分配，就是在堆上分配（也可能经过 JIT 编译后被拆散为标量类型并间接在栈上分配），对象主要分配在新生代的 Eden 区上，少数情况下可能直接分配在老年代，分配规则不固定，取决于当前使用的垃圾收集器组合以及相关的参数配置。

以下列举几条最普遍的内存分配规则，供大家学习。

对象优先在 Eden 分配

大多数情况下，对象在新生代 Eden 区中分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

👇Minor GC vs Major GC/Full GC：

Minor GC：回收新生代（包括 Eden 和 Survivor 区域），因为 Java 对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。
Major GC / Full GC：回收老年代，出现了 Major GC，经常会伴随至少一次的 Minor GC，但这并非绝对。Major GC 的速度一般会比 Minor GC 慢 10 倍以上。

在 JVM 规范中，Major GC 和 Full GC 都没有一个正式的定义，所以有人也简单地认为 Major GC 清理老年代，而 Full GC 清理整个内存堆。

大对象直接进入老年代

大对象是指需要大量连续内存空间的 Java 对象，如很长的字符串或数据。

一个大对象能够存入 Eden 区的概率比较小，发生分配担保的概率比较大，而分配担保需要涉及大量的复制，就会造成效率低下。

虚拟机提供了一个 -XX:PretenureSizeThreshold 参数，令大于这个设置值的对象直接在老年代分配，这样做的目的是避免在 Eden 区及两个 Survivor 区之间发生大量的内存复制。（还记得吗，新生代采用复制算法回收垃圾）

长期存活的对象将进入老年代

JVM 给每个对象定义了一个对象年龄计数器。当新生代发生一次 Minor GC 后，存活下来的对象年龄 +1，当年龄超过一定值时，就将超过该值的所有对象转移到老年代中去。

使用 -XXMaxTenuringThreshold 设置新生代的最大年龄，只要超过该参数的新生代对象都会被转移到老年代中去。

动态对象年龄判定

如果当前新生代的 Survivor 中，相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄 >= 该年龄的对象就可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。

空间分配担保

JDK 6 Update 24 之前的规则是这样的：

在发生 Minor GC 之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，Minor GC 可以确保是安全的；如果不成立，则虚拟机会查看 HandlePromotionFailure 值是否设置为允许担保失败，如果是，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次 Minor GC，尽管这次 Minor GC 是有风险的；如果小于，或者 HandlePromotionFailure 设置不允许冒险，那此时也要改为进行一次 Full GC。

JDK 6 Update 24 之后的规则变为：

只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行 Full GC。

通过清除老年代中的废弃数据来扩大老年代空闲空间，以便给新生代作担保。

这个过程就是分配担保。

👇 总结一下有哪些情况可能会触发 JVM 进行 Full GC。

System.gc() 方法的调用此方法的调用是建议 JVM 进行 Full GC，注意这只是建议而非一定，但在很多情况下它会触发 Full GC，从而增加 Full GC 的频率。通常情况下我们只需要让虚拟机自己去管理内存即可，我们可以通过 -XX:+ DisableExplicitGC 来禁止调用 System.gc()。
老年代空间不足老年代空间不足会触发 Full GC 操作，若进行该操作后空间依然不足，则会抛出如下错误：java.lang.OutOfMemoryError: Java heap space
永久代空间不足JVM 规范中运行时数据区域中的方法区，在 HotSpot 虚拟机中也称为永久代（Permanet Generation），存放一些类信息、常量、静态变量等数据，当系统要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，会触发 Full GC。如果经过 Full GC 仍然回收不了，那么 JVM 会抛出如下错误信息：java.lang.OutOfMemoryError: PermGen space
CMS GC 时出现 promotion failed 和 concurrent mode failurepromotion failed，就是上文所说的担保失败，而 concurrent mode failure 是在执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足造成的。
统计得到的 Minor GC 晋升到旧生代的平均大小大于老年代的剩余空间。

JVM运行时数据区之栈区

前几篇文章我们分别详细描述了JVM整体的内存结构、JVM对象内存是如何布局的以及内存分配的详细过程。

但是对JVM内存结构各个模块没有深入的分析，为了熟悉JVM底层结构，接下来将把JVM运行时数据区的各个模块逐一分析，体系化的理解JVM的各个模块。

阅读前思考

说一下 JVM 运行时数据区吧，都有哪些区？分别是干什么的？
Java 8 的内存分代改进
举例栈溢出的情况？
调整栈大小，就能保存不出现溢出吗？
分配的栈内存越大越好吗？
垃圾回收是否会涉及到虚拟机栈？
方法中定义的局部变量是否线程安全？

运行时数据区

内存是非常重要的系统资源，是硬盘和 CPU 的中间仓库及桥梁，承载着操作系统和应用程序的实时运行。JVM 内存布局规定了 Java 在运行过程中内存申请、分配、管理的策略，保证了 JVM 的高效稳定运行。不同的 JVM 对于内存的划分方式和管理机制存在着部分差异。

下图是 JVM 整体架构，中间部分就是 Java 虚拟机定义的各种运行时数据区域。

Java 虚拟机定义了若干种程序运行期间会使用到的运行时数据区，其中有一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与线程一一对应的，这些与线程一一对应的数据区域会随着线程开始和结束而创建和销毁。

线程私有：程序计数器、栈、本地栈
线程共享：堆、堆外内存（永久代或元空间、代码缓存）

虚拟机栈

概述

Java 虚拟机栈(Java Virtual Machine Stacks)，早期也叫 Java 栈。每个线程在创建的时候都会创建一个虚拟机栈，其内部保存一个个的栈帧(Stack Frame），对应着一次次 Java 方法调用，是线程私有的，生命周期和线程一致。栈中的元素用于支持虚拟机进行方法调用，每个方法从开始调用到执行完成的过程，就是栈帧从入栈到出栈的过程在活动线程中，只有位于栈顶的帧才是有效的，称为当前栈帧正在执行的方法称为当前方法栈帧是方法运行的基本结构

在执行引擎运行时，所有指令都只能针对当前栈帧进行操作 StackOverflowError表示请求的栈溢出，导致内存耗尽，通常出现在递归方法中 JVM能够横扫千军，虚拟机栈就是它的心腹大将，当前方法的栈帧，都是正在战斗的战场，其中的操作栈是参与战斗的士兵操作栈的压栈与出栈

虚拟机栈通过压/出栈的方式，对每个方法对应的活动栈帧进行运算处理，方法正常执行结束，肯定会跳转到另一个栈帧上在执行的过程中，如果出现异常，会进行异常回溯，返回地址通过异常处理表确定栈帧在整个JVM体系中的地位颇高,包括局部变量表、操作栈、动态连接、方法返回地址等。

作用：主管 Java 程序的运行，它保存方法的局部变量、部分结果，并参与方法的调用和返回。

特点：

栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器
JVM 直接对虚拟机栈的操作只有两个：每个方法执行，伴随着入栈（进栈/压栈），方法执行结束出栈
栈不存在垃圾回收问题

栈中可能出现的异常：

Java 虚拟机规范允许 Java虚拟机栈的大小是动态的或者是固定不变的

如果采用固定大小的 Java 虚拟机栈，那每个线程的 Java 虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过 Java 虚拟机栈允许的最大容量，Java 虚拟机将会抛出一个 StackOverflowError 异常
如果 Java 虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那 Java 虚拟机将会抛出一个OutOfMemoryError异常

可以通过参数-Xss来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度。

官方提供的参考工具，可查一些参数和操作：https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BGBCIEFC

2.2 栈的存储单位

栈中存储什么？

每个线程都有自己的栈，栈中的数据都是以栈帧（Stack Frame）的格式存在
在这个线程上正在执行的每个方法都各自有对应的一个栈帧
栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息

2.3 栈运行原理

JVM 直接对 Java 栈的操作只有两个，对栈帧的压栈和出栈，遵循“先进后出/后进先出”原则
在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为当前栈帧（Current Frame），与当前栈帧对应的方法就是当前方法（Current Method），定义这个方法的类就是当前类（Current Class）
执行引擎运行的所有字节码指令只针对当前栈帧进行操作
如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，称为新的当前栈帧
不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧中引用另外一个线程的栈帧
如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧
Java 方法有两种返回函数的方式，一种是正常的函数返回，使用 return 指令，另一种是抛出异常，不管用哪种方式，都会导致栈帧被弹出

IDEA 在 debug 时候，可以在 debug 窗口看到 Frames 中各种方法的压栈和出栈情况

栈帧的内部结构

每个栈帧（Stack Frame）中存储着：

局部变量表（Local Variables）
操作数栈（Operand Stack）(或称为表达式栈)
动态链接（Dynamic Linking）：指向运行时常量池的方法引用
方法返回地址（Return Address）：方法正常退出或异常退出的地址
一些附加信息

继续深抛栈帧中的五部分~~

2.4.1. 局部变量表

局部变量表也被称为局部变量数组或者本地变量表
是一组变量值存储空间，主要用于存储方法参数和定义在方法体内的局部变量，包括编译器可知的各种 Java 虚拟机基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它并不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此相关的位置）和 returnAddress 类型（指向了一条字节码指令的地址，已被异常表取代）
由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
局部变量表所需要的容量大小是编译期确定下来的，并保存在方法的 Code 属性的 maximum local variables 数据项中。在方法运行期间是不会改变局部变量表的大小的
方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。
参数值的存放总是在局部变量数组的 index0 开始，到数组长度 -1 的索引结束

槽 Slot

局部变量表最基本的存储单元是 Slot（变量槽）
在局部变量表中，32 位以内的类型只占用一个 Slot(包括returnAddress类型)，64 位的类型（long和double）占用两个连续的 Slot
- byte、short、char 在存储前被转换为int，boolean也被转换为int，0 表示 false，非 0 表示 true
- long 和 double 则占据两个 Slot
JVM 会为局部变量表中的每一个 Slot 都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值，索引值的范围从 0 开始到局部变量表最大的 Slot 数量
当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个 Slot 上
如果需要访问局部变量表中一个 64bit 的局部变量值时，只需要使用前一个索引即可。（比如：访问 long 或 double 类型变量，不允许采用任何方式单独访问其中的某一个 Slot）
如果当前帧是由构造方法或实例方法创建的，那么该对象引用 this 将会存放在 index 为 0 的 Slot 处，其余的参数按照参数表顺序继续排列（这里就引出一个问题：静态方法中为什么不可以引用 this，就是因为this 变量不存在于当前方法的局部变量表中）
栈帧中的局部变量表中的槽位是可以重用的，如果一个局部变量过了其作用域，那么在其作用域之后申明的新的局部变量就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。（下图中，this、a、b、c 理论上应该有 4 个变量，c 复用了 b 的槽）

在栈帧中，与性能调优关系最为密切的就是局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递
局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收

操作数栈

每个独立的栈帧中除了包含局部变量表之外，还包含一个后进先出（Last-In-First-Out）的操作数栈，也可以称为表达式栈（Expression Stack）
操作数栈，在方法执行过程中，根据字节码指令，往操作数栈中写入数据或提取数据，即入栈（push）、出栈（pop）
某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。比如，执行复制、交换、求和等操作

概述

操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间
操作数栈就是 JVM 执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，此时这个方法的操作数栈是空的
每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的 Code 属性的 max_stack 数据项中
栈中的任何一个元素都可以是任意的 Java 数据类型
- 32bit 的类型占用一个栈单位深度
- 64bit 的类型占用两个栈单位深度
操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一次数据访问
如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新 PC 寄存器中下一条需要执行的字节码指令
操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证
另外，我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈

栈顶缓存（Top-of-stack-Cashing）

HotSpot 的执行引擎采用的并非是基于寄存器的架构，但这并不代表 HotSpot VM 的实现并没有间接利用到寄存器资源。寄存器是物理 CPU 中的组成部分之一，它同时也是 CPU 中非常重要的高速存储资源。一般来说，寄存器的读/写速度非常迅速，甚至可以比内存的读/写速度快上几十倍不止，不过寄存器资源却非常有限，不同平台下的CPU 寄存器数量是不同和不规律的。寄存器主要用于缓存本地机器指令、数值和下一条需要被执行的指令地址等数据。

基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派（instruction dispatch）次数和内存读/写次数。由于操作数是存储在内存中的，因此频繁的执行内存读/写操作必然会影响执行速度。为了解决这个问题，HotSpot JVM 设计者们提出了栈顶缓存技术，将栈顶元素全部缓存在物理 CPU 的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率

动态链接（指向运行时常量池的方法引用）

每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接(Dynamic Linking)。
在 Java 源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在 Class 文件的常量池中。比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用

JVM 是如何执行方法调用的

方法调用不同于方法执行，方法调用阶段的唯一任务就是确定被调用方法的版本（即调用哪一个方法），暂时还不涉及方法内部的具体运行过程。Class 文件的编译过程中不包括传统编译器中的连接步骤，一切方法调用在 Class文件里面存储的都是符号引用，而不是方法在实际运行时内存布局中的入口地址（直接引用）。也就是需要在类加载阶段，甚至到运行期才能确定目标方法的直接引用。

【这一块内容，除了方法调用，还包括解析、分派（静态分派、动态分派、单分派与多分派），这里先不介绍，后续再挖】

在 JVM 中，将符号引用转换为调用方法的直接引用与方法的绑定机制有关

静态链接：当一个字节码文件被装载进 JVM 内部时，如果被调用的目标方法在编译期可知，且运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接
动态链接：如果被调用的方法在编译期无法被确定下来，也就是说，只能在程序运行期将调用方法的符号引用转换为直接引用，由于这种引用转换过程具备动态性，因此也就被称之为动态链接

对应的方法的绑定机制为：早期绑定（Early Binding）和晚期绑定（Late Binding）。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程，这仅仅发生一次。

早期绑定：早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。
晚期绑定：如果被调用的方法在编译器无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式就被称为晚期绑定。

虚方法和非虚方法

如果方法在编译器就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法，比如静态方法、私有方法、final 方法、实例构造器、父类方法都是非虚方法
其他方法称为虚方法

虚方法表

在面向对象编程中，会频繁的使用到动态分派，如果每次动态分派都要重新在类的方法元数据中搜索合适的目标有可能会影响到执行效率。为了提高性能，JVM 采用在类的方法区建立一个虚方法表（virtual method table），使用索引表来代替查找。非虚方法不会出现在表中。

每个类中都有一个虚方法表，表中存放着各个方法的实际入口。

虚方法表会在类加载的连接阶段被创建并开始初始化，类的变量初始值准备完成之后，JVM 会把该类的方法表也初始化完毕。

2.4.4. 方法返回地址（return address）

用来存放调用该方法的 PC 寄存器的值。

一个方法的结束，有两种方式

正常执行完成
出现未处理的异常，非正常退出

无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，调用者的 PC 计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过异常表来确定的，栈帧中一般不会保存这部分信息。

当一个方法开始执行后，只有两种方式可以退出这个方法：

执行引擎遇到任意一个方法返回的字节码指令，会有返回值传递给上层的方法调用者，简称正常完成出口

一个方法的正常调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定

在字节码指令中，返回指令包含 ireturn(当返回值是 boolean、byte、char、short 和 int 类型时使用)、lreturn、freturn、dreturn 以及 areturn，另外还有一个 return 指令供声明为 void 的方法、实例初始化方法、类和接口的初始化方法使用。
在方法执行的过程中遇到了异常，并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出。简称异常完成出口

方法执行过程中抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码。

本质上，方法的退出就是当前栈帧出栈的过程。此时，需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等，让调用者方法继续执行下去。

正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值

附加信息

栈帧中还允许携带与 Java 虚拟机实现相关的一些附加信息。例如，对程序调试提供支持的信息，但这些信息取决于具体的虚拟机实现。

三、本地方法栈

3.1 本地方法接口

简单的讲，一个 Native Method 就是一个 Java 调用非 Java 代码的接口。我们知道的 Unsafe 类就有很多本地方法。

为什么要使用本地方法（Native Method）?

Java 使用起来非常方便，然而有些层次的任务用 Java 实现起来也不容易，或者我们对程序的效率很在意时，问题就来了

与 Java 环境外交互：有时 Java 应用需要与 Java 外面的环境交互，这就是本地方法存在的原因。
与操作系统交互：JVM 支持 Java 语言本身和运行时库，但是有时仍需要依赖一些底层系统的支持。通过本地方法，我们可以实现用 Java 与实现了 jre 的底层系统交互， JVM 的一些部分就是 C 语言写的。
Sun's Java：Sun的解释器就是C实现的，这使得它能像一些普通的C一样与外部交互。jre大部分都是用 Java 实现的，它也通过一些本地方法与外界交互。比如，类 java.lang.Thread 的 setPriority() 的方法是用Java 实现的，但它实现调用的是该类的本地方法 setPrioruty()，该方法是C实现的，并被植入 JVM 内部。

本地方法栈（Native Method Stack）

Java 虚拟机栈用于管理 Java 方法的调用，而本地方法栈用于管理本地方法的调用
本地方法栈也是线程私有的
允许线程固定或者可动态扩展的内存大小
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java 虚拟机将会抛出一个 StackOverflowError 异常
- 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么 Java虚拟机将会抛出一个OutofMemoryError异常
本地方法是使用 C 语言实现的
它的具体做法是 Mative Method Stack 中登记 native 方法，在 Execution Engine 执行时加载本地方法库当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。
本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区，它甚至可以直接使用本地处理器中的寄存器，直接从本地内存的堆中分配任意数量的内存
并不是所有 JVM 都支持本地方法。因为 Java 虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果 JVM 产品不打算支持 native 方法，也可以无需实现本地方法栈
在 Hotspot JVM 中，直接将本地方栈和虚拟机栈合二为一

栈是运行时的单位，而堆是存储的单位。

栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。堆解决的是数据存储的问题，即数据怎么放、放在哪。

JVM运行时数据区之堆内存

阅读前思考

说一下 JVM 运行时数据区吧，都有哪些区？分别是干什么的？
Java 8 的内存分代改进
举例栈溢出的情况？
调整栈大小，就能保存不出现溢出吗？
分配的栈内存越大越好吗？
垃圾回收是否会涉及到虚拟机栈？
方法中定义的局部变量是否线程安全？

运行时数据区

下图是 JVM 整体架构，中间部分就是 Java 虚拟机定义的各种运行时数据区域。

线程私有：程序计数器、栈、本地栈
线程共享：堆、堆外内存（永久代或元空间、代码缓存）

虚拟机栈

概述

作用：主管 Java 程序的运行，它保存方法的局部变量、部分结果，并参与方法的调用和返回。

特点：

栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器
JVM 直接对虚拟机栈的操作只有两个：每个方法执行，伴随着入栈（进栈/压栈），方法执行结束出栈
栈不存在垃圾回收问题

栈中可能出现的异常：

Java 虚拟机规范允许 Java虚拟机栈的大小是动态的或者是固定不变的

如果采用固定大小的 Java 虚拟机栈，那每个线程的 Java 虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过 Java 虚拟机栈允许的最大容量，Java 虚拟机将会抛出一个 StackOverflowError 异常
如果 Java 虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那 Java 虚拟机将会抛出一个OutOfMemoryError异常

可以通过参数-Xss来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度。

官方提供的参考工具，可查一些参数和操作：https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BGBCIEFC

2.2 栈的存储单位

栈中存储什么？

每个线程都有自己的栈，栈中的数据都是以栈帧（Stack Frame）的格式存在
在这个线程上正在执行的每个方法都各自有对应的一个栈帧
栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息

2.3 栈运行原理

JVM 直接对 Java 栈的操作只有两个，对栈帧的压栈和出栈，遵循“先进后出/后进先出”原则
在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为当前栈帧（Current Frame），与当前栈帧对应的方法就是当前方法（Current Method），定义这个方法的类就是当前类（Current Class）
执行引擎运行的所有字节码指令只针对当前栈帧进行操作
如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，称为新的当前栈帧
不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧中引用另外一个线程的栈帧
如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧
Java 方法有两种返回函数的方式，一种是正常的函数返回，使用 return 指令，另一种是抛出异常，不管用哪种方式，都会导致栈帧被弹出

IDEA 在 debug 时候，可以在 debug 窗口看到 Frames 中各种方法的压栈和出栈情况

栈帧的内部结构

每个栈帧（Stack Frame）中存储着：

局部变量表（Local Variables）
操作数栈（Operand Stack）(或称为表达式栈)
动态链接（Dynamic Linking）：指向运行时常量池的方法引用
方法返回地址（Return Address）：方法正常退出或异常退出的地址
一些附加信息

继续深抛栈帧中的五部分~~

2.4.1. 局部变量表

局部变量表也被称为局部变量数组或者本地变量表
是一组变量值存储空间，主要用于存储方法参数和定义在方法体内的局部变量，包括编译器可知的各种 Java 虚拟机基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它并不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此相关的位置）和 returnAddress 类型（指向了一条字节码指令的地址，已被异常表取代）
由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
局部变量表所需要的容量大小是编译期确定下来的，并保存在方法的 Code 属性的 maximum local variables 数据项中。在方法运行期间是不会改变局部变量表的大小的
方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。
参数值的存放总是在局部变量数组的 index0 开始，到数组长度 -1 的索引结束

槽 Slot

局部变量表最基本的存储单元是 Slot（变量槽）
在局部变量表中，32 位以内的类型只占用一个 Slot(包括returnAddress类型)，64 位的类型（long和double）占用两个连续的 Slot
- byte、short、char 在存储前被转换为int，boolean也被转换为int，0 表示 false，非 0 表示 true
- long 和 double 则占据两个 Slot
JVM 会为局部变量表中的每一个 Slot 都分配一个访问索引，通过这个索引即可成功访问到局部变量表中指定的局部变量值，索引值的范围从 0 开始到局部变量表最大的 Slot 数量
当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个 Slot 上
如果需要访问局部变量表中一个 64bit 的局部变量值时，只需要使用前一个索引即可。（比如：访问 long 或 double 类型变量，不允许采用任何方式单独访问其中的某一个 Slot）
如果当前帧是由构造方法或实例方法创建的，那么该对象引用 this 将会存放在 index 为 0 的 Slot 处，其余的参数按照参数表顺序继续排列（这里就引出一个问题：静态方法中为什么不可以引用 this，就是因为this 变量不存在于当前方法的局部变量表中）
栈帧中的局部变量表中的槽位是可以重用的，如果一个局部变量过了其作用域，那么在其作用域之后申明的新的局部变量就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。（下图中，this、a、b、c 理论上应该有 4 个变量，c 复用了 b 的槽）

在栈帧中，与性能调优关系最为密切的就是局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递
局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收

操作数栈

每个独立的栈帧中除了包含局部变量表之外，还包含一个后进先出（Last-In-First-Out）的操作数栈，也可以称为表达式栈（Expression Stack）
操作数栈，在方法执行过程中，根据字节码指令，往操作数栈中写入数据或提取数据，即入栈（push）、出栈（pop）
某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。比如，执行复制、交换、求和等操作

概述

操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间
操作数栈就是 JVM 执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，此时这个方法的操作数栈是空的
每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的 Code 属性的 max_stack 数据项中
栈中的任何一个元素都可以是任意的 Java 数据类型
- 32bit 的类型占用一个栈单位深度
- 64bit 的类型占用两个栈单位深度
操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一次数据访问
如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新 PC 寄存器中下一条需要执行的字节码指令
操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证
另外，我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈

栈顶缓存（Top-of-stack-Cashing）

动态链接（指向运行时常量池的方法引用）

每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接(Dynamic Linking)。
在 Java 源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在 Class 文件的常量池中。比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用

JVM 是如何执行方法调用的

【这一块内容，除了方法调用，还包括解析、分派（静态分派、动态分派、单分派与多分派），这里先不介绍，后续再挖】

在 JVM 中，将符号引用转换为调用方法的直接引用与方法的绑定机制有关

静态链接：当一个字节码文件被装载进 JVM 内部时，如果被调用的目标方法在编译期可知，且运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接
动态链接：如果被调用的方法在编译期无法被确定下来，也就是说，只能在程序运行期将调用方法的符号引用转换为直接引用，由于这种引用转换过程具备动态性，因此也就被称之为动态链接

早期绑定：早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。
晚期绑定：如果被调用的方法在编译器无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式就被称为晚期绑定。

虚方法和非虚方法

如果方法在编译器就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法，比如静态方法、私有方法、final 方法、实例构造器、父类方法都是非虚方法
其他方法称为虚方法

虚方法表

每个类中都有一个虚方法表，表中存放着各个方法的实际入口。

虚方法表会在类加载的连接阶段被创建并开始初始化，类的变量初始值准备完成之后，JVM 会把该类的方法表也初始化完毕。

2.4.4. 方法返回地址（return address）

用来存放调用该方法的 PC 寄存器的值。

一个方法的结束，有两种方式

正常执行完成
出现未处理的异常，非正常退出

当一个方法开始执行后，只有两种方式可以退出这个方法：

执行引擎遇到任意一个方法返回的字节码指令，会有返回值传递给上层的方法调用者，简称正常完成出口

一个方法的正常调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定

在字节码指令中，返回指令包含 ireturn(当返回值是 boolean、byte、char、short 和 int 类型时使用)、lreturn、freturn、dreturn 以及 areturn，另外还有一个 return 指令供声明为 void 的方法、实例初始化方法、类和接口的初始化方法使用。
在方法执行的过程中遇到了异常，并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出。简称异常完成出口

方法执行过程中抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码。

正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给他的上层调用者产生任何的返回值

附加信息

栈帧中还允许携带与 Java 虚拟机实现相关的一些附加信息。例如，对程序调试提供支持的信息，但这些信息取决于具体的虚拟机实现。

三、本地方法栈

3.1 本地方法接口

简单的讲，一个 Native Method 就是一个 Java 调用非 Java 代码的接口。我们知道的 Unsafe 类就有很多本地方法。

为什么要使用本地方法（Native Method）?

Java 使用起来非常方便，然而有些层次的任务用 Java 实现起来也不容易，或者我们对程序的效率很在意时，问题就来了

与 Java 环境外交互：有时 Java 应用需要与 Java 外面的环境交互，这就是本地方法存在的原因。
与操作系统交互：JVM 支持 Java 语言本身和运行时库，但是有时仍需要依赖一些底层系统的支持。通过本地方法，我们可以实现用 Java 与实现了 jre 的底层系统交互， JVM 的一些部分就是 C 语言写的。
Sun's Java：Sun的解释器就是C实现的，这使得它能像一些普通的C一样与外部交互。jre大部分都是用 Java 实现的，它也通过一些本地方法与外界交互。比如，类 java.lang.Thread 的 setPriority() 的方法是用Java 实现的，但它实现调用的是该类的本地方法 setPrioruty()，该方法是C实现的，并被植入 JVM 内部。

本地方法栈（Native Method Stack）

Java 虚拟机栈用于管理 Java 方法的调用，而本地方法栈用于管理本地方法的调用
本地方法栈也是线程私有的
允许线程固定或者可动态扩展的内存大小
- 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java 虚拟机将会抛出一个 StackOverflowError 异常
- 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么 Java虚拟机将会抛出一个OutofMemoryError异常
本地方法是使用 C 语言实现的
它的具体做法是 Mative Method Stack 中登记 native 方法，在 Execution Engine 执行时加载本地方法库当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。
本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区，它甚至可以直接使用本地处理器中的寄存器，直接从本地内存的堆中分配任意数量的内存
并不是所有 JVM 都支持本地方法。因为 Java 虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果 JVM 产品不打算支持 native 方法，也可以无需实现本地方法栈
在 Hotspot JVM 中，直接将本地方栈和虚拟机栈合二为一

栈是运行时的单位，而堆是存储的单位。

栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。堆解决的是数据存储的问题，即数据怎么放、放在哪。

JVM运行时数据区之方法区

阅读前思考

说一下 JVM 运行时数据区吧，都有哪些区？分别是干什么的？
Java 8 的内存分代改进
举例栈溢出的情况？
调整栈大小，就能保存不出现溢出吗？
分配的栈内存越大越好吗？
垃圾回收是否会涉及到虚拟机栈？
方法中定义的局部变量是否线程安全？

运行时数据区

下图是 JVM 整体架构，中间部分就是 Java 虚拟机定义的各种运行时数据区域。

线程私有：程序计数器、栈、本地栈
线程共享：堆、堆外内存（永久代或元空间、代码缓存）

五、方法区

方法区（Method Area）与 Java 堆一样，是所有线程共享的内存区域。
虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫 Non-Heap（非堆），目的应该是与 Java 堆区分开。
运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本/字段/方法/接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将类在加载后进入方法区的运行时常量池中存放。运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的是 String.intern()方法。受方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常。
方法区的大小和堆空间一样，可以选择固定大小也可选择可扩展，方法区的大小决定了系统可以放多少个类，如果系统类太多，导致方法区溢出，虚拟机同样会抛出内存溢出错误
JVM 关闭后方法区即被释放

解惑

你是否也有看不同的参考资料，有的内存结构图有方法区，有的又是永久代，元数据区，一脸懵逼的时候？

方法区（method area）只是 JVM 规范中定义的一个概念，用于存储类信息、常量池、静态变量、JIT编译后的代码等数据，并没有规定如何去实现它，不同的厂商有不同的实现。而永久代（PermGen）是 Hotspot 虚拟机特有的概念， Java8 的时候又被元空间取代了，永久代和元空间都可以理解为方法区的落地实现。
永久代物理是堆的一部分，和新生代，老年代地址是连续的（受垃圾回收器管理），而元空间存在于本地内存（我们常说的堆外内存，不受垃圾回收器管理），这样就不受 JVM 限制了，也比较难发生OOM（都会有溢出异常）
Java7 中我们通过-XX:PermSize 和 -xx:MaxPermSize 来设置永久代参数，Java8 之后，随着永久代的取消，这些参数也就随之失效了，改为通过-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 用来设置元空间参数
存储内容不同，元空间存储类的元信息，静态变量和常量池等并入堆中。相当于永久代的数据被分到了堆和元空间中
如果方法区域中的内存不能用于满足分配请求，则 Java 虚拟机抛出 OutOfMemoryError
JVM 规范说方法区在逻辑上是堆的一部分，但目前实际上是与 Java 堆分开的（Non-Heap）

所以对于方法区，Java8 之后的变化：

移除了永久代（PermGen），替换为元空间（Metaspace）；
永久代中的 class metadata 转移到了 native memory（本地内存，而不是虚拟机）；
永久代中的 interned Strings 和 class static variables 转移到了 Java heap；
永久代参数（PermSize MaxPermSize） -> 元空间参数（MetaspaceSize MaxMetaspaceSize）

设置方法区内存的大小

JDK8 及以后：

元数据区大小可以使用参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 指定，替代上述原有的两个参数
默认值依赖于平台。Windows 下，-XX:MetaspaceSize 是 21M，-XX:MaxMetaspacaSize 的值是 -1，即没有限制
与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。如果元数据发生溢出，虚拟机一样会抛出异常 OutOfMemoryError:Metaspace
-XX:MetaspaceSize ：设置初始的元空间大小。对于一个 64 位的服务器端 JVM 来说，其默认的 -XX:MetaspaceSize 的值为20.75MB，这就是初始的高水位线，一旦触及这个水位线，Full GC 将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），然后这个高水位线将会重置，新的高水位线的值取决于 GC 后释放了多少元空间。如果释放的空间不足，那么在不超过 MaxMetaspaceSize时，适当提高该值。如果释放空间过多，则适当降低该值
如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次，通过垃圾回收的日志可观察到 Full GC 多次调用。为了避免频繁 GC，建议将 -XX:MetaspaceSize 设置为一个相对较高的值。

方法区内部结构

方法区用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。

类型信息

对每个加载的类型（类 class、接口 interface、枚举 enum、注解 annotation），JVM 必须在方法区中存储以下类型信息

这个类型的完整有效名称（全名=包名.类名）
这个类型直接父类的完整有效名（对于 interface或是 java.lang.Object，都没有父类）
这个类型的修饰符（public，abstract，final 的某个子集）
这个类型直接接口的一个有序列表

域（Field）信息

JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序
域的相关信息包括：域名称、域类型、域修饰符（public、private、protected、static、final、volatile、transient 的某个子集）

方法（Method）信息

JVM 必须保存所有方法的

方法名称
方法的返回类型
方法参数的数量和类型
方法的修饰符（public，private，protected，static，final，synchronized，native，abstract 的一个子集）
方法的字符码（bytecodes）、操作数栈、局部变量表及大小（abstract 和 native 方法除外）
异常表（abstract 和 native 方法除外）
- 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

栈、堆、方法区的交互关系

运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分，理解运行时常量池的话，我们先来说说字节码文件（Class 文件）中的常量池（常量池表）

常量池

一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表（Constant Pool Table），包含各种字面量和对类型、域和方法的符号引用。

为什么需要常量池？

一个 Java 源文件中的类、接口，编译后产生一个字节码文件。而 Java 中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池，这个字节码包含了指向常量池的引用。在动态链接的时候用到的就是运行时常量池。

如下，我们通过 jclasslib 查看一个只有 Main 方法的简单类，字节码中的 #2 指向的就是 Constant Pool

常量池可以看作是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。

运行时常量池

在加载类和结构到虚拟机后，就会创建对应的运行时常量池
常量池表（Constant Pool Table）是 Class 文件的一部分，用于存储编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中
JVM 为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的
运行时常量池中包含各种不同的常量，包括编译器就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或字段引用。此时不再是常量池中的符号地址了，这里换为真实地址
- 运行时常量池，相对于 Class 文件常量池的另一个重要特征是：动态性，Java 语言并不要求常量一定只有编译期间才能产生，运行期间也可以将新的常量放入池中，String 类的 intern() 方法就是这样的
当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则 JVM 会抛出 OutOfMemoryError 异常。

方法区在 JDK6、7、8中的演进细节

只有 HotSpot 才有永久代的概念

jdk1.6及之前	有永久代，静态变量存放在永久代上
jdk1.7	有永久代，但已经逐步“去永久代”，字符串常量池、静态变量移除，保存在堆中
jdk1.8及之后	取消永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍在堆中

移除永久代原因

http://openjdk.java.net/jeps/122

为永久代设置空间大小是很难确定的。

在某些场景下，如果动态加载类过多，容易产生 Perm 区的 OOM。如果某个实际 Web 工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现 OOM。而元空间和永久代最大的区别在于，元空间不在虚拟机中，而是使用本地内存，所以默认情况下，元空间的大小仅受本地内存限制
对永久代进行调优较困难

5.6 方法区的垃圾回收

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。

先来说说方法区内常量池之中主要存放的两大类常量：字面量和符号引用。字面量比较接近 Java 语言层次的常量概念，如文本字符串、被声明为 final 的常量值等。而符号引用则属于编译原理方面的概念，包括下面三类常量：

类和接口的全限定名
字段的名称和描述符
方法的名称和描述符

HotSpot 虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收

判定一个类型是否属于“不再被使用的类”，需要同时满足三个条件：

该类所有的实例都已经被回收，也就是 Java 堆中不存在该类及其任何派生子类的实例
加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如 OSGi、JSP 的重加载等，否则通常很难达成
该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

Java 虚拟机被允许堆满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，不使用了就必然会回收。是否对类进行回收，HotSpot 虚拟机提供了 -Xnoclassgc 参数进行控制，还可以使用 -verbose:class 以及 -XX:+TraceClassLoading 、-XX:+TraceClassUnLoading 查看类加载和卸载信息。

在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGi 这类频繁自定义 ClassLoader 的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。

JVM运行时数据区之程序计数器

阅读前思考

说一下 JVM 运行时数据区吧，都有哪些区？分别是干什么的？
Java 8 的内存分代改进
举例栈溢出的情况？
调整栈大小，就能保存不出现溢出吗？
分配的栈内存越大越好吗？
垃圾回收是否会涉及到虚拟机栈？
方法中定义的局部变量是否线程安全？

运行时数据区

下图是 JVM 整体架构，中间部分就是 Java 虚拟机定义的各种运行时数据区域。

线程私有：程序计数器、栈、本地栈
线程共享：堆、堆外内存（永久代或元空间、代码缓存）

程序计数器

程序计数寄存器（Program Counter Register），Register 的命名源于 CPU 的寄存器，寄存器存储指令相关的线程信息，CPU 只有把数据装载到寄存器才能够运行。

这里，并非是广义上所指的物理寄存器，叫程序计数器（或PC计数器或指令计数器）会更加贴切，并且也不容易引起一些不必要的误会。JVM 中的 PC 寄存器是对物理 PC 寄存器的一种抽象模拟。

程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器，若当前线程正在执行的是一个本地方法，那么此时程序计数器为Undefined。

作用

字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制。
在多线程情况下，程序计数器记录的是当前线程执行的位置，从而当线程切换回来时，就知道上次线程执行到哪了。

（分析：进入class文件所在目录，执行 javap -v xx.class 反解析（或者通过 IDEA 插件 Jclasslib 直接查看，上图），可以看到当前类对应的Code区（汇编指令）、本地变量表、异常表和代码行偏移量映射表、常量池等信息。）

概述

它是一块很小的内存空间，几乎可以忽略不计。也是运行速度最快的存储区域
在 JVM 规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期一致
任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。如果当前线程正在执行的是 Java 方法，程序计数器记录的是 JVM 字节码指令地址，如果是执行 natice 方法，则是未指定值（undefined）
它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成
字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令
它是唯一一个在 JVM 规范中没有规定任何 OutOfMemoryError 情况的区域

👨‍💻：使用PC寄存器存储字节码指令地址有什么用呢？为什么使用PC寄存器记录当前线程的执行地址呢？

🙋‍♂️：因为CPU需要不停的切换各个线程，这时候切换回来以后，就得知道接着从哪开始继续执行。JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令。

👨‍💻：PC寄存器为什么会被设定为线程私有的？

🙋‍♂️：多线程在一个特定的时间段内只会执行其中某一个线程方法，CPU会不停的做任务切换，这样必然会导致经常中断或恢复。为了能够准确的记录各个线程正在执行的当前字节码指令地址，所以为每个线程都分配了一个PC寄存器，每个线程都独立计算，不会互相影响。

JVM类加载机制

类加载子系统

类加载机制概念

Java 虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的 Java 类型，这就是虚拟机的加载机制。Class 文件由类装载器装载后，在 JVM 中将形成一份描述 Class 结构的元信息对象，通过该元信息对象可以获知 Class 的结构信息：如构造函数，属性和方法等，Java 允许用户借由这个 Class 相关的元信息对象间接调用 Class 对象的功能，这里就是我们经常能见到的 Class 类。

类加载子系统作用

类加载子系统负责从文件系统或者网络中加载 class 文件，class 文件在文件开头有特定的文件标识（0xCAFEBABE）
ClassLoader 只负责 class 文件的加载。至于它是否可以运行，则由 Execution Engine 决定
加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是class文件中常量池部分的内存映射）
Class 对象是存放在堆区的

类加载器 ClassLoader 角色

class file 存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM 当中来根据这个文件实例化出 n 个一模一样的实例
class file 加载到 JVM 中，被称为 DNA 元数据模板，放在方法区
在 .calss 文件 -> JVM -> 最终成为元数据模板，此过程就要一个运输工具（类装载器），扮演一个快递员的角色

类加载过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。(验证、准备和解析又统称为连接，为了支持 Java 语言的运行时绑定，所以解析阶段也可以是在初始化之后进行的。以上顺序都只是说开始的顺序，实际过程中是交叉的混合式进行的，加载过程中可能就已经开始验证了)

1. 加载（Loading）：

通过一个类的全限定名获取定义此类的二进制字节流
将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口

加载 .class 文件的方式

从本地系统中直接加载
通过网络获取，典型场景：Web Applet
从 zip 压缩文件中读取，成为日后 jar、war 格式的基础
运行时计算生成，使用最多的是：动态代理技术
由其他文件生成，比如 JSP 应用
从专有数据库提取 .class 文件，比较少见
从加密文件中获取，典型的防 Class 文件被反编译的保护措施

JVM只认识class文件，它并不管何种语言生成了class文件，只要class文件符合JVM的规范就能运行。

因此目前已经有Scala、JRuby、Jython等语言能够在JVM上运行。它们有各自的语法规则，不过它们的编译器都能将各自的源码编译成符合JVM规范的class文件，从而能够借助JVM运行它们。

Class文件是JVM的输入, Java虚拟机规范中定义了Class文件的结构。Class文件是JVM实现平台无关、技术无关的基础。

2. 连接（Linking）

验证（Verify）

目的在于确保 Class 文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全
主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证

class文件包含Java程序执行的字节码，数据严格按照格式紧凑排列在class文件中的二进制流，中间无任何分隔符。文件开头有一个0xcafebabe(16进制)特殊的一个标志。

以文件格式为例下图展示为16进制

准备（Prepare）

为类变量分配内存并且设置该类变量的默认初始值，即零值

数据类型零值
int 0
long 0L
short (short)0
char '\u0000'
byte (byte)0
boolean false
float 0.0f
double 0.0d
reference null
这里不包含用 final 修饰的 static，因为 final 在编译的时候就会分配了，准备阶段会显示初始化

数据类型	零值
int	0
long	0L
short	(short)0
char	'\u0000'
byte	(byte)0
boolean	false
float	0.0f
double	0.0d
reference	null

这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到 Java 堆中

private static int i = 1;  //变量i在准备阶只会被赋值为0，初始化时才会被赋值为1
private final static int j = 2;  //这里被final修饰的变量j，直接成为常量，编译时就会被分配为2

解析（Resolve）

将常量池内的符号引用转换为直接引用的过程
事实上，解析操作往往会伴随着 JVM 在执行完初始化之后再执行
符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《Java虚拟机规范》的 Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等

3. 初始化（Initialization）

初始化阶段就是执行类构造器方法 <clinit>() 的过程
此方法不需要定义，是 javac 编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来
构造器方法中指令按语句在源文件中出现的顺序执行
<clinit>() 不同于类的构造器（构造器是虚拟机视角下的 <init>()）
若该类具有父类，JVM 会保证子类的 <clinit>() 执行前，父类的 <clinit>() 已经执行完毕
虚拟机必须保证一个类的 <clinit>() 方法在多线程下被同步加锁

public class ClassInitTest{
  private static int num1 = 30;
  static{
    num1 = 10;
    num2 = 10;     //num2写在定义变量之前，为什么不会报错呢？？
    System.out.println(num2);   //這裡直接打印可以吗？ 报错，非法的前向引用，可以赋值，但不可调用
  }
  private static int num2 = 20;  //num2在准备阶段就被设置了默认初始值0，初始化阶段又将10改为20
  public static void main(String[] args){
    System.out.println(num1);  //10
    System.out.println(num2);   //20
  }
}

类的主动使用和被动使用

Java 程序对类的使用方式分为：主动使用和被动使用。虚拟机规范规定有且只有 5 种情况必须立即对类进行“初始化”，即类的主动使用。

创建类的实例、访问某个类或接口的静态变量，或者对该静态变量赋值、调用类的静态方法（即遇到 new、getstatic、putstatic、invokestatic 这四条字节码指令时）
反射
初始化一个类的子类
Java 虚拟机启动时被标明为启动类的类
JDK7 开始提供的动态语言支持：java.lang.invoke.MethodHandle 实例的解析结果，REF_getStatic、REF_putStatic、REF_invokeStatic 句柄对应的类没有初始化，则初始化

除以上五种情况，其他使用 Java 类的方式被看作是对类的被动使用，都不会导致类的初始化。

eg:

public class NotInitialization {
    public static void main(String[] args) { 
        //只输出SupperClass int 123,不会输出SubClass init
        //对于静态字段，只有直接定义这个字段的类才会被初始化
        System.out.println(SubClass.value); 
    }
}

class SuperClass {
    static {
        System.out.println("SupperClass init");
    }
    public static int value = 123;
}

class SubClass extends SuperClass {
    static {
        System.out.println("SubClass init");
    }
}

类加载器

JVM 支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）
从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是 Java 虚拟机规范却没有这么定义，而是将所有派生于抽象类 ClassLoader 的类加载器都划分为自定义类加载器

启动类加载器（引导类加载器，Bootstrap ClassLoader）

这个类加载使用 C/C++ 语言实现，嵌套在 JVM 内部
它用来加载 Java 的核心库（JAVA_HOME/jre/lib/rt.jar、resource.jar或sun.boot.class.path路径下的内容），用于提供 JVM 自身需要的类
并不继承自 java.lang.ClassLoader，没有父加载器
加载扩展类和应用程序类加载器，并指定为他们的父类加载器
出于安全考虑，Bootstrap 启动类加载器只加载名为 java、Javax、sun 等开头的类

扩展类加载器（Extension ClassLoader）

Java 语言编写，由 sun.misc.Launcher$ExtClassLoader 实现
派生于 ClassLoader
父类加载器为启动类加载器
从 java.ext.dirs 系统属性所指定的目录中加载类库，或从 JDK 的安装目录的 jre/lib/ext 子目录（扩展目录）下加载类库。如果用户创建的 JAR 放在此目录下，也会自动由扩展类加载器加载

应用程序类加载器（也叫系统类加载器，AppClassLoader）

Java 语言编写，由 sun.misc.Lanucher$AppClassLoader 实现
派生于 ClassLoader
父类加载器为扩展类加载器
它负责加载环境变量 classpath 或系统属性 java.class.path 指定路径下的类库
该类加载是程序中默认的类加载器，一般来说，Java 应用的类都是由它来完成加载的
通过 ClassLoader#getSystemClassLoader() 方法可以获取到该类加载器

public class ClassLoaderTest {
    public static void main(String[] args) {
        //获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);  //sun.misc.Launcher$AppClassLoader@135fbaa4

        //获取其上层：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);  //sun.misc.Launcher$ExtClassLoader@2503dbd3

        //再获取其上层：获取不到引导类加载器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader);     //null

        //对于用户自定义类来说，默认使用系统类加载器进行加载，输出和systemClassLoader一样
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(classLoader);  //sun.misc.Launcher$AppClassLoader@135fbaa4

        //String 类使用引导类加载器进行加载。Java的核心类库都使用引导类加载器进行加载，所以也获取不到
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1);  //null

        //获取BootstrapClassLoader可以加载的api的路径
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL url : urls) {
            System.out.println(url.toExternalForm());
        }
    }
}

用户自定义类加载器

在 Java 的日常应用程序开发中，类的加载几乎是由 3 种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式

为什么要自定义类加载器？

隔离加载类
修改类加载的方式
扩展加载源（可以从数据库、云端等指定来源加载类）
防止源码泄露（Java 代码容易被反编译，如果加密后，自定义加载器加载类的时候就可以先解密，再加载）

用户自定义加载器实现步骤

开发人员可以通过继承抽象类 java.lang.ClassLoader 类的方式，实现自己的类加载器，以满足一些特殊的需求
在 JDK1.2 之前，在自定义类加载器时，总会去继承 ClassLoader 类并重写 loadClass() 方法，从而实现自定义的类加载类，但是 JDK1.2 之后已经不建议用户去覆盖 loadClass() 方式，而是建议把自定义的类加载逻辑写在 findClass() 方法中
编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承 URLClassLoader 类，这样就可以避免自己去编写 findClass() 方法及其获取字节码流的方式，使自定义类加载器编写更加简洁

ClassLoader 常用方法

ClassLoader 类，是一个抽象类，其后所有的类加载器都继承自 ClassLoader（不包括启动类加载器）

方法	描述
getParent()	返回该类加载器的超类加载器
loadClass(String name)	加载名称为name的类，返回java.lang.Class类的实例
findClass(String name)	查找名称为name的类，返回java.lang.Class类的实例
findLoadedClass(String name)	查找名称为name的已经被加载过的类，返回java.lang.Class类的实例
defineClass(String name, byte[] b, int off, int len)	把字节数组b中内容转换为一个Java类，返回java.lang.Class类的实例
resolveClass(Class<?> c)	连接指定的一个Java类

对类加载器的引用

JVM 必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么 JVM 会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候，JVM 需要保证这两个类型的类加载器是相同的。

双亲委派机制

Java 虚拟机对 class 文件采用的是按需加载的方式，也就是说当需要使用该类的时候才会将它的 class 文件加载到内存生成 class 对象。而且加载某个类的 class 文件时，Java 虚拟机采用的是双亲委派模式，即把请求交给父类处理，它是一种任务委派模式。

工作过程

如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式

优势

避免类的重复加载，JVM 中区分不同类，不仅仅是根据类名，相同的 class 文件被不同的 ClassLoader 加载就属于两个不同的类（比如，Java中的Object类，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，如果不采用双亲委派模型，由各个类加载器自己去加载的话，系统中会存在多种不同的 Object 类）
保护程序安全，防止核心 API 被随意篡改，避免用户自己编写的类动态替换 Java 的一些核心类，比如我们自定义类：java.lang.String

在 JVM 中表示两个 class 对象是否为同一个类存在两个必要条件：

类的完成类名必须一致，包括包名
加载这个类的 ClassLoader（指ClassLoader实例对象）必须相同

沙箱安全机制

如果我们自定义 String 类，但是在加载自定义 String 类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载 jdk 自带的文件（rt.jar包中 java\lang\String.class），报错信息说没有 main 方法就是因为加载的是rt.jar包中的String类。这样就可以保证对 java 核心源代码的保护，这就是简单的沙箱安全机制。

破坏双亲委派模型

双亲委派模型并不是一个强制性的约束模型，而是 Java 设计者推荐给开发者的类加载器实现方式，可以“被破坏”，只要我们自定义类加载器，重写 loadClass() 方法，指定新的加载逻辑就破坏了，重写 findClass() 方法不会破坏双亲委派。
双亲委派模型有一个问题：顶层 ClassLoader，无法加载底层 ClassLoader 的类。典型例子JNDI、JDBC，所以加入了线程上下文类加载器（Thread Context ClassLoader），可以通过Thread.setContextClassLoaser()设置该类加载器，然后顶层 ClassLoader 再使用 Thread.getContextClassLoader() 获得底层的 ClassLoader 进行加载。
Tomcat 中使用了自定 ClassLoader，并且也破坏了双亲委托机制。每个应用使用 WebAppClassloader 进行单独加载，他首先使用 WebAppClassloader 进行类加载，如果加载不了再委托父加载器去加载，这样可以保证每个应用中的类不冲突。每个tomcat中可以部署多个项目，每个项目中存在很多相同的class文件（很多相同的jar包），他们加载到 jvm 中可以做到互不干扰。
利用破坏双亲委派来实现代码热替换（每次修改类文件，不需要重启服务）。因为一个 Class 只能被一个ClassLoader 加载一次，否则会报 java.lang.LinkageError。当我们想要实现代码热部署时，可以每次都new 一个自定义的 ClassLoader 来加载新的 Class文件。JSP 的实现动态修改就是使用此特性实现。

JVM类文件结构

1 JVM的“平台无关性”

Java具有平台无关性，即任何操作系统都能运行Java代码。之所以能实现这一点，是因为Java运行在虚拟机之上,不同的操作系统都拥有各自的Java虚拟机,因此Java能实现"一次编写,处处运行"。

而JVM不仅具有平台无关性，还具有语言无关性：

平台无关性是指不同操作系统都有各自的JVM
语言无关性是指Java虚拟机能运行除Java以外的代码!

但JVM对能运行的语言是有严格要求的。首先来了解下Java代码的运行过程：Java源代码首先需要使用Javac编译器编译成class文件，然后启动JVM执行class文件，从而程序开始运行。即JVM只认识class文件，它并不管何种语言生成了class文件，只要class文件符合JVM的规范就能运行。

Class文件是JVM的输入, Java虚拟机规范中定义了Class文件的结构。Class文件是JVM实现平台无关、技术无关的基础。

2 纵观Class文件结构

根据 JVM 规范，Class 文件通过 ClassFile 定义：

ClassFile {
    u4             magic; // Class 文件的标志
    u2             minor_version; // Class 的小版本号
    u2             major_version; // Class 的大版本号
    u2             constant_pool_count; // 常量池的数量
    cp_info        constant_pool[constant_pool_count-1]; // 常量池
    u2             access_flags;// Class 的访问标记
    u2             this_class; // 当前类
    u2             super_class; // 父类
    u2             interfaces_count; // 接口
    u2             interfaces[interfaces_count]; // 一个类可以实现多个接口
    u2             fields_count; // Class 文件的字段属性
    field_info     fields[fields_count]; // 一个类会可以有多个字段
    u2             methods_count; // Class 文件的方法数量
    method_info    methods[methods_count]; // 一个类可以有个多个方法
    u2             attributes_count; // 此类的属性表中的属性数
    attribute_info attributes[attributes_count]; // 属性表集合
}

通过分析 ClassFilee，得到 class 文件的组成：

![](https://files.mdnice.com/user/44823/a4ce496d-a452-4e97-bd00-d471ce6721cd.png) width='500px'/>

下图展示为16进制

class文件是一组以8字节为单位的二进制字节流，对于占用空间大于8字节的数据项,按照高位在前的方式分割成多个8字节进行存储。它的内容具有严格的规范，文件中没有任何分隔符，全是连续的0/1。

class文件中的所有内容被分为两种类型：

无符号数基本的数据类型,以u1、u2、u4、u8,分别代表1字节、2字节、4字节、8字节的无符号数
表 class文件中所有数据(即无符号数)要么单独存在,要么由多个无符号数组成二维表.即class文件中的数据要么是单个值,要么是二维表.通常以_info 结尾

文件格式

javap工具生成非正式的"虚拟机汇编语言” ,格式如下:

<index> <opcode> [<operand1> [<operand2> ...]][<comment>]

<index>是指令操作码在数组中的下标,该数组以字节形式来存储当前方法的Java虚拟机代码;也可以是相对于方法起始处的字节偏移量
<opcode>是指令的助记码
< operand>是操作数
<comment>是行尾的注释

实践

Demo1.java

Demo1.txt

版本号规则: JDK5,6,7,8 分别对应49,50,51,52

2.1 魔数(Magic Number)

class文件的头4个字节称为魔数,唯一作用是确定这个文件是否为一个能被JVM接受的Class文件. 作用就相当于文件后缀名,只不过后缀名容易被修改,不安全. 是用16进制表示的"CAFEBABE".

2.2 版本信息

紧接着魔数的4个字节是版本号.它表示本class中使用的是哪个版本的JDK. 在高版本的JVM上能够运行低版本的class文件,但在低版本的JVM上无法运行高版本的class文件.

2.3 常量池

2.3.1 什么是常量池?

紧接着版本号之后的就是常量池. 常量池中存放两种类型的常量:

字面量 (Literal) 接近Java语言的常量概念,如:字符串文本、final常量值等.
符号引用 (Symbolic Reference) 属于编译原理方面,包括下面三类常量:
- 类和接口的全限定名
- 字段的名称和描述符
- 方法的名称和描述符

2.3.2 常量池的特点

长度不固定常量池的大小不固定,因此常量池开头放置一个u2类型的无符号数,代表当前常量池的容量.该值从1开始,若为5表示池中有4项常量,索引值1~5
常量由二维表表示开头有个常量池容量计数值,接下来就全是一个个常量了,只不过常量都是由一张张二维表构成,除了记录常量的值以外,还记录当前常量的相关信息
class文件的资源仓库
与本class中其它部分关联最多的数据类型
占用Class文件空间最大的部分之一 ,也是第一个出现的表类型项目

2.3.3 常量池中常量的类型

根据常量的数据类型不同,被细分为14种常量类型,都有各自的二维表示结构每种常量类型的头1个字节都是tag,表示当前常量属于14种类型中的哪一个.

以CONSTANT_Class_info常量为例，它的二维表示结构如下：CONSTANT_Class_info表

类型	名称	数量
u1	tag	1
u2	name_index	1

tag 表示当前常量的类型(当前常量为CONSTANT_Class_info,因此tag的值应为7,表一个类或接口的全限定名);
name_index 表示这个类或接口全限定名的位置.它的值表示指向常量池的第几个常量.它会指向一个CONSTANT_Utf8_info类型的常量

类型	名称	数量
u1	tag	1
u2	length	1
u1	bytes	length

CONSTANT_Utf8_info表字符串常量

tag 表当前常量的类型,这里是1
length 表该字符串的长度
bytes为这个字符串的内容(采用缩略的UTF8编码)

Java中定义的类、变量名字必须小于64K类、接口、变量等名字都属于符号引用，它们都存储在常量池中而不管哪种符号引用，它们的名字都由CONSTANT_Utf8_info类型的常量表示，这种类型的常量使用u2存储字符串的长度由于2字节最多能表示65535个数，因此这些名字的最大长度最多只能是64K

UTF-8编码 VS 缩略UTF-8编码前者每个字符使用3个字节表示，而后者把128个ASCII码用1字节表示，某些字符用2字节表示，某些字符用3字节表示。

Demo1.txt中的常量池部分

类信息包含的静态常量，编译之后就能确认

JVM 指令


invokeinterface	用以调用接口方法，在运行时搜索一个实现了这个接口方法的对象，找出适合的方法进行调用。（Invoke interface method）
invokevirtual	指令用于调用对象的实例方法，根据对象的实际类型进行分派（Invoke instance method; dispatch based on class）
invokestatic	用以调用类方法（Invoke a class (static) method ）
invokespecial	指令用于调用一些需要特殊处理的实例方法，包括实例初始化方法、私有方法和父类方法。（Invoke instance method; special handling for superclass, private, and instance initialization method invocations ）

invokedynamic JDK1.7新加入的一个虚拟机指令，相比于之前的四条指令，他们的分派逻辑都是固化在JVM内部，而invokedynamic则用于处理新的方法分派：它允许应用级别的代码来确定执行哪一个方法调用，只有在调用要执行的时候，才会进行这种判断,从而达到动态语言的支持。(Invoke dynamic method)

2.4 访问控制

在常量池结束之后是2字节的访问控制表示这个class文件是类/接口、是否被public/abstract/final修饰等.

由于这些标志都由是/否表示,因此可以用0/1表示. 访问标志为2字节,可以表示16位标志,但JVM目前只定义了8种,未定义的直接写0.

标志名称	标志值	含义
ACC_INTERFACE		是一个接口,而不是一个类
ACC_MODULE		声明的模块；可能无法从其模块外部访问。仅当ClassFile具有Module属性时才可以设置。
ACC_STATIC	0x0008	声明为静态

Demo1.txt中的构造方法

Demo1这个示例中，我们并没有写构造函数。由此可见，没有定义构造函数时，会有隐式的无参构造函数

2.5 类索引、父类索引、接口索引集合

表示当前class文件所表示类的名字、父类名字、接口们的名字. 它们按照顺序依次排列,类索引和父类索引各自使用一个u2类型的无符号常量,这个常量指向CONSTANT_Class_info类型的常量,该常量的bytes字段记录了本类、父类的全限定名. 由于一个类的接口可能有好多个,因此需要用一个集合来表示接口索引,它在类索引和父类索引之后.这个集合头两个字节表示接口索引集合的长度,接下来就是接口的名字索引.

2.6 字段表的集合

2.6.1 什么是字段表集合?

用于存储本类所涉及到的成员变量,包括实例变量和类变量,但不包括方法中的局部变量. 每一个字段表只表示一个成员变量,本类中所有的成员变量构成了字段表集合.

2.6.2 字段表结构的定义

access_flags 字段的访问标志。在Java中，每个成员变量都有一系列的修饰符，和上述class文件的访问标志的作用一样，只不过成员变量的访问标志与类的访问标志稍有区别。
name_index 本字段名字的索引。指向一个CONSTANT_Class_info类型的常量，这里面存储了本字段的名字等信息。
descriptor_index 描述符。用于描述本字段在Java中的数据类型等信息(下面详细介绍)
attributes_count 属性表集合的长度。
attributes 属性表集合。到descriptor_index为止是字段表的固定信息，光有上述信息可能无法完整地描述一个字段，因此用属性表集合来存放额外的信息，比如一个字段的值。(下面会详细介绍)

2.6.3 什么是描述符?

成员变量(包括静态成员变量和实例变量) 和方法都有各自的描述符。对于字段而言，描述符用于描述字段的数据类型；对于方法而言，描述符用于描述字段的数据类型、参数列表、返回值。

在描述符中，基本数据类型用大写字母表示，对象类型用“L对象类型的全限定名”表示，数组用“[数组类型的全限定名”表示。描述方法时，将参数根据上述规则放在()中，()右侧按照上述方法放置返回值。而且，参数之间无需任何符号。

2.6.4 字段表集合的注意点

一个class文件的字段表集合中不能出现从父类/接口继承而来字段；
一个class文件的字段表集合中可能会出现程序猿没有定义的字段如编译器会自动地在内部类的class文件的字段表集合中添加外部类对象的成员变量，供内部类访问外部类。
Java中只要两个字段名字相同就无法通过编译。但在JVM规范中，允许两个字段的名字相同但描述符不同的情况，并且认为它们是两个不同的字段。
Demo1.txt中的程序入口main方法

2.7 方法表的集合

在class文件中，所有的方法以二维表的形式存储，每张表来表示一个函数，一个类中的所有方法构成方法表的集合。方法表的结构和字段表的结构一致，只不过访问标志和属性表集合的可选项有所不同。

方法表的属性表集合中有一张Code属性表，用于存储当前方法经编译器编译过后的字节码指令。

方法表集合的注意点

如果本class没有重写父类的方法，那么本class文件的方法表集合中是不会出现父类/父接口的方法表；
本class的方法表集合可能出现程序猿没有定义的方法编译器在编译时会在class文件的方法表集合中加入类构造器和实例构造器。
重载一个方法需要有相同的简单名称和不同的特征签名。JVM的特征签名和Java的特征签名有所不同：
Java特征签名：方法参数在常量池中的字段符号引用的集合
JVM特征签名：方法参数＋返回值

2.8 属性表的集合

程序完整运行分析

总结

我们将JVM运行的核心逻辑进行了详细剖析。

JVM运行原理中更底层实现，针对不同的操作系统或者处理器，会有不同的实现。这也是JAVA能够实现“一处编写，处处运行”的原因。

JVM之垃圾回收机制和常用算法

垃圾收集 (Garbage Collection,GC)

垃圾收集主要是针对堆和方法区进行。程序计数器、虚拟机栈和本地方法栈这三个区域属于线程私有的，只存在于线程的生命周期内，线程结束之后就会消失，因此不需要对这三个区域进行垃圾回收。

判断一个对象是否可被回收

堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）。

引用计数算法

为对象添加一个引用计数器，当对象增加一个引用时计数器加 1，引用失效时计数器减 1。引用计数为 0 的对象可被回收。

在两个对象出现循环引用的情况下，此时引用计数器永远不为 0，导致无法对它们进行回收。正是因为循环引用的存在，因此 Java 虚拟机不使用引用计数算法。

public class Test {

    public Object instance = null;

    public static void main(String[] args) {
        Test a = new Test();
        Test b = new Test();
        a.instance = b;
        b.instance = a;
        a = null;
        b = null;
        doSomething();
    }
}

在上述代码中，a 与 b 引用的对象实例互相持有了对象的引用，因此当我们把对 a 对象与 b 对象的引用去除之后，由于两个对象还存在互相之间的引用，导致两个 Test 对象无法被回收。

优点：执行效率高，程序执行受影响较小。
缺点：无法检测出循环引用的情况，引起内存泄漏。

可达性分析算法

通过判断对象的引用链是否可达来决定对象是否可以被回收。

以 GC Roots 为起始点进行搜索，可达的对象都是存活的，不可达的对象可被回收。

Java 虚拟机使用可达性分析算法来判断对象是否可被回收，GC Roots 一般包含以下几种：

虚拟机栈中局部变量表中引用的对象（栈帧中的本地方法变量表）
本地方法栈中 JNI（Native方法）中引用的对象
方法区中类静态属性引用的对象
方法区中的常量引用的对象
活跃线程的引用对象

方法区的回收

因为方法区主要存放永久代对象，而永久代对象的回收率比新生代低很多，所以在方法区上进行回收性价比不高。

主要是对常量池的回收和对类的卸载。

为了避免内存溢出，在大量使用反射和动态代理的场景都需要虚拟机具备类卸载功能。

类的卸载条件很多，需要满足以下三个条件，并且满足了条件也不一定会被卸载：

该类所有的实例都已经被回收，此时堆中不存在该类的任何实例。
加载该类的 ClassLoader 已经被回收。
该类对应的 Class 对象没有在任何地方被引用，也就无法在任何地方通过反射访问该类方法。

finalize()

类似 C++ 的析构函数（注意：只是类似，C++ 析构函数调用确定，而 finalize() 方法是不确定的），用于关闭外部资源。但是 try-finally 等方式可以做得更好，并且该方法运行代价很高，不确定性大，无法保证各个对象的调用顺序，因此最好不要使用。

当垃圾回收器要宣告一个对象死亡时，至少要经历两次标记过程。

如果对象在进行可达性分析以后，没有与GC Root 直接相连接的引用量，就会被第一次标记，并且判断是否执行 finalize() 方法；

如果这个对象覆盖了 finalize() 方法，并且未被引用，就会被放置于 F-Queue 队列，稍后由虚拟机创建的一个低优先级的 finalize() 线程去执行触发 finalize() 方法，在该方法中让对象重新被引用，从而实现自救。但是该线程的优先级比较低，执行过程随时可能会被终止。此外，自救只能进行一次，如果回收的对象之前调用了 finalize() 方法自救，后面回收时不会再调用该方法。

引用类型

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象是否可达，判定对象是否可被回收都与引用有关。

JDK1.2 之前，Java 中引用定义：如果 reference 类型的数据存储的数值代表的是另一块内存的起始地址，就称这块内存代表一个引用。

JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱）。

强引用 (Strong Reference)

被强引用关联的对象不会被回收。

使用 new 一个新对象的方式来创建强引用。

Object obj = new Object();

当内存空间不足，JVM 抛出 OOM Error 终止程序也不会回收具有强引用的对象，只有通过将对象设置为 null 来弱化引用，才能使其被回收。

软引用 (Soft Reference)

表示对象处在有用但非必须的状态。

被软引用关联的对象只有在内存不够的情况下才会被回收。可以用来实现内存敏感的高速缓存。

软引用可以和一个引用队列 ReferenceQueue 联合使用，如果软引用所引用的对象被垃圾回收，JVM 就会把这个软引用加入到与之关联的引用队列中。如果一个弱引用对象本身在引用队列中，就说明该引用对象所指向的对象被回收了。

使用 SoftReference 类来创建软引用。

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null;  // 使对象只被软引用关联

弱引用 (Weak Reference)

表示非必须的对象，比软引用更弱一些。适用于偶尔被使用且不影响垃圾收集的对象。

被弱引用关联的对象一定会被回收，也就是说它只能存活到下一次垃圾回收发生之前。

弱引用可以和一个引用队列 ReferenceQueue 联合使用，如果弱引用所引用的对象被垃圾回收，JVM 就会把这个弱引用加入到与之关联的引用队列中。如果一个弱引用对象本身在引用队列中，就说明该引用对象所指向的对象被回收了。

使用 WeakReference 类来创建弱引用。

Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);
obj = null;

虚引用 (Phantom Reference)

又称为幽灵引用或者幻影引用，一个对象是否有虚引用的存在，不会对其生存时间造成影响，也无法通过虚引用得到一个对象。

不会决定对象的生命周期，任何时候都可能被垃圾回收器回收。必须和引用队列 ReferenceQueue 联合使用。

为一个对象设置虚引用的唯一目的是能在这个对象被回收时收到一个系统通知，起哨兵作用。具体来说，就是通过判断引用队列 ReferenceQueue 是否加入虚引用来判断被引用对象是否被 GC（垃圾回收线程）回收：当 GC 准备回收一个对象时，如果发现它还仅有虚引用指向它，就会在回收该对象之前，把这个虚引用加入到与之关联的引用队列 ReferenceQueue 中。如果一个虚引用对象本身就在引用队列中，就说明该引用对象所指向的对象被回收了。

使用 PhantomReference 来创建虚引用。

Object obj = new Object();
ReferenceQueue queue = new ReferenceQueue(); 
// 虚引用必须和引用队列 ReferenceQueue 联合使用
PhantomReference<Object> pf = new PhantomReference<Object>(obj, queue);
obj = null;

总结：

引用类型	被垃圾回收的时间	用途	生存时间
强引用	从来不会	对象的一般状态	JVM停止运行时终止
软引用	在内存不足的时候	对象缓存	内存不足时终止
弱引用	在垃圾回收的时候	对象缓存	GC运行后终止
虚引用	Unknown	标记、哨兵	Unknown

垃圾收集算法

“标记-清除” 算法

在标记阶段，从根集合进行扫描，会检查每个对象是否为活动对象，如果是活动对象，则程序会在对象头部打上标记。

在清除阶段，会进行对象回收并取消标志位，另外，还会判断回收后的分块与前一个空闲分块是否连续，若连续，会合并这两个分块。回收对象就是把对象作为分块，连接到被称为 “空闲链表” 的单向链表，之后进行分配时只需要遍历这个空闲链表，就可以找到分块。

在分配时，程序会搜索空闲链表寻找空间大于等于新对象大小 size 的块 block。如果它找到的块等于 size，会直接返回这个分块；如果找到的块大于 size，会将块分割成大小为 size 与 (block - size) 的两部分，返回大小为 size 的分块，并把大小为 (block - size) 的块返回给空闲链表。

不足：

标记和清除过程效率都不高；
会产生大量不连续的内存碎片，导致无法给大对象分配内存。

”标记-整理“ 算法

标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

优点：不会产生内存碎片

不足：需要移动大量对象，处理效率比较低。

”复制“ 算法

将内存划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。

主要不足是只使用了内存的一半。

现在的商业虚拟机都采用这种收集算法回收新生代，但是并不是划分为大小相等的两块，而是一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor。在回收时，将 Eden 和 Survivor 中还存活着的对象全部复制到另一块 Survivor 上，最后清理 Eden 和使用过的那一块 Survivor。

HotSpot 虚拟机的 Eden 和 Survivor 大小比例默认为 8:1，保证了内存的利用率达到 90%。如果每次回收有多于 10% 的对象存活，那么一块 Survivor 就不够用了，此时需要依赖于老年代进行空间分配担保，也就是借用老年代的空间存储放不下的对象。

分代收集

现在的商业虚拟机采用分代收集算法，它根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。

一般将堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法：

新生代：新生代对象存活时间很短，所以可以选择“复制”算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。
老年代：老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

Stop-the-World & SafePoint

Stop-the-World

所谓 Stop-the-World（简称 STW），指的是 JVM 由于要执行 GC 而停止了应用程序的执行 ：

可达性分析算法中 GC Roots 会导致所有 Java 执行线程停顿，原因如下：
- 分析工作必须在一一个能确保一致性的快照中进行
- 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
- 如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证
被 STW 中断的应用程序线程会在完成 GC 之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，影响用户体验，所以需要减少 STW 的发生。

STW 事件和采用哪款垃圾收集器无关，所有的 GC 都有这个事件。哪怕是 G1 也不能完全避免 STW 情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间。

STW 是 JVM 在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。开发中不要用 System.gc() 这样会导致 STW 的发生。

目前，降低系统的停顿时间两种算法：增量收集算法和分区算法。

增量收集算法

基本思想：如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。垃圾收集线程一次只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。

不足：由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

分区算法

基本思想：一般来说，在相同条件下，堆空间越大，一次 GC 时所需要的时间就长，有关 GC 产生的停顿也越长。为了更好地控制 GC 产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次 GC 所产生的停顿。

注意分区算法与分代收集算法是不同的：分代收集算法将按照对象的生命周期长短划分成两个部分，而分区算法将整个堆空间划分成连续的不同小区间，其中每个小区间都独立使用，独立回收，这样可以控制一次回收多少个小区间。

总结：

增量收集算法是将总的收集量一部分一部分的去执行
分区算法是将总的内存空间分为小分区，一次可控的去收集多少个小区间。

SafePoint

程序执行时并非可以在任何地方都能停顿下来开始 GC，只有在特定的位置才能停顿下来开始 GC，这些位置称为Safepoint 。

SafePoint 的选择很重要，如果太少可能导致 GC 等待的时间太长，如果太频繁可能导致运行时的性能问题。

大部分指令的执行时间都非常短暂，通常会根据是否具有让程序长时间执行的特征为标准。比如选择一些执行时间较长的指令作为 SafePoint，如方法调用、循环跳转和异常跳转等。

一叶飘舟

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
详解JVM对象内存布局以及内存分配规则

程序计数器是一块较小的内存空间，是当前线程正在执行的那条字节码指令的地址。若当前线程正在执行的是一个本地方法，那么此时程序计数器为Undefined。Java 虚拟机栈是描述 Java 方法运行过程的内存模型。Java 虚拟机栈会为每一个即将运行的 Java 方法创建一块叫做“栈帧”的区域，用于存放该方法运行过程中的一些信息，如：局部变量表操作数栈动态链接方法出口信息......
复制链接

扫一扫