此笔记来自于黑马程序员

基础篇

初识 JVM(Java Virtual Machine)

什么是 JVM

JVM 本质上是一个运行在计算机上的程序，他的职责是运行 Java 字节码文件

JVM 的功能

翻译成字节码

即时编译

• Java语言如果不做任何优化，性能不如C、C++等语言。
• Java 支持跨平台特性

• JVM 提供了**即时编译（Just-In-Time 简称JIT）**进行性能的优化，最终能达到接近C、C++语言的运行性能甚至在特定场景下实现超越。

常见的 JVM

JVM 的种类

Java 虚拟机规范

• 《Java虚拟机规范》由 Oracle 制定，内容主要包含了 Java 虚拟机在设计和实现时需要遵守的规范，主要包含 class 字节码文件的定义、类和接口的加载和初始化、指令集等内容。
• 《Java虚拟机规范》是对虚拟机设计的要求，而不是对 Java 设计的要求，也就是说虚拟机可以运行在其他的语言比如 Groovy、Scala 生成的 class 字节码 文件之上。
• 官网地址：https://docs.oracle.com/javase/specs/index.html

HotSpot 的发展历程

字节码文件详解

Java虚拟机 的组成

应用场景

• 解决工作中的实际问题－版本冲突
• 解决工作中的实际问题－系统升级

字节码文件的组成

以正确的姿势打开文件

• 字节码文件中保存了源代码编译之后的内容，以二进制的方式存储，无法直接用记事本打开阅读。
• 推荐使用 jclasslib 工具查看字节码文件.
• Github地址：https://github.com/ingokegel/jclasslib

字节码文件的组成

字节码文件的组成部分-Magic魔数

• 文件是无法通过文件扩展名来确定文件类型的，文件扩展名可以随意修改，不影响文件的内容。
• 软件使用文件的头几个字节（文件头）去校验文件的类型，如果软件不支持该种类型就会出错。
• Java字节码文件中，将文件头称为 magic 魔数，

字节码文件的组成部分-主副版本号

• 主副版本号指的是编译字节码文件的 JDK 版本号，主版本号用来标识大版本号，JDK1.0-1.1 使用了 45.0 - 45.3，JDK1.2 是 46 之后每升级一个大版本就加 1；副版本号是当主版本号相同时作为区分不同版本的标识，一般只需要关心主版本号。
• 1.2之后大版本号计算方法就是：主版本号-44 比如主版本号 52 就是 JDK8
• 版本号的作用主要是判断当前字节码的版本和运行时的 JDK 是否兼容。

基础信息

字节码文件的组成部分-常量池

• 字节码文件中常量池的作用**：避免相同的内容重复定义，节省空间。**
• 常量池中的数据都有一个编号，编号从1开始。在字段或者字节码指令中通过编号可以快速的找到对应的数据。
• 字节码指令中通过编号引引用到常量池的过程称之为符号引用。

字节码文件的组成部分-方法

• 操作数栈是临时存放数据的地方，局部变量表是存放方法中的局部变量的位置。

• iconst_x 将 常量x放入操作数栈
• istore_1 将 x sotre 到数组下标为1的地方
• iload_1 将数组下标为1 的值拷贝到操作数栈
• iadd 操作栈中的两数相加
• return 方法结束，返回
• iinc 1 by 1 在局部变量1号位置增加1

玩转字节码常用工具

Jclasslib github 既有 IDEA 插件也有 exe

Github地址：https://github.com/ingokegel/jclasslib

javap -v 命令

• javap 是 JDK 自带的反编译工具，可以通过控制台查看字节码文件的内容。适合在服务器上查看字节码文件内容。

• 直接输入 javap 查看所有参数。

• 输入 javap -v 字节码文件名称 查看具体的字节码信息。(如果 jar 包需要先使用 jar-xvf 命令解压)

• jclasslib 也有 ldea 插件版本，建议开发时使用 ldea 插件版本，可以在代码编译之后实时看到字节码文件内容。

Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，大大提升线上问题排查效率。

• Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，大大提升线上问题排查效率。
• 官网: https://arthas.aliyun.com/doc/
• dump 类的全限定名：dump已加载类的字节码文件到特定目录。
• jad 类的全限定名：反编译已加载类的源码。

案例

总结

类的生命周期

类的生命周期描述了一个类加载、使用、、卸载的整个过程

生命周期概述

加载阶段

• 加载(Loading) 阶段第一步是类加载器根据类的全限定名通过不同的渠道以二进制流的方式获取字节码信息。程序员可以使用 Java 代码拓展的不同的渠道
• 类加载器在加载完类之后，Java虚拟机 会将字节码中的信息保存到方法区中
• 类加载器在加载完类之后，Java虚拟机 会将字节码中的信息保存到内存的方法区中生成一个 InstanceKlass 对象，保存类的所有信息，里边还包含实现特定功能比如多态的信息。
• 同时，Java虚拟机还会在堆中生成一份与方法区中数据类似的 java.lang.Class 对象。作用是在 Java 代码中去获取类的信息以及存储静态字段的数据（JDK8及之后）。
• 对于开发者来说，只需要访问堆中的 Class对象 而不需要访问 方法区中所有信息这样 Java虚拟机 就能很好地控制开发者访问数据的范围

• 推荐使用 JDK 自带的 hsdb工具 查看Java虚拟机 内存信息。工具位于 JDK 安装目录下 lib 文件夹中的 sa-jdi.jar 中。
• 启动命令: java -cp sa-jdi.jar sun.jvm.hotspot.HSDB

连接阶段

验证

验证内容是否满足《Java虚拟机规范》

• 连接（Linking）阶段的第一个环节是验证，验证的主要目的是检测Java字节码文件是否遵守了《Java虚拟机规范》中的约束。这个阶段一般不需要程序员参与。
• 主要包含如下四部分，具体详见《Java虚拟机规范》：
  文件格式验证，比如文件是否以 OxCAFEBABE 开头，主次版本号是否满足当前 Java虚拟机版本 要求。
