JVM知识点详细整理（长文警告）

傷城~ 2023-09-28 16:46 128阅读 0赞

**目录**

JVM概述

Java跨平台特性

JDK、JRE和JVM的区别

为什么要学习JVM

自动内存管理

Java内存区域与内存溢出异常

运行时数据区域

对象的创建

对象的内存布局

对象的访问定位

垃圾收集器与内存分配策略

判断对象是否存活的方法

引用的分类（强、软、弱、虚）

被判定为不可达的对象一定会被清除吗？

方法区的垃圾收集

垃圾收集算法

分代收集理论

Minor GC、Major GC、Full GC定义

垃圾收集算法分类

经典垃圾收集器

虚拟机指向子系统

Class类文件的结构

虚拟机类加载机制

类加载的过程

类加载器Class Loader

双亲委派模型

虚拟机字节码执行引擎

运行时的栈帧结构长什么样？

方法调用（分派：重载和重写）

什么是动态类型语言？

Tomcat：正统的类加载器架构（了解）

程序编译与代码优化

Javac编译器

即时编译器

提前编译器

编译器优化技术（举例几个重要的）

高效并发

Java内存模型（Java Memory Model）

先行发生原则

Java线程的状态转换

锁优化

Mark Word

管程Monitor

无锁(new)->偏向锁->轻量级锁(自旋锁)->重量级锁

锁粗化和锁消除

--------------------

## JVM概述 ##

#### Java跨平台特性 ####

JVM（Java虚拟机）是Java跨平台的关键。在程序运行前，Java源代码（.java）需要经过编译器编译成字节码（.class）。在程序运行时，JVM负责将字节码翻译成特定平台下的机器码并运行，也就是说，只要在不同的平台上安装对应的JVM，就可以运行字节码文件。

*  翻译的结果是生成字节码，不是机器码，字节码不能直接运行，需要通过JVM翻译成机器码才能运行
 *  跨平台的是Java程序，不是JVM，JVM是用C/C++开发的，不同平台需要安装不同的JVM

Java有JVM从软件层面屏蔽了底层硬件、指令层面的细节让它兼容各种系统。

#### JDK、JRE和JVM的区别 ####

![8e2415e88b104d1ab21b5e9e7ebbf9cc.png][]

jdk中包括了jre，jre包括了jvm。

Java技术体系包括：

![4eda3ed7ac7f414096ed26b907494d9a.png][]

*  JDK：Java程序设计语言、Java虚拟机、Java类库这三部分统称JDK，JDK是用于支持Java程序开发的最小环境。
 *  JRE：Java类库API中的Java SE API子集和Java虚拟机这两部分统称为JRE，JRE是支持Java程序运行的标准环境。

#### 为什么要学习JVM ####

内存管理，Java在开发中不需要考虑内存管理，不像C和C++还需要考虑什么时候释放资源，Java只需要考虑业务实现，在Java虚拟机自动内存管理机制的帮助下，不需要为每一个new操作去写配对的delete/free代码，也不容易出现内存泄漏和内存溢出问题，把控制内存的权力交给了Java虚拟机，但是一旦出现内存泄漏问题，如果不了解虚拟机是怎么使用内存的，那么排查错误、修正问题就很难了。

## 自动内存管理 ##

### Java内存区域与内存溢出异常 ###

#### 运行时数据区域 ####

![e3b28332b640410e920b5a274acaaea2.png][]

①程序计数器（Program Counter Register）

*  是一块较小的内存，当前线程所执行的字节码的行号指示器，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
 *  为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储。
 *  如果线程执行的是一个Java方法，则计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是本地（Native）方法，则计数器值为空（Undefined）
 *  唯一一个没有规定任何OOM（OutOfMemory Error 栈扩展时无法申请到足够的内存）情况的区域

②Java虚拟机栈（Java Virtual Machine Stack）

*  描述的是Java执行的线程内存模型：每个方法被执行的时候，Java虚拟机都会同步创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息。
 *  局部变量表存放了编译期间可知的各种基本数据类型、对象引用类型和returnAddress类型。
 *  两类异常：StackOverflowError（线程请求的栈深度大于虚拟机所允许的深度）和OOM异常

③本地方法栈（Native Method Stack）

*  和虚拟机栈发挥的作用是相似的，区别是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的本地（Native）方法服务。
 *  两类异常StackOverflowError和OOM异常

④Java堆（Java Heap）

*  内存最大的一块，被所有线程共享的一块内存区域，虚拟机启动时创建，存放对象实例。
 *  是垃圾收集器管理的内存区域，也被称作“GC堆”。
 *  可扩展的。如果Java堆中没有内存完成实例分配，并且堆再也无法扩展时，会抛出OOM异常。

⑤方法区（Method Area）

*  和Java堆一样，各个线程共享的内存区域，存储已被虚拟机加载的类型信息、常量、静态变量、即使编译器编译后的代码缓存等数据。
 *  如果方法区无法满足新的内存分配需求时，将抛出OOM异常。
 *  运行时常量池（Runtime Constant Pool）是方法区的一部分，常量池表用于存放编译期生成的各种字面量与符号引用，在类加载后放到运行时常量池中。

#### 对象的创建 ####

当Java虚拟机遇到一条new指令时：

1.  检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并检查这个符号引用代表的类是否已经被加载、解析和初始化过。
2.  如果没有就必须先执行相应的类加载过程
3.  为新生对象分配内存，分配方式有“指针碰撞”和“空闲列表”
4.  将分配到的内存空间（不包括对象头）都初始化为零值
5.  对对象进行必要的设置，例如这个对象是哪个类的实例、如何找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息，这些信息存放在对象的对象头。如根据是否有偏向锁而对对象头有不同的设置方式。
6.  构造函数，执行Class文件中的<init>()方法

