JVM

Java 语言之所以有跨平台的优点，完全是 JVM 的功劳

跨平台性是 JVM 存在的最大的亮点。

这大大提升了 Java 语言的平台灵活性，能够在众多语言争鸣的时代，脱颖而出。

举例说明

Java 虚拟机屏蔽了与具体操作系统平台相关的信息

使得 Java 程序只需生成在 Java 虚拟机上运行的目标代码（字节码）

这样就可以在多种平台上不加修改地运行。

Java语言的优势

C语言的缺点

java -version

C:\Users\Wayne.WangTJ>java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

全称 java development kit ，开发工具包

【Java的核心】面向开发者，为开发者提供开发类库

JDK 包含了JRE，一堆工具类（javac、java）以及 Java 的基础类库（Object，string）；

Java开发工具包(JDK)是完整的Java软件开发包

包含了JRE，编译器和其他的工具(比如：JavaDoc，Java调试器)，

可以让开发者开发、编译、执行Java应用程序。

Java运行时环境(JRE)是将要执行Java程序的Java虚拟机。

它同时也包含了执行applet需要的浏览器插件。

全称 java runtime environment。

包含了JVM 实现和需要的类库

JRE 是一个运行环境，并非开发工具

JVM(Java虚拟机)

JVM 是可运行 Java 代码的假想计算机 

它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

Java源文件被编译成能被Java虚拟机执行的字节码文件。

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

包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收，堆 和 一个存储方法域。 

Java虚拟机是一个可以执行Java字节码的虚拟机进程。

JVM 有自己完善的硬件架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。

Java 语言最重要的特点就是跨平台运行。使用 JVM 就是为了实现跨平台。

JDK 是开发工具包，包含了JRE

JRE 是运行环境，不提供开发工具包。

JRE 包含了JVM，JRE = JVM+lib。

JRE 为 Class 文件提供了运行的环境，但是需要 JVM 进行 Class文件的翻译

JVM 将翻译好的文件传给操作系统或者是 CPU 映射指令集，才能够最终完成运行。

JVM（安装路径\Java\jre1.8.0_144\bin）

所需类库（安装路径\Java\jre1.8.0_144\lib）

通过三种不同的类加载器对 Class 文件进行加载

【自定义类加载器】通过复写 classLoader 方法

对加载好的 Class 文件进行字节码、静态变量、方法引用等

进行验证和解析，为初始化做准备。

类加载的最后阶段

对类进行初始化

静态变量 

类级数据

只有一个

它是一个共享资源

由于方法区域共享多个线程的内存，所存储的数据不是线程安全的

为共享内存区域，多线程环境下共享这两块内存区域。

对象

对象对应的实例变量

数组

只有一个

由于堆区域共享多个线程的内存，所存储的数据不是线程安全的

为共享内存区域，多线程环境下共享这两块内存区域。

局部变量

栈区域是线程安全的，因为它不共享资源；

线程私有部分，私有数据对其他线程不可见。

也称作程序计数器

线程私有部分，私有数据对其他线程不可见。

本地方法信息

线程私有部分，私有数据对其他线程不可见。

“尽管所有方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。”

但对于HotSpotJVM而言，方法区还有一个别名叫作Non-Heap(非堆)，目的就是要和堆分开。、

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

该区域的内存内存回收目标主要是针对

只有一个

方法区存放的数据与堆内存之间的关系

【看图】方法区存放了 ClassLoader 对象的引用，也存放了一个到Class对象的引用

【看图】这两个引用的对象实例会存放到堆内存中。

一个到类 ClassLoader 的引用

JIT 编译器编译后的代码

即时编译器编译后的代码

（JTL）即时编译器编译后的代码缓存等数据

静态变量

final类型常量

static 变量

static-final 常量

类中的静态变量信息

static+final

区别final

这里只的静态变量的引用，即，public static Person person  = new Person(); 
存放的是 person部分(即，静态类型)，后面的实体是存放在堆中。

JDK7以后，静态变量就移动至堆中保存，概念上逻辑上(概念上)依然是属于方法区

所有域的相关信息

域申明顺序

具体：class/method/field 等

方法信息

类型信息或类信息

字段信息

常量

类型的常量池

Class文件中的常量池表和运行时常量池区别

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

JVM为每个已加载的类型(类或接口)都维护了一个常量池。
池中的数据像数据项一样是通过索引访问的

运行时常量池中包含多种不同常量

异常

运行时常量池

Class 文件中的常量池

方法区包含了一个特殊的区域 “运行时常量池”

Class 文件中的常量池（编译器生成的各种字面量和符号引用）会在类加载后被放入这个区域。

（Runtime Constant Pool）是方法区的一部分。

Class文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量池（Constant Pool Table）

用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

Java虚拟机对Class文件的每一部分（自然也包括常量池）的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可、装载和执行。

存储信息

常量池中存储的数据

运行时常量池

常量池的分类

常量池的优势

总结

方法区的实现方式为"永久代"，所以在此之前好多人讲方法区就曾为“永久代”，实际上两者并不等价

方法区不等于永久代

永久代（方法区/永久代（线程共享））

JDK8开始(元空间)

彻底废弃了“永久代的概念”，改用与“JRockit”，“J9”一样在本地内存中实现的“元空间”来代替

在JDK7时，HotSpot，把原来放在“永久代”的“字符串常量池”、“静态变量”等移至Java堆中

Java8中，永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代。

大小设置

元空间的本质和永久代类似，最大的区别

即使用Java堆的永久代来实现方法区,

这样，HotSpot的垃圾收集器，就可以像管理Java堆一样，管理这部分内存, 而不必为方法区开发专门的内存管理器

(永久代的内存回收的主要目标是针对常量池的回收和类型的卸载, 因此收益一般很小)

HotSpot 虚拟机 1.8之前

