JVM和Java体系结构

Java虚拟机

Java虚拟机（JVM，Java Virtual Machine）：

• 一台执行Java字节码的虚拟计算机，拥有独立的运行机制
• 转载字节码到内部，解释/编译为对应平台上的机器指令

特点：

1. 一次编译到处运行

2. 自动内存管理

3. 自动垃圾回收

Java代码执流程

flowchart LR
    code("Java源码（.java）") --> a("Java（前端）编译器")
    a --> cls("字节码（.class）")
    subgraph Java虚拟机
        direction TB
        类加载器 --> 字节码校验器
        subgraph 执行引擎
            direction TB
            jsq("解释执行（解释器）")
            jit("编译执行（JIT）")
        end
        字节码校验器 --> 执行引擎
    end
    cls --> Java虚拟机
    Java虚拟机 --> 操作系统

JVM位置

JVM运行在操作系统之上，与硬件没有直接的交互

JVM整体结构

HotSpot VM是目前高性能虚拟机代表之一，采用解释器与即使编译器并存的架构

Class loader：将字节码文件，加载到内存中，生成Class对象

Runtime Data Area：JVM内存，上一步加载的Class的实例就是存放在方法区中

​ 堆，方法区：多线程共享

​ 虚拟机栈，本地方法栈，程序计数器栈：每个线程一份

执行引擎：解释器，即时编译器（JIT编译器），垃圾回收器

JVM架构模型

JVM指令集架构为：基于栈的指令集架构

基于栈的指令集架构

1. 设计和实现简单
2. 避开寄存器分配难题
3. 零地址指令，指令集更小
4. 不需要硬件支持

基于寄存器的指令集架构

1. 典型：X86的二进制指令集
2. 指令集架构完全依赖于硬件
3. 性能优秀，执行高效
4. 花费更少指令，去完成一项操作
5. 以一地址指令、二地址指令和三地址指令为主

两种架构举例

• 基于栈的计算流程（以Java虚拟机为例）：

1
2
3
4
5
6
7
8

iconst_2	// 常量2入栈
istore_1
iconst_3	// 常量3入栈
istore_2
iload_1
iload_2
iadd		// 常量2，3出栈，执行相加
istore_0	// 结果5入栈

• 基于寄存器的计算流程

1
2

mov eax,2	// 将eax寄存器的值设为1
add eax,3	// 使eax寄存器的值加3

考虑跨平台性与移植性，Java指令集都是根据栈来设计的

• 优点：跨平台，指令集小，编译器容易实现

• 缺点：性能比寄存器差一些

JVM生命周期

JVM的启动

通过引导类加载器（bootstrap class loader）创建一个初始类（initial class）来完成的。这个初始类由虚拟机的具体实现来指定。

JVM的执行

• JVM有一个清晰的任务：执行Java程序
• 程序开始他才运行，程序结束他就停止

JVM的退出

1. 程序正常退出
2. 程序遇到异常或错误而停止
3. 操作系统出现错误导致JVM停止
4. 某线程调用了Runtime类或System类的exit方法，或Runtime类的halt方法，并且Java安全管理器也允许这次exit()或halt()操作

JVM发展历程

Sun Classic VM

• 1996年Java1.0时出现，世界第一款商用Java虚拟机，JDK1.4时被淘汰
• 只提供解释器
• 要使用JIT编译器，需要进行外挂，且会完全接管解释器。
  • 解释器和JIT编译器无法共存
  • 只使用JIT，需要把所有字节码都翻译成机器指令，翻译时间过长。程序启动的时候，等待时间长。
• 目前Hotspot内置此虚拟机

Exact VM

• JDK1.2时，Sun提供了此虚拟机
• 虚拟机可以知道内存中某个位置的数据具体是什么类型
• 具备现代高性能虚拟机的维形
  • 热点探测（寻找出热点代码进行缓存）
  • 编译器与解释器混合工作模式
• 只在Solaris平台短暂使用，终被Hotspot虚拟机替换

HotSpot VM（重点）

• JDK1.3时，成为oracle JDK和openJDK的默认虚拟机

• HotSpot：热点代码探测技术

  • 通过计数器，找到最具编译价值代码，触发即时编译或栈上替换
  • 编译器与解释器协同工作

JRockit（商用三大虚拟机之一）

• 即时编译器编译后执行
• 世界上最快的JVM

IBM的J9（商用三大虚拟机之一）

• 号称是世界上最快的Java虚拟机

KVM和CDC/CLDC Hotspot

• 面向更低端的设备，比如塞班

Azul VM

• 与特定硬件平台绑定

Liquid VM

• 运行在自家Hypervisor系统上
• 不需要操作系统的支持，或者说它自己本身实现了一个专用操作系统的必要功能，如线程调度、文件系统、网络支持等
• 随着JRockit虚拟机终止开发，Liquid vM项目也停止了

Apache Marmony

• 并没有Apache Harmony被大规模商用的案例，但是它的Java类库代码吸纳进了Android SDK

Micorsoft JVM

• 微软为了在IE3浏览器中支持Java Applets，开发了Microsoft JVM

Taobao JVM

• 目前已经在淘宝、天猫上线，把Oracle官方JVM版本全部替换了

Dalvik VM

• 执行的是编译以后的dex（Dalvik Executable）文件。执行效率比较高

• Android 5.0使用支持提前编译（Ahead of Time Compilation，AoT）的ART VM替换Dalvik VM

Graal VM（未来虚拟机）

• Run Programs Faster Anywhere
• 跨语言全栈虚拟机：Java，Scala，Groovy，Kotlin，C，C++，JavaScript，Ruby，Python，R
• 如果说HotSpot有一天真的被取代，Graalvm希望最大

课程学习路线

graph TB
    类的加载器 ---> 内存结构
    a["class文件结构"] ---> 内存结构
    执行引擎 ---> 内存结构
    内存结构 ---> 内存的分配与回收
    内存的分配与回收 ---> b["性能监控(命令行、可视化工具)"]
    b ---> 性能优化

类加载子系统

如果想手写一个Java虚拟机的话，需要考虑哪些结构？

• 类加载器（ClassLoader）
• 执行引擎

ClassLoader作用

1. 从文件系统或网络中加载class文件
2. Class Loader只负责加载，能否运行由执行引擎决定
3. 加载的类信息放在一块称为“方法区”的内存空间，除此之外，方法区还会存放运行时常量池信息（比如字符串字面量，数字常量）

（补充）加载class文件的方式：

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

ClassLoader角色

1. class file存在硬盘上（纸上的模板），最终需要实例化到JVM中（做好的成品）
2. class file加载到JVM中，被称为DNA元数据模板，放在方法区中
3. class file -> DNA元数据模板，需要一个运输工具，也即ClassLoader

类加载过程

阶段一：Loading

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

阶段二：Linking

验证

确保Class文件的字节流符合要求。主要包含四种验证：文件格式，元数据，字节码，符号引用

举例：字节码文件开头都是CA FE BA BE

准备

1. 为类变量（static）分配内存，并设置初始值（零值）

2. fianl static编译时就分配好了默认值，此时会显式初始化

3. 类变量分配在方法区中

举例：变量a在准备阶段会赋初始值0。初始化时才会赋值为1

1

private static int a = 1;

解析

1. 将常量池内的符号引用转换为直接引用的过程
   • 符号引用就是一组符号来描述所引用的目标
   • 直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄

举例：javap -v Hello.java反编译后，可以查看符号引用，下面带#的就是符号引用

阶段三：Initialization

1. 就是执行**类构造器方法<clinit>**的过程
   • 此方法不需要定义，是javac编译器自动收集类中所有类变量的赋值动作和静态代码块中的语句合并而来的
   • 执行顺序按照语句在源码中的顺序执行
   • 如果没有类变量或者static块，就不会有<clinit>方法了
   • 如果该类有父类，会保证父类的<clinit>先执行
   • 虚拟机保证<clinit>方法在多线程下被同步加锁

1
2
3
4
5
6
7
8
9
10
11
12
13

public class Main {
    private static int a = 1;

    static {
        a = 2;
        // initialization时执行，第一次赋值
        num = 100;
    }
	
    // linking时创建num变量，并赋零值
    // initialization时执行，第二次赋值，最终num为1
    private static int num = 1;
}

ClassLoader分类

引导类加载器（Bootstrap ClassLoader）

• C/C++实现，在JVM内部
• 用来加载Java核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar、或sun.boot.class.path路径下的内容）
• 用来加载扩展类加载器，系统类加载器，并指定为他们的父加载器
• 只加载包名为java、javax、sun等开头的类
• 没有父加载器

扩展类加载器（Extension Class Loader）

• Java语言编写，派生自ClassLoader类，父类加载器为引导类加载器
• 从系统属性java.ext.dirs指定的目录加载类库，或从JDK安装目录jre/lib/ext目录下加载类库
  • 如果用户创建JAR包放入其中，也会自动加载

系统类加载器（System Class Loader）

• Java语言编写，派生自ClassLoader类，父类加载器为扩展类加载器
• 加载环境变量classpath或系统属性java.class.path指定路径下的类库
• 是程序中的默认类加载器，可以ClassLoader.getSystemClassLoader()来获取

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class Test {
    public static void main(String[] args) {

        // 获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();

        // 获取其上层，扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();

        // 获取其上层，引导类加载器（为null，无法获取）
        ClassLoader bootstrpClassLoader = extClassLoader.getParent();

        // 获取用户自定义类的，类加载器（系统类加载器）
        ClassLoader classLoader1 = Test.class.getClassLoader();

        // 获取Java核心类的，类加载器（为null，其实是引导类加载器）
        ClassLoader classLoader2 = String.class.getClassLoader();
    }
}

自定义加载器（User-Defined ClassLoader）

• 所有派生于抽象类ClassLoader的类加载器
• 为什么需要自定义类加载器
  • 隔离加载类（例如：应用的jar包，中间件的jar包不会冲突）
  • 修改类加载的方式
  • 扩展加载源
  • 防止源码泄露

自定义类加载器简单实现

• 开发人员可以继承抽象类java.lang.Classloader，实现自己的类加载器

• JDK1.2之前，重写loadClass方法；JDK1.2之后，推荐把自定义类加载逻辑写在findClass中

• 如果没有太复杂的需求，可以直接继承URLClassLoader，避免去编写findClass()方法及其获取字节流的方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class CustomClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            byte[] result = getClassFromCustomPath(name);
            if (result == null) {
                throw new FileNotFoundException();
            } else {
                return defineClass(name, result, 0, result.length);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }
         throw new ClassNotFoundException(name);
    }

    private byte[] getClassFromCustomPath(String name) {
        // 从自定义路径中加载指定的类，细节略
        // 如果字节码文件进行了加密，需要在此进行解密
        return null;
    }
}

ClassLoader常用方法

获取ClassLoader的方法

双亲委派机制

JVM对Class文件采用的是按需加载方式。加载某个类的class文件时，JVM采用的是双亲委派机制，即把请求交给父类处理。

思考问题：假如我们创建一个java.lang.String类，new String()会被影响吗？

1
2
3
4
5
6
7

package java.lang;

class String {
    static {
        System.out.println("hello");
    }
}

答：java.lang.String由引导类加载器加载，根据双亲委派机制，不会被影响

工作原理

1. 类加载器收到了类加载请求，不会直接去执行，而是委托父类的加载器去执行
2. 父类如果还有父类，则进一步向上委托
3. 如果父类加载器可以加载，就成功返回；不能加载，子加载器才会尝试加载