#### 对象的内存布局 ####

对象在堆内存中的存储布局可以分为：

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

对象头部分包含两类信息：第一类是用于存储对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。另一部分是类型指针，即对象指向它的类型元数据的指针，Java虚拟机通过这个指针来确定该对象是哪个类的实例。

实例数据部分是对象真正存储的有效信息。即程序代码里面所定义的各种类型的字段内容，默认分配顺序longs/doubles、ints、shorts/chars、bytes/booleans、oops（Odinary Object Pointers），父类中定义的会出现在子类之前。

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

#### 对象的访问定位 ####

主流的访问方式主要有使用句柄和直接指针两种：

*  使用句柄：Java堆中划出一块内存作为句柄池，reference中存储的是对象的句柄地址，句柄中包含了对象实例数据与类型数据各自具体的地址信息。
 *  直接指针：Java堆中对象的内存布局需要考虑如何放置访问类型数据的相关信息，reference中直接存对象地址。

![797c2cedb51d4f01865c693892799184.png][]![ec9399fa3de4403fbd92004aaaa799af.png][]

*  前者的优势：reference中存储的是稳定句柄地址，在对象被移动时只改变句柄中的实例数据指针，而不需要修改reference。
 *  后者的优势：速度更快，节省一次指针定位的时间开销。

### 垃圾收集器与内存分配策略 ###

垃圾收集（Garbage Collection GC），程序计数器、虚拟机栈、本地方法栈3个区域随线程而生而免，因此这三个区域的内存分配和回收都具备确定性。而Java堆和方法区则不确定性，处于运行期间才知道会创建哪些对象，创建多少对象，这部分的分配和回收是动态的。

#### 判断对象是否存活的方法 ####

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

*  引用计数算法：在对象中添加一个引用计数器，每当有一个地方引用它时，计数值就加一；当引用失效时，计数器值就减一；任何时刻计数器为0的对象就是不能再被使用的。（单纯的引用计数难解决对象之间互相循环引用的问题）
 *  可达性分析算法：通过一系列称为“GC Roots”的根对象作为起点，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，或者说从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

![6d5316cfe2d248c297ced7599c83ffcd.png][]

固定可作为GC Roots的对象有以下几种：

*  虚拟机栈（栈帧中的本地向量表）中引用的对象，如各个线程被调用的方法堆栈中使用到的参数、局部变量等
 *  方法区中类静态属性引用的对象，如Java类的引用类型静态变量
 *  方法区中常量引用的对象，如字符串常量池里的引用
 *  本地方法栈中JNI（即Native方法）引用的对象
 *  Java虚拟机内部的引用，如一些常驻的异常对象
 *  所有被同步锁（synchronized关键字）持有的对象
 *  反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

可能还有其他对象“临时性”的加入共同构成完整的GC Roots。

#### 引用的分类（强、软、弱、虚） ####

强引用、软引用、弱引用、虚引用，引用强度依次逐渐减弱。

*  强引用，程序代码之中普遍存在的引用赋值，Object obj = new Object()。无论任何情况下，只要强引用关系还在，垃圾回收器就永远不会回收掉被引用的对象。
 *  软引用，一些还有用，但非必须的对象。在系统将要发生内存溢出异常前，会把这些对象加入回收范围之中再进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。
 *  弱引用，那些非必须的对象，强度比软引用更弱一点，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。
 *  虚引用，“幽灵引用”或者“幻影引用”，最弱的引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。

#### 被判定为不可达的对象一定会被清除吗？ ####

即使在可达性分析算法中被判定为不可达的对象，也不是“非死不可”的，处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那么它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机栈调用过，那么虚拟机将这两种情况都视为“没有必要执行”。

被判定为有必要执行finalize()方法，那么该对象会被放置在一个名为F-Queue的队列之中，之后会有线程去执行它们的finalize()方法。finalize()方法是对象逃脱死亡命运的最后一次机会，然后会对F-Queue中的对象进行第二次小规模的标记。如果还没有逃脱，那就真的要被回收了。

【注意】任何一个对象的finalize()方法只会被系统自动调用一次。

#### 方法区的垃圾收集 ####

方法区的垃圾收集的“性价比”比较低，Java堆中尤其是新生代，一次垃圾回收可以回收70%至90%的空间，但是方法区就很低了，它主要回收两部分的内容：废弃的常量和不再使用的类型。

判定一个常量废弃：没有任何字符串对象引用常量池中的某个常量，且虚拟机也没有其他地方引用这个字面量。

判定一个类型是否属于“不再被使用的类”：同时满足下面三个条件，但是满足了也不一定会被回收，只能说是“被允许”回收。

*  该类所有的实例都已经被回收
 *  加载该类的类加载器已经被回收
 *  该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

#### 垃圾收集算法 ####

*  引用计数式垃圾收集 “直接垃圾收集”
 *  追踪式垃圾收集 “间接垃圾收集” 后面讨论的均为这种

#### 分代收集理论 ####

*  弱分代假说：绝大多数对象都是朝生夕灭的
 *  强分代假说：熬过越多次垃圾收集过程的对象就越难以消亡

所以：收集器应该将Java堆划分出不同的区域，然后将回收对象依据年龄分配到不同的区域之中存储。因此有了Minor GC、Major GC、Full GC这样的划分，以及“标记-复制算法”、“标记-清除算法”、“标记-整理算法”等垃圾收集算法。

*  跨代引用假说：跨代引用相对于同代引用来实仅占极少数

所以：我们不应该为少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录每一个对象是否存在及存在哪些跨代引用，只需在新生代上建立一个全局的数据结构“记忆集”，这个结构把老年代划分成若干个小块，标识出老年代的哪一块内存会存在跨代引用。此后发生Minor GC时，只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots中进行扫描。