HotSpot 虚拟机 1.8之后

只有一个

堆（Heap-线程共享）- 运行时数据区

堆内存是运行时数据区中非常重要的结构

对于 JVM 来说，堆内存占据着十分重要的且不可替代的位置。

Java堆是虚拟机锁管理的内存中最大的一块

JVM启动时，从操作系统获取的一片内存空间

当 Java 程序开始运行时，JVM 会从操作系统获取一些内存。

JVM 使用这些内存，这些内存的一部分就是堆内存。

堆内存的大小在虚拟机被启动时就确定了

堆内存通常在存储地址的底层，向上排列。

当一个对象通过 new 关键字或通过其他方式创建后，对象从堆中获得内存。

当对象不再使用了，被当做垃圾回收掉后，这些内存又重新回到堆内存中。

数组

对象

对象对应的实例变量

从上文堆内存的结构图中，我们看到了比较多的JVM堆内存中的专有名词，比如：年轻代，老年代。

那么对于堆内存来说，分代是什么意思呢？为什么要进行分代呢？

将堆内存，从概念层面进行模块划分，总体分为两大部分，年轻代和老年代。

从物理层面，将堆内存进行内存容量划分，一部分分给年轻代，一部分分给老年代。

【易于堆内存分类管理】

【易于垃圾回收】

JVM 内存 与 堆内存中不同内存空间模块

不是所有虚拟机固有的

堆内存(由于现代VM采用分代收集算法，从GC角度细分)

Java堆，从GC的角度细分 

老年代

新生代/年轻代（YoungGen、YoungGeneration）

图解堆内存 

堆内存的结构图

堆内存中的不同的代

堆内存存放的是对象，垃圾收集器就是收集这些对象，然后根据 GC 算法回收；

新生成的对象首先放到年轻代 Eden 区

当 Eden 空间满了，触发执行 Minor GC，存活下来的对象移动到Survivor0 区

当 Survivor0空间满了，触发执行 Minor GC，Survivor0 区存活对象移动到 Suvivor1 区

经过多次 Minor GC 仍然存活的对象移动到老年代

理解并掌握对象优先在 Eden 区分配的实验案例【重点】
理解并掌握对象直接在老年代分配的触发条件，理解什么是大对象【重点】
掌握堆内存对象转移的完整流程图及触发机制【核心】
理解并掌握年龄判断的定义，作用及默认年龄值【重点】

其核心是围绕堆内存对象转移的完整流程图及触发机制

Eden 区属于年轻代（YoungGen）。

新创建的对象 优先存储于年轻代中的Eden区的

在创建新的对象时，大多数情况下，对象优先在 Eden 区中分配。

当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

“优先” 意味着首先考虑

【特殊情况】新创建的对象还是有可能不在Eden区分配的。

【特殊情况】对于新创建的大对象，会直接进入老年代中

【优先】新创建的对象是优先存放入 Eden 区的

【特殊情况】对于新创建的大对象，会直接进入老年代中

尽量避免程序中出现过多的大对象

什么是大对象

如果幸存者区（Survivor）中相同年龄的所有对象大小的总和大于Survivor空间的一半，

年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

图解

Eden 区优先存放新建的独享

新生成的非大对象首先放到年轻代 Eden 区，当 Eden 空间满了，触发 Minor GC，存活下来的对象移动到 Survivor0 区

Survivor0 区满后,触发执行 Minor GC，Survivor0 区存活对象移动到 Suvivor1 区

经过多次 Minor GC 仍然存活的对象移动到老年代。

如果新生成的是大对象，会直接将该对象存放入老年代。

老年代存储长期存活的对象，GC 期间会停止所有线程等待 GC 完成，所以对响应要求高的应用，尽量减少发生 Major GC，避免响应超时。

作用

对象年龄（Age）计数器

年龄增加

年龄默认阈值

谁进行空间担保？

什么是空间分配担保？

为什么要进行空间担保？

如果在Java堆中没有内存完成实力分配，并且堆也无法再扩展时，Java虚拟机将会抛出OOM异常

主要关注的栈内存，就是虚拟机栈中局部变量表部分。

栈内存的消耗，是因为每个方法执行的同时，会创建一个栈帧

占用空间最大的部分就是栈帧的局部变量表部分。

所有局部变量将在栈内存中创建。

虚拟机栈是什么？

Java虚拟机栈是线程私有的

栈帧

设置栈的大小

不同的线程中所包含的栈帧时不能互相引用的

方法调用

异常

是什么？

存储

线程安全

作用

和虚拟机栈类似和区别

没有明确要求本地方法栈所需要用什么语言

HotSpot把本地方法栈和虚拟机栈合二为一

一块较小、很小、非常小的内存空间

这块内存区域很小，几乎可以忽略不记

【线程私有】在 JVM 规范中，每个线程都有它自己的程序计数器，是线程私有的

每条线程都要有一个独立的程序计数器

程序计数器是每个线程私有的

线程私有部分，私有数据对其他线程不可见。

这类内存也称为“线程私有”的内存

它是程序控制流的指示器

基础功能，都需要依赖它来完成

控制着计算机指令的基础功能

基础功能包括分支、循环、跳转、异常处理、线程恢复等

每个线程都有一个单独的PC寄存器

每个线程启动时，都会创建一个 PC寄存器

每一个线程都有它自己的 PC 寄存器，也是该线程启动时创建的。

每个线程都有一个程序计数器

除了程序计数器外，其他区域都是可能发生OOM的区域

此内存区域是唯一一个不会出现OOM情况的区域。

它是唯一一个在 JVM规范中，没有规定任何 OOM 情况的区域

此内存区域是唯一一个在JVM规范中没规定任何OOM情况的区域

唯一一个在JVM中没有规定任何OOM Error情况的区域。

OutOfMemoryError(OOM)

JVM规范《Java虚拟机规范》

