深入理解Java虚拟机

优点

缺点

优点

缺点

典型应用是X86的二进制指令集，比如传统的PC以及安卓的Davlik虚拟机

大部分情况下，指令集往往以一地址指令，二地址指令和三地址指令为主

-v输出附加信息

-l输出行号和本地变量表

-p显示所有类和成员

-c对代码进行反汇编

通过引导类加载器（Bootstrap Class Loader）创建一个初始类来完成的，这个类是由虚拟机的具体实现指定的

JVM启动的入口就是main方法

一个JVM虚拟机就是一个进程

执行一个所谓的Java程序的时候，真正执行的是一个叫Java虚拟机的进程

每个线程执行子类重写的run方法或者是Runable接口实现类中run方法

程序正常执行结束

执行过程遇到异常或错误而异常终止

操作系统错误导致Java虚拟机进程终止

Runtime类或System类的exit()方法、Runtime类的halt()方法，并且Java安全管理器允许这次exit或halt操作

JNI（Java Native Interface）规范描述了用JNI Invocation API来加载或卸载Java虚拟机时，Java虚拟机退出的情况

没有一个前台线程了，也就是所有的线程都是后台守护线程，JVM会退出

世界第一款商用Java虚拟机

JDK1.4时被淘汰

只提供了解释器

如果使用JIT编译器，就需要外挂，但是JIT和解释器不能配合工作

为了解决上一个虚拟机问题，JDK1.2时，sun提供了此虚拟机

Exact Memory Management：准确式内存管理

具有现代高性能虚拟机的雏形

只在Solaris平台短暂使用，其他平台还是Classic VM

最初由Longview  Technologies的小公司设计，1997年被sun公司收购，2009年sun公司被甲骨文收购

JDK1.3时，HotSpot VM成为默认虚拟机

绝对市场地位，称霸武林

HotSpot最大的卖点就是他的热点代码探测技术

BEA公司

专注服务器端应用

世界上最快的JVM

全面的Java运行时解决方案组合

2008年BEA被oracle收购

JDK8中，在HotSpot的基础上，移植JRockit的优秀特性

全称：IBM Technology for java Virtual Machine 简称IT4J，内部代号J9

市场定位与HotSpot接近，服务器端、桌面应用，嵌入式等多用途VM

广泛应用于IBM的各种Java产品

有影响力的三大商用虚拟机之一

2017开源，OPEN J9

JavaME产品线产品

与特定硬件平台绑定、软硬件配合的专有虚拟机

运行于Azul Systems公司的专有硬件Vega系统上的虚拟机

每个实例可以管理至少数十个CPU和数百GB内存的硬件资源，并提供在巨大内存范围内实现可控的GC时间的垃圾收集器，专有硬件优化的线程调度等优秀特性

2010年，发布自己的Zing JVM，可以在通用X86平台上提供接近于vega系统的特性

BEA公司开发的，运行在自家Hypervisor系统上

不需要操作系统支持，本身实现了一个专用操作系统的必要功能，如线程调度、文件系统、网络支持等

随着JRockit虚拟机终止开发，Liquid VM项目也停止了

JDK1.5、1.6兼容

IBM和Intel联合开发的开源JVM，2011年退役

Java类库代码吸纳进了Android SDK

只能在Windows平台运行，xp系统中不用了

基于OpenJDK开发了自己的定制版本AlibabaJDK

深度定制且开源的高性能服务器版JAVA虚拟机

GCIH：GC invisible heap，将生命周期较长的Java对象从heap中已到heap之外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率

GCIH中的对象还能够在多个JAVA虚拟机进程中实现共享

使用crc32指令实现JVM intrinsic降低JNI的调用开销

针对大数据场景的ZenGC

在阿里产品上性能高，硬件严重依赖intel的CPU，损失了兼容性，但是提高了性能

淘宝、天猫上线，把oracle官方JVM版本全部替换

谷歌开发，应用于Android系统，安卓2.2提供了JIT，发展迅猛

只能称作虚拟机，不能称作Java虚拟机，没有遵循Java虚拟机规范

不能直接执行Java的Class文件

基于寄存器架构，不是JVM的栈架构

执行的是编译后的dex文件，执行效率比较高

安卓5.0使用支持提前编译AOT的ART VM替换Dalvik VM

2018年4月，Oracle labs公开了GraalVM

跨语言全栈虚拟机，可以作为任何语言的运行平台使用

虚拟机栈、堆内存、程序计数器、方法区、本地方法栈

为了保证线程切换后能恢复到正确的执行位置

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

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

Java虚拟机栈，早期也叫Java栈，每个线程创建时都会创建一个虚拟机栈，内部保存一个个栈帧，对应着一次次的Java方法调用

生命周期和线程的一致，线程被销毁，虚拟机栈也就随之销毁

主管Java程序的运行（主要是方法的执行），保存方法的局部变量（8种基本数据类型、对象的引用地址）、部分中间结果，并参与方法的调用和返回

快速有效的存储方式，访问速度仅次于程序计数器

JVM直接对Java栈的操作只有两个

栈不存在垃圾回收，但是存在OOM和StackOverflowError

使用-Xss的JVM参数，设置线程的最大栈空间

每个线程都有自己的栈，栈中的数据以栈帧格式存储

线程上正在执行的每个方法都各自对应一个栈帧

栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各个数据信息

一条活动的线程中，一个时间点上，只会有一个活动的栈帧。只有当前正在执行的方法的栈顶栈帧是有效的，这个称为当前栈帧，对应方法是当前方法，对应类是当前类

执行引擎运行的所有字节码指令只针对当前栈帧进行操作

先进后出，后进先出，如果方法中调用了其他方法，对应的新的栈帧会被创建出来，放在顶端，成为新的当前帧

不同线程中包含的栈帧不允许存在相互引用

当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为新的栈帧。

Java方法有两种返回方式

局部变量表（Local Variable Table）

操作数栈

动态链接

方法返回地址

一些附加信息

方法的调用

简单讲，就是一个Java调用非Java代码的接口

与Java环境外交互

内存溢出情况和Java虚拟机栈相同

堆内存位置（线程共享）

一个JVM实例只存在一个堆内存，堆内存也是Java内存管理的核心区域

Java堆区在JVM启动的时候即被创建。堆内存的大小是可调节的，可以通过启动参数，或者自适应调节

Java虚拟机规范规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的

所有的线程共享Java堆内存，在这里还可以划分线程私有的缓冲区（TLAB）

"几乎"所有的对象实例都在这里分配内存（HostSpot并没有实现栈上分配）

数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，引用指向对象或者数组在堆中的内存地址

方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除

堆内存是GC执行垃圾回收的重点区域

堆空间细分

jvisualvm工具

-XX:+PrintGCDetails，打印垃圾回收的日志

-Xms ：堆内存的起始内存（memory start），等价于-XX:InitialHeapSzie

-Xmx：堆内存最大占用量（memory max），等价于-XX:MaxHeapSize

通常将-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在Java垃圾会后清理完堆区后，不需要重新分隔计算堆区的大小，从而提高性能（防止内存抖动，降低GC频率，提高程序的吞吐量）

默认情况下

jps命令

jstat命令

Java对象划分为两类：生命周期短的和长的

堆内存 = 新生代（YoungGen）（Eden + Survior 0）+ 老年代（OldGen）

新生代与老年代空间默认比例1 : 2

jinfo -flag NewRatio <pid>，查看参数设定值

在HotSpot中，Eden区大小和另外两个Survivor大小缺省所占的比例是：8 : 1 : 1

几乎所有的Java对象都是在Eden区被new出来的。Eden区放不了的大对象，直接进入老年代了

IBM研究表明，新生代99%的对象都是朝生夕死

-Xmn：设置新生代最大内存大小，如果同时设置了新生代比例与此参数冲突，则以此参数为准

图示

1、new出来的对象先放在Eden区，此区有大小限制

2、当创建新对象，Eden空间填满时，会触发Minor GC，将Eden区不再被其他对象引用的对象进行销毁。再加载新的对象放到Eden区

3、将Eden中剩余的对象移到幸存者0区

4、再次触发垃圾回收，此时上次幸存者下来的，放在幸存者0区的，如果没有回收，就会放到幸存者1区

5、再次经历垃圾回收，又会将幸存者重新放回幸存者0区，依次类推

6、GC分代年龄默认是15次，超过15次，则会将幸存者区幸存下来的转去老年区

-XX:MaxTenuringThreshold=N进行设置晋升年龄

总结：

流程图

触发YGC，幸存者区就会附带进行回收，不会主动进行回收

超大对象Eden放不下，就要看Old区大小是否可以放下

JDK命令行

Eclipse：Memory Analyzer Tool

Jconsole

VisualVM

Jprofiler

Java Flight Recorder

针对HotSpotVM的实现

MinorGC的触发条件

MajorGC解释说明

老年代GC（MajorGC|FullGC）触发条件

其实不分代也可以，分代的理由是优化GC性能