#### Minor GC、Major GC、Full GC定义 ####

*  部分收集 Partial GC，目标不是完整收集整个Java堆的垃圾收集。其中又分为：新生代收集（Minor GC/Young GC）、老年代收集（Major GC/Old GC）、混合收集（Mixed GC）
 *  整堆收集 Full GC，收集整个Java堆和方法区的垃圾收集。

目前只要CMS收集器会有单独收集老年代的行为，只有G1收集器有混合收集行为，收集整个新生代以及部分老年代。

#### 垃圾收集算法分类 ####

*  标记-清除算法：分为“标记”和“清除”两个阶段，首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象。

缺点：①执行效率不稳定，随对象数量的增加而降低②内存空间的碎片化严重

*  标记-复制算法：将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块用完了，就将还活着的对象复制到另一块上，再把这一块已使用的空间一次清理掉。

如果内存中多数都是存活的，那会增加开销，但对于多数都是可回收的情况，算法需要复制的就是占少数的存活对象，而且也不用考虑空间碎片的复杂情况，只要顺序移动指针分配即可。缺点是可用内存空间缩小一半。

*  标记-整理算法：首先标记出所有需要回收的对象，标记完成后，让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。

对于老年代这种有大量对象存活的区域，如果移动存活对象并更新所有引用这些对象的地方，必须得**全部暂停用户应用程序才能进行**。

标记-清除和标记整理，是否移动对象都存在弊端，移动则内存回收时会更复杂，不移动则内存分配时会更加复杂。还一种解决方案，就是让虚拟机平时多数时间都采用标记-清除算法，暂时容忍内存碎片的存在，直到内存空间的碎片化程度已经大到影响对象分配时，再采用标记-整理算法收集一次，以获得规整的内存空间。CMS收集器就是这种处理方式。

#### 经典垃圾收集器 ####

![fd220725479f474ab3c35db81f4af6f9.png][]

上图展示了七种作用于不同分代的收集器，存在连线说明它们可以搭配使用。

*  Serial收集器：单线程工作的收集器，标记-复制法，进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。简单高效，是所有收集器里额外内存消耗最小的。HotSpot虚拟机运行在客户端模式下的默认新生收集器。
 *  ParNew收集器：是Serial收集器的多线程并行版本，标记-复制法，随着处理器核心数量的增加，ParNew对于垃圾收集时系统资源的高效利用还是有好处的。

在谈论垃圾收集时，并发和并行这么理解：

①并行，多条垃圾收集器线程之间的关系，同一时间有多条这样的线程在协同工作，此时默认用户线程是处于等待状态。

②并发，垃圾收集器与用户线程之间的关系，同一时间垃圾收集器线程与用户线程都在运行。系统能响应服务请求，但是吞吐量会受影响。

*  Parallel Scavenge收集器：新生代收集器，并行收集，标记-复制法，目标是达到一个可控制的吞吐量，高吞吐量可以更高效地利用处理器资源，尽快完成程序的运算任务。有垃圾收集的自适应的调节策略。
 *  Serial Old收集器：单线程收集器，使用标记-整理法，是Serial收集器的老年代版本。
 *  Parallel Old收集器：标记-整理法，多线程并发收集，是Parallel Scavenge收集器的老年代版本，jdk6开始提供，“吞吐量优先”收集器开始有了名副其实的搭配组合（和Parallel Scavenge收集器搭配）。
 *  CMS收集器：获取最短回收停顿时间为目标，基于标记-清除法，并发收集、低停顿，包括初始标记、并发标记、重新标记、并发清除四个步骤。但是，对处理器资源敏感、无法处理“浮动垃圾”、收集结束会产生大量空间碎片（可能会提前Full GC操作）。

首先说一下四个阶段：①初始标记：仅仅标记一下GC Roots能直接关联到的对象，速度很快；②并发标记：从GC Roots的直接关联对象开始遍历整个对象图的过程，耗时长但不需要停顿用户线程，并发运行；③重新标记：修正并发标记时因为用户程序运作而导致标记产生变动的那一部分对象的标记记录；④并发清除：清理删除掉标记阶段判断的已经死亡的对象，因为不需要移动存活对象，所以和用户线程并发执行。

产生“浮动垃圾”：并发标记和并发清除这两个阶段，用户现场还是在继续的，就会有新的垃圾对象产生，但是这一部分是出现在标记过程结束之后，CMS无法在档次收集中处理它们，只能留到下一次。而且由于并发，还得预留一部分空间给用户线程使用，所以不能等老年代几乎被填满才进行收集操作。

*  Garbage First（G1）收集器：面向服务端应用的垃圾收集器，面向堆内存任何部分来组成会收集进行回收，不分代，哪块内存中垃圾数量最多，回收收益最大。Mixed GC模式。把连续的Java堆划分为多个大小相等的独立区域Region，每一个Region都可以根据需要，扮演新生代的Eden、Survivor或者老年代空间，动态的。将Region作为单次回收的最小单元，每次都是收集的内存空间都是Region大小的整数倍。有初始标记、并发标记、最终标记、筛选回收四个步骤。

Region中还有一类特殊的Humongous区域，专门存储大对象->超过Region容量的一半，对于超过了整个Region容量的超级大对象会被存放在N个连续的Humongous Region区域中。

G1收集器会去跟踪各个Region里面的垃圾堆积的价值大小，维护一个优先级列表，根据用户设定允许的收集停顿时间，优先处理回收价值收益最大的那些Region。G1从整体来看是基于标记-整理算法的，从局部上（两个Region之间）看又是基于标记-复制算法的。

衡量垃圾收集器的三项最重要的指标：内存占用、吞吐量、延迟。

