|
|
|
|
|
# 一、类的加载介绍
|
|
|
|
|
|
类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个 `java.lang.Class`对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的 `Class`对象， `Class`对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。
|
|
|
|
|
|
![[640.jpg]]
|
|
|
|
|
|
类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误（LinkageError错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误。
|
|
|
|
|
|
|
|
|
|
|
|
# 二、类的生命周期
|
|
|
|
|
|
![[Snipaste_2023-02-27_15-13-44 1.png]]
|
|
|
|
|
|
其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。
|
|
|
|
|
|
|
|
|
|
|
|
## 2.1 加载
|
|
|
|
|
|
查找并加载类的二进制数据加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：
|
|
|
|
|
|
1. 通过一个类的全限定名来获取其定义的二进制字节流
|
|
|
|
|
|
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
|
|
|
|
|
|
3. 在Java堆中生成一个代表这个类的 `java.lang.Class`对象，作为对方法区中这些数据的访问入口
|
|
|
|
|
|
|
|
|
|
|
|
## 2.2 连接
|
|
|
|
|
|
|
|
|
|
|
|
### 2.2.1 验证 - 确保被加载的类的正确性
|
|
|
|
|
|
目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致会完成4个阶段的检验动作：
|
|
|
|
|
|
1. **文件格式验证**：验证字节流是否符合Class文件格式的规范；例如：是否以 `0xCAFEBABE`开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
|
|
|
|
|
|
2. **元数据验证**：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了 `java.lang.Object`之外。
|
|
|
|
|
|
3. **字节码验证**：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
|
|
|
|
|
|
4. **符号引用验证**：确保解析动作能正确执行。
|
|
|
|
|
|
|
|
|
|
|
|
### 2.2.2 准备 - 为类的 `静态变量分`配内存，并将其初始化为默认值
|
|
|
|
|
|
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：
|
|
|
|
|
|
1. 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
|
|
|
|
|
|
2. 这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。
|
|
|
|
|
|
### 2.2.3 解析 - 把类中的符号引用转换为直接引用
|
|
|
|
|
|
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。
|
|
|
|
|
|
直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
|
|
|
|
|
|
|
|
|
|
|
|
## 2.3 初始化
|
|
|
|
|
|
初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：
|
|
|
|
|
|
1. 声明类变量是指定初始值
|
|
|
|
|
|
2. 使用静态代码块为类变量指定初始值
|
|
|
|
|
|
**JVM初始化步骤**
|
|
|
|
|
|
1. 假如这个类还没有被加载和连接，则程序先加载并连接该类
|
|
|
|
|
|
2. 假如该类的直接父类还没有被初始化，则先初始化其直接父类
|
|
|
|
|
|
3. 假如类中有初始化语句，则系统依次执行这些初始化语句
|
|
|
|
|
|
|
|
|
|
|
|
**类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：**
|
|
|
|
|
|
- 创建类的实例，也就是new的方式
|
|
|
|
|
|
- 访问某个类或接口的静态变量，或者对该静态变量赋值
|
|
|
|
|
|
- 调用类的静态方法
|
|
|
|
|
|
- 反射（如 `Class.forName(“com.shengsiyuan.Test”)`）
|
|
|
|
|
|
- 初始化某个类的子类，则其父类也会被初始化
|
|
|
|
|
|
- Java虚拟机启动时被标明为启动类的类（ `JavaTest`），直接使用 `java.exe`命令来运行某个主类
|
|
|
|
|
|
|
|
|
|
|
|
## 2.4 结束生命周期
|
|
|
|
|
|
在如下几种情况下，Java虚拟机将结束生命周期：
|
|
|
|
|
|
- 执行了 `System.exit()`方法
|
|
|
|
|
|
- 程序正常执行结束
|
|
|
|
|
|
- 程序在执行过程中遇到了异常或错误而异常终止
|
|
|
|
|
|
- 由于操作系统出现错误而导致Java虚拟机进程终止
|
|
|
|
|
|
|
|
|
|
|
|
# 三、类的加载方式
|
|
|
|
|
|
类加载有三种方式：
|
|
|
|
|
|
1. 命令行启动应用时候由JVM初始化加载
|
|
|
|
|
|
2. 通过Class.forName()方法动态加载
|
|
|
|
|
|
3. 通过ClassLoader.loadClass()方法动态加载
|
|
|
|
|
|
|
|
|
|
|
|
**Class.forName()和ClassLoader.loadClass()区别**（是否执行static块）：
|
|
|
|
|
|
- `Class.forName()`：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块；
|
|
|
|
|
|
- `ClassLoader.loadClass()`：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。
|
|
|
|
|
|
- `Class.forName(name,initialize,loader)`带参函数也可控制是否加载static块。并且只有调用了newInstance()方法采用调用构造函数，创建类的对象。
|
|
|
|
|
|
|
|
|
|
|
|
# 四、双亲委派
|
|
|
|
|
|
双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。
|
|
|
|
|
|
![[Snipaste_2023-02-28_13-09-43 4.png]]
|
|
|
|
|
|
双亲委派机制:
|
|
|
|
|
|
- 1、当 `AppClassLoader`加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器`ExtClassLoader`去完成。
|
|
|
|
|
|
- 2、当 `ExtClassLoader`加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader```去完成。
|
|
|
|
|
|
- 3、如果 `BootStrapClassLoader`加载失败（例如在 `$JAVA_HOME/jre/lib`里未查找到该class），会使用 `ExtClassLoader`来尝试加载；
|
|
|
|
|
|
- 4、若ExtClassLoader也加载失败，则会使用 `AppClassLoader`来加载，如果 `AppClassLoader`也加载失败，则会报出异常 `ClassNotFoundException`。
|
|
|
|
|
|
|
|
|
|
|
|
# 五、JVM 内存结构（堆、方法区、栈）
|
|
|
|
|
|
![[640 1.jpg]]
|
|
|
|
|
|
|
|
|
|
|
|
JVM内存结构主要有三大块：**堆内存**、**方法区**和**栈**。堆内存是JVM中最大的一块由年轻代和老年代组成，而年轻代内存又被分成三部分，**Eden空间**、**From Survivor空间**、**To Survivor空间**,默认情况下年轻代按照**8:1:1**的比例来分配；
|
|
|
|
|
|
|
|
|
|
|
|
| | 存放内容 | 说明 |
|
|
|
|
|
|
| ------ | -------- | ---- |
|
|
|
|
|
|
| 堆 | 对象实例 | 所有线程共享 |
|
|
|
|
|
|
| 方法区（永久代） | 被加载类的信息、常量、静态变量、JIT后的代码 | 所有线程共享 |
|
|
|
|
|
|
| 栈 | 局部变量、动态链接、方法出口等 | 线程私有 |
|
|
|
|
|
|
|
|
|
|
|
|
## 5.1 堆（Heap）
|
|
|
|
|
|
对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中**最大**的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，**几乎所有的对象实例都在这里分配内存**。
|
|
|
|
|
|
Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“**GC堆**”。如果从内存回收的角度看，由于现在收集器基本都是采用的分代收集算法，所以Java堆中还可以细分为：**新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。**
|
|
|
|
|
|
根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。
|
|
|
|
|
|
如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
|
|
|
|
|
|
|
|
|
|
|
|
控制参数
|
|
|
|
|
|
- -Xms设置堆的最小空间大小。
|
|
|
|
|
|
- -Xmx设置堆的最大空间大小。
|
|
|
|
|
|
- -XX:NewSize设置新生代最小空间大小。
|
|
|
|
|
|
- -XX:MaxNewSize设置新生代最大空间大小。
|
|
|
|
|
|
- -Xss设置每个线程的堆栈大小。
|
|
|
|
|
|
|
|
|
|
|
|
## 5.2 方法区或永久代（Method Area）
|
|
|
|
|
|
方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，**它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。**虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java堆区分开来。对于习惯在HotSpot虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”。根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
|
|
|
|
|
|
|
|
|
|
|
|
- -XX:PermSize设置永久代最小空间大小。
|
|
|
|
|
|
- -XX:MaxPermSize设置永久代最大空间大小。
|
|
|
|
|
|
|
|
|
|
|
|
## 5.3 栈（Stacks）
|
|
|
|
|
|
Java虚拟机栈（Java Virtual Machine Stacks）是线程私有的，**它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：**每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息。**每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。**
|
|
|
|
|
|
局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向对象起始地址的引用指针，也可能指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。
|
|
|
|
|
|
在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。
|
|
|
|
|
|
|
|
|
|
|
|
## 5.4 出现OOM的情况
|
|
|
|
|
|
1. `Exception in thread “main”: java.lang.OutOfMemoryError: Java heap space` 原因：对象不能被分配到堆内存中
|
|
|
|
|
|
2. 1. `Exception in thread “main”: java.lang.OutOfMemoryError: PermGen space` 原因：类或者方法不能被加载到老年代。它可能出现在一个程序加载很多类的时候，比如引用了很多第三方的库；
|
|
|
|
|
|
3. 1. `Exception in thread “main”: java.lang.OutOfMemoryError: Requested array size exceeds VM limit` 原因：创建的数组大于堆内存的空间
|
|
|
|
|
|
4. 1. `Exception in thread “main”: java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?` 原因：分配本地分配失败。JNI、本地库或者Java虚拟机都会从本地堆中分配内存空间。
|
|
|
|
|
|
5. 1. `Exception in thread “main”: java.lang.OutOfMemoryError: <reason> <stack trace>（Native method）` 原因：同样是本地方法内存分配失败，只不过是JNI或者本地方法或者Java虚拟机发现
|
|
|
|
|
|
|
|
|
|
|
|
# 六、JVM优化
|