如果将所有生命周期对象全部放在一起，那判断对象是否存活就需要遍历整个堆内存，效率就大大降低

分代之后，大多数情况下只需要遍历新生代，也就是对象生命周期短的内存区域，就可以回收大量内存

长期存活的对象分配到老年代

大对象直接分配到老年代

动态对象年龄分配

空间分配担保

堆区是线程共享区域，任何线程都可以访问到堆区的共享数据

由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的

因此JVM采用两种策略（TLAB、CAS加失败重试）为对象分配内存

TLAB

使用TLAB的方式为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度

随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术，将会导致一些微秒变化，所有对象分配到堆上渐渐变得不那么绝对了

有一种特殊情况，如果经过逃逸分析后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配，这样无需堆上分配，也不需要垃圾回收了，也是最常见的堆外存储技术

TaoBaoVM，其中创新的GCIH（GC invisible heap）技术实现了off-heap，实现了将生命周期较长的Java对象从heap中移动heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的

逃逸分析概述

从线程是否共享该区域来看，方法区线程共享

从变量的存放区域来看，方法区存放类的元数据信息

Java虚拟机规范中明确说明：尽管所有的方法区在逻辑上是属于堆的一部分，但是一些简单的实现，可能不会选择去进行垃圾收集或者进行压缩。对于HotSpot而言，方法区还有一个别名叫Non-Heap（非堆），目的就是要和堆分开

所以方法区看作是一块独立于Java堆的内存空间

方法区和Java堆一样，是各个线程共享的内存区域

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

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

方法区的大小决定了系统可以保存多少个类，如果定义太多类，加载大量的第三方的Jar包，Tomcat部署过多工程，导致方法区溢出，虚拟机同样会抛出内存溢出OOM：PermGenspace或者Metaspace 

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

在JDK7及以前，习惯上把方法区，称为永久代，JDK8开始，使用元空间取代了永久代

本质上，方法区和永久代并不等价，仅是对HostSpot而言的。

Java虚拟机规范，对如何实现方法区，不做统一要求，例如BEA JRockit/IBM J9中不存在永久代的概念

现在来看，当年使用永久代，不是好的点子，导致Java程序更容易OOM

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

方法区存储什么

原始代码

字节码指令、程序计数器、局部变量表、操作数栈示例

sipush 500（把500这个数值压入操作数栈中）

istore_1（弹出操作数栈栈顶元素500，保存到局部变量表中索引为1的位置）

bipush 100（将100这个数值压入操作数栈栈顶）

istore_2（弹出操作数栈栈顶元素100，保存到局部变量表索引为2的位置）

iload_1（将局部变量表中索引为1处的数值500，压入操作数栈栈顶）

iload_2（将局部变量表中索引为2处的数值100，压入操作数栈栈顶）

idiv（依次弹出操作数栈中的两个元素100、500，然后进行两数相除，结果5压入操作数栈栈顶）

istore_3（弹出栈顶元素5，将局部变量表索引为3处的值修改为5）

bipush 50（将50压入操作数栈中）

istore 4（弹出操作数栈栈顶元素，存储到局部变量表索引为4的位置）

getstatic #2 （获取类或者接口字段的值并将其推入操作数栈 #2 对应常量池中的Fieldref #15.#16）

iload_3（将局部变量表中索引为3的位置的数据5压入操作数栈中）

iload_4（将局部变量表中索引为4的位置的数据50压入操作数栈中）

iadd（弹出栈顶两个int类型的数相加，结果压入操作数栈）

invokevirtual #3

return（结束方法的运行）

首先明确，只有HotSpot才有永久代

HotSpot中方法区的变化

永久代为什么被元空间替换

有些人认为方法区是没有垃圾收集行为的，其实不然。Java虚拟机规范对方法区的约束非常宽松，提到过可以不要求虚拟机在方法区实现垃圾收集。事实上，也确实有未实现或未能完整实现方法区类型卸载的收集器，如JDK11 ZGC

方法区的垃圾收集主要回收两部分内容

方法区内常量池中主要存放的两大类常量

因此出于性能考虑，读写频繁的场合可能会考虑使用直接内存

Java的NIO库允许Java程序使用直接内存，用于数据缓冲区

直接内存在堆外，所以大小不受限于-Xmx指定的最大堆大小

但是系统内存是有限的，Java堆和直接内存的总和依然受限于操作系统能给出的最大内存

分配回收成本较高

不受JVM内存回收管理

如果出现内存泄漏难以排查

new

Class的newInstance

Constructor的newInstance

使用clone

使用反序列化

第三方库Objenesis

判断对象对应的类是否加载、链接、初始化

为对象分配内存

处理并发安全问题

初始化分配到的空间

设置对象的对象头

执行类的构造器<init>()方法进行初始化

包含三部分（运行时元数据、指向方法区中的KClass对象、如果为数组需要有数组的长度（数据类型为int））

说明：如果是数组，还需要记录数组的长度，4字节

对象的实例数据部分，是对象的真正存储的有效信息，即我们在程序代码中定义的各种类型的字段，无论是父类继承下来，还是子类中定义的字段都要记录下来

这里不包括静态字段，因为静态字段属于类，而不属于类的实例对象

为字段分配内存的策略

对其填充，这并不是必然存在，没有特别的意义，它仅仅起着占位符的作用

因为HotSpot虚拟机自动内存管理系统，要对对象的起始地址必须是8字节的整数倍，换句话就是任何对象的大小都必须是8字节的整数倍

对象实例数据部分如果没有对齐的话，就需要通过对其填充来补全

什么是对象指针压缩（Ordinary Object Pointers Compress）

如果开启了指针压缩，那么引用数据类型的指针大小就是4个字节共32位。如果进行内存寻址，最大只能访问4G（2的(4 * 8)次方 / 1024 / 1024 / 1024 ）的内存。堆内存如果大于4G，那么如何访问4G之外的内存呢？

Java对象的大小必须是8字节的整数倍，如果是2进制表示，最后三位必然都是000，那么就可以将32位进行无符号左移3位，变成35位。那么可以最大内存寻址的范围就是32G

举例一下，假如对象实际偏移量为24字节，那么指针只存储3字节，实际内存寻址的时候，进行无符号左移3位，其实就是乘以8，得到24，达到节约内存的目的。其实这也是时间换空间思想的体现，利用CPU的计算资源，减少内存消耗

如果堆内存大于32G时，压缩指针会失效，会强制使用64位（即8字节）来对Java对象寻址

如果堆内存小于4G，就没必要使用指针压缩了

使用句柄，Java堆中将划出一块内存作为句柄池，reference中存储的就是对象的句柄地址，句柄包含对象实例数据与类型数据各自的具体信息

使用指针，reference中存储的直接就是对象地址，如果访问对象本身，不需要多一次的间接访问的开销

使用句柄最大好处是reference中存放的是稳定句柄地址，在对象被移动（垃圾回收时会产生）时只改变句柄中实例数据指针，reference本身不用改变

使用指针最大好处就是速度快，节省了一次指针定位的时间开销，由于对象访问在Java中非常频繁，所以积少成多也是一项可观的执行成本

HotSpot主要是用指针，进行对象访问（例外情况，如果使用Shenandoah收集器的话，也会有一次额外的转发）

执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器

每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址

当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息

JVM在执行Java代码的时候，通常会将解释执行与编译执行二者结合起来进行

各种采用二进制编码方式表示的指令，叫做机器指令码

机器指令与CPU紧密相关，不同种类的CPU所对应的机器指令也就不同

由于机器码由01组成，可读性太差。于是人们发明了指令

指令就是把机器码特定的0和1序列，简化成对应的指令，一般为英文编写如mov、inc等，可读性稍好

由于不同的硬件平台，执行同一个操作，对应的机器码可能不同。所以不同的硬件平台的同一种指令，对应的机器码也可能不同

不同硬件平台，各自支持的指令，是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集

x86指令集，对应的x86架构的平台

ARM指令集，对应的是ARM架构的平台

由于指令的可读性太差，于是又有了汇编语言

汇编语言用助记符代替机器指令的操作码，用地址符号或标号，代替指令或操作数的地址

汇编语言要翻译成机器指令码，计算机才能识别和执行

字节码是一种中间状态的二进制代码，它比机器码更加抽象，需要直译器转义后才能完成机器码

字节码主要为了实现特定软件运行和软件环境，与硬件环境无关

字节码的实现方式是通过编译器和虚拟机器。编译器将源码编译成字节码，特定平台上的虚拟机器将字节码转译为可以执行的指令。典型的应用为Java bytecode

模板解释器将每一条字节码和一个模板函数相关联，模板函数直接产生这条字节码执行时的机器码，提高解释器的性能

Interpreter模块

Code模块

把.java文件转换为.class文件的过程

把字节码转为机器码的过程

Ahead of Time Compliler AOT，直接把.java文件编译器本地机器代码（可直接运行的二进制文件）的过程

需要根据代码被调用执行的频率而定，需要被编译为本地代码的字节码，也称之为热点代码