*  ZGC收集器：Z Garbage Collector是jdk11中新加入的具有实验性质的低延迟垃圾收集器。同样采用基于Region的堆内存布局，分为小型Region（2MB）、中型Region（32MB）、大型Region（N\*2MB，动态变化的），采用染色指针技术，把标记信息记在引用对象的指针上，染色指针可以使得一旦某个Region的存活对象被转移之后，这个Region立即就能够被释放和重用，而不必等待整个堆中所有指向该Region的引用都被修正后才能清理。并发标记、并发预备重分配、并发重分配、并发重映射四个大阶段。

这个垃圾收集器可以去具体看看它的过程，上图中没有它是因为它是jdk11才出现的，尚未具备全部商用收集器应有的特征，而且可能还在不断变化中，稍微知道一下即可。

## 虚拟机指向子系统 ##

字节码是构成平台无关性的基石，“一次编写，到处运行”。Java语言中的各种语法、关键字、常量变量和运算符号的语义最终都会由多条字节码指令组合来表达，字节码指令提供的语言描述能力比Java本身更强大。

![a60d9f02d15642819712a1aa1f21b309.png][]

#### Class类文件的结构 ####

任何一个Class文件都对应着唯一的一个类或接口的定义信息，但是反过来，类或接口并不一定都得定义在文件里（比如动态生成，直接送入类加载中）。

Class文件是一组以8个字节为基础单位的二进制流。Class文件格式采用类似C语言结构体的伪结构来存储数据，只有两种数据类型：“无符号数”和“表”

*  无符号数，基本的数据类型，u1、u2、u4、u8分别表示1个字节、2个字节、4个字节和8个字节的无符号数，可以用来描述数字、索引引用、数量值或者按照UTF-8编码构成字符串值。
 *  表，多个无符号数或者其他表作为数据项构成的复合数据类型。

![5f45b7596b604088bb22770bf4d13c4d.png][]

关于表中的数据项，无论是顺序还是数量甚至于数据存储的字节序，都是被严格限制的。

#### 虚拟机类加载机制 ####

一个类型从被加载到虚拟机内存中开始，到写在出内存为止，它的整个生命周期将会经历加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）、卸载（Unloading）七个阶段。

![4e9f8ceadc29408db19094ff9dd3f867.png][]

其中验证、准备、解析三部分统称为连接（Linking）。

#### 类加载的过程 ####

加载阶段

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

二进制数据流的来源可以有很多，比如zip压缩包中（jar、war）、网络中获取、运行时计算生成等。

加载阶段结束后，Java虚拟机外部的二进制字节流就按照虚拟机所设定的格式存储在方法区之中了。

验证阶段

确保Class文件的字节流中包含的信息符合约束要求，保护这些信息被当作代码运行后不会危害虚拟机自身的安全。主要是文件格式验证、元数据验证、字节码验证和符号引用验证四个阶段。

文件格式验证是基于二进制字节流进行的，后面三个验证阶段是基于方法区的存储结构进行的。

准备阶段

是正式为类中定义的变量（静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段。这里的初始值通常是数据类型的零值。

public static int value = 99;

【注意】那变量value在准备阶段后的初始值是0而不是99，因为这个时候还没有执行任何的Java方法，而把value赋值为99的指令是程序被编译之后，存放于类构造器<clinit>()方法中，所以value赋值为99的动作要放在类的初始化阶段才会被执行。也有特殊情况，如果被声明为final类型的，那就会被初始化为99。

public static final int value = 99;

解析阶段

是Java虚拟机将常量池内的符号引用替换为直接引用的过程。符号引用以一组符号来描述所引用的目标；直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。

初始化阶段

Java虚拟机真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。初始化阶段就是执行类构造器<clinit>()方法的过程。

<clinit>()方法是Javac编译器的自动生成物，编译器自动收集类中的所有类变量的赋值动作和静态语句块（static\{\}块）中语句和并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的。同时还会保证，子类的<clinit>()方法执行前，父类的<clinit>()已经执行完。还必须保证一个类的<clinit>()方法在多线程环境中被正确地加锁同步，只能有一个线程在同一时间去执行这个类的<clinit>()方法。

【注意】<clinit>()并不是必须的，如果没有静态语句块或者静态变量赋值操作，那编译器就不会生成<clinit>()方法。

#### 类加载器Class Loader ####

类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到虚拟机的外部去实现，以便让应用程序自己决定如何区获取所需的类。

任何一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性。即使两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

*  启动类加载器（Bootstrap Class Loader）：使用C++实现，是虚拟机自身的一部分。启动类加载器无法被Java程序直接引用。
 *  扩展类加载器（Extension Class Loader）：Java实现的，负责加载<JAVA\_HOME>\\lib\\ext目录中或者被java.ext.dirs系统变量所指定的路径中所有的类库。开发者可以直接在程序代码中使用扩展类加载器来加载Class文件。
 *  应用程序类加载器（Application Class Loader）：由于应用程序类加载器是ClassLoader类中的getSystemClassLoader()方法的返回值，所以也称“系统类加载器”，负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以使用。

#### 双亲委派模型 ####

![f2fcf89c222f45c8a5f1b0f290cf19b0.png][]

双亲委派模型工作过程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求时（它的搜索范围中没有找到所需的类），子加载器才会尝试自己去完成加载。

好处：Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。对于保证Java程序的稳定运作极为重要。

*  （例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的的ClassPath中，那么系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序就会变得一片混乱。）

#### 虚拟机字节码执行引擎 ####

执行引擎是Java虚拟机核心的组成部分之一。物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。执行引擎执行字节码：

*  解释执行（通过解释器执行）
 *  编译执行（通过即时编译器产生本地代码执行）