优势

• 避免类的重复加载
• 保护程序安全：防止核心API被篡改
  • java.lang.String：不会被篡改
  • java.lang.MyTest：无法添加（因为包名java开头，引导类加载器不会加载）

沙箱安全机制

1
2
3
4
5
6
7

package java.lang;

class String {
    public static void main(String[] args) {
        System.out.println("hello");
    }
}

加载java.lang.String时，会率先使用引导类加载器。引导类加载器会先加载jdk自带的文件（rt.jar包中的java\lang\String.class）

报错信息说：没有main方法

这样可以保证对java核心源代码的保护，这就是沙箱安全机制

其他

在JVM中两个class对象是否为同一个？

• 类的完整类名必须一致，包括包名

• 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同

JVM必须知道一个类型是由启动加载器加载的，还是由用户类加载器加载的

• 如果是用户类加载器加载的，那么JVM会将这个类加载器的引用作为类型信息的一部分，存放在方法区中
• 当解析一个类型到另一个类型的引用时，JVM需要保证这两个类型的类加载器是相同的

Java程序对类的使用分为主动使用和被动使用

• 主动使用

• 被动使用：其他对类的使用都是被动使用，不会导致类的初始化（Initialization）

运行时数据区

基本情况

不同的JVM对于内存的划分方式和管理机制存在着部分差异。我们结合JVM虚拟机规范，来探讨一下经典的JVM内存布局

Runtime类：运行时环境，也即被框出来的部分。每个JVM只有一个Runtime实例

线程

基本知识

1. 在Hotspot JVM中，每个线程都与本地线程直接映射
   • 当一个Java线程准备好执行后，一个操作系统线程也同时创建
   • Java线程执行终止后，本地线程也会回收
2. 操作系统会将线程调度到任何可用CPU上。一旦本地线程创建成功，就会调用Java线程中的run()方法

JVM系统线程

除了main线程和main创建的线程外，还有很多后台线程（简单了解下）：

• 虚拟机线程：JVM达到安全点才会出现
• 周期任务线程
• GC线程
• 编译线程
• 信号调度线程

程序计数器

PC Register介绍

程序计数寄存器（Program Counter Register），并非物理意义上的寄存器，而是一种抽象模拟

• 作用：用来指向下一条指令的地址
• 它是一块很小的内存空间，运行速度最快
• 每个线程都有自己的PC计数器，生命周期与线程一致
• 一个线程只会有一个方法在执行，也即当前方法
  • PC计数器会存储当前线程正在执行的Java方法的JVM指令地址
  • 如果是native方法，则是未指定值（undefined）
• 它是程序控制流的指示器
  • 分支、循环、跳转、异常处理、线程恢复等基础功能，都需要依赖这个计数器来完成
• 解释器工作时，改变这个计数器的值，来选取下一条需要执行的指令
• 在JVM中，唯一没有规定任何OutofMemoryError情况的区域

举例说明

• 源代码

1
2
3
4
5
6
7
8
9
10

public class Test {
    public static void main(String[] args) {
        int i = 10;
        int j = 20;
        int k = i + j;

        String s = "abc";
        System.out.println(s);
    }
}

• javap -verbose Test.class反编译（部分代码）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

 0: bipush        10
 2: istore_1
 3: bipush        20
 5: istore_2
 6: iload_1
 7: iload_2
 8: iadd
 9: istore_3
10: ldc           #7                  // String abc
12: astore        4
14: getstatic     #9                  // Field java/lang/System.out:Ljava/io/PrintStream;
17: aload         4
19: invokevirtual #15                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
22: return

两个面试问题

为什么使用 PC 寄存器来记录当前线程的执行地址？

1. CPU会不断切换各线程，切换回来后，需要知道从哪里继续
2. JVM字节码解释器需要通过改变PC寄存器的值，来明确下一条应该执行的指令

PC寄存器为什么被设定为私有的？

1. CPU会不断做任务切换，必然导致线程中断和恢复
2. 为了准确记录各线程当前执行的字节码地址，最好为每个线程都分配一个PC寄存器

虚拟机栈

基本内容

• Java虚拟机栈是什么？

​ Java虚拟机栈（Java Virtual Machine Stack），也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次的Java方法调用，栈是线程私有的

• 虚拟机栈的生命周期

  生命周期和线程一致

虚拟机栈的特点

• 快速有效，访问速度仅次于PC寄存器
• JVM对虚拟机栈的操作只有两个
  • 方法执行，对应入栈
  • 方法结束，对应出栈
• 栈不存在垃圾回收问题
  • 栈不需要GC，但是可能存在OOM

虚拟机栈的异常

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

• 如果固定大小：每个线程的虚拟机栈可以在创建时设定，执行时如果超过，JVM将抛出StackOverflowError异常
• 如果动态扩展：扩展时无法获
• 得足够内存，或创建时无法获取足够内存创建，JVM将抛出OutofMemoryError异常

设置栈大小

使用-Xss选项，在VM options中设定

1
2
3

-Xss1m
-Xss1024k
-Xss1048576

栈的存储单元

栈中存储什么？

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

栈运行原理

1. JVM对虚拟机栈只能进行压栈和出栈
2. 一个线程中，只能有一个活动的栈帧
   • 当前栈帧（Current Frame）
   • 当前方法（Current Method）
   • 当前类（Current Class）
3. 执行引擎运行的字节码指令只针对当前栈帧
4. 如果该方法调用了其他方法，会创建新的栈帧，放在栈顶，成为新的当前帧
   • 方法返回时，当前栈帧会传回执行结果给前一个栈帧。虚拟机丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧
5. 不同线程的栈帧之间，不允许相互引用
6. Java方法有两种返回方式
   • 正常返回：使用return指令
   • 异常返回：执行中出现未捕获的异常

栈帧内部结构

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

局部变量表（Local Variables）

1. 定义为一个数字数组，存储方法参数和局部变量
   • 数据类型包括：基本数据类型、对象引用（reference）、returnAddress返回值类型
2. 线程的私有数据，不存在数据安全问题
3. 容量大小在编译期就确定下来，保存在字节码中：方法的Code属性的maximum local variables数据项中
4. 只在当前方法中有效

Slot的理解

1. 局部变量表，最基础的存储单位是Slot
2. 32位的变量占一个Slot，64位的占两个
   • byte，char，short，boolean存储前都转换位int
   • long，double占两个slot
3. 局部变量表每个Slot都有一个索引（从0开始），通过索引即可访问变量值
   • 64位变量使用前一个索引访问即可
4. 方法被调用时，方法参数和局部变量，将会按照顺序被复制到局部变量表的每一个slot上
5. 如果是构造方法或实例方法，this将被存放在index为0的slot处

Slot的重复利用

一个栈帧中的Slot可以重复利用。一个局部变量过了其作用域，新的局部变量可以使用之前的槽位

1
2
3
4
5
6
7

public void test4() {
    {
        int b = 0;
    }
    // 使用之前的槽位
    int c = 1;
}

操作数栈（Operand Stack）

也被称为：表达式栈

操作数栈的作用

1. 主要用于保存计算中间结果，同时作为变量临时存储的空间
2. 可以视为JVM执行引擎的工作区。方法开始执行时，新的栈帧也随之创建，此时方法操作数栈是空的
3. 操作数栈有明确的栈深度，所需最大深度在编译期就已定义好了，保存在字节码中方法的Code属性中（maxstack）
4. 栈中的元素可以是任意Java类型
   • 32bit类型占一个栈深度
   • 64bit类型占两个栈深度
5. 如果被调用函数有返回值，其返回值会被压入当前栈帧的操作数栈中
   • 然后更新PC寄存器中下一条要执行的指令
6. 操作数栈中的元素数据类型，必须与字节码指令的序列严格匹配
   • 在编译阶段，编译器验证
   • 在类加载过程中，类检验阶段（Linking-检验）的数据流分析阶段再次检验

举例说明

1
2
3

byte i = 15;
int j = 8;
int k = i + j;

1
2
3
4
5
6
7
8
9

 0 bipush 15
 2 istore_1
 3 bipush 8
 5 istore_2
 6 iload_1
 7 iload_2
 8 iadd
 9 istore_3
10 return

1. 第一条指令，PC寄存器指向0。使用bipush让操作数15入操作数栈

2. PC寄存器+1，指向下一行代码。使用istore_1将操作数栈的元素存储到局部变量表1的位置（局部变量表0存的是this）

3. 同理，bipush将操作数8入栈，istore_2将操作数栈的元素存储到局部变量表2的位置

4. 使用iload_1，iload_2，从局部变量表中取出两个操作数，放入栈中

5. 使用iadd，将操作数栈顶端两个元素相加，然后入栈。再使用istore_3将其存储在变量表3的位置

关于类型转换

int j = 8;

• 8可以存储在byte类型中，所以压入栈的类型为byte（bipush 8）

• 存储为局部变量时，会转为int类型（istore_4）

int j = 800;

• byte存储不了，改为short型（sipush 800）

关于返回值的问题

1
2
3
4
5
6
7
8
9
10
11

public int getSum() {
    int a = 1;
    int b = 2;
    int c = a + b;
    return c;
}

public void testGetSum() {
    int i = getSum();
    int j = 10;
}

• getSum()方法字节码指令，最后带着ireturn

• testGetSum()方法字节码指令，一上来就加载getSum()方法的返回值

栈顶缓存技术

HotSpot JVM的设计者们提出了栈顶缓存（Tos，Top-of-Stack Cashing）技术

• 将栈顶元素全部缓存在物理CPU的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率

动态链接（Dynamic Linking）

• 每个栈帧中都包含一个：指向常量池中，该方法的引用
  • 包含这个引用的目的，就是为了实现动态链接（Dynamic Linking）