JIT编译器会在运行时针对频繁调用的热点代码做出深度优化，将其直接编译为对应平台的本地机器指令，以此提升Java程序的执行性能

一个被多次调用的方法，或者一个方法体内部循环次数较多的循环体，都可以被称之为热点代码

因此可以通过JIT编译器编译为本地机器指令，由于这种编译方法发生在方法的执行过程中，因此也被称之为栈上替换，OSR On Statck Replacement

一个方法调用都少次才能达到标准？这个依靠热点探测功能

client 

server

大多情况下简称C1、C2

-client：指定Java虚拟机在Client模式下，并使用C1编译器

-server：指定虚拟机在server模式下，并使用C2编译器

char数组一个char占2字节，String是堆空间的主要部分，大部分是latin-1字符，一个字节就够了，这样会有一半空间浪费

中文等UTF-16的用两个字节存储

StringBuffer、StringBuilder同样做了修改

简称不可变性

当字符串重新赋值，需要重写指定内存区域赋值，不能使用原有的value进行赋值

当对现有的字符串进行连接操作时，也需要重新指定内存区域赋值，不能对使用原有的value进行赋值

当调用String的replace()方法修改指定字符或字符串时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值

由于String的不可变性，因此String也是线程安全的对象

String的String pool是一个固定大小的HashTable，默认大小长度是1009，如果放进String Pool的String非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了，直接影响就是调用String.intern()方法时性能会大幅下降

-XX:StringTableSize可设置StringTable的大小

JDK6固定1009，JDK7中StringTable默认的长度是60013，JDK8时默认是60013，1009是可设置的最小值

直接使用双引号，声明出来的String对象会直接存储在常量池中

如果不是双引号声明的String对象，可以使用String提供的intern()方法

调优时仅需调整堆大小就可以

永久代默认情况下比较小，永久代垃圾回收频率低，大量字符串容易导致OOM

字节码ldc # 2 <abc>，是指加载常量池中索引为2的字面量abc压入操作数栈

代码演示

代码截图

代码截图

截图

由于使用了final修饰变量，在编译器就对其进行了优化，使之变成了常量

拼接10万次，+号4000毫秒，append用了7毫秒，原因是+号每次循环创建一个StringBuilder，还要通过toString创建一个String对象

内存中由于创建了较多的对象，内存占用更大，如果需要GC需要花费额外的时间

改进空间：StringBuilder默认是16长度的char型数组，不够的时候会扩容，可以一次建一个比较大长度的数组

代码

变形

new String("ab")会创建几个对象？

new String("a") + new String("b")?

JDK6中，将这个字符串对象放入串池

JDK7起，将这个字符串对象尝试放入串池

截图

大的网站平台，需要内存中存储大量的字符串，比如社交网站，很多人存储：北京市、海淀区等信息，这时候如果字符串调用intern()方法，则会明显降低内存的大小

FastJson将json字符串反序列化成Java对象的时候，将key进行了使用了intern()方法，理由是key是经常出现的，放入String Table中可以大大减少内存消耗

堆存活数据集合里面String对象占了25%

堆存活数据集合里面重复的String对象有13.5%

String对象的平均长度是45

对每个对象保存一个整型的引用计数器属性，用于记录被对象引用的情况

被对象引用了就+1，引用失效就-1。0表示不可能再被使用，可进行回收

优点：实现简单，垃圾便于辨识，判断效率高，回收没有延迟性

缺点

案例演示（判断Java采用引用计数，还是可达性分析法）

小结

Java、C#选择的

基本思路

GC Roots包括

可触及的

可复活的

不可触及的

只有对象是不可触及时才可以被回收

判断一个对象objA是否可以被回收，至少需要经历两次标记过程

代码

执行结果

在Finalizer类中有静态内部类FinalizerThread继承自Thread，重写run()方法，并且在静态代码块中启动了Finalizer线程

重写的run()方法中的逻辑就是从队列中获取对象，然后执行finalize()方法，当然了finalize()方法只会被执行一次

Finalizer线程的优先级低finalizer.setPriority(Thread.MAX_PRIORITY - 2)

Finalizer线程为后台守护线程finalizer.setDaemon(true)

标记

清除

算法图示

缺点

何为清除？

将或者的内存空间分为两块，每次使用其中一块。在垃圾回收时，将正在使用的内存中的存活的对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有的对象，交换两个内存的角色，最后完成垃圾回收

算法图示

优点

缺点

应用场景

标记阶段（Mark）标记清除算法一样，从根节点开始标记所有被引用的对象

清除阶段（Sweep）第二阶段将所有的存活对象压缩在内存的一端，按照顺序排放，之后清理边界外所有的空间

整理阶段（Compact）标记清除算法执行完成后，再进行一次内存碎片整理

算法图示

与标记清除算法本质区别，标记清除算法是非移动式的算法，标记压缩是移动式的

是否移动回收后的存活对象时一项优缺点并存的风险决策

优点

缺点

从效率上来说，复制算法是当之无愧的老大，但是却浪费了太多的内存。为了尽量兼顾上面提到的三个指标，标记-整理算法相对平滑一些，但是效率上不尽如人意，它比复制算法多了一个标记阶段，比标记-清除多了一个整理内存的阶段

图示

新生代

老年代

每次垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程，依次反复，直到垃圾收集完成

通过对线程间冲突的妥善管理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作

缺点

为了控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理的回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的时间

分代算法是将对象按照生命周期长短划分为两个部分，分区算法是将整个堆划分为连续的不同的小区间

每一个小区间都独立使用，独立回收，这种算法的好处是可以控制一次回收多少个小区间

Java虚拟机的堆内存设置不够

代码创建大量大对象，并且长时间不能被垃圾收集器收集（仍然有GC Roots引用这这些对象）

只有对象不再被程序用到了，但是GC又不能回收他们的情况，才叫内存泄露

实际情况有一些疏忽导致对象的生命周期变的很长甚至OOM，宽泛意义上的内存泄露

举例

简称STW，指的是GC事件发生过程中，会发生应用程序的停顿

停顿产生式整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STW

可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿，确认哪些对象存活，哪些对象死亡

分析工作必须保证在一个能确保一致性的快照中进行

一致性是指整个分析期间整个执行系统看起来像被冻结在某个时间点上

如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证

STW事件和采用哪款GC无关，所有的GC都有这个事件

哪怕是G1也不能完全避免STW情况的发生，只能说GC越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间

STW是JVM后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉

开发中不要使用System.gc()，会导致STW事件的发生

一段时间内，同一个CPU处理运行多个线程的代码

一个CPU执行一个进程时，另一个CPU可以执行另一个进程，两个进程互相不抢占资源，可以同时进行，我们称之为并行

并行因素取决于CPU的核心数量

并发指的是多个事情，在同一时间段内交替发生了

并行指的是多个事情，在同一个时间点上同时发生了

并发的多个任务之间抢占资源

并行多个任务之间不互相抢占资源

只有在多CPU或者一个CPU多核的情况中，才会发生并行。否则看似同时发生的事情，其实都是并发执行的

串行（Serial）

并行（Parallel ）

并发（Concurrent）

在JDK1.2之前，Java的引用还是很传统的，reference类型的数据就是另外一块内存的起始地址

如果我们想要描述这样一些对象，当内存空间足够时，保留在内存中。当内存空间在垃圾回收之后仍然非常紧张，那么就可以回收这些对象

在JDK1.2之后，Java对引用的概念进行了扩充，分为强引用、软引用、弱引用和虚引用，这4中引用强度依次减弱

最传统的引用定义，程序代码中普遍存在的引用赋值，类似Object obj = new Object()这种引用关系，无论任何情况下，强引用存在，垃圾收集器永远不会回收掉被引用的对象

强引用是造成Java内存泄露的主要原因之一

强引用可以直接访问目标对象

用来描述一些还有用，但是非必须的对象。系统将要发生内存溢出之前，会将这些对象列入回收范围之中进行第二次回收，如果这次回收后还没有足够内存，才会抛出内存溢出异常

软引用通常用来实现内存敏感的缓存，高速缓存就有用到软引用

垃圾回收器在某个时间决定回收软可达的对象的时候，会清理软引用，并可选的把引用存放到一个引用队列

代码演示

弱引用也是用来描述那些非必须的对象，只被弱引用关联的对象只能够生存到下一次垃圾收集器之前，当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象

代码演示

一个对象是否有虚引用存在，完全不会对其生存时间构成影响。唯一目的就是在这个对象被收集器回收时收到一个系统通知

他不能单独使用，也无法通过虚引用获取被引用的对象

测试代码

控制台输出

在JDK源码中DirectByteBuffer使用了虚引用

用以实现对象的finalize()方法，所以被称为终结器引用

无需手动编码，其内部配合引用队列使用

GC时，终结器引用入队，由finalizer线程通过终结器引用找到被引用对象并调用他的finalize方法，第二次GC时才能回收被引用对象

当一个对象被一个或者多个对象同时引用，且引用还有强、软、弱、虚那么如何判定引用关系呢？