#### 运行时的栈帧结构长什么样？ ####

![a74e07a72a4d4afb9fc991c1c5446d34.png][]

“当前栈帧”：对于执行引擎来说，在线程活动中，只有位于栈顶的方法才是在运行的，只有位于栈顶的栈帧才是生效的，其被称为“当前栈帧”。

局部变量表是一组变量值的存储空间，用于存放方法参数和方法内部定义的局部变量。前面在介绍句柄的时候提到了reference，这个reference就是存储在局部变量表里面的，reference类型表示对一个对象实例的引用，一是根据引用直接或间接地查找到对象在Java堆中的数据存放的起始地址或索引，二是根据引用直接或间接地查找到对象所属类型在方法区中的存储的类型信息。

【注意】我们前文说到类变量有两次赋值的过程，一次是准备阶段，赋予系统初始值，一次是初始化阶段，赋予程序员定义的初始值。打算局部变量就不一样了，如果局部变量没有赋初始值，就不能使用了，他没有默认赋予初始值这样的规则。

操作数栈：也是操作栈，先入后出，操作数栈中元素的数据类型必须与字节码指令的序列严格匹配。

动态连接，每一个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用。

方法返回地址，当一个方法开始执行时只有两种方式退出这个方法，一是执行引擎遇到任意一个方法返回的字节码指令，二是在方法执行的过程中遇到了异常。方法退出都必须返回到最初方法被调用的位置，程序才能继续执行。方法正常退出时，主调方法的PC计数器的值就可以作为返回地址，但是异常退出时，返回地址主要是通过异常处理器表来确定的。

#### 方法调用（分派：重载和重写） ####

方法调用并不等同于方法中的代码被执行，方法调用阶段唯一的任务是确定被调用方法的版本即确定调用哪一个方法。一切方法调用在Class文件里面存储的都只是符号引用，某些调用需要在类加载期间，甚至到运行期间才能确定目标方法的直接引用。

*  解析调用：在类加载的解析阶段，会将其中一部的符号引用转化为直接引用。调用目标在程序代码写好、编译器进行编译时就已经能确定下来。主要有静态方法、私有方法、实例构造器、父类方法、final修饰的方法。
 *  分派调用：静态分派、动态分派。主要是多态性的体现。

静态分派，依赖静态类型来决定方法执行版本，最典型的是重载。发生在编译阶段，因此静态分派的动作实际上不是由虚拟机来执行的，有些把它纳入解析调用，编译器在重载时根据参数的静态类型而不是实际类型作为判断依据，根据参数的静态类型决定使用哪个重载版本。

动态分派，在运行期根据实际类型确定方法执行版本，重要体现是重写，根据方法接收者的实际类型来选择方法版本 。

静态分派属于多分派类型，动态分派属于单分派类型。

虚拟机动态分派的实现：在为类型在方法区中建立一个虚方法表（vtable），使用虚方法表索引来代替元数据查找以提高性能。虚方法表中存放着各个方法的实际入口地址。这样当类型转换时，仅需要变更查找的虚方法表，从不同的虚方法表中按照索引转换出所需的入口地址。虚方法表一般在类加载的连接阶段进行初始化。

*  如果某个方法在子类中没有被重写，那子类的虚方法表的入口地址和父类相同方法的入口地址相同，都指向父类的实现入口。
 *  如果子类中重写了这个方法，那么子类虚方法表中的地址也会被替换为指向子类实现版本的入口地址。

#### 什么是动态类型语言？ ####

动态类型语言的关键特征是数据类型检查的主体过程是在运行期而不是编译期进行的。比如JavaScript、PHP、Python等语言，在编译期就进行类型检查过程的语言，比如Java和C++就是静态类型语言。（注意是：数据类型的检查）

*  动态类型语言编程时，不用给任何变量指定数据类型，该语言会在第一次赋值给变量时，在内部将数据类型记录下来。静态类型语言的数据类型在编译期间检查，也就是说在写程序时要声明所有变量的数据类型。

public static void main(String[] args){
        int[][][] array = new int[1][0][-1];
    }

上面代码能正常编译，但是运行的时候会出现NegativeArraySizeException异常，这是一个运行时异常，通俗解释就是不执行到这一行不会出现问题。与运行时异常相对应的是连接时异常，比如NoClassDefFoundError。

但其实在C语言里，这个代码就会在编译期间直接报错，而不是等到运行时：

int main(void){
       int arr[1][0][-1]; //GCC拒绝编译，会报“size of array is negative”
       return 0;
    }

*  静态类型语言能够在编译期确定变量类型，最显著的好处是编译器可以提供全面严谨的类型检查，这样与数据类型相关的潜在问题就能在编码时被及时发现，利于稳定性及让项目容易达到更大的规模。
 *  动态类型语言在运行期才确定类型，这可以为开发人员提供极大的灵活性，某些在静态语言中要花大量臃肿代码来实现的功能，由动态类型语言去做可能会很清晰简洁，开发效率提升。

#### Tomcat：正统的类加载器架构（了解） ####

在Tomcat目录结构中，可以设置三组目录用于存放Java类库，另外再加上Web应用程序自身的WEB-INF目录。

*  /Common目录：类库可被Tomcat和所有的Web应用程序共同使用。
 *  /server目录：类库可悲Tomcat使用，对所有的Web应用程序都不可见。
 *  /shared目录：类库可被所有的Web应用程序共同使用，但对Tomcat自己不可见
 *  /WebApp/WEB-INF目录：类库仅仅可被该Web应用程序使用，对Tomcat和其他Web应用程序都不可见。

为了支持这套目录结构，并对里面的类进行加载和隔离，Tomcat自定义了多个类加载器，按照经典的双亲委派模型来实现。

![099ec099045541138d2a6b6e8d91727e.png][]