【当前方法】

其实就是一个指针，指向方法区中的方法字节码

任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。

PC 寄存器里，保存有当前正在执行的 JVM 指令的地址。

程序计数器会存储当前线程正在执行的 java 方法的 JVM 指令地址

指向下一条指令的地址

由执行引擎读取下一条指令

一旦执行指令，它会将被下一条指令更新

每个线程都有一个程序计数器，分别记录着自己线程的下一跳代码(指令)的地址，

PC寄存器的内容，总是指向下一条将被执行指令的地址

它保存着下一条将要执行的指令地址

它寄存着字节码中下一句要运行的代码的地址

当CPU在线程调度，切换时，保证每次的切换都能够切换回上次运行的地方。

【工作原理】字节码解释器工作时，就是通过改变这个计数器的值，来选取下一个条需要执行的字节码指令

避免了在Java 堆和Native 堆中来回复制数据，能够提高效率

在一些场景中可以显著提高性能。

访问直接内存的速度会优于Java堆

当新生代空间不足时，就会触发Minor GC，这里的新生代满指Eden满，Survivor满不会引发GC。
（每次Minor GC会清理年轻代内存）

大多数Java对象的生命周期都比较短，所以 Minor GC会非常频繁，一般回收速度也比较快。

Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行。

指发生在老年代的GC，对象从老年代消失时，我们说“Major GC”或 “Full GC”发生了(上面讲了Major GC 与 Full GC 很多地方叫法混淆)

出现了Major GC，经常会伴随至少一次的Minor GC
（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）

如果Major GC内存还不足，就报OOM

1.找到GC Roots不可达的对象，如果没有重写finalize()或者调用过finalize()，则将该对象加入到F-Queue中

2.再次进行标记，如果此时对象还未与GC Roots建立引用关系，则被回收

不同对象的可达性状态

对垃圾收集的影响

该算法是通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连(用图论的话来说,就是从GC Roots到这个对象不可达)时,则证明此对象是不可用的。

当一个对象到GC Roots没有引用链相连(GC Roots到这个对象不可达)时，证明此对象不可用

GC Roots种类

GC Roots

前言

引用划分种类的意义

强引用

软引用

弱引用

虚引用

引用队列又称为Reference Queue

， 它位于java.lang.ref包下， 我们在建各种引用(软引用， 弱引
用， 幻象引用) 并关联到响应对象时， 可以选择是否需要关联引用队列。JVM会在特定的时机将引用入
队到队列中，程序可以通过判断引用队列中是否已经加入引用，来了解被引用的对象是否被GC回收。

java.lang.ref.Reference为软(soft) 引用、弱(weak) 引用、虚(phantom) 引用的父类。

因为Reference对象和垃圾回收密切配合实现， 该类可能不能被直接子类化.

finalize()

即使在可达性分析算法中不可达的对象，也并非是非死不可的，要真正被回收至少经历两次标记过程，

如果没有与GCRoots的引用链，对象将会被第一次标记和筛选（执行finalize()方法）

注意：并不建议使用该方法。

对象是否覆盖finalize方法

JVM是否执行过该对象的finalize方法

Java和C++的一大区别：C++允许对象定义析构函数方法

然而， 内存并不是唯一需要被释放的资源

finalizer方法什么？

finalizers的finalize() 方法产生的负面影响非常大

finalize()方法什么时候被调用？析构函数(finalization)的目的是什么？

当对象对当前使用这个对象的应用程序变得不可触及时，这个对象就可被回收。

给对象添加一个引用计数器，每当一个地方引用它时计数器加1；引用失效计数器减1，计数器为0说明不再引用

给对象添加一个引用计数器，当对象增加一个引用时计数器加 1，引用失效时计数器减 1。引用计数为 0 的对象可被回收。

优点：实现简单，判定效率高

缺点：无法解决对象相互循环引用的问题

缺陷：循环引用会导致内存泄漏

在Java中，引用和对象是有关联的，如果要操作对象，则必须用引用进行。

因此，很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收。

一个对象如果没有任何与之关联的引用，即引用计数都不为0，则说明对象不太可能再被用到，那么这个对象就是可回收对象。

没办法解决循环引用的问题

前言

如何检测对象是否为垃圾

可达性分析法基本原理

可达性分析法示例（图示）

如何选取 GCRoots 对象呢？四种类型的对象解释

GC Roots

下面是一个不同可达性状态的转换图

判断可达性条件， 也是JVM垃圾收集器决定如何处理对象的一部分考虑因素

所有的对象可达性引用都是java.lang.ref.Reference的子类

它里面有一个get()方法， 返回引用对象。

如果已通过程序或垃圾收集器清除了此引用对象， 则此方法返回null。

也就是说， 除了幻象引用外，软引用和弱引用都是可以得到对象的。

而且这些对象可以人为拯救，变为强引用，例如把this关键字赋值给对象， 只要重新和引用链上的任意一个对象建立关联即可，

为了解决引用计数法的循环引用问题，Java使用了可达性分析的方法。

虚拟机栈（栈帧中的本地变量表）中引用的对象
方法区中类静态属性引用的对象
方法区中常量变量引用的对象
本地方法栈中JNI（即一般说的Native方法）引用的对象
活跃线程的引用对象

通过一系列的“GC roots”对象作为起点搜索。

如果在“GC roots”和一个对象之间没有可达路径，则称该对象是不可达的。

注意：不可达对象 != 可回收对象，不可达对象变为可回收对象至少要经过两次标记过程。

两次标记后仍然是可回收对象，则将面临回收。

两种可达性判断条件

优点

缺点

Python

Squirrel等

可达性分析图解

finalize

1.在虚拟机栈(栈帧中的本地变量表)中引用对象

2.在方法区类静态属性引用的对象

3.在方法区中常量引用的对象，譬如字符串常量池里的引用