下图是一个引用关系图。在这个树形引用链中，对象的箭头代表了引用关系。比如到达对象5就有① - ⑤和③ - ⑦这两种途径

由此带来了一个问题，某个对象的可达性如何判断

比如，假设①、③为强引用，⑤为软引用，⑦为弱引用。对于对象5按照这两个原则，路径① - ⑤取最弱的引用⑤，因此该路径对象5的引用为软引用。同样③ - ⑦为弱引用。在这两条路径之间取最强的引用，最终对象5是一个软引用

抢先式中断

主动式中断

老年代引用新生代的对象，对象从新生代晋升到老年代

新生代引用老年代，用户线程手动修改老年代对象的引用，使其指向新生代的对象

字段精度：每个记录精确到一个机器字长（就是处理器的寻址位数，如常见的32位或64位，这个精度决定了机器访问物理内存地址的指针长度），该字段包含跨带指针

对象精度：每个记录精确到一个对象，该对象里有字段包含跨代指针

卡精度：每个记录精确到一块内存区域，该区域内有对象含有跨带指针

把原本消亡的对象标记位存活，这不是好事，但其实是可以接受的，只不过产生了一点逃过本次收集的浮动垃圾而已，下次收集清理就好了

把原本存活的对象错误标记为已消亡，这就是非常致命的错误了

白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始阶段，所有的对象都是白色的，若分析结束阶段，仍然是白色的对象，即代表不可达

黑色：表示对象已经被垃圾收集器访问过，且这个对象所有直接引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象

灰色：表示对象已经被垃圾收集器访问过，但这个对象至少存在一个引用还没有被扫描过

（1）初始时，所有对象都在白色集合

（2）将GC Roots直接引用的对象挪到灰色对象中

（3）从灰色对象集合中获取对象obj

（4）重复步骤（3）直至灰色集合为空时结束

（5）结束后，仍在白色集合的对象即为GC Roots不可达，可以进行内存回收

从上面的过程可以看出对象图的遍历方式是广度优先遍历的方式，当然没有考虑循环引用的情况

示意图

假设已经遍历到E（变成了灰色），此时用户线程执行了objD.fieldE = null; 此刻之后，对象E、F、G是应该被回收的。然而因为E已经变成了灰色，其仍然会被当做存活的对象继续遍历下去。最终的结果：部分对象（F、G）仍然会被标记为存活，即本轮GC不会回收这部分内存

这也就导致了并发标记阶段不能等到内存不够，才来回收内存，而是当内存使用达到一定比例就需要提前开始回收内存

这部分本来应该回收但是没有回收到的内存，被称之为浮动垃圾。浮动垃圾不会影响程序的正确性，这是需要等待下一轮垃圾回收

另外，针对并发标记阶段生成的新对象，通常的做法是直接全部当成黑色的，本轮不会清除。这部分对象可能变成垃圾，这也算是浮动垃圾的一部分

示意图

假设GC线程已经遍历到了对象E（已经变成了灰色），此时用户线程执行了如下代码

此时切回GC线程继续跑，因为对象E已经没有对对象G的引用了，所以不会将对象G放到灰色集合；尽管对象D重新引用了对象G，但是因为对象D已经是黑色的，不会重新做遍历处理

最终导致的结束是：对象G会一直停留在白色集合中，最后被当做垃圾进行清除。这直接影响到了程序的正确性，是不可接受的

Wilson于1994年在理论上证明了，当且仅当以下两个条件同时满足时，才会产生漏标

过程分析（添加读写屏障）

写屏障（Store Barrier）

读屏障（Load Barrier）

现代追踪式（可达性分析法）的垃圾收集器几乎都借鉴了三色标记的算法思想，尽管实现的方式不尽相同：比如白色、黑色集合一般不会出现，灰色集合可以是通过栈、队列、缓存日志的方式实现，遍历的方式可以是广度、深度遍历等等

对于读写屏障，以Java HotSpot VM为例，并发标记对于漏标的处理方案如下：CMS：写屏障 + 增量更新、G1：写屏障 + STAB、ZGC：读屏障

按垃圾回收线程数（串行和并行）

按照工作模式分（并发式和独占式）

按照碎片处理方式（是否压缩内存）

按个工作内存区间分

吞吐量

垃圾收集开销

暂停时间

收集频率

内存占用

快速

简单来说抓住两点：吞吐量和暂停时间

高吞吐量与低暂停时间，是一对互相竞争的。因为如果高吞吐量优先，必然需要降低内存回收的执行频率，导致GC需要更长的暂停时间来执行内存回收

如果选择低延迟优先为原则，也只能频繁的执行内存回收，引起程序吞吐量的下降

普遍的标准，在最大吞吐量优先的情况下，降低停顿时间

Serial GC

ParNew

Parallel GC和Concurrent Mark SweepGC

G1

Epsilon 垃圾回收器、ZGC，可伸缩低延迟垃圾回收器

Shenandoah GC：低停顿时间的GC，实验版

增强ZGC

删除CMS垃圾回收器，扩展ZGC在macOS和Windows上的应用

截图

JDK8之前，可以用虚线参考关系

CMS下面的实线，是CMS回收失败的后备方案

JDK8中取消了红线的组合，标记为废弃的。如果要用也可以用

JDK9中将红线做了remove

JDK9中标记CMS为废弃的

JDK14中弃用了绿线组合

JDK14中删除了CMS

JDK9默认使用G1

JDK8默认使用Parallel Scavenge、Parallel Old GC。新生代用了Parallel Scavenge则老年代自动触发用Parallel Old

Parallel底层与ParNew底层不同，所以不能和CMS组合

总结一下随着JDK版本的更新，出现了不同垃圾收集器且组合之间关系也发生变化

Client模式下默认使用Serial GC和Serial Old GC，JDK8默认使用Parallel Scavenge和Parallel Old GC，JDK9默认使用G1，JDK15默认使用ZGC

-XX:+PrintCommandLineFlags

jinfo -flag 相关垃圾回收器参数 进程ID

执行流程图

使用一个CPU或者一条收集线程去完成垃圾收集工作，在进行垃圾收集时，必须暂停其他所有工作线程

简单而高效，对于限定单个CPU的环境来说，由于没有线程交互的开销，可以获取最高的单线程收集效率

执行流程图

-XX:+UseParallelGC

-XX:+UseParallelOldGC

-XX:ParallelGCThreads

-XX:MaxGCPauseMillis

-XX:GCTimeRatio

-XX:+UseAdaptiveSizePolicy

执行流程图

初始标记：STW，仅仅只是标记出GC Roots能直接关联的对象，一旦标记完成后就会恢复之前被暂停的所有应用线程，由于直接关联对象比较小，所以这里速度非常快

并发标记：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长，但是不需要停顿用户线程。可以与垃圾收集线程一起并发运行

重新标记：为了修正并发标记期间，因用户程序继续运作导致标记产生变动的那一部分对象的标记记录（增量更新，这一步需要STW）

并发清除：清理删除标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也可以与用户线程同时并发

为什么不采取标记压缩呢？

因为并发清除时，如果用压缩整理内存，对象的地址就会发生变化，用户线程使用对象就会发生错误

标记压缩更适合STW场景下使用

并发收集

低延迟

会产生内存碎片

对CPU资源非常敏感

无法处理浮动垃圾

-XX:+UseConcMarkSweepGC

-XX:CMSlnitiatingOccupanyFraction

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction

-XX:ParallelCMSThreads

如果想要最小化使用内存和并行开销，选择Serial GC

如果最大化应用程序的吞吐量，选择Parallel GC

如果想要最小化的GC的中断或停顿时间，选择CMS GC

CMS在JDK9被标记为废弃的，在JDK14正式删除

就是在延迟可控的情况下，获得尽可能高的吞吐量，所以才担当起全功能收集器的重任和期望

G1是一个并行回收器，他把堆内存分割为很多不相关的区域（Region）（物理上不连续）

使用不同的region表示Eden、S0、S1、老年代等

G1跟踪各个region里面垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region

并行与并发

分代收集

空间整合

可预测的停顿时间模型

相较于CMS，G1不具备全方位，压倒性优势。比如用户程序运行中，G1无论是为了垃圾收集产生的内存占用，还是程序运行时的额外执行负载都要比CMS要高

经验上来说，小内存应用CMS表现大概率优于G1，在大内存上G1优势发挥更多，平衡点在6 - 8GB

-XX:+UseG1GC

-XX:G1HeapRegionSize

-XX:MaxGCPauseMillis

-XX:ParallelGCThreads

-XX:ConcGCThreads

-XX:InitiatingHeapOccupancyPercent

第一步开启G1垃圾收集器

第二步设置堆的最大内存

第三步设置最大的停顿时间

G1提供了三种垃圾回收模式在不同的条件下触发

面向服务器端应用，针对具有大内存，多处理器的机器

最主要应用是需要低GC延迟

如：在堆大小约6GB或更大，可预测的暂停时间可以低于0.5s，G1每次清理一部分region来保证每次GC停顿时间不会过长

用来替换1.5中的CMS