• 在字节码文件中，所有变量和方法的引用都作为符号引用（Symbolic Reference）保存在class文件的常量池中
  • 比如：调用一个方法，就是通过常量池中指向方法的符号引用来表示的
  • 动态链接作用就是为了将这些符号引用转换为直接引用

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Test {

    int num = 10;

    public void methodA() {
        System.out.println("A");
    }

    public void methodB() {
        System.out.println("B");
        methodA();
        num++;
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

# 字节码中的常量池
Constant pool:
   #1 = Methodref          #2.#3          // java/lang/Object."<init>":()V
   #2 = Class              #4             // java/lang/Object
   #3 = NameAndType        #5:#6          // "<init>":()V
   #4 = Utf8               java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = Fieldref           #8.#9          // org/example/Test.num:I
   #8 = Class              #10            // org/example/Test
   #9 = NameAndType        #11:#12        // num:I
  #10 = Utf8               org/example/Test
  #11 = Utf8               num
  #12 = Utf8               I
  #13 = Methodref          #8.#3          // org/example/Test."<init>":()V
  #14 = Methodref          #8.#15         // org/example/Test.methodB:()V
  #15 = NameAndType        #16:#6         // methodB:()V
  #16 = Utf8               methodB
  #17 = Fieldref           #18.#19        // java/lang/System.out:Ljava/io/PrintStream;
  #18 = Class              #20            // java/lang/System
  #19 = NameAndType        #21:#22        // out:Ljava/io/PrintStream;
  #20 = Utf8               java/lang/System
  #21 = Utf8               out
  #22 = Utf8               Ljava/io/PrintStream;
  #23 = String             #24            // A
  #24 = Utf8               A
  #25 = Methodref          #26.#27        // java/io/PrintStream.println:(Ljava/lang/String;)V
  #26 = Class              #28            // java/io/PrintStream
  #27 = NameAndType        #29:#30        // println:(Ljava/lang/String;)V
  #28 = Utf8               java/io/PrintStream
  #29 = Utf8               println
  #30 = Utf8               (Ljava/lang/String;)V
  #31 = String             #32            // B
  #32 = Utf8               B
  #33 = Methodref          #8.#34         // org/example/Test.methodA:()V
  #34 = NameAndType        #35:#6         // methodA:()V
  #35 = Utf8               methodA
  #36 = Utf8               Code
  #37 = Utf8               LineNumberTable
  #38 = Utf8               LocalVariableTable
  #39 = Utf8               this
  #40 = Utf8               Lorg/example/Test;
  #41 = Utf8               main
  #42 = Utf8               ([Ljava/lang/String;)V
  #43 = Utf8               args
  #44 = Utf8               [Ljava/lang/String;
  #45 = Utf8               test
  #46 = Utf8               SourceFile
  #47 = Utf8               Test.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 字节码中methodB的Code

 0 getstatic #17		<java/lang/System.out : Ljava/io/PrintStream;>
 3 ldc #31 				<B>
 5 invokevirtual #25 	<java/io/PrintStream.println : (Ljava/lang/String;)V>
 8 aload_0
 9 invokevirtual #33 	<org/example/Test.methodA : ()V>
12 aload_0
13 dup
14 getfield #7 			<org/example/Test.num : I>
17 iconst_1
18 iadd
19 putfield #7 			<org/example/Test.num : I>
22 return

1. methodB()方法通过invokevirtual #33调用了方法A

2. 常量池中：#33 = Methodref #8.#34

   • #8 = Class #10
     • #10 = Utf8 org/example/Test，找到了类名
   • #34 = NameAndType #35:#6
     • #35 = Utf8 methodA，找到了方法名
     • #6 = Utf8 ()V，方法没有形参，返回值为void

3. 结论：通过#33，我们找到了需要调用的methodA()方法，并进行调用

方法的调用

方法绑定机制

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

• 静态链接（方法的绑定机制：早期绑定）
  • 被调用的目标方法在编译期可知，将调用方法的符号引用转换为直接引用
• 动态链接（方法的绑定机制：晚期绑定）
  • 如果在编译器无法确定，只能在程序运行期，将符号引用转换为直接引用

具体例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

class Cat extends Animal implements Huntable {

    public Cat() {
        // 1 invokespecial #1 <org/example/Animal.<init> : ()V>
        // 表现为：早期绑定
        super();
    }

    public Cat(String name) {
        // 1 invokespecial #7 <org/example/Cat.<init> : ()V>
        // 表现为：早期绑定
        this();
    }
}

public class AnimalTest {
    public void showAnimal(Animal animal) {
        // 1 invokevirtual #7 <org/example/Animal.eat : ()V>
        // 表现为：晚期绑定
        animal.eat();
    }

    public void showHunt(Huntable h) {
        // 1 invokeinterface #12 <org/example/Huntable.hunt : ()V> count 1
        // 表现为：晚期绑定
        h.hunt();
    }
}

虚方法与非虚方法

多态使用的前提：① 类的继承； ② 方法的重写

• Java中任何一个方法都具备虚函数的特征
  • 相当于C++语言中的虚函数（C++中则需要使用关键字virtual来显式定义）
• 不希望方法拥有虚函数的特征时，可以使用关键字final来标记

虚方法与非虚方法：

非虚方法

• 编译器就确定了具体的调用版本，运行时不可变
• 如：静态方法，私有方法，final方法，实例构造器，父类方法

虚方法

• 其他所有方法，都是虚方法

普通指令与动态指令

普通指令

• invokestatic：调用静态方法，(早期绑定)
• invokespecial：调用唯一确认的方法，(早期绑定)
• invokevirtual：调用虚方法，(晚期绑定，但是final方法例外)
• invokeinterface：调用接口方法，(晚期绑定)

动态指令

• invokedynamic：动态解析出需要调用的方法
  • Java7出现
  • Java8开始有用（Lambda表达式）

动态类型语言 VS 静态类型语言

• 静态类型：判断变量自身的类型
• 动态类型：变量没有类型信息，变量值才有类型信息

体验动态指令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@FunctionalInterface
interface Func {
    public boolean func(String str);
}

public class Lambda {
    public void lambda(Func func) {
        return;
    }

    public static void main(String[] args) {
        Lambda lambda = new Lambda();
        // 根据值来确认类型
        Func func = s -> {
            return true;
        };
        lambda.lambda(func);
    }
}

方法重写的本质

当我们执行对象的方法时（如果是虚方法）：

1. 对象压入操作数栈
2. 找到操作数栈顶元素的实际类型（记作C）
3. 如果C中找到与常量池中相符的方法，则进行访问权限校验
   • 通过，返回方法的直接引用，查找结束
   • 不通过，返回java.lang.IllegalAccessError异常
4. 如果找不到相符的方法，按照继承关系依次找
5. 如果最终依然找不到，抛出java.lang.AbstractMethodError异常

提升性能：

• 如果每次都要向上层找（动态分派），十分影响效率
• JVM会在类的方法区建立一个虚方法表（virtual method table）（非虚的方法不会在表中），使用索引表来代替查找。
  • 每个类都有一个虚方法表，存放虚方法的实际入口
  • 创建时间：类加载的Linking阶段。类变量初始值准备完成后，JVM会把类的方法表也初始化完毕
• 虚方法表的例子：

方法返回地址（return address）

1. 存放调用方PC寄存器的值
2. 无论有无异常，方法退出后都返回到该方法被调用的位置
   • 方法正常退出：调用方PC寄存器的下一条指令的地址，作为返回地址
   • 方法异常退出：返回地址通过异常表来确定，栈帧中不会有这部分信息
3. 方法退出其实就是当前栈帧出栈的过程
   • 需要恢复上层方法的：局部变量表，操作数栈
   • 还需：将返回值压入调用者操作数栈，设置PC寄存器
4. 正常完成和异常完成的区别在于：异常完成不会给上级调用者产生任何返回值

只有两种方式可以退出方法：

1. 正常完成出口：执行引擎遇到方法返回的字节码指令（return），会有返回值传递给上层的方法调用者
   • 返回不同类型的值，字节码指令不同：
     • ireturn（boolean，byte，char，short，int）
     • lreturn
     • freturn
     • dreturn
     • areturn
     • return（void，实例初始化方法，类和接口初始化方法）
2. 异常完成出口：方法执行过程中遇到了异常，且方法内无法处理
   • 异常处理，存储在一个异常处理表中，方便在发生异常的时候找到处理异常的代码

4-16行字节码出了异常，就按照19行字节码指令进行处理，针对任何异常类型

栈帧中的一些附加信息

栈帧中允许携带与Java虚拟机实现相关的一些附加信息。如：对程序调试提供支持的信息

虚拟机栈的5道面试题

举例栈溢出的情况？

• StackOverflowError，可以通过-Xss设置栈的大小

调整栈大小，就能保证不溢出吗？

• 不能，比如以前递归5000次StackOverflowError，现在调大栈的大小，可能7000次才会StackOverflowError。调大只会保证出现晚一些，无法一定保证不会溢出

分配的栈内存越大越好吗？

• 不是的，会挤占其他的内存空间（比如影响线程的数量）

垃圾回收是否会涉及到虚拟机栈？

• 不涉及

方法中定义的局部变量是否线程安全？

• 如果对象在方法内部产生，内部消亡，则是线程安全的；反之线程不安全

1
2
3
4
5
6

// s1是线程安全的（只在方法内部用了）
public static void method1(){
    StringBuilder s1 = new StringBuilder();
    s1.append("a");
    s1.append("b");
}

1
2
3
4
5

// s1是线程不安全的（作为参数传进来，可能被其它线程操作）
public static void method2(StringBuilder s1){
    s1.append("a");
    s1.append("b");
}

1
2
3
4
5
6
7

// s1是线程不安全的（有返回值，可能被其它线程操作）
public static StringBuilder method3(){
    StringBuilder s1 = new StringBuilder();
    s1.append("a");
    s1.append("b");
    return s1;
}

1
2
3
4
5
6
7

// s1是线程安全的（s1自己消亡了，最后返回的只是s1.toString的一个新对象）
public static String method4(){
    StringBuilder s1 = new StringBuilder();
    s1.append("a");
    s1.append("b");
    return s1.toString();
}

本地方法接口

什么是本地方法

Native Method：Java调用非Java代码接口，初衷是融合C/C++程序

1
2
3
4
5
6
7
8
9
10

public class IHaveNatives {
    // 除了不能用abstract修饰，其他关键词都可以用
	public native void native1(int x);
    
    public native static long native2();
    
    private native synchronized float native3(Object o);
    
    native void native4(int[] ary) throws Exception;
}

为什么要使用本地方法

• 与Java环境外的交互

  有时Java应用需要与Java外面的环境交互，这是本地方法存在的主要原因

• 与操作系统的交互

  通过使用本地方法，我们得以用Java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用C写的

• Sun’s Java

  Sun的解释器是用C实现的，这使得它能像一些普通的C一样与外部交互

目前该方法使用越来越少了，除非是与硬件相关的应用。异构领域间通信很发达，可以使用Socket通信，也可以使用Web Service等

本地方法栈的理解

本地方法栈：

• 管理本地方法的调用，也是线程私有的

• 允许被设为固定大小的或可动态扩展的

  • 固定大小，超过本地方法栈最大容量：StackOverflowError异常
  • 动态扩展，创建或扩展时没有足够的内存：OutOfMemoryError异常

假如我们调用一个Java方法，方法栈帧会被压入Java虚拟机栈中；

如果我们需要调用本地方法了，本地方法的栈帧会被压入到本地方法栈中，执行引擎通过动态链接的方式调用C的相关的库

当某一线程调用本地方法时，就进入了一个全新的不受虚拟机限制的世界。他和虚拟机有同样的权限

• 访问虚拟机内部的运行时数据
• 世界使用本地处理器的寄存器
• 直接从本地内存的堆中分配任意大小内存

并不是所有JVM都支持本地方法

• Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构

在Hotspot JVM中，直接将本地方法栈和虚拟机栈合二为一

堆

堆的核心概念

1. 一个JVM实例（进程）只有一个堆内存，是Java内存管理的核心区域
2. 在JVM启动时就被创建，空间大小就已确定
   • 堆空间大小可以调节
3. 堆可以处于物理上不连续的内存空间中，但逻辑上它被视作连续的
4. 所有线程共享Java堆，还可以划分线程私有缓冲区（Thread Local Allocation Buffer，TLAB）
5. （几乎）所有的对象和数组，都分配在堆上
6. 方法结束后，堆中的对象不会立刻移除，仅在垃圾回收时移除
7. 堆，是GC（Garbage Collection，垃圾回收器）执行垃圾回收的重点区域

可视化工具

启动一个JVM实例

1
2
3
4
5
6
7
8
9
10
11
12

// 虚拟机参数：-Xms10m -Xmx10m
public class HeapDemo1 {
    public static void main(String[] args) {
        System.out.println("start");
        try {
            Thread.sleep(100000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("end");
    }
}

JDK14之后，已不再集成visualvm，手动安装

Eden Space + Survivor 0 + Survivor 1 + Old Gen就是我们堆空间的大小

内存细分

Java7及之前：

• 新生代，老年代，永久代

Java8及以后

1. 新生代（New Gen）

   • Eden Space

   • Survivor 0

   • Survivor 1

2. 老年代（Old Gen）

3. 元空间（MetaSpace）

设置堆内存大小与OOM

设置大小

• -Xms：堆起始内存大小，等价于-XX:InitialHeapSize
• -Xmx：堆最大内存大小，等价于-XX:MaxHeapSize
  • 堆超过此大小，会报OutOfMemoryError错误

通常，会将这两个值设为一样。以便在GC完成后不需要重新分隔堆区的大小，提高性能

默认情况下：初始内存大小=物理内存大小 / 64；最大内存大小=物理内存大小 / 4

查看大小

代码查看一下大小

（我的电脑内存40GB）

1
2
3
4
5

long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;	// 初始大小
long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;		// 最大大小

System.out.println("-Xms : " + initialMemory + "M");	// 640M
System.out.println("-Xmx : " + maxMemory + "M");		// 10168M

命令行查看大小

jps：查看java进程

jstat -gc <进程id>：查看进程中内存使用情况

1
2
3
4
5
6
7
8

SOC: S0区总共容量
S1C: S1区总共容量
S0U: S0区使用的量
S1U: S1区使用的量
EC: 伊甸园区总共容量
EU: 伊甸园区使用的量
OC: 老年代总共容量
OU: 老年代使用的量

有个细节：S0和S1之间只能二选一，算总量的时候应该：S0C（或者S1C） + EC + OC

虚拟机选项查看大小

-XX:+PrintGCDetails

OOM举例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class HeapDemo1 {
    public static void main(String[] args) throws InterruptedException {
        ArrayList<Picture> list = new ArrayList<>();
        while (true) {
            Thread.sleep(5);
            list.add(new Picture(new Random().nextInt(1024 * 1024)));
        }
    }
}

class Picture {
    private byte[] pixels;

    public Picture(int length) {
        this.pixels = new byte[length];
    }
}

年轻代与老年代

• 存储在JVM中的数据分为两类：

  • 一类生命周期较短，创建和消亡都非常迅速

  • 另一类生命周期非常长，甚至可能和JVM生命周期一致

• Java堆进一步细分，可以划分为：年轻代（YoungGen）和老年代（OldGen）

  • 年轻代可以继续细分为：Eden空间，Survivor0空间，Survivor1空间
  • 年轻代内部比例：8 : 1 : 1

• （几乎）所有Java对象都在Eden区被new出来

  • 比如：Eden空间装不下…

• 绝大多数Java对象都是在新生代销毁的（IBM研究80%都是）

相关虚拟机选项

一般不会调整

设置新生代空间大小：

• -Xmn50m：如果和下面设置比例的选项冲突，还是优先使用它

年轻代与老年代比例：

• 默认：-XX:NewRatio=2，表示新生代占1，老年代占2（新生代占1/3）

• 可以修改：-XX:NewRatio=2，表示新生代占1，老年代占4（新生代占1/5）

年轻代内部比例：

• 默认：-XX:SurvivorRatio=8，表示8 : 1 : 1（但未必一定是这个比例，因为有自适应策略）

使用自适应的内存比例：

• 默认使用：-XX:+UseAdaptiveSizePolicy
• 关闭策略：-XX:-UseAdaptiveSizePolicy

图解对象分配过程

具体过程

1. new对象先放伊甸园区
2. 如果伊甸园区满了，进行垃圾回收：
   • 将进行Minor GC，不被引用的对象将被销毁
   • 幸存的对象移动到S0中
3. 下一次伊甸园满了，进行垃圾回收时：
   • 这一次幸存的对象移动到S1中
   • S0中也进行垃圾回收，幸存的也移动到S1中
4. 每进入一次垃圾回收，幸存者age加一
5. 在从S0->S1或者S1->S0过程中，如果age达到阈值（默认15），会进入老年区（promotion，晋升）
   • 可以设置参数：-XX:MaxTenuringThreshold=15

注意：

伊甸园区满的时候：会触发伊甸园区和幸存者区的垃圾回收

特殊情况

• 伊甸园放得下：分配内存
• 伊甸园放不下：触发Minor GC
  • 幸存者区放得下：放置在S0或S1，达到阈值的对象晋升老年代
  • 幸存者区放不下：直接放到老年代
• 伊甸园依然放不下（超大对象）：直接放到老年代
  • 老年代放不下：触发Major GC
  • 老年代依然放不下：OOM

Minor GC、Major GC、Full GC

GC的分类

部分收集（Partial GC）：

• Minor GC：只是新生代（Eden，S0，S1）的垃圾回收

• Major GC：只是老年代的垃圾回收

  • 目前，只有CMS GC会有单独收集老年代的行为
  • 目前，很多时候Major GC会和Full GC混淆使用，需要具体区分是老年代回收还是整堆回收

• Mixed GC：整个新生代以及部分老年代的垃圾回收

  • 目前，只有G1 GC会有这种行为

整堆收集（Full GC）：

• Full GC：整个Java堆和方法区的垃圾收集

Minor GC的触发机制

• Eden满了触发，Survivor满了不会引发GC
• Minor GC触发频率非常高，回收速度也很快
• Minor GC会引发STW（Stop The World），暂停其他用户的线程，等垃圾回收结束才会恢复

Major GC的触发条件

• 指发生在老年代的GC，对象从老年代消失时，我们说”Major GC“或”Full GC“发生了

• 出现Major GC，经常伴随至少一次的Minor GC

  • 但并非绝对的，Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略
    • 也即：老年代空间不足时，先尝试触发Minor GC，空间还是不足才触发Major GC

• Major GC的速度比Minor GC慢10倍以上，STW时间更长

• Major GC后内存还是不足，报OOM

Full GC的触发条件

• 调用System.gc()，系统建议执行Full GC，但不必然执行
• 老年代空间不足
• 方法区空间不足

由于暂停时间长，应当尽量避免Full GC / Major GC

GC举例与日志分析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// -Xms9m -Xmx9m -XX:+PrintGCDetails
// JDK17使用 -Xms9m -Xmx9m -XX:+UseParallelGC -Xlog:gc*
public class GCTest {
    public static void main(String[] args) {
        int i = 0;
        try {
            List<String> list = new ArrayList<>();
            String a = "atguigu.com";
            while (true) {
                list.add(a);
                a = a + a;
                i++;
            }

        } catch (Throwable t) {
            t.printStackTrace();
            System.out.println("遍历次数为：" + i);
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# JDK17的结果

GC(4) Pause Full (Allocation Failure)
GC(4) PSYoungGen: 0K(2560K)->0K(2560K) Eden: 0K(2048K)->0K(2048K) From: 0K(512K)->0K(512K)
GC(4) ParOldGen: 6498K(7168K)->6492K(7168K)
GC(4) Metaspace: 523K(704K)->523K(704K) NonClass: 490K(576K)->490K(576K) Class: 33K(128K)->33K(128K)
GC(4) Pause Full (Allocation Failure) 6M->6M(9M) 3.082ms
GC(4) User=0.00s Sys=0.00s Real=0.00s
遍历次数为：18
Heap
PSYoungGen      total 2560K, used 339K
eden space 2048K, 16% used
from space 512K, 0% used
to   space 512K, 0% used
ParOldGen       total 7168K, used 6492K
object space 7168K, 90% used
Metaspace       used 778K, committed 896K, reserved 1056768K
class space    used 63K, committed 128K, reserved 1048576K

堆空间分代思想

为什么要把Java堆分代？

• 分代的唯一理由就是优化GC性能

• 经研究，70%-99%的对象是临时对象

  • 将朝生夕死的对象进行回收，能腾出大量的空间

• 如果没有分代，GC需要对堆的所有区域进行扫描

总结–内存分配策略

1. 如果对象在Eden出生并经过第一次Minor GC后仍然存活，且能被Survivor容纳，将被移动到Survivor空间中，年龄设为1。
2. 对象在Survivor区中每熬过一次MinorGC，年龄就增加1。当它的年龄增加到一定程度（默认为15岁，其实每个JVM、每个GC都有所不同），就会被晋升到老年代
3. 晋升老年代的阀值，可以通过选项**-XX:MaxTenuringThreshold**来设置

针对不同年龄段的对象分配原则：

• 优点分配到Eden
• 大对象直接分配到老年代
  • Eden都放不下了
• 长期存活的对象分配到老年代
  • 年龄超过阈值的对象
• 动态年龄判断（特例）
  • 如果Survivor区中相同年龄的对象大小的总和，大于Survivor空间的一半。年龄大于等于该年龄的对象可以直接进入老年代，无需达到阈值
  • 避免S0和S1反复倒来倒去
• 空间分配担保
  • -XX:HandlePromptFailure（后面参数设置部分有讲）

补充–为对象分配内存：TLAB

TLAB：Thread Local Allocation Buffer

为什么有TLAB：

• 堆区是线程共享区域
• 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度

什么是TLAB：

• JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内
• 多线程分配内存时，可以避免一系列线程安全问题，还能提升内存分配吞吐量，这种内存分配方式称之为快速分配策略
• 几乎所有OpenJDK衍生出来的JVM都提供了TLAB的设计
• 当一个线程TLAB存满时，可以使用公共（蓝色）区域

TLAB的一些说明：

• 不是所有的对象都能够在TLAB中成功分配内存，但JVM将TLAB作为内存分配的首选
• -XX:+UseTLAB设置是否开启TLAB空间（默认开启）
• 默认仅占Eden空间的1%，可以通过选项-XX:TLABWasteTargetPercent设置百分比大小
• 如果在TLAB空间分配内存失败，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，直接在Eden空间中分配内存

总结：TLAB分配过程

小结–参数设置

官方文档：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

什么是空间分配担保

Minor GC之前，JVM会检查老年代最大可用的连续空间，是否大于新生代所有对象的总空间

如果大于，此次GC是安全的

如果小于：

• 如果HandlePromotionFailure=true，继续检查老年代最大可用连续空间是否大于历次晋升到老年代的平均大小
  • 如果大于，则尝试进行一次Minor GC，这次GC仍然是有风险的
  • 如果小于，则进行一次Full GC
• 如果HandlePromotionFailure=false，则进行一次Full GC

jdk7之后，这个参数已经失效了

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

也即默认为true

具体查看某个参数的指令：

jps：查看当前运行的进程

jinfo -flag SurvivorRatio 进程id：查看某个参数的值

逃逸分析

堆是分配对象唯一选择吗？在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述：

1. 随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
2. 在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过逃逸分析（Escape Analysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。
3. 此外，前面提到的基于OpenJDK深度定制的TaoBao VM，其中创新的GCIH（GC invisible heap）技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。

什么是逃逸分析

1. 将堆上的对象分配到栈，需要使用逃逸分析手段。
2. 这是一种可以有效减少Java程序中，同步负载和内存堆分配压力的，跨函数全局数据流分析算法。
3. 通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围，从而决定是否要将这个对象分配到堆上。
4. 逃逸分析的基本行为就是分析对象动态作用域：
   • 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
   • 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。

逃逸举例

1. 没有发生逃逸，可以分配到栈上。方法执行结束，栈空间就被移除（无需GC）

1
2
3
4
5
6

public void my_method() {
    V v = new V();
    // use v
    // ....
    v = null;
}

2. StringBuffer sb 发生了逃逸，不能在栈上分配

1
2
3
4
5
6

public static StringBuffer createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb;
}

3. 想要StringBuffer sb不发生逃逸，进行优化

1
2
3
4
5
6

public static String createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString();
}

参数设置：

• 在JDK 1.7 版本之后，HotSpot中默认就已经开启了逃逸分析

• -XX:+DoEscapeAnalysis：显式开启逃逸分析

• -XX:+PrintEscapeAnalysis：查看逃逸分析的筛选结果

总结：能使用局部变量，就不要在方法外部定义

代码优化

栈上分配

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// -Xmx128m -Xms128m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
public class StackAllocation {
    public static void main(String[] args) throws InterruptedException {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            alloc();
        }
        // 查看执行时间
        long end = System.currentTimeMillis();
        System.out.println("花费的时间为： " + (end - start) + " ms");
        
        // 为了方便查看堆内存中对象个数，线程sleep
        Thread.sleep(1000000);
    }

    private static void alloc() {
        User user = new User(); // 未发生逃逸
    }

    static class User {

    }
}

• -XX:-DoEscapeAnalysis关闭逃逸分析，进行了垃圾回收，速度较慢

1
2
3
4
5

[GC (Allocation Failure) [PSYoungGen: 33280K->872K(38400K)] 33280K->880K(125952K), 0.0013246 secs]
[GC (Allocation Failure) [PSYoungGen: 34152K->808K(38400K)] 34160K->816K(125952K), 0.0007481 secs]
[GC (Allocation Failure) [PSYoungGen: 34088K->808K(38400K)] 34096K->816K(125952K), 0.0010414 secs]
[GC (Allocation Failure) [PSYoungGen: 34088K->840K(38400K)] 34096K->848K(125952K), 0.0005889 secs]
# 花费的时间为： 27 ms

-XX:+DoEscapeAnalysis开启逃逸分析，没有进行垃圾回收，速度快很多

1

# 花费的时间为： 2 ms

同步省略

• 如果一个对象被发现只能从一个线程中被访问到，那么对于这个对象的操作可以不考虑同步

• 在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程

• 如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除

例如，下面的代码

1
2
3
4
5
6

public void f() {
    Object hollis = new Object();
    synchronized(hollis) {
        System.out.println(hollis);
    }
}

但是hollis对象的生命周期只在方法中，并不会被其他线程所访问到。在JIT编译阶段会被优化掉，优化成：

1
2
3
4

public void f() {
    Object hellis = new Object();
	System.out.println(hellis);
}

通过反编译字节码可以看到，依然有加锁（monitorenter，monitorexit），同步省略操作是在解释运行时发生的

标量替换

• 标量（scalar）是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量

• 相对的，那些还可以分解的数据叫做聚合量（Aggregate），Java中的对象就是聚合量，因为他可以分解成其他聚合量和标量

• 在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换

代码举例

1
2
3
4
5
6
7
8
9

private static void alloc() {
    Point point = new Point(1,2);
    System.out.println("point.x" + point.x + ";point.y" + point.y);
}

class Point {
    private int x;
    private int y;
}

以上代码，经过标量替换后，就会变成

1
2
3
4
5

private static void alloc() {
    int x = 1;
    int y = 2;
    System.out.println("point.x = " + x + "; point.y=" + y);
}

Point经过逃逸分析后，发现他并没有逃逸，就被替换成两个聚合量了。不再需要分配堆内存，大大减少堆内存的占用。

实际测试

-XX:+ElimilnateAllocations：是否开启标量替换（默认打开）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations
public class ScalarReplace {
    public static class User {
        public int id;
        public String name;
    }

    public static void alloc() {
        User u = new User(); // 未发生逃逸
        u.id = 5;
        u.name = "www.atguigu.com";
    }

    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println("花费的时间为： " + (end - start) + " ms");
    }
}

• -XX:-ElimilnateAllocations：关闭标量替换，进行了垃圾回收

1
2
3
4
5
6
7
8
9

[GC (Allocation Failure)  25600K->944K(98304K), 0.0008014 secs]
[GC (Allocation Failure)  26544K->864K(98304K), 0.0007089 secs]
[GC (Allocation Failure)  26464K->848K(98304K), 0.0008019 secs]
[GC (Allocation Failure)  26448K->912K(98304K), 0.0007006 secs]
[GC (Allocation Failure)  26512K->864K(98304K), 0.0006461 secs]
[GC (Allocation Failure)  26464K->816K(101376K), 0.0007875 secs]
[GC (Allocation Failure)  32560K->712K(100864K), 0.0005971 secs]
[GC (Allocation Failure)  32456K->712K(100864K), 0.0008559 secs]
花费的时间为： 43 ms

• -XX:+ElimilnateAllocations：开启标量替换，未进行垃圾回收

1

# 花费的时间为： 3 ms

逃逸分析并不成熟

关于逃逸分析的论文在1999年就已经发表了，但直到JDK1.6才有实现，而且这项技术到如今也并不是十分成熟。

其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。

一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。

虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。

注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象（no），这在理论上是可行的，但是取决于JVM设计者的选择。据我所知，Oracle Hotspot JVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。

目前很多书籍还是基于JDK7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是，intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。

本章小结

• 年轻代是对象的诞生、成长、消亡的区域，一个对象在这里产生、应用，最后被垃圾回收器收集、结束生命。

• 老年代放置长生命周期的对象，通常都是从Survivor区域筛选拷贝过来的Java对象。当然，也有特殊情况，我们知道普通的对象可能会被分配在TLAB上；如果对象较大，无法分配在 TLAB 上，则JVM会试图直接分配在Eden其他位置上；如果对象太大，完全无法在新生代找到足够长的连续空闲空间，JVM就会直接分配到老年代。

• 当GC只发生在年轻代中，回收年轻代对象的行为被称为Minor GC。当GC发生在老年代时则被称为Major GC或者Full GC。一般的，Minor GC的发生频率要比Major GC高很多，即老年代中垃圾回收发生的频率将大大低于年轻代。

方法区

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

从线程共享与否来看

从代码角度来看

方法区的理解

官方文档：https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.5.4

• 可以看作是，一块独立于Java堆的内存空间

• 方法区主要存放Class，堆主要存放实例化的对象

• 方法区在JVM启动的时候被创建，它的实际的物理内存和Java堆区一样，都可以是不连续的

• 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展

• 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，JVM同样会抛出OOM

  • JDK8以前：java.lang.OutofMemoryError:PermGen space

  • JDK8及以后：java.lang.OutOfMemoryError:Metaspace

  • 加载大量的第三方的jar包

  • Tomcat部署的工程过多（30~50个）

  • 大量动态的生成反射类

• 关闭JVM就会释放这个区域的内存

Hotspot中方法区的演进

• JDK8之前，习惯上把方法区称为永久代。JDK8开始使用元空间取代了永久代
  • 现在来看，使用永久代并不是好的做法，容易导致程序OOM（超过XX:MaxPermSize上限）
• 永久代/元空间，都是对JVM规范中方法区的实现。区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存

设置方法区大小与OOM

方法区的大小不必是固定的，JVM可以根据应用的需要动态调整

JDK8及以后（元空间）

• 元空间大小由-XX:MetaspaceSize和-XX:MaxMetaspaceSize指定
  • 默认值依赖于平台，windows 64位下：
  • MetaspaceSize约为21MB
  • MaxMetaspaceSize值为-1，即没有限制
• 默认情况下，JVM会耗尽所有的可用系统内存。如果元数据区发生溢出，JVM会抛出异常OutOfMemoryError:Metaspace
• 对一个64位的服务器端JVM来说，元空间初始大小一般为21MB。
  • 一旦触及这个水位线，Full GC将触发并卸载没用的类。这个高水位线将被重置。
  • 如果释放的空间不足，会适当提高该值
  • 如果释放的空间过多，则适当降低改值
• 为避免频繁GC，建议将-XX:MetaspaceSize设置为一个相对较高的值

方法区OOM代码举例

方法一：借助CGLib使得方法区出现内存溢出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
public class JavaMethodAreaOOM {
    public static void main(String[] args) {
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(OOMObject.class);
            enhancer.setUseCache(false);
            enhancer.setCallback(new MethodInterceptor() {
                @Override
                public Object intercept(Object obj, 
                                        Method method, 
                                        Object[] args, 
                                        MethodProxy proxy) throws Throwable {
                    return proxy.invokeSuper(obj, args);
                }
            });
            enhancer.create();
        }
    }
    
    static class OOMObject {
        
    }
}

方法二：使用二进制字节码来定义类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
public class OOMTest extends ClassLoader {
    public static void main(String[] args) {
        int j = 0;
        try {
            OOMTest test = new OOMTest();
            for (int i = 0; i < 10000; i++) {
                //创建ClassWriter对象，用于生成类的二进制字节码
                ClassWriter classWriter = new ClassWriter(0);
                //指明版本号，修饰符，类名，包名，父类，接口
                classWriter.visit(Opcodes.V1_8, 
                                  Opcodes.ACC_PUBLIC, 
                                  "Class" + i, 
                                  null, 
                                  "java/lang/Object", 
                                  null);
                //返回byte[]
                byte[] code = classWriter.toByteArray();
                //类的加载
                test.defineClass("Class" + i, code, 0, code.length);//Class对象
                j++;
            }
        } finally {
            System.out.println(j);
        }
    }
}

如何解决OOM

这个属于调优的问题，这里先简单的说一下

1. 要解决OOM异常或heap space的异常，一般的手段是首先通过内存映像分析工具（如Eclipse Memory Analyzer）对dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）

   • 内存泄漏：大量的引用指向某些对象，但是这些对象以后不会使用了。但是因为它们还和GC ROOT有关联，所以导致以后这些对象也不会被回收

   • 内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息，以及GC Roots引用链的信息，就可以比较准确地定位出泄漏代码的位置。

   • 如果不存在内存泄漏（对象确实都还必须存活），那就应当检查虚拟机的堆参数（-Xmx与-Xms），与机器物理内存对比看是否还可以调大。从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

方法区的内部结构

《深入理解Java虚拟机》书中对方法区（Method Area）存储内容描述如下：

• 它用于存储已被虚拟机加载的类型信息、常量、静态变量、JIT编译器编译后的代码缓存等

类型(class)信息

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

1. 完整名称（包名.类名）
2. 直接父类的完整有效名（interface或java.lang.Object都没有父类）
3. 类型的修饰符（public，abstract，final的某个子类）
4. 实现接口的有序列表

域(Field)信息

也即成员变量

1. 所有域的相关信息
   • 名称
   • 类型
   • 修饰符（public，private，protected，static，final，volatile，transient的某个子集）
2. 域的声明顺序

方法(Method)信息

1. 名称
2. 返回类型（包括void，void.class）
3. 参数的数量和类型（按顺序）
4. 方法的修饰符（public，private，protected，static，final，synchronized，native，abstract的一个子集）
5. 方法的字节码，操作数栈大小，局部变量表（abstract和native方法除外）
6. 异常表（abstract和native方法除外）
   • 记录每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引

举例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class MethodInnerStrucTest extends Object implements Comparable<String>, Serializable {
    // 属性
    public int num = 10;
    private static String str = "测试方法的内部结构";

    // 构造器（没有显示声明），方法
    public void test1() {
        int count = 20;
        System.out.println("count = " + count);
    }

    public static int test2(int cal) {
        int result = 0;
        try {
            int value = 30;
            result = value / cal;
        } catch (Exception e) {
            e.printStackTrace();
        }
        return result;
    }

    @Override
    public int compareTo(String o) {
        return 0;
    }
}

javap -v -p MethodInnerStrucTest.class > test.txt

• 反编译字节码文件，并输出值到文本文件中，便于查看。参数-p确保能查看private权限类型的字段或方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238

Classfile /C:/Users/xdy/Desktop/learn-jvm/target/classes/org/example/methodArea/MethodInnerStrucTest.class
  Last modified 2023年10月11日; size 1638 bytes
  SHA-256 checksum 411f5a2ceaa376e17b1e5b2e2102ccb64862c8356379cc9f5684cd6242c20cd9
  Compiled from "MethodInnerStrucTest.java"
################################# 类型信息：修饰符，全类名，直接父类，实现的接口 #################################
public class org.example.methodArea.MethodInnerStrucTest extends java.lang.Object implements java.lang.Comparable<java.lang.String>, java.io.Serializable
  minor version: 0
  major version: 52
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #17                         // org/example/methodArea/MethodInnerStrucTest
  super_class: #18                        // java/lang/Object
  interfaces: 2, fields: 2, methods: 6, attributes: 2
Constant pool:
   #1 = Methodref          #18.#52        // java/lang/Object."<init>":()V
   #2 = Fieldref           #17.#53        // org/example/methodArea/MethodInnerStrucTest.num:I
   #3 = Fieldref           #54.#55        // java/lang/System.out:Ljava/io/PrintStream;
   #4 = Class              #56            // java/lang/StringBuilder
   #5 = Methodref          #4.#52         // java/lang/StringBuilder."<init>":()V
   #6 = String             #57            // count =
   #7 = Methodref          #4.#58         // java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   #8 = Methodref          #4.#59         // java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
   #9 = Methodref          #4.#60         // java/lang/StringBuilder.toString:()Ljava/lang/String;
  #10 = Methodref          #61.#62        // java/io/PrintStream.println:(Ljava/lang/String;)V
  #11 = Class              #63            // java/lang/Exception
  #12 = Methodref          #11.#64        // java/lang/Exception.printStackTrace:()V
  #13 = Class              #65            // java/lang/String
  #14 = Methodref          #17.#66        // org/example/methodArea/MethodInnerStrucTest.compareTo:(Ljava/lang/String;)I
  #15 = String             #67            // 测试方法的内部结构
  #16 = Fieldref           #17.#68        // org/example/methodArea/MethodInnerStrucTest.str:Ljava/lang/String;
  #17 = Class              #69            // org/example/methodArea/MethodInnerStrucTest
  #18 = Class              #70            // java/lang/Object
  #19 = Class              #71            // java/lang/Comparable
  #20 = Class              #72            // java/io/Serializable
  #21 = Utf8               num
  #22 = Utf8               I
  #23 = Utf8               str
  #24 = Utf8               Ljava/lang/String;
  #25 = Utf8               <init>
  #26 = Utf8               ()V
  #27 = Utf8               Code
  #28 = Utf8               LineNumberTable
  #29 = Utf8               LocalVariableTable
  #30 = Utf8               this
  #31 = Utf8               Lorg/example/methodArea/MethodInnerStrucTest;
  #32 = Utf8               test1
  #33 = Utf8               count
  #34 = Utf8               test2
  #35 = Utf8               (I)I
  #36 = Utf8               value
  #37 = Utf8               e
  #38 = Utf8               Ljava/lang/Exception;
  #39 = Utf8               cal
  #40 = Utf8               result
  #41 = Utf8               StackMapTable
  #42 = Class              #63            // java/lang/Exception
  #43 = Utf8               compareTo
  #44 = Utf8               (Ljava/lang/String;)I
  #45 = Utf8               o
  #46 = Utf8               (Ljava/lang/Object;)I
  #47 = Utf8               <clinit>
  #48 = Utf8               Signature
  #49 = Utf8               Ljava/lang/Object;Ljava/lang/Comparable<Ljava/lang/String;>;Ljava/io/Serializable;
  #50 = Utf8               SourceFile
  #51 = Utf8               MethodInnerStrucTest.java
  #52 = NameAndType        #25:#26        // "<init>":()V
  #53 = NameAndType        #21:#22        // num:I
  #54 = Class              #73            // java/lang/System
  #55 = NameAndType        #74:#75        // out:Ljava/io/PrintStream;
  #56 = Utf8               java/lang/StringBuilder
  #57 = Utf8               count =
  #58 = NameAndType        #76:#77        // append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
  #59 = NameAndType        #76:#78        // append:(I)Ljava/lang/StringBuilder;
  #60 = NameAndType        #79:#80        // toString:()Ljava/lang/String;
  #61 = Class              #81            // java/io/PrintStream
  #62 = NameAndType        #82:#83        // println:(Ljava/lang/String;)V
  #63 = Utf8               java/lang/Exception
  #64 = NameAndType        #84:#26        // printStackTrace:()V
  #65 = Utf8               java/lang/String
  #66 = NameAndType        #43:#44        // compareTo:(Ljava/lang/String;)I
  #67 = Utf8               测试方法的内部结构
  #68 = NameAndType        #23:#24        // str:Ljava/lang/String;
  #69 = Utf8               org/example/methodArea/MethodInnerStrucTest
  #70 = Utf8               java/lang/Object
  #71 = Utf8               java/lang/Comparable
  #72 = Utf8               java/io/Serializable
  #73 = Utf8               java/lang/System
  #74 = Utf8               out
  #75 = Utf8               Ljava/io/PrintStream;
  #76 = Utf8               append
  #77 = Utf8               (Ljava/lang/String;)Ljava/lang/StringBuilder;
  #78 = Utf8               (I)Ljava/lang/StringBuilder;
  #79 = Utf8               toString
  #80 = Utf8               ()Ljava/lang/String;
  #81 = Utf8               java/io/PrintStream
  #82 = Utf8               println
  #83 = Utf8               (Ljava/lang/String;)V
  #84 = Utf8               printStackTrace
{
################################# 域信息 #################################
  public int num;
    descriptor: I
    flags: (0x0001) ACC_PUBLIC

  private static java.lang.String str;
    descriptor: Ljava/lang/String;
    flags: (0x000a) ACC_PRIVATE, ACC_STATIC
#################### 方法信息（包括构造器），操作数栈大小，参数数量，局部变量表，异常表 ####################
  public org.example.methodArea.MethodInnerStrucTest();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: aload_0
         5: bipush        10
         7: putfield      #2                  // Field num:I
        10: return
      LineNumberTable:
        line 13: 0
        line 15: 4
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      11     0  this   Lorg/example/methodArea/MethodInnerStrucTest;

  public void test1();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=3, locals=2, args_size=1
         0: bipush        20
         2: istore_1
         3: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
         6: new           #4                  // class java/lang/StringBuilder
         9: dup
        10: invokespecial #5                  // Method java/lang/StringBuilder."<init>":()V
        13: ldc           #6                  // String count =
        15: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        18: iload_1
        19: invokevirtual #8                  // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
        22: invokevirtual #9                  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        25: invokevirtual #10                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        28: return
      LineNumberTable:
        line 20: 0
        line 21: 3
        line 22: 28
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      29     0  this   Lorg/example/methodArea/MethodInnerStrucTest;
            3      26     1 count   I

  public static int test2(int);
    descriptor: (I)I
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=1
         0: iconst_0
         1: istore_1
         2: bipush        30
         4: istore_2
         5: iload_2
         6: iload_0
         7: idiv
         8: istore_1
         9: goto          17
        12: astore_2
        13: aload_2
        14: invokevirtual #12                 // Method java/lang/Exception.printStackTrace:()V
        17: iload_1
        18: ireturn
      Exception table:
         from    to  target type
             2     9    12   Class java/lang/Exception
      LineNumberTable:
        line 25: 0
        line 27: 2
        line 28: 5
        line 31: 9
        line 29: 12
        line 30: 13
        line 32: 17
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            5       4     2 value   I
           13       4     2     e   Ljava/lang/Exception;
            0      19     0   cal   I
            2      17     1 result   I
      StackMapTable: number_of_entries = 2
        frame_type = 255 /* full_frame */
          offset_delta = 12
          locals = [ int, int ]
          stack = [ class java/lang/Exception ]
        frame_type = 4 /* same */

  public int compareTo(java.lang.String);
    descriptor: (Ljava/lang/String;)I
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=2, args_size=2
         0: iconst_0
         1: ireturn
      LineNumberTable:
        line 37: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       2     0  this   Lorg/example/methodArea/MethodInnerStrucTest;
            0       2     1     o   Ljava/lang/String;

  public int compareTo(java.lang.Object);
    descriptor: (Ljava/lang/Object;)I
    flags: (0x1041) ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: aload_1
         2: checkcast     #13                 // class java/lang/String
         5: invokevirtual #14                 // Method compareTo:(Ljava/lang/String;)I
         8: ireturn
      LineNumberTable:
        line 13: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       9     0  this   Lorg/example/methodArea/MethodInnerStrucTest;

  static {};
    descriptor: ()V
    flags: (0x0008) ACC_STATIC
    Code:
      stack=1, locals=0, args_size=0
         0: ldc           #15                 // String 测试方法的内部结构
         2: putstatic     #16                 // Field str:Ljava/lang/String;
         5: return
      LineNumberTable:
        line 16: 0
}
Signature: #49                          // Ljava/lang/Object;Ljava/lang/Comparable<Ljava/lang/String;>;Ljava/io/Serializable;
SourceFile: "MethodInnerStrucTest.java"

final static类变量

1
2
3
4

class Order {
    public static int count = 1;
    public static final int number = 2;
}

• 静态类变量和类关联在一起，随着类的加载而加载（clinit赋值），被所有实例共享

• 全局常量：static final，在编译时就会被分配

1
2
3
4
5
6
7
8
9
10

# clinit时才会被赋值
public static int count;
  descriptor: I
  flags: (0x0009) ACC_PUBLIC, ACC_STATIC

# 在编译时就被赋值
public static final int number;
  descriptor: I
  flags: (0x0019) ACC_PUBLIC, ACC_STATIC, ACC_FINAL
  ConstantValue: int 2 

运行时常量池

1
2

# 【#5】就是在引用常量池
10 invokespecial #5 <java/lang/StringBuilder.<init>>

• 方法区中，包含运行时常量池

• 字节码文件中，包含常量池

常量池

• 字节码文件中，包含常量池（Constant Pool Table），包含各种字面量、对类型的符号引用、对域的符号引用、对方法的符号引用

为什么需要常量池

• 如果不用常量池，就需要在所有地方全写一遍，造成臃肿
• 需要用到的结构信息记录在常量池中，并通过引用的方式，来加载、调用所需的结构（减少代码大小）

常量池中有什么

1. 数量值
2. 字符串值
3. 类引用
4. 字段引用
5. 方法引用

运行时常量池

1. 运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池。

2. 运行时常量池就是常量池在程序运行时的称呼

3. JVM为每个已加载的类型（类或接口）都维护一个常量池

4. 运行时常量池，相对于常量池的另一重要特征是：具备动态性（String.intern）

   • 运行时常量池中包含多种不同的常量，包括：

     • 编译期就已经明确的数值字面量

     • 运行期解析后才能够获得的方法或者字段引用（此时不再是常量池中的符号地址了，这里换为真实地址）

5. 当创建类或接口的运行时常量池时，如果所需的内存超过了方法区所能提供的最大值，JVM会抛OutofMemoryError异常。

方法区使用举例

• 原始代码

1
2
3
4
5
6
7
8
9

public class MethodAreaDemo {
    public static void main(String[] args) {
        int x = 500;
        int y = 100;
        int a = x / y;
        int b = 50;
        System.out.println(a + b);
    }
}

• 字节码文件（常量池部分）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

Constant pool:
   #1 = Methodref          #5.#24         // java/lang/Object."<init>":()V
   #2 = Fieldref           #25.#26        // java/lang/System.out:Ljava/io/PrintStream;
   #3 = Methodref          #27.#28        // java/io/PrintStream.println:(I)V
   #4 = Class              #29            // org/example/methodArea/MethodAreaDemo
   #5 = Class              #30            // java/lang/Object
   #6 = Utf8               <init>
   #7 = Utf8               ()V
   #8 = Utf8               Code
   #9 = Utf8               LineNumberTable
  #10 = Utf8               LocalVariableTable
  #11 = Utf8               this
  #12 = Utf8               Lorg/example/methodArea/MethodAreaDemo;
  #13 = Utf8               main
  #14 = Utf8               ([Ljava/lang/String;)V
  #15 = Utf8               args
  #16 = Utf8               [Ljava/lang/String;
  #17 = Utf8               x
  #18 = Utf8               I
  #19 = Utf8               y
  #20 = Utf8               a
  #21 = Utf8               b
  #22 = Utf8               SourceFile
  #23 = Utf8               MethodAreaDemo.java
  #24 = NameAndType        #6:#7          // "<init>":()V
  #25 = Class              #31            // java/lang/System
  #26 = NameAndType        #32:#33        // out:Ljava/io/PrintStream;
  #27 = Class              #34            // java/io/PrintStream
  #28 = NameAndType        #35:#36        // println:(I)V
  #29 = Utf8               org/example/methodArea/MethodAreaDemo
  #30 = Utf8               java/lang/Object
  #31 = Utf8               java/lang/System
  #32 = Utf8               out
  #33 = Utf8               Ljava/io/PrintStream;
  #34 = Utf8               java/io/PrintStream
  #35 = Utf8               println
  #36 = Utf8               (I)V

• 字节码文件（main函数部分）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

public static void main(java.lang.String[]);
  descriptor: ([Ljava/lang/String;)V
  flags: (0x0009) ACC_PUBLIC, ACC_STATIC
  Code:
    stack=3, locals=5, args_size=1
       0: sipush        500
       3: istore_1
       4: bipush        100
       6: istore_2
       7: iload_1
       8: iload_2
       9: idiv
      10: istore_3
      11: bipush        50
      13: istore        4
      15: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
      18: iload_3
      19: iload         4
      21: iadd
      22: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V
      25: return
    LineNumberTable:
      line 14: 0
      line 15: 4
      line 16: 7
      line 17: 11
      line 18: 15
      line 19: 25
    LocalVariableTable:
      Start  Length  Slot  Name   Signature
          0      26     0  args   [Ljava/lang/String;
          4      22     1     x   I
          7      19     2     y   I
         11      15     3     a   I
         15      11     4     b   I

• 500放入操作数栈中

• 弹出操作数栈顶，保存到本地变量表中：位置1（因为main是静态方法，所以没有this）

• 100放入操作数栈中

• 弹出操作数栈顶元素，存入本地变量表中：位置2

• 读取本地变量1，压入操作数栈

• 读取本地变量2，压入操作数栈

• 栈顶元素运算，再放回栈顶

• 弹出操作数栈顶元素，存入本地变量表中：位置3
• 将50压入操作数栈

• 弹出操作数栈顶元素，存入本地变量表中：位置4

• 获取常量池中的变量，压入操作数栈中
  • #2 = Fieldref #25.#26 // java/lang/System.out:Ljava/io/PrintStream;
  • #25 = Class #31 // java/lang/System
  • #26 = NameAndType #32:#33 // out:Ljava/io/PrintStream;

• 将本地变量表中：位置3，位置4的元素放入操作数栈中
• 栈顶元素运算，再放回栈顶
• 调用方法，方法中的参数会从操作数栈中弹出，压入虚拟机栈；虚拟机会开始执行虚拟机栈最上面的栈帧
  • #3 = Methodref #27.#28 // java/io/PrintStream.println:(I)V

方法区的演进细节

JDK6

• 有永久代（permanent generation），静态变量存储在永久代上

• 方法区由永久代实现，使用 JVM 虚拟机内存（虚拟的内存）

JDK7

• 有永久代，但已经逐步 “去永久代”

• 字符串常量池，静态变量移除。保存在堆中

• 方法区由永久代实现，使用 JVM 虚拟机内存

JDK8

• 无永久代，类型信息、字段、方法、常量保存在本地内存的元空间

• 字符串常量池、静态变量仍然在堆中

• 方法区由元空间实现，使用物理机本地内存

永久代为什么要被元空间替代？

官方文档：http://openjdk.java.net/jeps/122

• Java8中移除了永久代。其中的元数据被移到了堆之外，元空间（MetaSpace）中
• 元空间使用物理内存，最大可用空间就是系统可用空间
• 改动原因：
  • 永久代很难确定大小。在某些场景下，如果动态加载类过多，容易产生永久代的OOM、
  • 永久代调优很困难
    • 方法区的垃圾收集主要有两部分，常量池中：废弃的常量，不再用的类型
    • 一般来说，这个区域的回收效果难令人满意，尤其是类型的卸载，条件相当苛刻

字符串常量池为什么调整位置

• JDK7中将StringTable放到了堆空间中

因为永久代的回收效率很低，在Full GC的时候才会执行永久代的垃圾回收。

而Full GC是老年代的空间不足、永久代不足时才会触发。

这就导致StringTable回收效率不高，而我们开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。

放到堆里，能及时回收内存。

静态变量放在哪里？

1
2
3
4
5
6
7

/**
 * JDK7：-Xms200m -Xmx200m -XX:PermSize=300m -XX:MaxPermSize=300m -XX:+PrintGCDetails
 * JDK8：-Xms200m -Xmx200m -XX:MetaspaceSize=300m -XX:MaxMetaspaceSize=300m -XX:+PrintGCDetails
 */
public class StaticFieldTest {
    private static byte[] arr = new byte[1024 * 1024 * 100]; // 100MB
}

• 对象实例（也就是这个new byte[1024 * 1024 * 100]）无论如何都存在堆空间

• 静态变量（这个对象）在JDK6，JDK7，JDK8存放位置中有所变化

  • JDK6：方法区中（永久代实现）
  • JDK7：堆空间中
  • JDK8：堆空间（元空间中）

方法区的垃圾回收

• 《Java虚拟机规范》对方法区的约束非常宽松，不要求JVM在方法区中实现GC。确实有未实现方法区类型卸载的收集器存在（如JDK11时期的ZGC收集器就不支持类卸载）。方法区GC效果难令人满意，尤其是类型的卸载，条件相当苛刻。
• 方法区的GC主要回收两部分，常量池中：废弃的常量、不再使用的类型

常量的回收

• 方法区内常量池之中主要存放的两大类常量：字面量和符号引用

  • 字面量：如文本字符串、被声明为final的常量值等
  • 符号引用：类和接口的全限定名、字段的名称和描述符、方法的名称和描述符

• HotSpot虚拟机，对常量池的GC策略：常量没有被任何地方引用，就可以被回收

• 回收废弃常量比较简单

类的卸载

• 判断常量是否废弃很简单，判断类型是否不再使用很困难
  • 该类所有实例（包括派生类）都被回收
  • 加载该类的类加载器已被回收（这个条件除非特殊设计，不然很难触发）
  • 该类的java.lang.Class对象没有在任何地方被引用（无法在任何地方反射访问此类）
• JVM“被允许”对无用的类进行回收（不是必然被回收），HotSpot虚拟机
  • -Xnoclassgc：不对方法区进行垃圾回收
  • -verbose:class：输出JVM载入类的相关信息
  • -XX:+TraceClassLoading：同上，监控类的加载
  • -XX:+TraceClassUnLoading：监控类的卸载
• 在大量使用：反射、动态代理、CGLib等字节码框架；动态生成JSP和OSGi等，频繁自定义类加载器的场景中，通常都需要JVM具备类型卸载的能力，以保证不会对方法区造成过大的内存压力

总结

栈帧中动态链接，指向常量池中当前方法的引用

面试题

1. 百度
   • 三面：说一下JVM内存模型吧，有哪些区？分别干什么的？
2. 蚂蚁金服：
   • Java8的内存分代改进
   • JVM内存分哪几个区，每个区的作用是什么？
   • 一面：JVM内存分布/内存结构？栈和堆的区别？堆的结构？为什么两个survivor区？
   • 二面：Eden和survior的比例分配
3. 小米：
   • jvm内存分区，为什么要有新生代和老年代
4. 字节跳动：
   • 二面：Java的内存分区
   • 二面：讲讲vm运行时数据库区
   • 什么时候对象会进入老年代？
5. 京东：
   • JVM的内存结构，Eden和Survivor比例。
   • JVM内存为什么要分成新生代，老年代，持久代。新生代中为什么要分为Eden和survivor。
6. 天猫：
   • 一面：Jvm内存模型以及分区，需要详细到每个区放什么。
   • 一面：JVM的内存模型，Java8做了什么改
7. 拼多多：
   • JVM内存分哪几个区，每个区的作用是什么？
8. 美团：
   • java内存分配
   • jvm的永久代中会发生垃圾回收吗？
   • 一面：jvm内存分区，为什么要有新生代和老年代？

实例化

对象的实例化

对象创建的方式：

1. new，最常见的方式
   • 变形1：单例类中调用静态类方法，getInstance()
   • 变形2：XxxBuilder/XxxFactory的静态方法
2. Class的newInstance()方法，使用反射
   • 必须空参，权限必须public
3. Constructor的newInstance()方法，使用反射
   • 可以带参数，权限没有要求
4. 使用clone()，不调用任何构造器，当前类需要实现Cloneable接口
5. 使用反序列化，从文件或网络中获取对象的二进制流
6. 使用第三方库（Objenesis），动态生成对象

对象创建的步骤

1. 判断对象对应的类是否：加载，链接，初始化
   • 虚拟机遇到new指令，检查能否在元空间的常量池中定位到此类的符号引用
   • 并检查此类是否已被加载、解析、初始化（类的元信息是否存在）
   • 如果没有，在双亲委派机制下，使用当前类加载器，用包名+类名为key查找对应class文件。找不到文件抛出ClassNotFoundException异常。找到了则进行类加载
2. 为对象分配内存
   • 如果内存规整：指针碰撞（Bump The Point）
     • 意思是所有用过的内存在一边，空闲的内存放另外一边，中间放着一个指针作为分界点的指示器，分配内存就仅仅是把指针往空闲内存那边挪动一段与对象大小相等的距离罢了
     • 如果垃圾收集器选择的是Serial ，ParNew这种基于压缩算法的，虚拟机采用这种分配方式
   • 如果内存不规整：空闲列表（Free List）
     • 维护一个空闲列表，记录上哪些内存块是可用的
     • 分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的内容
3. 处理并发安全问题
   • 采用CAS+失败重试，保证更新的原子性（乐观锁）
   • 每个线程预先分配TLAB，通过设置-XX:+UseTLAB参数来设置
4. 初始化分配到的空间（属性的默认初始化，零值）
5. 设置对象的对象头
   • 将对象的所属类（即类的元数据信息）、对象的HashCode和对象的GC信息、锁信息，等数据存储在对象的对象头中。这个过程的具体设置方式取决于JVM实现。
6. 执行init方法进行初始化
   • 属性值初始化
   • 代码块初始化
   • 构造器初始化

对象的内存布局

对象头（Header）

1. 运行时元数据

   • 哈希值（HashCode）：对象在堆空间中都有一个首地址值，引用根据这个地址指向堆中的对象，这就是哈希值起的作用
   • GC分代年龄
   • 锁状态标志
   • 线程持有的锁
   • 偏向线程ID
   • 偏向时间戳

2. 类型指针

   • 指向元空间中，对象所属的类型

3. 如果是数组对象，还会记录数组长度

实例数据（Instance Data）

父类定义的变量、本身定义的变量

规则：

• 父类变量，出现在子类变量之前
• 相同宽度的字段总是被分配在一起
• 如果CompactFields参数为true（默认true），子类窄变量，可能插入到父类变量的空隙

对齐填充（Padding）

没作用，仅是占位符

对象的访问定位

JVM如何让通过栈帧中的对象引用，访问到堆空间中的对象实例的呢？

对象访问的方式

• 使用直接指针

• 使用句柄访问（使用句柄池）

  

直接内存（了解）

JDK8引入元空间，就是使用的直接内存

• 不是虚拟运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域
• 直接内存是在Java堆外的、直接向系统申请的内存区间
• 来源于NIO，通过存储在堆中的DirectByteBuffer操作Native内存
• 读写性能更高
  • 出于性能考虑，读写频繁的场合考虑使用直接内存
  • Java的NIO库允许Java程序使用直接内存，用于数据缓存
• 也可能导致OutOfMemoryError: Direct buffer memory异常
  • 大小受限于系统内存大小
• 缺点：
  • 分配回收成本较高
  • 不受JVM内存回收管理
• 也可以设置直接内存的最大值
  • 可以通过-XX:MaxDirectMemorySize=10m设置
  • 如果不指定，默认和堆最大值-Xmx一致

简单使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public class BufferTest {
    private static final int BUFFER = 1024 * 1024 * 1024;

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
		
        // 直接分配内存空间
        ByteBuffer byteBuffer = ByteBuffer.allocateDirect(BUFFER);

        // 通过任务管理器可以看到，内存被占用了1G
        System.out.println("直接内存分配完毕")
        scanner.next();
		
        // 通过任务管理器可以看到，内存被释放了1G
        System.out.println("直接内存开始释放");
        byteBuffer = null;
        System.gc();
        scanner.next();
    }
}

性能测试

访问直接内存读写性能更高。使用JVM时，读取内存，应用需要从用户态切换到内核态。

• 读内存时：应用需要，先从用户态的虚拟机内存中读取数据，而此数据需要从内核态的物理内存上获取

• 写内存时：应用需要，先写到用户态的虚拟机内存空间上，然后copy到内核态的本地物理内存上

使用直接内存，则不会有用户态和内核态的copy，避免中间商赚差价，读写速度更快

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 测试：将一个文件复制三次
public class BufferTest1 {
    private static final int _100Mb = 1024 * 1024 * 100;

    public static void main(String[] args) {
        long sum = 0;
        String src = "D:\\data.nsp";
        for (int i = 0; i < 3; i++) {
            String dest = "D:\\data" + i + ".nsp";
            sum += directBuffer(src, dest);
        }
        System.out.println("总时间sum = " + sum);
    }
}

• 使用JVM内存做Buffer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 总时间sum = 26416
private static long io(String src, String dest) {
    long start = System.currentTimeMillis();
    try (
            FileInputStream fis = new FileInputStream(src);
            FileOutputStream fos = new FileOutputStream(dest);
    ) {
        byte[] buffer = new byte[_100Mb];
        int len;
        while ((len = fis.read(buffer)) != -1) {
            fos.write(buffer, 0, len);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
    long end = System.currentTimeMillis();
    return end - start;
}

• 使用直接内存地址做Buffer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// 总时间sum = 11260
private static long directBuffer(String src, String dest) {
    long start = System.currentTimeMillis();
    try (
            FileInputStream fis = new FileInputStream(src);
            FileOutputStream fos = new FileOutputStream(dest);

            FileChannel inChannel = fis.getChannel();
            FileChannel outChannel = fos.getChannel();
    ) {
        ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_100Mb);
        while (inChannel.read(byteBuffer) != -1) {
            byteBuffer.flip(); // 修改为读数据模式
            outChannel.write(byteBuffer);
            byteBuffer.clear(); // 清空
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
    long end = System.currentTimeMillis();
    return end - start;
}

直接内存溢出实验

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// -Xmx20m -XX:MaxDirectMemorySize=10m
// 没有OOM：使用UnSafe API分配的内存不受-XX:MaxDirectMemorySize参数的控制
public class MaxDirectMemorySizeTest {
    private static final long _1MB = 1024 * 1024;

    public static void main(String[] args) throws IllegalAccessException {
        Field unsafeField = Unsafe.class.getDeclaredFields()[0];
        unsafeField.setAccessible(true);
        Unsafe unsafe = (Unsafe) unsafeField.get(null);
        while (true) {
            unsafe.allocateMemory(_1MB);
        }
    }
}

1
2
3
4
5
6
7
8

// -Xmx20m -XX:MaxDirectMemorySize=10m
// Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory
public class MaxDirectMemorySizeTest {

    public static void main(String[] args) throws IllegalAccessException {
        ByteBuffer.allocateDirect(128 * 1024 * 1024);
    }
}

执行引擎

• 执行引擎包括：解释器、即时编译器、垃圾回收器
• 执行引擎的任务：将字节码指令翻译/解释为对应平台上的本地机器指令

执行引擎的工作流程

• 执行什么字节码指令：依赖PC寄存器
  • 执行完成后，PC寄存器更新为下一条需要被执行的指令地址
• 执行过程中，执行引擎会通过：
  • 局部变量表中的对象引用，准确定位存储在堆中的对象实例
  • 对象头中的元数据指针，准确定位存储在方法区的对象类型信息

代码编译和执行的过程

1. 黄色部分：编译生成字节码的过程，javac编译器（前端编译器）完成，与JVM无关
2. 后面绿色，蓝色部分：解释执行与即时编译，JVM完成

3. javac编译器（前端编译器）流程：

4. java字节码执行由JVM执行引擎来完成，流程如下：

什么是解释器？什么是JIT编译器？

1. 解释器：当JVM启动时，会根据预定义的规范对字节码采用逐行解释的方式执行，将字节码“翻译”为本地机器指令执行
2. JIT编译器：就是虚拟机将源代码一次性编译成机器语言，但并不是马上执行

为什么Java是半编译半解释语言？

1. 现在JVM在执行时，通常会将解释执行与编译执行结合起来进行
2. JIT编译器将字节码翻译成本地代码后，可以做缓存操作，存储在方法区的JIT代码缓存中（执行效率更高了），并且在翻译成本地代码的过程中可以做优化

解释器

为什么要有解释器：

• JVM设计者们的初衷：跨平台特性，避免由静态编译的方式生成本地机器指令，从而诞生了逐行解释的想法（不产生中间产品）

解释器的分类：

• Java发展历史中，出现了字节码解释器和模板解释器
  • 字节码解释器：通过纯软件代码，模拟字节码的执行，效率低下
  • 模板解释器：将每一条字节码与一个模板函数关联，模板函数中直接产生执行的机器码，大幅度提高了性能
• HotSpot VM中，解释器主要由Interpreter模块和Code模块构成
  • Interpreter模块：实现解释器的核心功能
  • Code模块：用于管理HotSpot VM在运行时生成的本地机器指令

解释器的现状：

• Python、Perl、Ruby等高级语言也是使用解释器的
• 为了解决低效的问题，JVM平台支持JIT技术
  • 避免函数被解释执行，将整个函数编译成机器码，效率大幅度提升

JIT编译器

• HotSpot VM是高性能虚拟机的代表作之一，它采用解释器与即时编译器并存的架构

比如：JRockit只部署在服务器上，已经砍掉了解释器

为什么还需要解释器:

• 看重启动时间的场景，需要两者并存的架构，来换取一个平衡
• 此模式下，解释器可以首先发挥作用，省去编译时间；随着时间的推移，编译器发挥作用，把越来越多的代码编译成本地代码，提高执行效率
• 在编译器进行激进优化不成立的时候，作为编译器的“逃生门”（后备方案）

阿里的案例：

• 机器在热机状态（运行了一段时间）可以承受的负载要大于冷机状态
• 程序员分批发布时，误分为两批发布。本来热机状态一半的机器可以勉强承载流量。但由于刚启动的JVM均是解释执行，还没有进行热点代码统计和JIT动态编译，导致机器启动之后，当前1/2发布成功的服务器马上全部宕机，此故障说明了JIT的存在

编译器相关概念

1. 前端编译器：把.java文件转变为.class
2. JVM的后端运行期编译器（JIT编译器）：把字节码转变为机器码
3. 静态提前编译器（AOT编译器）：直接把.java文件编译成本地机器码（后续发展的趋势）

典型的编译器：

1. 前端编译器：Sun的javac、Eclipse JDT的增量式编译器（ECJ）
2. JIT编译器：HotSpot VM的C1、C2编译器
3. AOT编译器：GNU Compiler for the Java（GCJ）、Excelsior JET

热点代码及探测方式

• 在运行时，JIT编译器针对频繁被调用的热点代码做出优化，直接编译为机器指令，以提升性能

  • 这种编译方式发生在方法的执行过程中，因此也被称之为栈上替换（OSR编译，On StackReplacement）

• 目前HotSpot VM所采用的热点探测方式是基于计数器的热点探测

• 每个函数都建立两个不同类型的计数器

  • 调用计数器：方法的调用次数
  • 回边计数器：方法体中，循环体执行的次数

方法调用计数器：

• 统计方法调用的次数，达到阈值触发JIT编译

  • 阈值可以用-XX:CompileThreshold来设定

• 方法被调用时，会检查是否存在被JIT编译过的版本

  • 存在，执行编译后的本地代码
  • 不存在，计数器加一
    • 超过阈值，向JIT编译器提交此方法的代码编译请求
    • 未超过阈值，对字节码解释执行

• 存在热度衰减：超过一定的时间，如果调用次数不足以让它提交给JIT编译器编译，那此方法的调用计数器就会减少一半

  • 可以用-XX:-UseCounterDecay关闭热度衰减（这样绝大多数方法都会被编译成本地方法）
  • 可以用-XX:CounterHalfLifeTime参数设置半衰期时间，单位是秒

回边计数器：

统计方法中循环体代码执行的次数，字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。建立回边计数器统计的目的就是为了触发OSR编译

HotSpot中的程序执行

设置程序执行的方式：

• -Xint：完全采用解释器模式执行
• -Xcomp：完全采用JIT编译器模式执行。编译出问题，解释器会介入
• -Xmixed：采用解释器+编译器混合的模式执行

-Xint : 6520ms -Xcomp : 950ms -Xmixed : 936ms

实验结论：只用解释器执行是真的慢