4.在本地方法栈中JNI(即，通常所说的Native方法)引用的对象

5.Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻异常对象等，还有系统类加载器

6.所有被同步锁(synchroonized关键字)持有的对象

7.反应Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等

除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合

JAVA

C#

Lisp等

保守式GC

半保守式GC

准确式GC

适用于，GC与用户线程并发的环境中，在不停止用户线程的情况下，对垃圾进行标记

使用

会产生的问题

强引用是最传统的引用，无论任何情况下，只要强引用还在，垃圾回收器就永远不会回收掉被引用的对象

Object obj = new Object()

弱引用是用来描述一些还有有用，但非必须的对象。
只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行回收。

1.2JDK版本后：提供SoftReference类来实现软引用

弱引用也是用来描述那些非必须的对象，但是它的强度比软引用低一些，被弱引用关联着的对象只能生存到下一次垃圾回收发生为止。无论当前内存是否足够

JDK1.2版本后：提供WeakReference类来实现弱引用

又叫“幽灵引用”或“幻影引用”，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。

虚引用的唯一目的只是为了能够在这个对象被收集器回收时收到一个和系统通知。

JDK1.2版本后：提供PhantomReference类来实现虚引用

“根节点枚举”就是在确认根节点(GC Roots)的过程

而且，迄今为止所有的收集器在“根节点枚举”这一步骤时都必须暂停用户线程(STW)

什么是OopMap？

可达性分析算法必须是在一个确保一致性的内存快照中进行。如果在分析的过程中对象引用关系还在不断变化，分析结果的准确性就不能保证。
安全点意味着在这个点时，所有工作线程的状态是确定的，JVM 就可以安全地执行 GC 。

如何选定安全点

如何让所有线程在安全点上停止下来呢？

如果一个线程处于 Sleep 或中断状态，它就不能响应 JVM 的中断请求，再运行到 Safe Point 上。

Safe Region 是指在一段代码片段中，引用关系不会发生变化。在这个区域内的任意地方开始 GC 都是安全的。

线程在进入 Safe Region 的时候先标记自己已进入了 Safe Region，在这段时间里，虚拟机要发起垃圾收集时就不会管这些声明已经在安全区域内的线程了，等到被唤醒时准备离开 Safe Region 时，先检查能否离开，如果 GC 完成了，那么线程可以离开，否则它必须等待直到收到安全离开的信号为止。

基本概念

分为两个阶段：标注和清除

图解

适用场景

标记清除垃圾回收背后的想法很简单

标记-清除收集具有如下几个阶段

下面来考虑一个例子

缺点

基本概念

大致原理

适合场景

优缺点

基本概念

老年代使用的是标记-整理算法

结合了以上两个算法，为了避免缺陷而提出。

标记阶段和Mark-Sweep算法相同，标记后不是清理对象，而是将存活对象移向内存的一端。然后清除端边界外的对象。

原理和标记清除算法类似，只是最后一步的清除改为了将存活对象全部移动到一端，然后再将边界之外的内存全部回收。

标记整理算法(老年代)

即在标记-清除算法的基础上，做一个整理的过程，以解决标记-清除中的碎片化问题

优缺点

在CMS中为了解决不在内存分配上和访问上增加太大额外负担的方案

图解

不是，通常称之为分代收集理论，或称之为分代收集思想。

目前虚拟机基本都采用分代收集理论，来进行垃圾回收。

edan

s1

s2

minor gc

major gc 等价于 full gc

(Tenured/Old Generation)

特点：每次垃圾回收时只有少量对象需要被回收

Eden/s1/s2

特点：每次垃圾回收时都有大量垃圾需要被回收，因此可以根据不同区域选择不同的算法。

因为新生代中每次垃圾回收都要回收大部分对象，

即要复制的操作比较少，但通常并不是按照1：1来划分新生代。

一般将新生代划分为一块较大的Eden空间和两个较小的Survivor空间(From Space, To Space)，

每次使用Eden空间和其中的一块Survivor空间，当进行回收时，将该两块空间中还存活的对象复制到另一块Survivor空间中。

它用来存储class类，常量，方法描述等。

对永生代的回收主要包括废弃常量和无用的类。

单线程

串行单线程收集器

最基本、发展历史最久的收集器

是Client 模式下的默认新生代收集器

采用复制算法的、单线程的收集器

Serial收集器依然是虚拟机运行在 Client 模式下的默认新生代收集器

特点：单线程收集；标记-复制算法

优点：简单高效

对线程开销少，简单有效，适用于内存资源受限，和处理器核心数教少的环境。(目前，客户端模式下默认使用收集器)

只会使用一个 CPU 或者一条线程去完成垃圾收集工作

进行垃圾收集时必须暂停其他线程的所有工作，直到它收集结束为止。

Serial 收集器运行过程

Serial 收集器运行过程

(serial)

对大多数的小应用就足够了。

小应用(在现代处理器上，需要大概100M左右的内存)

单线程

简单高效

使用复制算法

采用复制算法

Serial收集器的多线程版本

除了使用多线程进行垃圾收集外，其余行为和 Serial 收集器完全一样

Server 模式下的虚拟机首选的新生代收集器。

本质上是Serial收集器的多线程并行版本，除了多线程并发没有，其他几乎与Serial保持一致

除了 Serial 收集器外，目前只有它，能与 CMS 收集器配合工作。

CMS 收集器第一次实现了让垃圾收集器与用户线程基本上同时工作

默认开启的收集线程数，与 CPU 数量相同

在 CPU 数量非常多的情况下，可以使用 -XX:ParallelGCThreads 参数来限制垃圾收集的线程数。

Parnew 收集器运行过程如图所示

多线程

使用复制算法

(throughput)

使用并行版本的新生代垃圾收集器

它用于中等规模和大规模数据的应用程序