所有region大小相同，且在JVM生命周期内不会改变

年轻代GC（STW）

老年代GC，并发标记过程

混合回收

有可能FullGC

每个region对应一个记忆集

每次引用类型数据写操作时，会产生一个写屏障暂时中断操作

然后检查将要希尔的引用指向的对象是否和该引用对象类型数据在不同的region，如果不同就通过Card Table把相关的引用信息记录到引用指向对象所在的Region对应的记忆集中

当进行垃圾收集时，在GC根节点枚举范围加入记忆集，就可以保证不进行全局扫描，也不会有遗漏

1、扫描GC Roots

2、更新Rset

3、处理Rset

4、复制对象

5、处理引用

初始标记阶段（STW）

根区域扫描阶段

并发标记

再次标记

独占清理

并发清理阶段

当越来越多的对象晋升到老年代Old Region时，为了避免内存被耗尽，虚拟机会触发一次混合的垃圾收集器，该算法除了回收整个Young Region，还会回收一部分的Old Region。也要注意Mixed GC并不是Full GC

并发标记结束后，老年代中百分百为垃圾的Region被回收了。部分为垃圾的内存分段被计算出来了，默认情况下，这些老年代的内存分段会分8次被回收，由-XX:G1MixedGCCountTarget参数设置

混合回收的回收集包括八分之一的老年代、Eden区内存分段、Survivor区内存分段

由于老年代中内存分段默认分8次回收，G1会优先回收垃圾多的内存分段，并且有一个阈值会决定内存分段是否被回收。-XX:G1MixedGCLiveThresholdPercent，默认为65%。意思是垃圾占比达到65%才会被回收。如果垃圾占比比较低，意味存活对象较高，复制的时候花更多时间

混合回收不一定要进行8次，有一个阈值：-XX:G1HeapWastePercent

G1初衷就是要避免FullGC，如果上述方式不能正常工作，G1会停止应用程序的执行。使用单线程的内存回收算法进行垃圾回收，性能非常差。应用程序停顿时间长

比如堆太小，当G1复制存活对象的时候没有空的内存分段可用，则会回退到FullGC

导致FullGC原因可能有两个

避免使用-Xmn或-XX:NewRatio等相关选项显式设置年轻代大小

固定的年轻代大小会覆盖暂停时间目标

暂停时间目标不要太苛刻，太苛刻会影响吞吐量

关于日志分析工具可以到后面的故障排查章节继续讲解

强项

弱项

在尽可能堆吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾回收的停顿时间限制在10毫秒以内的低延迟

标记阶段和整理阶段都是并发的，移动对象的过程中也可以并发的

GC过程分为初始标记、并发标记、并发预备重分配、并发重分配、并发重映射

除了初始标记是STW，其他地方几乎都是并发执行的

生产环境中的问题

防止出现OOM

解决OOM

减少Full GC出现的频率

提高程序的吞吐量

减少GC停顿时间

减少Java进程的内存占用

上线前，在本地开发环境

项目运行阶段

线上出现OOM

监控的依据

调优的大方向

第一步（发现问题）：性能监控

第二步（排查问题）：性能分析

第三步（解决问题）：性能调优

1. 停顿时间

2. 吞吐量

3. QPS

4. 内存占用

5. 请求收到GC影响比例计算

jps（虚拟机进程状况工具）

jinfo（实时查看和修改JVM配置参数）

jstat（虚拟机统计信息监视工具）

jmap（导出内存映像文件&内存使用情况）

jstack（Java堆栈跟踪工具）

arthas（Java应用诊断利器）

MAT（Memory Analyzer Tool）

VisualVM（多和-故障处理工具）

JProfiler

OQL（对象查询语句）

类型一：标准参数选项

类型二：-X参数选项

类型三：-XX参数选项

IDEA

运行jar包

通过Tomcat运行war包

程序运行过程中

打印设置的XX选项及值

堆、栈、方法区等内存大小设置

OutOfMemory相关设置

垃圾收集器相关设置

GC日志相关参数

其他参数

可以使用RunTime类获取相关参数

-verbose:gc

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-XX:+PrintGCDateStamps

-XX:+PrintHeapAtGC

-Xloggc:<file>

-XX:+UseSerialGC

-XX:+UseConcMarkSweepGC

-XX:+UseParallelGC

-XX:+UseG1GC

针对HotSpot VM的实现，它里面的GC按照回收区域分为两大种类型：一种部分收集（Partial GC），一种整堆收集（Full GC）

部分收集

整堆收集（Full GC），收集整个Java堆和方法区

GC类型和GC发生的原因

垃圾收集器

GC发生的内存区域

GC前后情况区域的使用情况

GC前后堆内存的使用情况

GC时间

Young GC日志解析

Full GC日志解析

GCEasy

内存泄漏是指程序申请并使用内存后一直不释放，内存一直占用着。一次泄露不会有明显影响，累积泄露会导致OOM(内存溢出)

内存泄漏是导致内存溢出的原因之一

如果应用周期性发布，重新部署，内存泄漏可能就非常隐蔽，难以发现

内存泄漏是由于代码不善引起的，要注意程序一些容易犯错的地方

内存泄漏的典型现象

图示是一个博客关于内存泄漏的案例，可以看到老年代内存占用呈现逐步上升趋势，且每次Old GC后，内存占用仍然呈现上升趋势

内存泄漏的案例

典型内存泄漏用法

一般的手段是通过内存映像分析工具（主要是MAT工具），对dump出来的堆转存储快照进行分析，重点确认内存中的对象是否是必要的，先分清楚到底是出现了内存泄露，还是内存溢出

如果是内存泄露，可进一步通过工具查看泄露对象到GC Roots的引用链，于是就能找到内存泄露对象时通过怎样的路径与GC Roots相关联，导致垃圾收集器无法自动回收他们。根据引用链信息，可以较准确的定位出泄露代码的位置

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

原生命令

show-busy-java-threads，显示繁忙的java线程脚本

arthas的thread -n 线程数命令

Young GC频繁的直接原因是频繁创建对象，且伊甸园区放不下，进行了Young GC，且没有回收对少内存。因为这些对象还存活着，业务过程还没有结束

调大新生代，查看Young GC的执行频率

jstat -gccause -t <pid> [interval] [count] 观察Young GC发生的次数，以及频率

直接原因

Full GC可能会发生OOM，也可能不会发生OOM

排查步骤

所谓加载，就是将字节码文件加载到内存中，并且在内存中构建出Java类的原型--类模板对象

反射的机制即基于这一基础。如果JVM没有将Java类的声明信息存储起来，则JVM在运行期也无法反射

通过一个类的全限定名获取定义此类的二进制字节流

将这个字节流所代表的的静态存储结果转化为方法区的运行时数据结构

在堆内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据访问入口

类模型的位置

Class实例的位置

目的

四种验证

为类变量（static修饰的成员变量）分配内存，并且设置该类变量的初始值，即零值

不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化

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

在这个阶段不会像初始化阶段那样会有初始化或者代码被执行

注意

将类、接口、方法、字段的符号引用转换为直接引用

符号引用就是一组符号来描述引用的目标。符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中

直接引用就是直接指向目标的指针，相对偏移量或一个间接定位到目标的句柄

解析动作主要针对类、接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info

具体解释说明

事实上，在HotSpot VM中，加载、验证、准备和初始化会按照顺序有条不紊地执行，但是解析操作往往会伴随着JVM在执行完初始化之后再执行

代码演示多线程环境下执行<clinit>()方法发生死锁

执行结果（代码发生死锁，使用jstack -l <pid>命令无法检测出死锁）

非法的前向引用问题

如果没有类变量和静态代码块，也不会有<clinit>()方法

一个类中没有任何类变量以及静态代码块

一个类声明了类变量，但是没有显式赋值

一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式

代码示例1

代码示例2

在类加载器内部实现中，用一个Java集合（Vector）存放所加载类的引用

一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法就可以获得它的类加载器

由此可见某个类的Class实例与其加载的类加载器之间为双向关联关系

一个类的对象实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回对象所属类的Class对象的引用

当Sample类被加载、链接、初始化后，它的生命周期就开始了。当代表Sample类的Class对象不再被引用，即不可触及时，Class对象的生命周期就结束了，Sample类在方法区内的数据也会被卸载，从而结束Sample类的生命周期

引用示例

事实上Sample对象也指向Sample类的二进制数据结构，在对象头中有一个指向方法区类元数据的指针

loader1变量和obj变量间接引用Sample类的Class对象，而objClass变量则直接引用它

如果在运行中，将上图左侧三个引用类型变量都置为null，此时Sample对象生命周期结束，MyClassLoader对象结束生命周期，代表Sample类的Class对象也结束生命周期，Sample类在方法区内的二进制数据也被卸载

当再次需要使用时，会检查Sample类的Class对象是否存在，如果存在会直接使用，不再重新加载

如果不存在Sample类会被重新加载，在Java虚拟机的堆内存中生成一个新的代表Sample类的Class实例