Common类加载器能加载的类都可以被Cataline类加载器和Shared类加载器使用，而Cataline类加载器和Shared类加载器自己能加载的类与对方相互隔离。WebApp类加载器可以使用Shared类加载器加载到的类，但各个WebApp类加载器实例之间相互隔离。而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个Class文件。

以上是Tomcat6之前的默认类加载器结构，之后的版本简化了，只有指定了server.loader和share.loader项才会真正建立Cataline类加载器和Shared类加载器的实例，否则都会使用Common类加载器的实例代替。所以Tomcat6之后都把/Common、/server、/shared这三个目录默认合并到一起变成了一个/lib目录项。

【问题】：Spring要对用户程序的累类进行管理，自然要访问到用户程序的类，但是用户程序显然是放在/Web/WEB-INF目录中，那么被Common类加载器或者Shared类加载器加载的Spring若一个访问并不在其加载范围内的用户程序呢？

【答案】：使用线程上下文类加载器。 Spring加载类所用的classLoader都是通过Thread.currentThread().getContextClassLoader()获取的。当线程创建时会默认创建一个AppClassLoader类加载器（对应Tomcat中的WebAppclassLoader类加载器）： setContextClassLoader(AppClassLoader)。  
利用这个来加载用户程序。即任何一个线程都可通过getContextClassLoader()获取到WebAppclassLoader。

## 程序编译与代码优化 ##

*  前端编译器：把\*.java文件转变成\*.class文件。jdk的javac、Eclipse JDT中的增量式编译器
 *  即时编译器：把字节码转变成本地机器码。HotSpot虚拟机的C1、C2编译器，Graal编译器
 *  提前编译器：直接把程序编译成与目标机器指令集相关的二进制代码。jdk的Jaotc、GUN Compiler for the Java、Excelsior JET

#### Javac编译器 ####

编译过程大致可以分为1个准备过程和3个处理过程：

*  准备过程：初始化插入式注解处理器。
 *  解析与填充符号表过程：包括词法和语法分析（将源代码的字符流转变为标记集合，构造出抽象语法树）、填充符号表（产生符号地址和符号信息）。
 *  插入式注解处理器的注解处理过程：插入式注解处理器的执行阶段。
 *  分析与字节码生成过程：包括标注检查（对语法的静态信息进行检查）、数据流及控制流分析（对程序动态运行过程进行检查）、解语法糖（将简化代码编码的语法糖还原成原有的形式）、字节码生成（将前面各个步骤所生成的信息转化成字节码）。

标注检查步骤要检查的内容包括诸如变量使用前是否已经被声明、变量与赋值之间的数据类型是否能够匹配等，该过程还会进行常量折叠的代码优化。数据流及控制流分析，是对程序上下文逻辑更进一步的验证，它可以检查出比如程序局部变量在使用前是否有赋值、方法的每条路径是否都有返回值、是否所有的受查异常都被正确处理了等问题。Java中最常见的语法糖包括泛型、变长参数、自动装箱拆箱等。字节码生成不仅仅是把前面各个步骤所生产的信息（语法树、符号表）转化成字节码指令写到磁盘中，还进行了少量的代码添加和转换工作，例如实例构造器<init>()方法和<clinit>()方法就是这个阶段被加到语法树之中的。

#### 即时编译器 ####

即时编译器所做的事情：Java程序最初都是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁，就会把这些代码认定为“热点代码”，为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成本地机器码，并尽可能地优化代码。

解释器与编译器：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即运行。当程序启动后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，这样可以减少解释器的中间损耗，获得更高的执行效率。

![ae670fbfdb3d45b3a421991ec98730b1.png][]

客户端编译器-C1编译器、服务端编译器-C2编译器，以及用来代替C2的Graal编译器。

#### 提前编译器 ####

提前编译器有两条明显的分支，一条是做和传统C编译器类似，在程序运行之前把程序代码编译成机器码的静态翻译工作。一条是把原本即时编译器在运行时要做的编译工作提前做好并保存下来，下次运行到这些代码时直接把它加载进来使用（比如公共库代码在被同一台机器其他Java进程使用）。

第二条本质是给即时编译器做缓存加速，去改善Java程序的启动时间，以及需要一段时间预热后才能到达最高性能的问题。

#### 编译器优化技术（举例几个重要的） ####

*  方法内联：消除方法的调用成本，为其他优化手段建立良好的基础。
 *  逃逸分析：分析对象动态作用域，当一个对象在方法里面被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法，这种叫方法逃逸；甚至还有可能被外部线程访问到，比如可以在其他线程中访问的实例变量，这种叫线程逃逸。优化方式有栈上分配（支持方法逃逸）、标量替换、同步消除
 *  公共子表达式消除：如果一个表达式E之前被计算过了，并且从先前的计算到现在E中所有的变量的值都没有发生变化，那么E的这次出现就成为公共子表达式。
 *  数组边界检查消除：即将运行期检查提前到编译器完成的思路。在编译器确定下标是否越界，没有的话在执行期间就不需要判断了，循环变量也是，在编译期间判断循环变量的范围是否在数组区间范围内，执行期间就不需要判断了，节省很多次的条件判断。还一种隐式异常处理。

## 高效并发 ##

#### Java内存模型（Java Memory Model） ####

使用Java内存模型来屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。

![ffc6da446e03414ca0239217421898b9.png][]

主要目的是定义程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。这里所说的变量包括实例字段、静态字段和构成数组对象的元素，但不包括局部变量和方法参数，因为它们是线程私有的，它们不会被共享，自然不存在竞争问题。