CPU用于运行用户代码的时间/CPU总消耗时间

吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)

是一个吞吐量优先的收集器

也是一个新生代收集器，并行的多线程收集器。

采用了复制算法

目标：达到一个可控制的吞吐量。

虚拟机运行在 Server 模式下的默认垃圾收集器。

被称为“吞吐量优先收集器”。

Parallel Scavenge 收集器运行过程同 Parnew 收集器一样

图解

CMS 等收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，

而 Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量。、

吞吐量：CPU 用于运行用户代码时间与 CPU 总消耗时间的比值

即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。

-XX：MaxGCPauseMills 和 -XX：GCTimeRatio参数

-XX：UseAdaptiveSizePolicy 参数

在 JDK 1.5 以及之前版本（Parallel Old 诞生以前）中与 Parallel Scavenge 收集器搭配使用

作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。 

Serial Old 收集器同样是一个单线程收集器，作用于老年代

使用“标记-整理算法”

这个收集器的主要意义也是在于：给 Client 模式下的虚拟机使用。

Serial Old 收集器运行过程如图所示

1. 在JDK1.5之前版本中与新生代的Parallel Scavenge收集器搭配使用。

2. 作为年老代中使用CMS收集器的后备垃圾收集方案。

子主题

都是多线程的收集器

都使用的是复制算法

在垃圾收集过程中都需要暂停所有的工作线程

子主题

Parallel Old 收集器是 Parallel Scavenge 收集器的老年代版本

使用多线程和“标记-整理算法”进行垃圾回收

这个收集器在 JDK 1.6 之后的出现，“吞吐量优先收集器”终于有了比较名副其实的应用组合，

在注重吞吐量以及 CPU 资源敏感的场合，都可以优先考虑 Parallel Scavenge收集器+Parallel Old收集器 的组合。

由于在JDK6之前，Parallel Scavenge唯一能够搭配的就是 Serial Old收集器，但是 Serial Old是一个单线程的处理器，实际上Serial Old 在一定程度上拖累了 Parallel Scavenge所以 Parallel Old 就诞生了

Parallel Scavenge 收集器+Parallel Old 收集器 的组合运行过程如图所示

在JDK1.6之前，新生代使用ParallelScavenge收集器只能搭配年老代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量

Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器

如果系统对吞吐量要求比较高，可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。

子主题

默认启动的线程数是：(处理器核心数量+3)/4

初始标记

并发标记

重新标记

并发清除

优点

缺点

CMS（Conrrurent Mark Sweep，连续标记扫描）收集器

是以获取最短回收停顿时间为目标的收集器。

使用标记-清除算法。

初始标记：仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，需要停顿（STW）。

并发标记：从GC Root 开始对堆中对象进行可达性分析，找到存活对象，它在整个回收过程中耗时最长，不需要停顿。

重新标记：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿(STW)。

并发清除：不需要停顿。

吞吐量低

无法处理浮动垃圾，可能出现 Concurrent Mode Failure

会产生空间碎片

初始标记：标记GC Roots直接关联的对象，速度快

并发标记：GC Roots Tracing过程，好市场，与用户进程并发工作

重新标记：修正并发标记期间用户进程继续运行而产生变化的标记，耗时比初始标记长，但远小于并发标记

并发清除：清除标记的对象

对CPU资源敏感

无法回收浮动垃圾

标记-清除算法，会产生内存碎片，可以通过参数开启碎片的合并整理

初始标记：标记 GCRoots 能直接关联到的对象，时间很短；
并发标记：进行 GCRoots Tracing（可达性分析）过程，时间很长；
重新标记：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，时间较长；
并发清除：回收内存空间，时间很长。其中，并发标记与并发清除两个阶段耗时最长，但是可以与用户线程并发执行。

CMS 收集器运行过程如下图所示:

最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。

初始标记

并发标记

重新标记

并发清除

CMS收集器工作过程

对cpu资源敏感

无法处理浮动垃圾

基于标记清除算法 大量空间碎片

使用多个 CPU 来缩短 Stop The World 停顿时间，与用户线程并发执行；

独立管理整个堆，但是能够采用不同的方式去处理新创建对象和已经存活了一段时间、熬过多次 GC 的旧对象，以获取更好的收集效果；

基于标记-整理算法

无内存碎片产生

空间整合，不会产生内存碎片

可预测的停顿：

能建立可预测的停顿时间模型

能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集器上的时间不得超过N毫秒。

标记GC Roots直接关联的对象

初始标记：仅仅只是标记一下GC Roots 能直接关联到的对象，并且修改TAMS（Nest Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以的Region中创建对象，此阶段需要停顿线程(STW)，但耗时很短。

对堆中对象进行可达性分析，找出存活对象，耗时长，与用户进程并发工作

从GC Root 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行。

为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中。

这阶段需要停顿线程(STW)，但是可并行执行。

修正并发标记期间用户进程继续运行而产生变化的标记

对各个Region的回收价值排序，然后根据期望的GC停顿时间制定回收计划

首先对各个 Region 中的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。

此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。

仅仅是标记一下GC Roots能够直接关联到的对象并且修改TAMS指针值

从GC Roots开始对队中对象进行可达性分析自己，找到需要回收的对象

递归扫描完成后，还需要重新处理SATB记录下在并发时有引用变动的对象

需要STW

对并发阶段结果后遗留下来的少量SATB记录进行处理

因为涉及到对象移动，所以需要STW

对Region进行数据统计，对各个Region的回收价值和成本进行排序，更具用户所期望的停顿时间来制定回收计划

可以自由选择任意多个Region进行收集，然后回收的那一部分Region的存活对象复制到空的Region中，清理掉原来的Region

从整体来看：标记-整理

从region之间来看：复制算法

停顿时间可以预测：我们指定时间，在指定时间内只回收部分价值最大的空间，而CMS需要扫描整个年老代，无法预测停顿时间