满足以上三个条件后，并不是和对象一样立即被回收，而是仅仅允许回收

被启动类加载器的类型在整个运行期间是不可能被卸载的（JVM和JSL规范）

被系统类加载器和扩展类加载器加载的类型在运行期不太可能被卸载，因为系统类加载器或者扩展类的实例基本上在整个运行期间总能直接或者间接访问到

被开发者自定义的类加载器加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于调用虚拟机的垃圾收集功能才可以做到

总和以上三点，一个已经加载的类型被卸载的几率很小，几乎不会被卸载

方法区的垃圾收集主要是常量池中废弃的常量和不再使用的类型

只要常量池中的常量没有被任何地方引用，就可以被回收

判断一个类型能否被回收

遇到new、getstatic、putstatic或invokestatic这四条字节码指令时

对类型进行反射调用，如果类型没有经过初始化，则需要触发初始化

初始化类的时候，发现父类没有初始化，则先触发父类初始化

虚拟机启动时，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会初始化这个主类

只用JDK7中新加入的动态语言支持，如果一个java.lang.invoke.MethodHandler实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法对应的类没有进行初始化，则先触发其初始化

当一个接口中定了JDK8新加入的默认方法时，如果这个接口的实现类发生了初始化，要先将接口进行初始化

常量池运行时加载到内存中，即运行时常量池

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性

每一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义

否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等

每个类加载器都有自己的命名空间，命名空间由该加载器所有的父加载器所加载的类组成

在同一命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类

在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两 个类

在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本

当类加载器接收到加载一个类的请求时，自己并不会去加载这个类，而是委托给父类加载器进行加载，如果父类加载器仍然存在父类加载器，则递归向上传递，直至顶层的启动类加载器

如果父类加载器成功加载该类，则成功返回

如果父类加载无法加载该类，则由子类尝试加载

事实上是一种任务委派的模型

子类加载器可以访问父加载器加载的类型，但是反过来是不允许的

 不然，因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑

由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载

但是注意，类加载器"邻居"间， 同一类型仍然可以被加载多次，因为相互并不可见

概念上，将所有派生于抽象类ClassLoader的类加载器都划分为自定义加载器

代码截图

对于用户自定义类，默认使用系统类加载器进行加载

Java的核心类库，使用引导类加载器进行加载

C/C++语言实现，嵌套JVM内部

用来加载Java核心类库，rt.jar、resources.jar、sun.boot.class.path路径下的内容

并不继承java.lang.ClassLoader，没有父加载器

加载扩展类和应用程序类加载器，并指定为他们的父类加载器

出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

Java语言编写，由sun.misc.Launcher$ExtClassLoader实现

派生于ClassLoader类

父类加载器为启动类加载器

从java.ext.dirs系统属性所指定的目录中加载类库，或从jre/lib/ext子目录下加载类库

Java语言编写，由sun.misc.Launcher$AppClassLoader实现

派生于ClassLoader类

父类加载器为扩展类加载器

负责加载环境变量classpath或系统属性java.class.path指定路径下的类库

该类加载器是程序中默认的类加载器。一般来说Java应用的类都是由它来完成加载

通过ClassLoader.getSystemClassLoader()方法可以后去到改类加载器

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

实现步骤

数组类的Class对象，不是由类加载器去创建的，而是在运行期JVM根据需要自动创建的

对于元素为基本数据类型的数组，没有类加载器

对于元素为引用数据类型的数组，类加载器就是对应的加载该类的类加载器

测试

Java虚拟机对Class文件采用的是按需加载，而且加载class文件时，Java虚拟机使用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式

1、如果一个类加载器收到了类加载请求，它并不会自己先去加载。而是把这个请求委托给父类的加载器去执行

2、如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将达到顶层的启动类加载器

3、如果父类的加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式

避免类的重复加载

保护程序安全，防止核心API被篡改

保证对Java核心源代码的保护，防止核心API被篡改

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

JVM必须知道一个类型是由启动类加载器加载的，还是由用户类加载器加载的。如果是用户类加载器加载的，JVM会将这个类加载器的一个引用作为类型信息的一部分，保存到方法区中

是一个抽象类，除了启动类加载器，其他类加载器都继承自他

ClassLoader方法详细解释

双亲委派模型的实现就在loadClass()方法中

双亲委派模型的第一次"被破坏"其实发生在双亲委派模型出现之前——即JDK1.2面世以前的"远古"时代由于双亲委派模型在JDK1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在

面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一 些妥协，为了兼容这些已有的代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass() 中编写代码

上节我们已经分析过loadClass()方法， 双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则

双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为"基础"，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户代码，那该怎么办？

造成问题的根源是类加载器的单一性，子类加载器可以访问父类加载器加载的类，但是父类加载器无法访问子类加载加载的类

例如JDBC系列接口，使用线程上下文类加载去加载MySQL的驱动类

为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）

这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器

有了线程上下文类加载器，程序就可以做一些"舞弊"的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码。这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情

Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JBI 等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的方式 ，在JDK6时 ，JDK提供了java.util.ServiceLoader类 ，以META-INF/Services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案

过程图示

双亲委派模型的第三次"被破坏"是由于用户对程序动态性的追求而导致的。 如：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等

隔离加载类

修改类加载的方式

扩展加载源

防止源码泄露

Tomcat这类Web容器同时部署多个war包，服务器本身也有类库依赖的问题，一般来说，基于安全考虑，服务器所使用的类库应该与应用程序的类库互相独立。同时多个war之间的类也应该隔离

为了实现类隔离的目标，Tomcat制定了如下规则

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

Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类

方式一：重写loadClass()方法

方式二：重写findClass()方法

自定义类加载器重写findClass()方法

main()方法测试，循环创建类加载的实例，加载测试类

MyClassLoader类代码

TestClass类代码

点击运行MyClassLodaer的main()方法，控制台输出

修改TestClass.java源代码，同时使用javac编译器进行编译生成.class文件

观察控制台输出，代码热替换成功

当Java源代码成功编译成字节码后，如果想在不同的平台上面运行， 则无须再次编译

这个优势不再那么吸引人了。Python、PHP、Perl、Ruby、Lisp等有强大的解释器

跨平台似乎已经快成为一门语言必选的特性

Java虚拟机不和包括Java在内的任何语言绑定，它只与.class文件这种特定的二进制文件格式所关联

无论使用何种语言进行软件开发， 只要能将源文件编译为正确的.class文件，那么这种语言就可以在Java虚拟机上执行，可以说统一而强大的Class文件结构，就是Java虚拟机的基石、桥梁

所有的JVM全部遵守Java虚拟机规范，也就是说所有的JVM环境都是一样的， 这样一来字节码文件可以在各种JVM上进行

各语言、编译器、字节码、虚拟机的关系

前端编译器的主要任务就是负责将符合Java语法规范的Java代码转换为符合JVM规范的字节码文件

javac是一种能够将Java源码编译为字节码的前端编译器

javac编译器在将Java源码编译为一个有效的字节码文件过程中经历了4个步骤，分别是词法分析、语法分析、语义分析以及生成字节码

javac编译器整个程序中的位置

有些问题需要从字节码的角度来看待问题，知道了字节码才知道程序到底是怎么运行的

例子

源代码经过编译器编译之后便会生成一个字节码文件，字节码是一种十六进制的类文件，它的内容是JVM的指令，而不像C、C++经由编译器直接生成本地机器码

Java虚拟机的指令由一个字节长度的，代表着某种特定操作含义的操作码 (opcode)以及跟随其后的零至多个代表此操作所需参数的操作数（operand）所构成

虚拟机中许多指令并不包含操作数，只有一个操作码

由于指令只有一个字节大小，所以最多只有256个，对于添加新的指令要非常小心，超过256个可就完蛋了

1. 使用Notepad++查看，安装HEX-Editor插件后进行查看

2. 使用javap指令，JDK自带的反解析工具

3. 使用IDEA插件，jclasslib或jclasslib bytecode viewer客户端工具

任何一个Class文件都对应着唯一一个类或接口的定义信息，但反过来说Class文件实际上它并不一定以磁盘文件形式存在。Class文件是一组以字节为基础单位的二进制流，在内存中的表现形式为字节数组

Class的结构不像XML等描述语言，由于它没有任何分隔符号。所以在其中的数据项，无论是字节顺序还是数量，都是被严格限定的。哪个字节代表什么含义，长度是多少，先后顺序如何，都不允许改变

Class文件格式采用一种类似于C语言结构体的方式进行数据存储，这种结构中只有两种数据类型：无符号数和表

无符号数属于基本的数据类型，以u1、u2、u4、u8来分别代表1个字节、2个字节、4个字节、8个字节的无符号数，无符号数可以用来描述数字、索引引用、数量值或者按照UTF-8编码构成字符串值

表是由多个无符号数或者其他表作为数据项构成的复合数据类型，所有表都习惯性地以"_info"结尾。表用于描述有层次关系的复合结构的数据，整个Class文件本质上就是一张表。由于表没有固定长度，所以通常会在其前面加上个数说明