• 元信息验证，例如类必须有父类**(super不能为空）**
• 验证程序执行指令的语义，比如方法内的指令执行到一半强行跳转到其他方法中去。
• 符号引用验证，例如是否访问了其他类中 private的 方法等。

• Hotspot JDK8 中虚拟机源码对版本号检测的代码如下，你能读懂它的含义吗：

准备

准备阶段为静态变量 (static) 分配内存并设置初始值。

• 注意：本章涉及到的内存结构只讨论 JDK8 及之后的版本，8 之前的版本后续章节详述。
• 准备阶段只会给静态变量赋初始值，而每一种基本数据类型和引用数据类型都有其初始值。

• final修饰的基本数据类型的静态变量**，准备阶段直接会将代码中的值进行赋值。**

解析

将常量池中的符号引用替换成指向内存的直接引用

• 符号引用就是在字节码文件中使用编号来访问常量池中的内容。

• 直接引用不在使用编号，而是使用内存中地址进行访问具体的数据。

初始化阶段(Most important)

初始化阶段会执行静态代码块中的代码并为静态变量赋值。 初始化阶段会执行字节码文件中 clinit 部分的字节码指令。(class init) 缩写为 clinit

• putstatic #2 <init/Demo1.value : I>

clinit 方法中的执行顺序与 Java 中编写的顺序是一致的

添加 -XX+TraceClassLoading 参数可以打印出加载井初始化的类

以下几种方式会导致类的初始化：

1. 访问一个类的静态变量或者静态方法，注意变量是 **final修饰的并且等号右边是常量 **不会触发初始化。
2. 调用 Class.forName(String className)。
3. new 一个该类的对象时。
4. 执行 Main 方法的当前类。

执行 main 方法先初始化 Test1 的初始化方法，输出结果 DA

clinit指令 在特定情况下不会出现，比如：如下几种情况是不会进行初始化指令执行的。

1. 无静态代码块且无静态变量赋值语句。
2. 有静态变量的声明，但是没有赋值语句。
3. 静态变量的定义使用 final关键字，这类变量会在准备阶段直接进行初始化。
4. 直接访问父类的静态变量，不会触发子类的初始化。
5. 子类的初始化clinit 调用之前，会先调用父类的 clinit初始化方法。(类似于类的继承)

• 结论

• final 修饰的变量如果赋值的内容需要执行指令才能得出结果，会执行 clinit方法 进行初始化

• 数组的创建不会导致数组中元素的类进行初始化。

类加载器

类加载器（ClassLoader）是 Java虚拟机 提供给应用程序去实现获取类和接口字节码数据的技术。类加载器只参与加载过程中的字节码获取并加载到内存这一部分。

类加载器的分类

类加载器的设计 JDK8 和 8 之后的版本差别较大，JDK8 及之前的版本中默认的类加载器有如下几种：

Arthas 中类加载器相关的功能

• 类加载器的详细信息可以通过 classloader 命令查看：

  classloader -查看 classloader 的继承树，urls，类加载信息，使用 classloader 去 getResource

类加载器的分类-启动类加载器

• 启动 类加载器（Bootstrap ClassLoader）是由 Hotspot虚拟机 提供的、使用 C++编写的类 加载器。
• 默认加载 Java安装目录/jre/lib下 的类文件，比如 rt.jar，tools.jar， resources.jar 等。

类加载器的分类-Java 中的默认类加载器

• 扩展类加载器和应用程序类加载器都是 JDK 中提供的、使用 Java编写的类加载器。
• 它们的源码都位于 sun.misc.Launcher 中 ，是一个静态内部类。继承自 URLClassLoader。具备通过目录或者指定 jar包 将字节码文件加载到内存中

• 类加载器的加载路径可以通过 classloader -c hash值查看：

  

双亲委派机制

由于 Java虚拟机 中有多个类加载器，双亲委派机制的核心是解决一个类到底由谁加载的问题。

双亲委派机制指的是：当一个类加载器接收到加载类的任务时，会自底向上查找是否加载过再由顶向下进行加载。

1.保证类加载的安全性

通过双亲委派机制避免恶意代码替换 JDK 中的核心类库，比如 java.lang.String，确保核心类库的完整性和安全性。

2.避免重复加载

双亲委派机制可以避免同一个类被多次加载。

向下委派加载起到了一个加载优先级的作用

• 每个 Java实现的类加载器 中保存了一个成员变量叫"父”（Parent）类加载器，可以理解为它的上级并不是继承关系。

打破双亲委派机制

• 一个 Tomcat程序 中是可以运行多个 Web应用 的，如果这两个应用中出现了相同限定名的类，比如 Servlet 类，Tomcat 要保证这两个类都能加载并且它们应该是不同的类。
• 如果不打破 双亲委派机制，当应用 类加载器加载Web应用中的 MyServlet 之后，Web应用2 中相同限定名 的MyServlet类 就无法被加载了。

• Tomcat 使用了自定义类加载器来实现应用之间类的隔离。每一个应用会有一个独立的类加载器加载对应的类。

打破双亲委派机制－自定义类加载器

• 先来分析 ClassLoader 的原理，，ClassLoader 中包含了 4个核心方法。双亲委派机制的核心代码就位于 loadClass 方法中。

• 阅读双亲委派机制的核心代码，分析如何通过自定义的类加载器打破双亲委派机制

• 打破双亲委派机制的核心就是将下边这一段代码重新实现

  

• 自定义类加载器默认的父类加载器

打破双亲委派机制的第二种方法：JDBC 案例

• DriverManager 类位于 rt.jar包 中，由启动类加载器加载。

• 依赖中的 mysql驱动 对应的类，由应用程序类加载器来加载。

• DriverManager 属于 rt.jar 是启动类加载器加载的。而 用户jar包 中的驱动需要由 应用类加载器 加载，这就违反了 双亲委派机制。

JDBC 案例之 SPI 机制

• spi 全称为 (Service Provider Interface)，是 JDK 内置的一种服务提供发现机制。

  spi 的工作原理：

  1. 在 ClassPath路径下 的 META-INF/services文件夹 中，以接口的全限定名来命名文件名，对应的文件里面写该接口的实现。
  2. DriverManage 使用 SPi 机制，最终加载 jar包 中对应的驱动类。

  

流程总结

1、启动类加载器加载 DriverManager

2、在初始化 DriverManager 时，通过 SPI机制 加载 jar包 中的 myql 驱动。

3、SPI 中利用了线程上下文类加载器（应用程序类加载器）去加载类并创建对象。

4, 这种由启动类加载器加载的类，委派应用程序类加载器去加载类的方式，打破了双亲委派机制。

打破双亲委派机制的第三种方法：OSGi 模块化

• 历史上，OSGi模块 化框架。它存在同级之间的类加载器的委托加载。OSGi 还使用类加载器实现了热部署的功能。

• 热部署指的是在服务不停止的情况下，动态地更新字节码文件到内存中。

注意事项：

1、程序重启之后，字节码文件会恢复，除非将 class文件 放入 jar包 中进行更新。
2、使用 retransform 不能添加方法或者字段，也不能更新正在执行中的方法。

JDK9 之后的类加载器

JDK8 及之前的版本中，扩展类加载器和应用程序类加载器的源码位于 rt.jar包 中的 sun.misc.Launcher.java。

• 由于 JDK9 引入了 module 的概念，类加载器在设计上发生了很多变化。

• 启动类加载器使用 Java编写，位于 jdk.internal.loader.ClassLoaders类 中。Java 中的 BootClassLoader 继承自 BuiltinClassLoader 实现从模

  块中找到要加载的字节码资源文件。启动类加载器依然无法通过 java代码 获取到，返回的仍然 是null，保持了统一。

  

2、扩展类加载器被替换成了平台类加载器（Platform Class Loader）。
平台类加载器遵循模块化方式加载字节码文件，所以继承关系从 URLClassLoader 变成了BuiltinClassLoader，BuiltinClassLoader 实现了从模块中加载字节码文件。平台类加载器的存在更多的是为了与老版本的设计方案兼容，自身没有特殊的逻辑。

小总结

JVM 的内存区域

运行时数据区-总览

• Java虚拟机 在运行Java程序 过程中管理的内存区域，称之为运行时数据区。
• 《Java虚拟机规范》中规定了每一部分的作用。

程序计数器

• 程序计数器（Program Counter Register）也叫 pc 寄存器，每个线程会通过程序计数器记录当前要执行的的字节码指令的地址。

• 在代码执行过程中，程序计数器会记录下一行字节码指令的地址。执行完当前指令之后，虚拟机的执行引擎根据程序计数器执行下一行指令。

• 程序计数器可以控制程序指令的进行，实现分支、跳转、异常等逻辑。

• 在多线程执行情况下，Java虚拟机 需要通过程序计数器记录 CPU切换 前解释执行到那一句指令并继续解释运行。

Java 虚拟机栈

• **Java虚拟机栈（Java Virtual Machine Stack）**采用栈的数据结构来管理方法调用中的基本数据，先进后出（First In Last Out），每一个方法的调用用一个 **栈帧（StackFrame）**来保存。

• Java虚拟机栈 随着线程的创建而创建，而回收则会在线程的销毁时进行。由于方法可能会在不同线程中执行，每个线程都会包含一个自己的虚拟机栈。

Java 虚拟机栈-局部变量表

局部变量表的作用是在方法执行过程中存放所有的局部变量。编译成字节码文件时就可以确定局部变量表的内容。

• 栈帧中的局部变量表是一个数组，数组中每一个位置称之为槽 (slot），long 和 double类型 占用两个槽，其他类型占用一个 槽

• 实例方法中的序号为 0 的位置存放的是 this，指的是当前调用方法的对象，运行时会在内存中存放实例对象的地址。

• 方法参数也会保存在局部变量表中，其顺序与方法中参数定义的顺序一致。

• 局部变量表保存的内容有：实例方法的 this对象，方法的参数，方法体中声明的局部变量。

• 为了节省空间，局部变量表中的槽是可以复用的，一旦某个局部变量不再生效，当前槽就可以再次被使用。

Java 虚拟机栈- 操作数栈

操作数栈是栈帧中虚拟机在执行指令过程中用来存放临时数据的一块区域

• 操作数栈是栈帧中虚拟机在执行指令过程中用来存放中间数据的一块区域。他是一种栈式的数据结构，如果一条指令将一个值压入操作数栈，则后面

  的指令可以弹出并使用该值。

• 在编译期就可以确定操作数栈的最大深度，从而在执行时正确的分配内存大小。

Java 虚拟机栈帧数据

帧数据主要包含 动态链接、方法出口、异常表的引用

动态链接

• 当前类的字节码指令引用了其他类的属性或者方法时，需要将符号引用（编号）转换成对应的运行时常量池中的内存地址。动态链接就保存了编号到运行时常量池的内存地址的映射关系。

方法出口

方法出口指的是方法在正确或者异常结束时，当前栈帧会被弹出，同时程序计数器应该指向上一个栈帧中的下一条指令的地址。所以在当前栈帧中，需要存储此方法出口的地址。

异常表的引用

异常表存放的是代码中异常的处理信息，包含了异常捕获的生效范围以及异常发生后跳转到的字节码指令位置。

Java虚拟机栈-栈内存溢出

• Java虚拟机栈如果栈帧过多，占用内存超过栈内存可以分配的最大大小就会出现内存溢出。
• Java虚拟机栈内存溢出时会出现 StackOverflowError 的错误。

Java虚拟机栈-默认大小

如果我们不指定栈的大小，JVM 将创建一个具有默认大小的栈。大小取决于操作系统和计算机的体系结构

Java虚拟机栈-栈内存溢出模拟

public static int count = 0;

// 递归方法调用自己
public static void recursion() {
    System.out.println(++count);
    recursion();
}
// 查看错误发生时总调用次数

Java虚拟机栈－设置大小

• 要修改 Java虚拟机栈 的大小，可以使用虚拟机参数 -Xss。
• 语法：-Xss 栈大小
• 单位：字节（默认，必须是 1024 的倍数）、k 或者 K（KB）、m 或者 M(MB）、g 或者G（GB)

• 与 -Xss 类似，也可以使用 -XX：ThreadStackSize 调整标志来配置堆栈大小。格式为：-XX:ThreadStackSize=1024

2、HotSpotJVM对栈大小的最大值和最小值有要求：
比如测试如下两个参数：
-Xss 1k
-Xss1025m
Windows（64位）下的 JDK8 测试最小值为 180k，最大值为 1024m。

3、局部变量过多、操作数栈深度过大也会影响栈内存的大小。

一般情况下，工作中即便使用了递归进行操作，栈的深度最多也只能到几百，不会出现栈的溢出。所以此参数可以手动指定为-Xss256k节省内存。

本地方法栈

• Java虚拟机栈 存储了 Java方法 调用时的栈帧，而本地方法栈存储的是 native本地方法的栈帧。

• 在 Hotspot虚拟机 中，Java虚拟机栈和本地方法栈实现上使用了同一个栈空间。本地方法栈会在栈内存上生成一个栈帧，临时保存方法的参数同时

  方便出现异常时也把本地方法的栈信息打印出来。

Java 堆

• 一般Java程序 中堆内存是空间最大的一块内存区域。创建出来的对象都存在于堆上。
• **栈上的局部变量表中，可以存放堆上对象的引用。**静态变量也可以存放堆对象的引用，通过静态变量就可以实现对象在线程之间共享。
  

• 堆空间有三个需要关注的值，used total max。
• used 指的是当前已使用的堆内存，total是 java虚拟机 已经分配的可用堆内存，max 是 java 虚拟机可以分配的最大堆内存。

• 随着堆中的对象增多，当 total 可以使用的内存即将不足时，java虚拟机 会继续分配内存给堆。

• 如果堆内存不足，java虚拟机就会不断的分配内存，total值会变大。total最多只能与max相等。

• 如果不设置任何的虚拟机参数，max默认 是系统内存的 1/4，total 默认是系统内存的 1/64。在实际应用中一般都需要设置total和max的值。

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

堆－设置大小

• 要修改堆的大小，可以使用虚拟机参数 -Xmx（max最大值）和 -Xms（初始的total)。
• 语法：-Xmx值 -Xms值
• 单位：字节（默认，必须是1024 的倍数）、k或者K（KB）、m或者M（MB）、g或者G（GB）
• 限制：Xmx必须大于 2MB，XmS必须大于 1MB

• Java服务端程序开发时，建议将 -Xmx 和 -Xms 设置为相同的值，这样在程序启动之后可使用的总内存就是最大内存，而无需向 java虚拟机 再次申请，减少了申请并分配内存时间上的开销，同时也不会出现内存过剩之后堆收缩的情况。
• -Xmx 具体设置的值与实际的应用程序运行环境有关，在《实战篇》中会给出设置方案。

arthas 中堆内存相关的功能

• 堆内存 used total max 三个值可以通过 dashboard命令 看到
• 手动指定刷新频率 (不指定默认5秒一次）：dashboard-i 刷新频率(毫秒)

方法区 (Method Area)

方法区是存放基础信息的位置，线程共享，主要包含三部分内容：

方法区是用来存储每个类的基本信息（元信息），一般称之为 lnstanceKlass 对象。在类的加载阶段 完成。

• 方法区除了存储类的元信息之外，还存放了运行时常量池。常量池中存放的是字节码中的常量池内容。

• 字节码文件中通过编号查表的方式找到常量，这种常量池称为静态常量池。当常量池加载到内存中之后，可以通过内存地址快速的定位到常量池中的

  内容，这种常量池称为运行时常量池。

• 方法区是《Java虚拟机规范》中设计的虚拟概念，每款 Java虚拟机 在实现上都各不相同。Hotspot设计如下：
  • **JDK7及之前的版本 **将方法区存放 在堆区域中的永久代空间，堆的大小由虚拟机参数来控制。
  • JDK8及之后的版本将方法区存放在元空间中，元空间位于操作系统维护的直接内存中，默认情况下只要不超过操作系统承受的上限，可以一直分配。

arthas 中查看方法区

• 使用 memory 打印出内存情况，JDK7 及之前的版本查看 ps_perm_gen 属性。
• JDK8 及之后的版本查看 metaspace 属性。

ByteBuddy框架 的基本使用方法

• 实验发现，JDK7 上运行大概十几万次，就出现了错误。在 JDK8 上运行百万次，程序都没有出现任何错误，但是内存会直线升高。这说明 JDK7 和JDK8 在方法区的存放上，采用了不同的设计。

• JDK7 将方法区存放在堆区域中的永久代空间，堆的大小由虚拟机参数**-XX:MaxPermSize=值**来控制。

• JDK8 将方法区存放在元空间中，元空间位于操作系统维护的直接内存中，默认情况下只要不超过操作系统承受的上限，可以一直分配。可以使用 -XX:MaxMetaspaceSize=值 将元空间最大大小进行限制。

方法区（Method Area）字符串常量池

• 方法区中除了类的元信息、运行时常量池之外，还有一块区域叫字符串常量池(String Table)。
• 字符串常量池存储在代码中定义的常量字符串内容。比如“123”这个123就会被放入字符串常量池。

方法区（Method Area）字符串常量池(StringTable)

• 字符串常量池和运行时常量池有什么关系？
  • 早期设计时，字符串常量池是属于运行时常量池的一部分，他们存储的位置也是一致的。后续做出了调整，将字符串常量池和运行时常量池做了拆分。

练习题一

练习题二

神奇的 intern

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

运行时数据区都学完了，静态变量存储在哪里呢？

• JDK7 及之后的版本中，静态变量是存放在堆中的 Class对象中，脱离了永久代。具体源码可参考虚拟机源码：Bytecodelnterpreter 针对 putstatic指令的处理。

直接内存

• 直接内存（DirectMemory）并不在《ava虚拟机规范》中存在，所以并不属于 **Java运行时的内存区域。**在 JDK1.4 中引I入了 NIO机制，使用了直接内存，主要为了解决以下两个问题：

1. Java堆中的对象如果不再使用要回收，回收时会影响对象的创建和使用。
2. IO操作比如读文件，需要先把文件读入直接内存（缓冲区）再把数据复制到ava堆中。**现在直接放入直接内存即可，同时Java堆上维护直接内存的引I用，减少了数据复制的开销。**写文件也是类似的思路。

直接内存（Direct Memory)

• 要创建直接内存上的数据，可以使用 ByteBuffer。
• 语法：ByteBuffer directBuffer = ByteBuffer.allocateDirect(size);
• 注意事项：arthas 的 memory命令 可以查看直接内存大小，属性名 direct。

如果需要手动调整直接内存的大小，可以使用 -XX:MaxDirectMemorySize=大小

• 单位k或K表示干字节，m或M表示兆字节，g或G表示干兆字节。默认不设置该参数情况下，JVM 自动选择最大分配的大小。
• 以下示例以不同的单位说明如何将直接内存大小设置为 1024KB:
  -XX:MaxDirectMemorySize = 1m
  -XX:MaxDirectMemorySize = 1024k
  -XX:MaxDirectMemorySize =1048576

JVM 的垃圾回收

自动垃圾回收

• 在 C/C++ 这类没有自动垃圾回收机制的语言中，一个对象如果不再使用，需要手动释放，否则就会出现内存泄漏。我们称这种释放对象的过程为垃圾回收，而需要程序员编写代码进行回收的方式为手动回收。

• 内存泄漏指的是不再使用的对象在系统中未被回收，内存泄漏的积累可能会导致内存溢出。

• 很多现代语言比如 C#、Python、Go 都拥有自己的垃圾回收器

方法区的回收

• 线程不共享的部分，都是伴随着线程的创建而创建，线程的销毁而销毁。而方法的栈帧在执行完方法之后就会自动弹出栈并释放掉对应的内存。

• 方法区中能回收的内容主要就是不再使用的类。

判定一个类可以被卸载。需要同时满足下面三个条件：

1、此类所有实例对象都已经被回收，在堆中不存在任何该类的实例对象以及子类对象。
2、加载该类的类加载器已经被回收。
3、该类对应的 java.lang.Class 对象没有在任何地方被引用。

方法区的回收－手动触发回收

• 如果需要手动触发垃圾回收，可以调用 System.gc() 方法。
  语法：System.gc()
  注意事项：
  调用 System·gc() 方法并不一定会立即回收垃圾，仅仅是向 Java虚拟机 发送一个垃圾回收的请求，具体是否需要执行 垃圾回收Java虚拟机 会自行判断。

public class ClassUnload {
	public static void main(String[] args) throws InterruptedException {
        
        try {
            ArrayList<Class<?>> classes = new ArrayList<>();
            ArrayList<URLClassLoader> loaders = new ArrayList<>();
            ArrayList<Object> objs = new ArrayList<>();
            while (true) {
                
                URLClassLoader loader = new URLClassLoader (
                	new URL[] {new URL("file:D:\\lib\\")});
                
                Class<?> clazz = loader.loadClass("com.itheima.my.A");
                Object o = clazz.newInstance();
                
                // objs.add(o);
                // Loader = null;
                // classes.add(clazz);
                // loaders.add(loader);
                
                System.gc();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        
    }
}

堆回收

• Java中 的对象是否能被回收，是根据对象是否被引用来决定的。如果对象被引用了，说明该对象还在使用，不允许被回收。

如何判断堆上的对象可以回收?

只有无法通过引用获取到对象时，该对象才能被回收。

引用计数法和可达性分析法

引用计数法

引用计数法会为每个对象维护一个引用计数器，当对象被引引用时 加1，取消引用时减1。

• 引用计数法的优点是实现简单，C++中的智能指针就采用了引用计数法，但是它也存在缺点，主要有两点：
  1. 每次引用和取消引用都需要维护计数器，对系统性能会有一定的影响
  2. 存在循环引I用问题，所谓循环引用就是当 A引用B，B同时引用A时 会出现对象无法回收的问题(见上图)

查看垃圾回收日志

• 如果想要查看垃圾回收的信息，可以使用-verbose：gc 参数。
• 语法：-verbose:gc

可达性分析法

Java 使用的是可达性分析算法来判断对象是否可以被回收。可达性分析将对象分为两类：垃圾回收的根对象（GCRoot）和普通对象，对象与对象之间存在引用关系。

下图中 A 到 B 再到 C 和 D，形成了一个引用链，可达性分析算法指的是如果从某个到 GCRoot对象是可达的，对象就不可被回收。

哪些对象被称之为 GCRoot对象呢？

• 线程Thread对象，引用线程栈帧中的方法参数、局部变量等。
• 系统类加载器加载的 java.lang.Class对象 引用类中的静态变量
• 监视器对象，用来保存 同步锁synchronized关键字 持有的对象。
• 本地方法调用时使用的全局对象。

分析下面代码中的A实例对象和B示例对象，是如何通过可达性算法判断对象能被回收的？

查看 GCRoot(Java高手必备)

通过 arthas 和 eclipse Memory Analyzer(MAT)工具可以查看 GC Root，MAT 工具是 eclipse 推出的 Java堆内存检测工具。

具体操作步骤如下:

1. 使用 arthas 的 heapdump 命令将堆内存快照保存到本地磁盘中。
2. 使用 MAT 工具打开堆内存快照文件。
3. 选择 GC Roots 功能查看所有的 GC Root。

五种对象引用

几种常见的对象引用

可达性算法中描述的对象引用，一般指的是强引用，即是 GCRoot对象 对普通对象有引用关系，只要这层关系存在，普通对象就不会被回收。除了强引用之外，Java中还设计了几种其他引用方式：

• 软引用
• 弱引用
• 虚引用
• 终结器引用

软引用

软引用相对于强引用是一种比较弱的引用关系，如果一个对象只有软引用关联到它，当程序内存不足时，就会将软引用中的数据进行回收。

在 JDK1.2版 之后提供了 SoftReference类 来实现软引用，软引用常用于缓存中。

软引用的执行过程如下：

1. 将对象使用软引用包装起来，new SoftReference<对象类型>（对象)。
2. 内存不足时，虚拟机尝试进行垃圾回收。
3. 如果垃圾回收仍不能解决内存不足的问题，回收软引用中的对象。
4. 如果依然内存不足，抛出 OutOfMemory 异常。

软引用中的对象如果在内存不足时回收，SoftReference对象 本身也需要被回收。如何知道哪些 SoftReference 对象需要回收呢？

SoftReference 提供了一套队列机制:

1、软引用创建时，通过构造器传入引用队列
2、在软引用中包含的对象被回收时，该软引用对象会被放入引用队列
3、通过代码遍历引用队列，将 SoftReference 的强引用删除

public class SoftReferenceDemo3 {
    
    public static void main(String[] args) throws IOException {
        
        ArrayList<SoftReference> softReferences = new ArrayList<>();
        ReferenceQueue<byte[]> queues = new ReferenceQueue<byte[]>();
        
        for (int i = 0; i < 10; i++) {
            byte[] bytes = new byte[1024 * 1024 * 100];
            SoftReference studentRef = new SoftReference<byte[]> (bytes, queue);
            softReference.add(studentRef);
        }
        
        SoftReference<byte[]> ref = null;
        int count = 0;
        while ((ref = (SoftReference<byte[]>) queues.poll()) != null) {
			count++;
        }
        
        System.out.println(count);
    }
    
}

软引用也可以使用继承自 SoftReference类 的方式来实现，StudentRef类 就是一个软引用对象。
通过构造器传入软引用包含的对象，以及引用队列。

public class StudentCache {
    
    private static StudentCache cache = new StudentCache();
    
    public static void main(String[] args) {
        
        for (int i = 0; ; i++) {
            StudentCache.getInstance().cacheStudent(new Student(i, String.valueOf(i)));
        }
    }
    
    private Map<Integer, Student> StudentRefs; // 用于 Cache 内容的存储
    private ReferenceQueue<Student> q; // 垃圾 Reference的队列
    
    // 继承 SoftReference，使得每一个实例都具有可识别的标识。
    // 并且该标识与其在HashMap内的key相同
    private class StudentRef extends SoftReference<Student> {
        private Integer _key = null;
        
        public StudentRef(Student em, ReferenceQueue<Student> q) {
            super(em, q);
            _key = em.getId();
        }
    }
    
    // 构建一个缓存器实例
	private StudentCache() {
        StudentRefs = new HashMap<Integer, StudentRef>();
        q = new ReferenceQueue<Student>();
    }
    
    // 取得缓存器实例
    public static StudentCache getInstance() { return cache; }
    
    // 以软引用的方式对一个Student对象的实例进行引用并保存该引用
    private void cacheStudent(Student em) {
        cleanCache(); // 清除垃圾引用
        StudentRef ref = new StudentRef(em, q);
        StudentRefs.put(em.getId(), ref);
        System.out.println(StudentRefs.size());
    }
}

class Student {
    int id;
    String name;
    
    public Student(int id, String name) {
        this.id = id;
        this.name = name;
    }
    
    public int getId() { return id; }
    
    public void setId(int id) { this.id = id; }
    
    public String getName() { return name; }
    
    public void setName(String name) { this.name = name; }
}

弱引用

弱引用的整体机制和软引用基本一致，区别在于弱引用包含的对象在垃圾回收时，**不管内存够不够都会直接被回收。**在 JDK1.2版 之后提供了 WeakReference类 来实现弱引用，弱引用主要在 ThreadLocal中 使用。

弱引用对象本身也可以使用引用队列进行回收。

public class WeakReferenceDemo2 {
    public static void main(String[] args) throws IOException {
        
        byte[] bytes = new byte[1024 * 1024 * 100];
    	WeakReference<byte[]> weakReference = new WeakReference<byte[]> (bytes);
        bytes = null;
        System.out.println(weakReference.get());
        
        System.gc();
        
        System.out.println(weakReference.get());
    }
}

虚引用和终结器引用

• 这两种引用在常规开发中是不会使用的。
• 虚引用也叫幽灵引用/幻影引|用，不能通过虚引用对象获取到包含的对象。**虚引用唯一的用途是当对象被垃圾回收器回收时可以接收到对应的通知。**Java 中使用 PhantomReference 实现了 虚引用，直接内存中为了及时知道直接内存对象不再使用，从而回收内存，使用了虚引用来实现。
• 终结器引用指的是在对象需要被回收时，对象将会被放置 在Finalizer类中 的引用队列中，并在稍后由一条 由FinalizerThread线程 从队列中获取对象，然后执行 对象的finalize方法。在这个过程中可以 在finalize方法中 再将自身对象使用强引用关联上，但是不建议这样做，如果耗时过长会影响其他对象的回收。

public class Demo1 {
    public static int size = 1024 * 1024 * 100; // 100 mb
    public static List<ByteBuffer> list = new ArrayList<~>();
    public static int count = 0;
    
    public static void main(String[] args) throws IOException, InterruptedException {
        System.in.read();
        while (true) {
            // 1. 创建 DirectByteBuffer 对象并返回
            // 2. 在 DirecByteBuffer 构造方法中，向操作系统申请直接内存空间
			ByteBuffer directBuffer = ByteBuffer.allocateDirece(size);
            directBuffer = null;
            
    //        list.add(directBuffer);
   //         System.out.println(++count);
   //         Thread.sleep(5000);
            
            
        }
    }
}

/**
* 终结器引用
*/
public class FinalizeReferenceDemo {
    public static FinalizeReferenceDemo reference = null;
    
    public void alive() {
        System.out.println("当前对象还存活");
    }
    
    @Override
    protected void finalize() throws Throwable {
        try {
            System.out.println("finalize()被执行了");
            // 设置强引用自救
            reference = this;
        } finally {
            super.finalize();
        }
    }
    
    public static void main(String[] args) throws Throwable {
        reference = new FinalizaReferenceDemo();
        test();
        test();
    }
    
    private static void test() throws InterruptedException {
        reference = null;
        
        // 回收对象
		System.gc();
        // 执行 finalize 方法的优先级比较低，休眠 500 ms等待一下
        
        Thread.sleep(500);
        
        if (reference != null) {
            reference.alive();
        } else {
            System.out.println("对象已被回收");
        }
    }
}

垃圾回收算法

• Java 是如何实现垃圾回收的呢？简单来说，垃圾回收要做的有两件事：

• 1960年 John McCarthy 发布了第一个 GC算法：标记-清除算法

• 1963年 Marvin L.Minsky 发布了 复制算法
  本质上后续所有的垃圾回收算法，都是在上述两种算法的基础上优化而来。

Java垃圾回收过程 会通过单独的 GC线程 来完成，但是不管使用哪一种 GC算法，都会**有部分阶段需要停止所有的用户线程。**这个过程被称之为Stop The World简称 STW，如果 STW时间过长 则会影响用户的使用。

import lombok.SneakyThrows;
import java.util.LinkedList;
import java.util.List;

public class StopWorldTest {
    public static void main(String[] args) {
        new PrintThread().start();
        new ObjectThread().start();
    }
    
    static class PrintThread extends Thread {
        @SneakyThrows
        @Override
        public void run() {
            // 记录开始时间
            long last = System.currentTimeMillis();
            while (true) {
                long now = System.currentTimeMillis();
                System.out.println(now - last);
                last = now;
                Thread.sleep(100);
            }
        }
    }
    
    static class ObjectThread extends Thread {
        @SneakyThrows
        @Override
        public void run() {
            List<byte[]> bytes = new LinkedList<>();
            while (true) {
                // 最多存放 8G 然后删除强引用，垃圾回收时释放 8G
                if (bytes.size() >= 80) {
                    bytes.clear();
                }
                bytes.add(new byte[1024 * 1024 * 100]);
                Thread.sleep(10);
            }
        }
    }	
}

所以判断GC算法是否优秀，可以从三个方面来考虑：

1.吞吐量

吞吐量指的是 CPU 用于执行用户代码的时间与 CPU总执行时间 的比值，即 吞吐量 = 执行用户代码时间 / (执行用户代码时间 + GC时间）。吞吐量数值越高，垃圾回收的效率就越高。

2.最大暂停时间

最大暂停时间指的是所有在垃圾回收过程中的 STW时间 最大值。比如如下的图中，黄色部分的STW就是最大暂停时间，显而易见上面的图比下面的图拥有更少的最大暂停时间。最大暂停时间越短，用户使用系统时受到的影响就越短。

3.堆使用效率

不同垃圾回收算法，对堆内存的使用方式是不同的。比如标记清除算法，可以使用完整的堆内存。而复制算法会将堆内存一分为二，每次只能使用一半内存。从堆使用效率上来说，标记清除算法要优于复制算法。

上述三种评价标准：堆使用效率、吞吐量，以及最大暂停时间不可兼得。一般来说，堆内存越大，最大暂停时间就越长。想要减少最大暂停时间，就会降低吞吐量。不同的垃圾回收算法，适用于不同的场景。

垃圾回收算法-标记清除算法

标记清除算法的核心思想分为两个阶段：

1.标记阶段，将所有存活的对象进行标记。Java中使用可达性分析算法，从GC Root开始通过引用链遍历出所有存活对象。
2.清除阶段，从内存中删除没有被标记也就是非存活对象。

垃圾回收算法-标记清除算法的优缺点

**优点：**实现简单，只需要在第一阶段给每个对象维护标志位，第二阶段删除对象即可。
缺点：1.碎片化问题
由于内存是连续的，所以在对象被删除之后，内存中会出现很多细小的可用内存单元。如果我们需要的是一个比较大的空间，很有可能这些内存单元的大小过小无法进行分配。

2.分配速度慢。由于内存碎片的存在，需要维护一个空闲链表，极有可能发生每次需要遍历到链表的最后才能获得合适的内存空间。

垃圾回收算法-复制算法

复制算法的优缺点

垃圾回收算法-标记整理算法

**标记整理算法也叫标记压缩算法，**是对标记清理算法中容易产生内存碎片问题的一种解决方案。
核心思想分为两个阶段：
1.标记阶段，将所有存活的对象进行标记。Java中使用可达性分析算法，从GCRoot开始通过引l用链遍历出所有存活对象。
2.整理阶段，将存活对象移动到堆的一端。清理掉存活对象的内存空间。

标记整理算法的优缺点

垃圾回收算法-分代垃圾回收算法

现代优秀的垃圾回收算法，会将上述描述的垃圾回收算法组合进行使用，其中应用最广的就是分代垃圾回收

arthas 查看分代之后的内存情况

• 在 JDK8中，添加-XX:+UseSerialGC 参数使用分代回收的垃圾回收器，运行程序。
• 在 arthas中 使用 memory命令 查看内存，显示出三个区域的内存情况。

调整内存区域的大小

根据以下虚拟机参数，调整堆的大小并观察结果。注意加上-XX:+UseSerialGC

public class GcDemo0 {
    
    public static void main throws IOException {
        List<Object> list = new ArrayList<>();
        int count = 0;
        
        while (true) {
            System.in.read();
            System.out.println(++count);
            // 每次添加 1m 的数据
            list.add(new byte[1024 * 1024 * 1]);
        }    
    }
}

垃圾回收算法-分代垃圾回收算法

分代回收时，创建出来的对象，首先会被放入 Eden伊甸园区。
随着对象在 Eden区越来越多，如果 Eden区满，新创建的对象已经无法放入，就会 触发年轻代的GC，称为 Minor GC 或者 Young GC. Minor GC会把需要 eden中和 From需要回收的对象回收，把没有回收的对象放入To区。

接下来，S0 会变成 To区，S1 变成 From区。当 eden区 满时再往里放入对象，依然会发生 Minor GC。此时会 回收eden区 和 S1(from)中的对象，并把 eden和 from区 中剩余的对象放入S0。
注意：每次 Minor GC中都会为对象记录他的年龄，初始值为0，每次GC完加1。

如果 Minor GC 后对象的年龄达到阈值（最大15，默认值和垃圾回收器有关），对象就会被晋升至老年代。
当老年代中空间不足，无法放入新的对象时，先尝试 minor gc 如果还是不足，就会触发 Full GC，Ful lGC 会对整个堆进行垃圾回收。

垃圾回收器

垃圾回收器组合关系

第一种组合

年轻代-Serial 垃圾回收器

老年代 -SerialOld 垃圾回收器

第二种组合

年轻代 -ParNew 垃圾回收器

老年代 -CMS(Concurrent Mark Sweep) 垃圾回收器

缺点：
1、CMS 使用了 标记-清除算法，在垃圾收集结束之后会出现大量的内存碎片，CMS 会在 FulIGC 时进行碎片的整理。这样会导致用户线程暂停，可以使用 -XX:CMSFuLlGCsBeforeCompaction = N 参数（默认0）调整 N次 Full GC 之后再整理。
2.、无法处理在并发清理过程中产生的“浮动垃圾”，不能做到完全的垃圾回收。
3、如果老年代内存不足无法分配对象，CMS 就会退化成 Serial Old单线程 回收老年代。

第三种组合

年轻代 -Parallel Scavenge 垃圾回收器

老年代 -Parallel Old 垃圾回收器

// -XX:+UseSerialGc -Xmn1g -Xmx16g -XX:SurvivorRatio=8 -XX:+PrintGCDetails -verbose:gc -XX:+PrintFlagsFinal
// -XX:+UseParNewGc -Xmn1g -Xmx16g -XX:SurvivorRatio=8 -XX:PrintGCDetails -verbose:gc
// -XX:+UseConcMarkSweepGC
// -XX:UseG1Gc -Xmn8g -Xmx16g -XX:SurvivorRatio=8 -XX:+PrintGCDetails -verbose:gc
// -XX:PrintFlagsFinal -XX:GCTimeRatio = 19 -XX:MaxGCPauseMills = 1 -XX:UseAdaptiveSizePolicy
public class GcDemo2 {
    
    public static void main(String[] args) throws IOException {
        int count = 0;
        List<Object> list = new ArrayList<>();
        while(true) {
            // System.out.println(++count)
            if (count++ % 1024 == 0) {
                list.clear();
            }
            // byte[] bytes = new byte[1024 * 1021 *1]
            list.add(new byte[1024 * 1024 * 1024]);
            // System.gc();
        }
    }
}

G1垃圾回收器

JDK9 之后默认的垃圾回收器是 G1（GarbageFirst）垃圾回收器。
Parallel Scavenge关注吞吐量，允许用户设置最大暂停时间，但是会减少年轻代可用空间的大小。
CMS 关注暂停时间，但是吞吐量方面会下降。

而 G1设计目标 就是将上述两种垃圾回收器的优点融合：

1. 支持巨大的堆空间回收，并有较高的吞吐量。
2. 支持 多CPU并行垃圾回收。
3. 允许用户设置最大暂停时间。

G1 垃圾回收器－内存结构

G1 出现之前的垃圾回收器，内存结构一般是连续的，如下图：

G1 的整个堆会被划分成多个大小相等的区域，称之为 区Region，区域不要求是连续的。分为Eden、Survivor、Old区。Region的大小通过堆空间大小/2048 计算得到，也可以通过参数 -XX:G1HeapRegionSize=32m指定(其中32m指定region大小为32M)，Region size必须是2的指数幂，取值范围从1M 到 32M。

G1垃圾回收 有两种方式：

• 年轻代回收(Young GC)
• 混合回收(Mixed GC)

年轻代回收

• 年轻代回收（Young GC），回收 Eden区 和Survivor区中 不用的对象。会导致STW，G1中 可以通过参数 -XX:MaxGCPauseMillis = n (默认200) 设置每次垃圾回收时的最大暂停时间毫秒数，G1垃圾回收器 会尽可能地保证暂停时间。

总结