无内存碎片：垃圾回收后会整合空间，CMS采用"标记-清理"算法，存在内存碎片

由于只回收部分region，所以STW时间我们可控，所以不需要与用户线程并发争抢CPU资源，而CMS并发清理需要占据一部分的CPU

相比Parallel Scavenge/Parallel Old 没有吞吐量优势

由于采用分区算法，所以每个区需要设计RSet，在内存空间上回尝试额外的消耗(20%左右)

可达性分析算法

根据用户期待的gc停顿时间指定回收计划

回收所有的eden s区

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

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

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

从ZIP压缩包中读取，JAR,EAR,WAR格式等等

从网络中获取，典型的就是Web Applet

在运行时计算生成，例如：动态代理技术，可动态生成一个“*&Proxy”的代理类

由其他文件生成，例如JSP文件生成对应的Class文件

从数据库中读取，该场景相对少见，例如：中间件服务器，可以将程序安装到数据库中完成程序代码在集群间的群发

从加密文件中获取，通过加载中进行解密Class文件

虚拟机内置的启动类加载器来完成

用户自定义的类加载去完成

数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存中动态构建出来的

类加载器类型

获得类加载器的方式

从ZIP包中读取（比如从jar包和war包中读取）

在运行时计算生成（动态代理）

由其它文件生成（比如将JSP文件转换成对应的Class类）

验证时连接阶段的第一步，这个阶段的目的时确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息不被当作代码运行后不会危害虚拟机自身安全。

验证会大致完成一下四个检验动作

确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全

目的：确保Class文件的字节流中包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

验证

默认值

static会分配内存

正式为类变量分配内存并设置初始值

准备阶段正式为类中定义的变量(类变量，即：静态变量。不包括实例变量)分配内存并设置类变量初始值的阶段

初始值：通常情况下，是数据类型的零值

例如：public static int value = 123;
在经过准备阶段时 value会被赋值为int的零值，即 0

当类字段的字段属性表中存在ConstantValue属性时(也就是被final标志的常量),在准备阶段，将会直接指定为所指定的初始值

准备阶段为类变量分配内存并设置初始值，使用的是方法区的内存

准备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即在方法区中分配这些变量所使用的内存空间。

注意这里所说的初始值概念，

解析

解析阶段是Java虚拟机常量池内的符号引用替换为直接引用的过程

把间接引用转换为直接引用

该阶段就是执行类构造器<clinit>()方法的过程
<clinit>()方法并不是由程序员在Java直接编写的代码

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{})中的语句合并产生的

编译器收集顺序是由语句在源文件中出现的顺序决定的

静态语句块中只能访问到静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问

Java虚拟机会保证在子类的<clinit>()方法执行前，父类的<clinit>()方法已经执行完毕。因此，在Java虚拟机中第一个被执行的类型一定是Object类

<clinit>()方法对于类或接口来说不是必需的，如果一个类没有静态语句块，也没有对变量进行赋值操作，那么编译器可以不为这个类生成<clinit>()方法。

接口也可以生成<clinit>()方法，但是于类有所不同

Java虚拟机必须保证一个类的<clinit>()方法在多线程环境下 被正确的加同步锁

遇到new、getstatic、putstatic、invokestatic这四条字节码指令时，如果没有初始化，则需要先触发其初始化阶段。

调用反射包的方法对类型进行反射调用的时候

当初始化类时，如果该类的父类没有经行初始化，则需要先触发父类的初始化

虚拟机启动时，虚拟机会先初始化要执行的主类，也就是含有main()方法的那个类

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

当接口中定义了JDK8新加入的默认方法(defult)时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化

执行&lt;cliinit&gt;()，初始化类变量、静态代码块

类加载子系统的处理过程

Java 的动态类加载功能，由类加载器子系统处理，处理过程包括加载、链接和初始化

加载

链接

初始化

启动（Bootstrap）类加载器的作用及代码验证【重点】
扩展（Extension）类加载器的作用及代码验证【重点】
系统（System Application）类加载器的作用及代码验证【重点】

加载（Loading）步骤的模块划分

步骤加载（loading）里边包含了三个更加细粒度的模块

这三个 Class Loader 就是加载过程中必须要使用到的三大类加载器。

链接（Linking）步骤更加详细的模块划分：验证，准备和解析【基础】
掌握在链接（Linking）步骤中的第一步：验证的详细验证内容【重点】
掌握在链接（Linking）步骤中的第二步：准备的准备内容【重点】
掌握在链接（Linking）步骤中的第三步：解析的具体解析内容【重点】
掌握初始化（Init）步骤中的规则以及实例初始化顺序【重点】

链接步骤，三个更加细粒度的模块

定义

目的

主要验证信息（三种类型的数据）

定义

不同类型的类变量的默认值是不同的

定义

符号引用

直接引用

解析过程具体的解析内容

【链接-准备】阶段，变量已经赋过一次系统要求的初始零值

【初始化】阶段，则会根据程序员通过程序编码制定的主观计划，去初始化类变量和其他资源。

类的【初始化】阶段是类加载过程的最后一个步骤

除了在【加载】阶段，用户应用程序可以通过自定义类加载器的方式局部参与外，其余动作都完全由JVM来主导控制。

直到【初始化】阶段，JVM才真正开始执行类中编写的 Java 程序代码，将主导权移交给应用程序。

在进行初始化时，实例变量的初始化顺序如下图所示：

实例变量的初始化顺序图示

线程上下文类加载器

重写ClassLoader类的loadClass()

JDBC

JNDI服务需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者的代码

resources.jar 会先通过自定义类加载器（前提是实现了自定义类加载器）

自定义类加载器不会做处理，直接向上委托给系统加载器

系统类加载器，接到委托后，也不做任何处理，直接向上委托给扩展类加载器；