魔数（Class文件的标志）

Class文件版本号

常量池（存放所有常量）

访问标识

类索引（this_class）、父类索引（super_class）、接口索引集合（interfaces_count、interfaces[]）

字段表集合

方法表集合

属性表集合

总结

随着Java平台的不断发展，在将来Class文件的内容也一定会做进一步的扩充，但是其基本的格式和结构不会做重大调整

从Java虚拟机的角度看，通过Class文件，可以让更多的计算机语言支持Java虚拟机平台

因此，Class文件结构不仅仅是Java虚拟机的执行入口，更是Java生态圈的基础和核心

cafe babe 0000 0034 0016 0a00 0400 1209
0003 0013 0700 1407 0015 0100 036e 756d
0100 0149 0100 063c 696e 6974 3e01 0003
2829 5601 0004 436f 6465 0100 0f4c 696e
654e 756d 6265 7254 6162 6c65 0100 124c
6f63 616c 5661 7269 6162 6c65 5461 626c
6501 0004 7468 6973 0100 184c 636f 6d2f
6174 6775 6967 752f 6a61 7661 312f 4465
6d6f 3b01 0003 6164 6401 0003 2829 4901
000a 536f 7572 6365 4669 6c65 0100 0944
656d 6f2e 6a61 7661 0c00 0700 080c 0005
0006 0100 1663 6f6d 2f61 7467 7569 6775
2f6a 6176 6131 2f44 656d 6f01 0010 6a61
7661 2f6c 616e 672f 4f62 6a65 6374 0021
0003 0004 0000 0001 0002 0005 0006 0000
0002 0001 0007 0008 0001 0009 0000 0038
0002 0001 0000 000a 2ab7 0001 2a04 b500
02b1 0000 0002 000a 0000 000a 0002 0000
0007 0004 0008 000b 0000 000c 0001 0000
000a 000c 000d 0000 0001 000e 000f 0001
0009 0000 003d 0003 0001 0000 000f 2a2a
b400 0205 60b5 0002 2ab4 0002 ac00 0000
0200 0a00 0000 0a00 0200 0000 0b00 0a00
0c00 0b00 0000 0c00 0100 0000 0f00 0c00
0d00 0000 0100 1000 0000 0200 11

对Demo.class文件（16进制文本）一点一点进行解析

加载和存储指令用于将数据从栈帧的局部变量表和操作数栈之间来回传递

算术指令用于对两个操作数栈上的值进行某种特定运算，并把结果重新压入操作数栈

将两种不同的数值类型进行相互转换

创建对象、访问字段、数组操作和类型检查

进行方法调用，结束方法以及放回相应的值

用于操作操作数栈

进行流程控制例如if、if...else、if...else if...else、switch、for、while等

例如对于throw等关键字的处理

使用了synchronized关键字的处理

加载和存储指令用于将数据从栈帧的局部变量表和操作数栈之间来回传递

局部变量压栈指令

常量入栈指令

出栈装入局部变量表指令

算术指令用于两个操作数栈上的值进行某种特定运算，并且把计算后的结果重新压入操作数栈

Java虚拟机中没有直接支持byte、short、char和boolean类型的算术指令，而是使用int类型的指令来代替处理

在处理这些类型的数组时，也会转换成对应的int类型的字节码指令来处理

Java虚拟机中的实际类型与运算类型

数据运算可能会导致溢出，例如两个很大的正整数相加，结果可能是一个负数（补码）

其实Java虚拟机规范并无明确规定过整型数据溢出的具体结果，仅规定了在处理整型数据时，只有除法指令以及求余指令中当出现除数为0时会导致虚拟机抛出异常ArithmeticException

加法指令

减法指令

乘法指令

除法指令

求余指令

取反指令

自增指令

位运算指令

比较指令

原始代码

字节码

类型转换指令可以将两种不同的数值类型进行相互转换

这些转换操作一般用于实现用户代码中的显式类型转换操作，或者用来处理字节码指令集中数据类型相关指令无法与数据类型一一对应的问题

宽化类型转换

窄化类型转换

转换规则

精度丢失问题

转换规则

精度丢失问题

Java是面向对象的程序设计语言，虚拟机平台从字节码层面就对面向对象做了深层次的支持

有一系列指令专门用于对象操作，可进一步细分为创建指令、 字段访问指令、数组操作指令和类型检查指令

虽然类实例和数组都是对象，但Java虚拟机对类实例和数组的创建与操作使用了不同的字节码指令

创建类实例的指令

创建数组的指令

上述创建指令可以用于创建对象或者数组，由于对象和数组在Java中的广泛使用，这些指令的使用频率也很高

对象创建后，就可以通过对象访问指令获取对象实例或数组实例中的字段或者数组元素

访问类字段（static字段，或者称为类变量）的指令：getstatic、putstatic

访问类实例字段（非static字段，或者称为实例变量）的指令：getfield、putfield

数组操作指令主要有：xastore和xaload指令，其中x为具体的数据类型

xaload指令

将一个操作数栈的值存储到数组元素中的指令：bastore、castore、sastore、 iastore、lastore、fastore、dastore、aastore

图示

取数组长度的指令：arraylength

检查类实例或数组类型的指令：instanceof、checkcast

指令checkcast用于检查类型强制转换是否可以进行

指令instanceof用来判断给定对象是否是某一个类的实例，它会将判断结果压入操作数栈

方法调用指令主要有5个：invokevirtual、invokeinterface、invokespecial、invokestatic、invokedynamic

invokevirtual

invokeinterface

invokespecial

invokestatic

invokedynamic

方法调用结束前，需要进行返回。方法返回指令是根据返回值的类型区分的

包含xreturn和return指令

xreturn指令

return指令

总结

说明

如同操作一个普通数据结构中的堆栈那样，JVM提供的操作数栈管理指令，可以用于直接操作操作数栈的指令

将一个或两个元素从栈顶弹出，并且直接废弃

pop：将栈顶的1个Slot数值出栈。例如1个short类型数值

pop2：将栈顶的2个Slot数值出栈。例如1个double类型数值，或者2个int类型数值

复制栈顶一个或两个数值并将复制值或双份的复制值重新压入栈顶

将栈最顶端的两个Slot数值位置交换：swap

Java虚拟机没有提供交换两个64位数据类型（long、double）数值的指令

指令nop是一个非常特殊的指令，它的字节码为0x00

和汇编语言中的nop一样，它表示什么都不做，这条指令一般可用于调试、占位等

程序流程离不开条件控制，为了支持条件跳转，虚拟机提供了大量字节码指令

大体上可以分为比较指令、条件跳转指令、比较条件跳转指令、多条件分支跳转指令、无条件跳转指令等

athrow指令

注意

过程一：异常对象的生成过程 -> throw（手动/自动） -> 指令：athrow

过程二：异常的处理：抓抛模型try - catch - finally -> 使用异常表

处理异常

异常表

详细处理过程

Java虚拟机支持两种同步结构：方法级同步和方法内部一段指令序列的同步，这两种同步都是使用monitor（本质上是对象中的对象头支持的）来支持的

方法级的同步：是隐式的，即无需通过字节码指令来控制，它实现在方法调用和返回操作之中

虚拟机可以从方法常量池的方法表结构中的ACC_SYNCHRONIZED访问标志得知一个方法是否声明为同步方法

当调用方法时，调用指令将会检查方法的ACC_SYNCHRONIZED访问标志是否设置

具体过程

具体

同步一段指令集序列

执行流程

锁必须要释放

计算机由CPU、内存、磁盘、输入设备（鼠标和键盘）、输出设备（显示器）等组成

CPU：中央处理器，计算机最核心的配件，负责所有的计算

内存：你编写的程序、运行的游戏、打开的浏览器都要加载到内存中才能运行，程序读取的数据、计算的结果也都在内存中，内存的大小决定了你能加载的东西的多少

磁盘：提供数据的持久化存储，程序可以进行多次读取

输入设备：一个程序有标准输入、标准输出以及标准错误输出。由鼠标或者是键盘输入数据，提交给程序进行运行

输出设备：程序计算完成后，需要将计算结果进行输出，可以输出到屏幕进行显示

程序员不需要直接和底层硬件打交道，那是因为在底层硬件的基础之上，计算机安装了一层软件

这层软件能够通过响应用户输入的指令进行控制硬件，从而满足程序需求，这种软件称之为操作系统 Operating System（OS）

操作系统对应用程序提供底层硬件支持，例如从网卡中读取输入、从磁盘中读取数据等

操作系统和硬件、应用程序关系图

内核就是操作系统最为核心的部分，操作系统包含内核

操作系统还包括像用户界面（shell、gui、工具和服务）的应用程序

虚拟内存被操作系统划分成两块：内核空间和用户空间，内核空间是内核代码运行的地方，用户空间是用户程序代码运行的地方

大部分计算机有两种运行模式：内核态和用户态，软件中最基础的部分是操作系统，它运行在内核态中。操作系统具有硬件的访问权，可以执行机器能够运行的任何指令。软件的其余部分运行在用户态下