*  所有的变量都存储在主内存中。每条线程有自己的工作内存，线程的工作内存中保存了被该线程使用的变量的主内存副本，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同的线程也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。
 *  主内存主要对应于堆中对象的实例部分，而工作内存主要对应与虚拟机栈中的部分区域。
 *  主内存主要对应于硬件内存部分，工作内存主要对应于CPU的高速缓存和寄存器部分。

八种内存操作：

*  lock：锁定，作用于主内存的变量，它把主内存中的变量标识为一条线程独占状态
 *  unlock：解锁，作用于主内存的变量，它把锁定的变量释放出来，释放出来的变量才可以被其它线程锁定
 *  read：读取，作用于主内存的变量，它把一个变量从主内存传输到工作内存中，以便后续的load操作使用
 *  load：载入，作用于工作内存的变量，它把read操作从主内存得到的变量放入工作内存的变量副本中
 *  use：使用，作用于工作内存的变量，它把工作内存中的一个变量传递给执行引擎
 *  assign：赋值，作用于工作内存的变量，它把一个从执行引擎接收到的变量赋值给工作内存的变量
 *  store：存储，作用于工作内存的变量，它把工作内存中一个变量的值传递到主内存中，以便后续的write操作使用
 *  write：写入，作用于主内存的变量，它把store操作从工作内存得到的变量的值放入到主内存的变量中

三个特性：原子性、可见性、有序性

*  原子性：一段操作一旦开始就会一直运行到底，中间不会被其它线程打断。原子性操作包括read、load、use、assign、store、write，可以大致认为基本类型变量的读写是具备原子性的。可以使用lock和unlock来满足更大范围的原子性，lock和unlock是实现synchronized的基础，Java并没有把lock和unlock操作直接开放给用户使用，但是却提供了两个更高层次的指令来隐式地使用这两个操作，即moniterenter和moniterexit。
 *  可见性：当一个线程修改了共享变量的值，其它线程能立即感知到这种变化。变更修改后同步回主内存，在变量读取前从主内存刷新。volite变量可以保证多线程可见性：普通变量与volatile变量的主要区别是是否会在修改之后立即同步回主内存，以及是否在每次读取前立即从主内存刷新。synchronized的可见性：通过lock和unlock实现，对一个变量执行lock操作，会清空工作内存中的值，在执行引擎使用这个变量前，需要重新从主内存读取；对一个变量执行unlock操作之前，必须先把此变量同步回主内存中。final的可见性：被final修饰的字段在构造器中一旦被初始化完成，那么其它线程中就能看见这个final字段了。
 *  有序性：如果在本线程中观察，所有的操作都是有序的；如果在另一个线程中观察，所有的操作都是无序的。本线程操作有序，串行语义。其他线程操作无序，“指令重排序”现象和“工作内存和主内存同步延迟”现象。volite天然有序，其禁止重排序。synchronized的有序性，“一个变量同一时刻只允许一条线程对其进行lock操作”这条规则。

#### 先行发生原则 ####

如果Java内存模型中所有的有序性都仅靠volatile和synchronized来完成，那么有一些操作就会变得很啰嗦，但是我们在编写Java并发代码时并没有感受到，这是因为Java语言天然定义了一个“先行发生”原则，这个原则非常重要，依靠这个原则我们可以很容易地判断在并发环境下两个操作是否可能存在竞争冲突问题。

先行发生，是指**操作A先行发生于操作B，那么操作A产生的影响能够被操作B感知到**，这种影响包括修改了共享内存中变量的值、发送了消息、调用了方法等。**先行发生不等于时间上的先发生**。

*  程序次序规则：在一个线程内，按照程序的顺序执行，前面的操作先行发生于后面的操作
 *  监视器锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作
 *  volatile变量规则：对一个volatile变量的写操作先行发生于后面对该变量的读操作
 *  线程启动规则：对线程的start()操作先行发生于线程内的任何操作
 *  线程终止规则：线程中的所有操作先行发生于检测到线程终止，可以通过Thread.join()、Thread.isAlive()的返回值检测线程是否已经终止
 *  线程中断规则：对线程的interrupt()的调用先行发生于线程的代码中检测到中断事件的发生，可以通过Thread.interrupted()方法检测是否发生中断
 *  对象终结规则：一个对象的初始化完成（构造方法执行结束）先行发生于它的finalize()方法的开始
 *  传递性规则：如果操作A先行发生于操作B，操作B先行发生于操作C，那么操作A先行发生于操作C

#### Java线程的状态转换 ####

![b0947ff04c3f427fa9d5b9cf6c67d3dd.png][]

### 锁优化 ###

#### Mark Word ####

markword是每个对象Object的头部的8个字节(64bit)，用来储存锁信息、GC信息等。

![b59a8ed3996045129ffe5afd2ac409f5.png][]

对象hashcode：

*  无锁状态下，Mark Word中可以存储对象的hashcode值。当对象的hashCode()方法第一次被调用时，JVM会生成hashcode并将其存储到Mark Word中。后续如果该对象的hashCode()方法再次被调用则不会再通过JVM进行计算得到，而是直接从Mark Word中获取。
 *  当一个对象已经计算过hashcode，它就无法进入偏向锁状态
 *  当一个对象当前正处于偏向锁状态，并且需要计算hashcode的话，则它的偏向锁会被撤销，并且锁会膨胀为轻量级锁或者重量锁
 *  轻量级锁的实现中，会通过线程栈帧的锁记录存储Displaced Mark Word；重量锁的实现中，ObjectMonitor类里有字段可以记录非加锁状态下的mark word，其中可以存储identity hash code的值。

#### 管程Monitor ####

管程是一种程序结构，结构内的多个子程序形成的多个工作线程互斥访问共享资源。