扩展类加载器接到委托后，也不做任何处理

直接向上委托给启动类加载器

启动类加载器接到委托后，发现 resources.jar 是自己负责加载的核心类库

于是进行加载，最后成功加载了 resources.jar。

cldrdata.jar 会先通过自定义类加载器（前提是实现了自定义类加载器）

自定义类加载器不会做处理，直接向上委托给系统类加载器

系统类加载器接到委托后，也不做任何处理

直接向上委托给扩展类加载器

扩展类加载器接到委托后，也不做任何处理

直接向上委托给启动类加载器

启动类加载器接到委托后，发现 plugin.jar 不是自己负责加载的核心类库

于是进行向下委派，委派给扩展类加载器

扩展类加载器接到委派后，发现 plugin.jar 也不是自己负责加载的核心类库

于是进行向下委派，委派给系统类加载器

系统类加载器接到委派后，发现 plugin.jar 是自己负责加载的核心类库

于是进行加载，最后成功加载了 plugin.jar。

plugin.jar 会先通过自定义类加载器（前提是实现了自定义类加载器）

自定义类加载器不会做处理，直接向上委托给系统类加载器

系统类加载器接到委托后，也不做任何处理

直接向上委托给扩展类加载器

扩展类加载器接到委托后，也不做任何处理

直接向上委托给启动类加载器

启动类加载器接到委托后，发现 plugin.jar 不是自己负责加载的核心类库

于是进行向下委派，委派给扩展类加载器

扩展类加载器接到委派后，发现 plugin.jar 也不是自己负责加载的核心类库

于是进行向下委派，委派给系统类加载器；

系统类加载器接到委派后，发现 plugin.jar 是自己负责加载的核心类库

于是进行加载，最后成功加载了 plugin.jar。

绝大多数

少部分

通过编写一个 main 函数，打印出通过启动（Bootstrap）类加载器加载的所有的类库信息

以证实启动（Bootstrap）类加载器加载的是 %JAVA_HOME%/lib 下边的核心类库。

注意下 main 函数代码的第二行代码 URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs(); 

这是通过 sun 公司提供的 Launcher 包获取 Bootstrap 类加载器下 ClassPath 下的所有的 URL。

import java.net.URL;

public class LoaderDemo {
    public static void main(String[] args) {
        System.out.println("BootstrapClassLoader 的加载路径: ");
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for(URL url : urls)
            System.out.println(url);
     }
}

运行 main 函数。

此处运行结果所打印的类库的绝对路径为本人本机的安装路径，学习者应按照自己真实的JDK安装路径以及版本对号入座，此处仅为示例。

BootstrapClassLoader 的加载路径: 
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/resources.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/rt.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/sunrsasign.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/jsse.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/jce.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/charsets.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/jfr.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/classes

运行结果中的前 7 个类库（不同JDK版本会有差异，此处JDK 1.8），都是出自lib下的核心类库。

【了解】但是对于最后一条加载信息却不是 lib 下的类库。

启动类加载器

Bootstrap ClassLoader

【重点】%JAVA_HOME%/lib/ext中的类库

【了解】少数由系统变量 -Djava.ext.dir 指定位置中的类库

import java.net.URL;
import java.net.URLClassLoader;
public class LoaderDemo {
    public static void main(String[] args) {
        //取得扩展类加载器
        URLClassLoader extClassLoader = (URLClassLoader)ClassLoader.getSystemClassLoader().getParent();
        System.out.println(extClassLoader);
        System.out.println("扩展类加载器 的加载路径: ");
        URL[] urls = extClassLoader.getURLs();
        for(URL url : urls)
            System.out.println(url);
     }
}

运行 main 函数。

扩展类加载器 的加载路径: 
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/access-bridge-64.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/cldrdata.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/dnsns.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/jaccess.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/jfxrt.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/localedata.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/nashorn.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/sunec.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/sunjce_provider.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/sunmscapi.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/sunpkcs11.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/zipfs.jar

运行结果中所有的核心类库均来自 %JAVA_HOME%/lib/ext 的文件夹。

即当前类所在路径及其引用的第三方类库的路径

java -classpath或-Djava.class.path变量所指的目录

lib 下，未被（Bootstrap） 启动类加载器加载的类库

ext下，未被（Extension）扩展 类加载器加载的类库

其他类库

加载除了启动类加载器和扩展 类加载器所加载的其余的所有的核心类库。

import java.net.URL;
import java.net.URLClassLoader;
public class LoaderDemo {
    public static void main(String[] args) {
        //取得应用(系统)类加载器
        URLClassLoader appClassLoader = (URLClassLoader)ClassLoader.getSystemClassLoader();
        System.out.println(appClassLoader);
        System.out.println("应用(系统)类加载器 的加载路径: ");
        URL[] urls = appClassLoader.getURLs();
        for(URL url : urls)
            System.out.println(url);
     }
}

运行 main 函数。

应用(系统)类加载器 的加载路径: 
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/charsets.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/deploy.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/access-bridge-64.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/cldrdata.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/dnsns.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/jaccess.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/jfxrt.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/localedata.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/nashorn.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/sunec.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/sunjce_provider.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/sunmscapi.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/sunpkcs11.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/ext/zipfs.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/javaws.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/jce.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/jfr.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/jfxswt.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/jsse.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/management-agent.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/plugin.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/resources.jar
file:/D:/Programs/Java/jdk1.8.0_111/jre/lib/rt.jar
file:/E:/IdeaWorkspace/LeeCode/target/classes/
file:/D:/Programs/IntelliJ%20IDEA%20Educational%20Edition%202019.3.1/lib/idea_rt.jar

系统（System Application）类加载器加载的类库种类很多

除了之前两种类加载器加载的类库，其余必须的核心类库，都由系统类加载器加载。

 Class 文件的标准模样