如果需要底层硬件支持例如分配内存，就需要进行系统调用。程序也就是从用户态转到了内核态，当系统调用完成也就从内核态转到了用户态

用户态到内核态的切换有三种情况（系统调用、异常事件、外围设备的中断）

为什么用户态和内核态的切换耗费时间（保护现场和恢复现场耗费大量时间）

系统调用是操作系统的最小功能单位

内核提供了一系列系统函数，在Linux系统中和网络相关有socket、bind、listen、accept、select、poll、epoll等

用户态程序执行系统函数，也就称程序进行了系统调用

这是用户态进程主动要求切换到内核态的一种方式

用户态进程通过系统调用申请使用操作系统提供的服务程序完成工作。例如fork()就是执行了一个创建新进程的系统调用

系统调用的机制核心是使用了操作系统为用户特别开放的一个中断来实现，如Linux的int 80h中断（软中断）

系统调用开销大，从用户态到内核态进行切换

程序

进程

线程

线程和进程的区别

使用内核线程实现（1：1实现）

使用用户线程实现（1：N实现）

使用用户线程加轻量级进程混合实现（N：M实现）

使用内核线程实现的方式也被称为1：1实现

内核线程（Kernel-Level Thread，KLT）就是直接由操作系统内核（Kernel，下称内核）支持的线程

这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上

程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口——轻量级进程（Light Weight Process，LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程

这种轻量级进程与内核线程之间1：1的关系称为一对一的线程模型

1：1模型图

内核线程优势和劣势

使用用户线程实现的方式被称为1：N实现

用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到用户线程的存在及如何实现的

用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助

如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，也能够支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的

1：N模型图

用户线程优势和劣势

线程除了依赖内核线程实现和完全由用户程序自己实现之外，还有一种将内核线程与用户线程一起使用的实现方式，被称为N：M实现

在这种混合实现下，既存在用户线程，也存在轻量级进程

在这种混合模式中，用户线程与轻量级进程的数量比是不定的，是N：M的关系

N：M模型图

线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上去

优点

缺点

线程的执行时间由操作系统分配，线程的切换也是由操作系统来完成

线程本身无法主动获取执行时间，但是可以让出执行时间。如Thread.yield()方法

线程的执行时间可控，不会因为某个程序的代码出现故障导致整个系统崩溃

新建（New）：创建后尚未启动的线程处于这种状态

运行（Runnable）：包括操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着操作系统为它分配执行时间

无限期等待（Waiting）：处于这种状态的线程不会被分配处理器执行时间，它们要等待被其他线程显式唤醒。以下方法会让线程陷入无限期的等待状态：

限期等待（Timed Waiting）：处于这种状态的线程也不会被分配处理器执行时间，不过无须等待被其他线程显式唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待状态：

阻塞（Blocked）：线程被阻塞了，"阻塞状态"与"等待状态"的区别是"阻塞状态"在等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生；而"等待状态"则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态

结束（Terminated）：已终止线程的线程状态，线程已经结束执行

线程各状态转换图

New和Terminated状态分别为起始和结束状态，和Runable状态不可逆。其他状态均能和Runnable状态相互转换

New -> Runnable为单向，不可能再次变成New状态，一个已经调用start()方法的线程再次调用start()方法直接报错，start()方法内部对线程状态进行检查，也就是说start()方法只能够被调用一次

Runnable -> Terminated为单向，当线程处于死亡状态后，不能重新变成Runnable状态，再次调用start()方法直接报错，start()方法内部对线程状态进行检查，也就是说start()方法只能够被调用一次

流程一：NEW -> RUNNABLE（READY <-> RUNNING） -> TERMINATED

流程二：NEW -> READY -> RUNNING -> TIMED WAITING -> RUNNABLE（READY <-> RUNNING） -> TERMINATED

流程三：NEW -> READY -> RUNNING -> BLOCKED -> RUNNABLE（READY <-> RUNNING） -> TERMINATED

之前的讲述中说过，Java线程的实现方式是1：1，也就是一个Java线程映射到内核线程

这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂，操作系统能容纳的线程数量也很有限

可能用户线程切换的成本接近于计算本身的开销

线程数量越多，切换的成本越高

这对于大并发的场景无能为力

内核线程的调度成本主要来自于用户态与内核态之间的状态转换

这两种状态转换的开销主要来自于响应中断、保护和恢复执行现场的成本

线程上下文切换解释说明

内核线程（1：1）切换成本高昂，那么之前的用户线程（1：N）就非常合适了

例如其他语言提供了自己的解决方案

OpenJDK在2018年创建了Loom项目，这是Java用来应对本节开篇所列场景的官方解决方案

在Java中协程被叫做纤程（Fiber）

纤程的出现并不是为了取代当前基于操作系统的线程实现，而是会有两个并发编程模型在Java虚拟机中并存，可以在程序中同时使用

新模型有意地保持了与目前线程模型相似的API设计，用户甚至不需要改动大量代码就能够使用纤程

纤程对Java来说是一个划时代的出现，是自Java8以来最有革命性的改动，有可能在JDK17中以预览版出现

如果在Java中正式使用了纤程，那么一直以来Go语言簇拥着，Go具有高并发的优势将不复存在。JDK16以后ZGC可以将GC停顿控制在1ms以内，随着JIT技术的发展，C++对于Java高性能的优势也将不复存在

不能同时卖出第20张票

不能卖出第-1张票

在Java语言里面（特指JDK5以后，即Java内存模型被修正之后的Java语言），不可变（Immutable）的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再进行任何线程安全保障措施

如果多线程共享的数据是一个基本数据类型，那么只要在定义时使用final关键字修饰它就可以保证它是不可变的

如果共享数据是一个对象，由于Java语言目前暂时还没有提供值类型的支持，那就需要对象自行保证其行为不会对其状态产生任何影响才行

把对象里面带有状态的变量都声明为final，这样在构造函数结束之后，它就是不可变的

java.lang.String就是一个典型的不可变对象

总结来说就是将变量声明为final，变成只读的，不提供修改的机会

不管运行时环境如何，调用者都不需要任何额外的同步措施

在Java API中标注自己是线程安全的类，大多数都不是绝对的线程安全

测试Vector是否为绝对线程安全

可以看到即使Vector的add()、remove()、get()方法都被synchronized关键字修饰，但是在多线程并发访问的情况下仍然是线程不安全的

相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单次的操作是线程安全的，我们在调用的时候不需要进行额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性

在Java语言中，大部分声称线程安全的类都属于这种类型，例如Vector、HashTable、Collections的synchronizedCollection()方法包装的集合等

线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用

我们平常说一个类不是线程安全的，通常就是指这种情况。Java类库API中大部分的类都是线程兼容的，如与前面的Vector和HashTable相对应的集合类ArrayList和HashMap等

线程对立是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用代码。由于Java 语言天生就支持多线程的特性，线程对立这种排斥多线程的代码是很少出现的，而且通常都是有害的，应当尽量避免

一个线程对立的例子是Thread类的suspend()和resume()方法

常见的线程对立的操作还有System.setIn()、Sytem.setOut()和System.runFinalizersOnExit()等

互斥同步（Mutual Exclusion & Synchronization）是一种最常见也是最主要的并发正确性保障手段

同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者是一些，当使用信号量的时候）线程使用

而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量 （Mutex）和信号量（Semaphore）都是常见的互斥实现方式

在"互斥同步"这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的

在Java里面，最基本的互斥同步手段就是synchronized关键字，这是一种块结构（Block Structured）的同步语法

自JDK5起，Java类库中新提供了java.util.concurrent包（下文称J.U.C包），其中的java.util.concurrent.locks.Lock接口便成了Java的另一种全新的互斥同步手段

ReentrantLock只是提供了synchronized更丰富的功能，而不一定有更优的性能，所以在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步

互斥同步面临的主要问题是进行线程阻塞和唤醒所带来的性能开销，因此这种同步也被称为阻塞同步（Blocking Synchronization）

互斥同步属于一种悲观的并发策略，其总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享的数据是否真的会 出现竞争，它都会进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加锁），这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开销

基于冲突检测的乐观并发策略，通俗地说就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了

如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止

这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被称为非阻塞同步（Non-Blocking Synchronization），使用这种措施的代码也常被称为无锁（Lock-Free）编程

这里需要保证操作和冲突检测这两个步骤具备原子性，本质上是CPU指令lock cmpxchg 指令

常用的指令为Compare-and-Swap（比较并交换），下文称CAS

CAS指令需要有三个操作数，分别是内存位置（在Java中可以简单地理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）

CAS指令执行时，当且仅当V符合A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断

CAS存在ABA问题

如果能让一个方法本来就不涉及共享数据，那它自然就不需要任何同步措施去保证其正确性

因此会有一些代码天生就是线程安全的，其中有两类：可重入代码（Reentrant Code）和线程本地存储（Thread Local Storage）

锁消除是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除

这部分不是很有用，但是面试经常问，掌握和理解也比较困难，这个知识点并不需要掌握