管程提供了一个入口，保证一次只有一个进程可以进入，其他试图进入管程的进程被阻塞并加入等待队列中。当一个进程在管程中时，它可能会通过发送cwait(x)把自己暂时阻塞在条件x上，放入条件队列。另一个进程发送csignal(x)，唤醒条件队列中的线程。

#### 无锁(new)->偏向锁->轻量级锁(自旋锁)->重量级锁 ####

*  偏向锁：当没有多线程竞争，只有一个线程去获取锁，此时进入偏向锁状态。当一个线程访问同步代码并获取锁时会在对象头和栈帧中的锁记录里存储锁偏向的线程ID,以后该线程在进入和退出同步块时不需要CAS操作来加锁和解锁

获取偏向锁：首先判断对象是否为偏向锁状态，再判断是否有线程持有该对象(threadId是否有值)，如果为空，则通过CAS设置为当前线程的ID；如果不为空，且threadId为当前线程，则直接执行同步块；如果不为空，且threadId为其他线程，或者CAS失败，则释放偏向锁（为无锁或者升级锁）。

释放偏向锁：线程不会主动去释放偏向锁，需要等待其他线程来竞争，此时才会释放偏向锁。若获得偏向锁的线程处于未活动状态或者已退出同步代码块，则释放偏向锁，变为无锁；若获得偏向锁的线程仍未退出同步代码块，则升级为轻量级锁。

*  轻量级锁：引入轻量级锁的主要目的是在短时间竞争不激烈的前提下，减少使用重量级锁的性能消耗。当关闭偏向锁功能或者多个线程竞争偏向锁导致偏向锁升级为轻量级锁，则会尝试获取轻量级锁，适用于2个线程相互竞争锁的情况。

获取轻量级锁：首先判断是否处于无锁态（关闭偏向锁功能时）。如果否，则判断当前对象的Mark Word是否指向当前线程id（偏向锁态），如果是则表示当前线程已经持有当前对象的锁，则直接升级为轻量级锁，执行同步代码块；如果否，明该锁已经被其他线程抢占了。处于无锁状态或者该锁被其他线程抢占了，那么在当前线程的栈帧中建立一个名为锁记录(Lock Record)的空间，用于存储锁对象的Markword的拷贝(Displaced Markword)，通过CAS操作尝试将对象的Mark Word更新为指向 Lock Record的指针。如果成功，则表示获取到锁，开始执行同步代码块；如果失败，自旋锁（jdk1.4，不断CAS，自旋超过一定次数(10次) ，就升级为重量级锁）和适应自旋锁（jdk1.8，自旋次数并非是固定的，而是会根据实际情况动态改变自旋等待的次数）。

释放轻量级锁：CAS将之前复制在栈桢中的 Displaced Mard Word 替换回 Mark Word 中。

*  重量级锁：重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高

#### 锁粗化和锁消除 ####

*  锁粗化：将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁，避免频繁的加锁解锁操作
 *  锁消除：JIT编译时通过对运行上下文的扫描，经过逃逸分析，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁

[8e2415e88b104d1ab21b5e9e7ebbf9cc.png]: https://img-blog.csdnimg.cn/8e2415e88b104d1ab21b5e9e7ebbf9cc.png
[4eda3ed7ac7f414096ed26b907494d9a.png]: https://img-blog.csdnimg.cn/4eda3ed7ac7f414096ed26b907494d9a.png
[e3b28332b640410e920b5a274acaaea2.png]: https://img-blog.csdnimg.cn/e3b28332b640410e920b5a274acaaea2.png
[797c2cedb51d4f01865c693892799184.png]: https://img-blog.csdnimg.cn/797c2cedb51d4f01865c693892799184.png
[ec9399fa3de4403fbd92004aaaa799af.png]: https://img-blog.csdnimg.cn/ec9399fa3de4403fbd92004aaaa799af.png
[6d5316cfe2d248c297ced7599c83ffcd.png]: https://img-blog.csdnimg.cn/6d5316cfe2d248c297ced7599c83ffcd.png
[fd220725479f474ab3c35db81f4af6f9.png]: https://img-blog.csdnimg.cn/fd220725479f474ab3c35db81f4af6f9.png
[a60d9f02d15642819712a1aa1f21b309.png]: https://img-blog.csdnimg.cn/a60d9f02d15642819712a1aa1f21b309.png
[5f45b7596b604088bb22770bf4d13c4d.png]: https://img-blog.csdnimg.cn/5f45b7596b604088bb22770bf4d13c4d.png
[4e9f8ceadc29408db19094ff9dd3f867.png]: https://img-blog.csdnimg.cn/4e9f8ceadc29408db19094ff9dd3f867.png
[f2fcf89c222f45c8a5f1b0f290cf19b0.png]: https://img-blog.csdnimg.cn/f2fcf89c222f45c8a5f1b0f290cf19b0.png
[a74e07a72a4d4afb9fc991c1c5446d34.png]: https://img-blog.csdnimg.cn/a74e07a72a4d4afb9fc991c1c5446d34.png
[099ec099045541138d2a6b6e8d91727e.png]: https://img-blog.csdnimg.cn/099ec099045541138d2a6b6e8d91727e.png
[ae670fbfdb3d45b3a421991ec98730b1.png]: https://img-blog.csdnimg.cn/ae670fbfdb3d45b3a421991ec98730b1.png
[ffc6da446e03414ca0239217421898b9.png]: https://img-blog.csdnimg.cn/ffc6da446e03414ca0239217421898b9.png
[b0947ff04c3f427fa9d5b9cf6c67d3dd.png]: https://img-blog.csdnimg.cn/b0947ff04c3f427fa9d5b9cf6c67d3dd.png
[b59a8ed3996045129ffe5afd2ac409f5.png]: https://img-blog.csdnimg.cn/b59a8ed3996045129ffe5afd2ac409f5.png