软件本身提供的辅助信息

记录当前行前面总共有多少个 byte (或者说多少个 u1 )

用于快速定位数据，通过数据偏移量的方式。

直接以编辑器打开 Class 文件的样子

显示为乱码

次版本号为 u2 大小，用字节码表示为 00 00

主版本号也是 u2 大小，用字节码表示为 00 34。

这是一个 JVM 可识别的 Class 文件，且使用的 JDK 1.8.0的版本进行的编译

前4个字节魔数为 CA FE BA BE 符合标准

后4 个字节 00 00 00 34 为 JDK 1.8.0的版本。

记录常量池中的常量的数量。

由于常量池中的常数的数量是不固定的，所以在常量池的入口放置了一个 u2 类型的数据，来代表常量池容器记数值

常量池容器记数值（constant_pool_count）

常量池计数器也是无符号数类型数据。

无符号数结构示意图

Class 文件中的资源仓库

它是 Class 文件结构中与其他项目关联最多的数据类型

它是占用Class文件空间最多的数据项目之一

它还是 Class 文件中，第一个出现的表类型数据项目。

常量池表结构示意图

cp_info类型

常量池中主要存放着两种常量，字面量（Literal）和符号引用（Synbolic References）。

字面量（Literal）

符号引用

用于确定这个类的全限定名

用于确定这个类父类的全限定名

描述这个类实现了哪些接口

this_class

都是一个 u2 大小的数据。

确定当前类的全限定名。

super_class

都是一个 u2 大小的数据。

确定当前类的父类的全限定名。

由于 Java 单继承的原则，父类只可能有一个；

由于 Object 是所有其他类的基类，所以除了 Object 类没有父类以外，其余所有类的 super_class 都不为空。

类索引是紧跟在访问标志之后的结构，类索引后边紧跟的结构是父类索引。

由于类索引与父类索引关系非常紧密，都是描述的当前类以及当前类的父类的全限定名，所以此处我们将二者放在一起进行讲解。

类索引+父类索引 的 无符号数结构示意图

代表了接口索引集合中接口的数量

类似于常量池计数器和常量池的关系，接口索引计数器记录的是接口索引集合中接口索引的数量。

按照当前类 implements（或当前接口extends）的接口的顺序，从左到右依次排列在接口索引集合中

此部分集合称为接口索引集合。

对于常量池计数器和常量池，一个是无符号数类型，一个是表类型。

相比而言，接口索引计数器和接口索引集合，皆为无符号数类型

接口索引计数器和接口索引集合均为无符号数类型结构

从图中可以看出，接口索引计数器占用了 2 个字节，为 u2 大小，接口索引集合中的每一个接口元素占用了 2 个字节大小，也为 u2 大小。

字段表、方法表与属性表

字段表计数器和字段表

方法表计数器和方法表

属性表计数器与属性表

因为每一种表结构，都需要有计数器进行计数。

与其他计数器一样，字段表计数器（fields_count）是一个无符号数结构类型的数据，u2 大小。

字段表计数器无符号数结构示意图

字段表的表结构示意图

上图所示的一个 field_info 就代表了一个变量。

为了表示一个变量，需要知道这个变量的修饰符，如 public

还需要知道这个变量的变量名称，因此一个 field_info 中存储了很多特征值，所有的特征值综合起来就完整的描述了一个变量。

方法表是一个表结构的类型数据，与前文所讲解的字段表结构一样。

存储了当前类或者当前接口中的 public 方法，protected 方法，default 方法，private 方法等。

方法表为表结构类型。

Class文件是通过Java文件编译而来的，如果文件中有方法，就会将方法的信息存储到方法表，并通过方法表计数器进行方法的计数。

方法表-表结构类型示意图

方法表是一个表结构的类型数据

一个method_info中会存储很多方法的特征值

通过如下示例方法进行举例：

对于get 方法，method_info 中会存储如下信息：

methods_count

与方法表不可分割

记录方法表中字段的数量，为无符号数类型。

方法表计数器无符号数结构示意图

（attributes_count）

属性表计数器与属性表不可分割

记录属性表中属性的数量，为无符号数类型。

与其他计数器一样，属性表计数器（attributes_count）是一个无符号数结构类型的数据，u2 大小。

属性表计数器无符号数结构示意图

（attributes）

属性表与 Class 文件中其他的数据项目要求严格的顺序、长度和内容不同

属性表集合的限制稍微宽松一些，不再要求各个属性表具有严格的顺序，并且只要不与已有属性名重复

任何人实现的编译器都可以向属性表中写入自己定义的属性信息，Java 虚拟机运行时会忽略掉它不能识别的属性。

属性表作为 Class 文件的一个结构，是非常灵活的，且没有明确的长度大小规定。

属性表也是一个表结构类型，与字段表、方法表结构类似，但是属性表没有固定的长度和顺序限制

子主题

数字

索引引用

数量值

按照UTF-8编码构成的字符串值

CAFEBABE

四个字节

存放着常量池中常量的个数

从1开始默认保留下标为0的空位置

字面量

符号引用

Java堆是否规整由所采用的垃圾收集器是否带有压缩整理功能决定。

1.查看常量池中是否有这相同字符串的变量

2.如果有则将该对象的引用放回，如果没有则在常量池中创建该对象后再返回该引用(注意此时，会有两个对象，一在堆中，一个在常量池中)

1.查看常量池中是否有这相同字符串的变量

2.如果有则返回对象该引用，如果没有则将堆中的对象引用保存在字符串常量池中(此时只有一个对象，常量池中引用的是堆中的对象)

stop-the-world 垃圾回收、

线程栈 dump

线程暂停、

线程偏向锁（biased locking）解除。

将内部类定义为static

用static的变量引用匿名内部类的实例

或将匿名内部类的实例化操作放到外部类的静态方法中