深入浅出java虚拟机-笔记-改良版

第一章 走近Java

1. Java技术体系
   java程序设计语言、各种硬件平台上的Java虚拟机、Class文件格式、Java API类库、来自商业机构和开源社区的第三方Java类库

​ JDK（Java Development Kit）：Java程序设计语言、Java虚拟机、Java API类库
​ JRE（Java Runtime Environment）：Java SE API子集、Java虚拟机
​ JVM（Java Virture Machine）：Java虚拟机

2. Java平台
   按照技术所服务的领域，可以分为4个平台：

​ Java Card：支持一些Java小程序运行在小内存设备上的平台。
​ Java ME（Micro Edition）：支持Java程序运行在移动终端上的平台
​ Java SE（Standard Edition）：支持面向桌面级应用的Java平台
​ Java EE（Enterprise Edition）：支持使用多层架构的企业应用的Java平台

第二章 Java内存区域与内存溢出异常

1. 运行时数据区域

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间。Java虚拟机所管理的内存将会包括以下几个运行时数据区域：

• 程序计数器（Program CounterRegister）：是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
• Java虚拟机栈（Java Virtual Machine Stacks）：是线程私有的，它的生命周期与线程相同。
• 本地方法栈（Native Method Stack）：与虚拟机栈所发挥的作用是非常相似的，它们之间的区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。
• Java堆（Java Heap）：是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。
• 方法区（Method Area）：与方法堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。也被人称为“永久代”。
• 运行时常量池（Runtime Constant Pool）：是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。
• 直接内存（Direct Memory）：并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用。

2.对象的创建

虚拟机中，创建对象的步骤如下所示：

1. 虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

2. 在类加载检查通过后，接下来虚拟机将为新生对象分配内存。为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。内存分配根据Java堆中的内存摆放，分为两种：

   • 指针碰撞（Bump the Pointer）：如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。

   • 空闲列表（Free List）：如果Java堆中内存并不是规整的，已使用的内存和空闲的内存相互交错，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。

     除此之外，还要保证对象创建在虚拟机中是线程安全的（并发情况下）。解决这个问题有两种方案：

     • 对分配内存空间的动作进行同步处理——实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性

     • 把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB）。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。虚拟机是否使用TLAB，可以通过 -XX:+/-UseTLAB参数来设定。

3. 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。

4. 接下来，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在**对象的对象头（Object Header）**之中。

5. 一般来说（由字节码中是否跟随invokespecial指令所决定），执行new指令之后会接着执行方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

   

3.对象的内存布局

在HotSpot虚拟机中，对象在内存中存储的布局可用分为3块区域：

对象头（Header）、实例数据（Instance Data）和对齐填充（Padding），如下所示：

• 对象头：包括两部分信息
  • 第一部分信息用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。
  • 第二部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
  • 另外，如果对象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中却无法确定数组的大小。
• 实例数据：是对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容。
• 对齐填充：不是必然存在的，也没有特别的含义，仅仅起到占位符的作用。

4.对象的访问定位

建立对象是为了使用对象，Java程序需要通过栈上的reference数据来操作堆上的具体对象，目前主流的访问方式有使用句柄和直接指针两种，如下所示：

• 句柄访问：Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息。好处是reference中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而reference本身不需要修改。

• 直接指针访问：Java堆对象的布局中必须考虑如何放置访问类型数据的相关信息，而reference中存储的直接就是对象地址。好处是速度更快，节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。HotSpot就是使用第二种方式进行对象访问。

5.OutOfMemoryError异常

在Java虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError异常的可能，如下所示：

• Java堆溢出：Java堆用于存储对象实例，只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。
• 虚拟机栈和本地方法栈溢出：在Java虚拟机规范中，描述了两种异常：
  • 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。
  • 如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
• 方法区和运行时常量池溢出：运行时产生大量的类去填满方法区，就会溢出。
• 本机直接内存溢出：若向操作系统中申请分配过多内存，就会溢出。

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

1.判断对象是否存在

垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象）：

• 引用计数算法（Reference Counting）：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1，；任何时刻计数器为0的对象就是不可能再被使用的。主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。
• 可达性分析算法（Reachability Analysis）：通过一系列的称谓“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。

2.引用的类型

Java对引用的概念进行了扩充，如下所示：

• 强引用（Strong Reference）：就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用（Soft Reference）：用来描述一些还有用但并非必需的对象
• 弱引用（Weak Reference）：用来描述非必需的对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。
• 虚引用（Phantom Reference）：称为幽灵引用或者幻影引用，是最弱的一种引用关系。

3.无用的类

类需要同时满足下面3个条件才能算是“无用的类”，如下所示：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

4.垃圾收集算法

• 标记-清除算法（Mark-Sweep）：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。主要不足是效率问题和空间问题。

• 复制算法（Copying）：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。主要不足是将内存缩小为原来的一半，代价太高了些。

• 标记-整理算法（Mark-Compact）：标记过程与标记-清除算法相同，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

• 分代收集算法（Generational Collection）：根据对象存活周期的不同将内存划分为几块。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5oRXCt3u-1667799912750)(https://cdn.jsdelivr.net/gh/hututu-tech/IMG-gongfeng@main/2022/03/20/6236d31896d59.jpeg)]

  大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入s0或者s1，并且对象的年龄还会加1（Eden区->Survivor区后对象的初始年龄变为1），当它的年龄增加到一定程度（默认为15岁），就会被晋升到老年代中。

  大对象直接进入老年代

  大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。

5.HotSpot的算法实现

• 枚举根节点：可作为GC Roots的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中。
• 安全点：HotSpot也的确没有为每条指令都生成OopMap，只有在“特定的位置”记录了这些信息，这些位置称为安全点（SafePoint）。
• 安全区域：在一段代码片段中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。

6.垃圾收集器

收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

垃圾收集器根据作用域，分为新生代和老年代：

• 新生代（Young generation）：
  • Serial收集器：这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。
  • ParNew收集器：ParNew收集器其实就是Serial收集器的多线程版本。
  • Parallel Scavenge收集器：这是一个使用复制算法的收集器，也是并行的多线程收集器。这个收集器的目标是达到一个可控制的吞吐量（Throughput），也被称为“吞吐量优先”收集器。
• 老年代（Tenured generation）：
  • Serial Old收集器：这个收集器是Serial收集器的老年代版本，同样是一个单线程收集器，使用“标记-整理”算法，这个收集器的主要意义也是在于给Client模式下的虚拟机使用。
  • Parallel Old收集器：Parallel Old收集器其实就是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。
  • CMS收集器：这是一种以获取最短回收停顿时间为目标的收集器，基于“标记-清除”算法实现。

除了上面这6个收集器之外，还存在有一个同时支持新生代和老年代的收集器：

G1收集器：是一款面向服务端应用的垃圾收集器。具有如下特点：

• 并行与并发
• 分代收集
• 空间整合
• 可预测的停顿

7.内存分配与回收策略

大多数情况下，虚拟机中存在如下的内存分配策略：

• 对象优先在Eden分配：大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
• 大对象直接进入老年代：大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。
• 长期存活的对象将进入老年代：虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代。虚拟机给每个对象定义了一个对象年龄（Age）计数器，如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survior容纳的话，将被移动到Survivor控件中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度时，就将会被晋升到老年代中。
• 动态对象年龄判定：如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或者等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
• 空间分配担保：在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。

第四章 虚拟机性能监控与故障处理工具

1.Sun JDK监控和故障处理工具

当应用程序部署到生产环境后，无论是直接接触物理服务器还是远程Telnet到服务器上都可能会受到限制。借助tools.jar类库里面的接口，我们可以直接在应用程序中实现功能强大的监控分析功能。工具如下：

• jps（虚拟机进程状况工具）：可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class,main()函数所在的类）名称以及这些进程的本地虚拟机唯一ID（Local Virtual Machine Identifier，LVMID）。
• jstat（虚拟机统计信息监视工具）：用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。
• jinfo（Java配置信息工具）：是实时地查看和调整虚拟机各项参数。
• jmap（Java内存映像工具）：用于生成堆转储快照（一般称为heapdump或dump文件）。
• jhat（虚拟机堆转储快照分析工具）：与jmap搭配使用，来分析jmap生成的堆转储快照。
• jstack（Java堆栈跟踪工具）：用于生成虚拟机当前时刻的线程快照（一般称为threaddump或者javacore文件）。
• HSDIS（JIT生成代码反汇编）：是官方推荐的HotSpot虚拟机JIT编译代码的反汇编插件，它包含在HotSpot虚拟机的源码之中，但没有提供编译后的程序。

2.JDK的可视化工具

JDK中除了提供大量的命令行工具外，还有两个功能强大的可视化工具：JConsole和VisualVM，如下所示：

• JConsole（Java监视与管理控制台）：是一种基于JMX的可视化监视、管理工具。
• VisualVM（多合一故障处理工具）：是到目前为止随JDK发布的功能最强大的运行监视和故障处理程序，并且可以预见在未来一段时间内都是官方主力发展的虚拟机故障处理工具。

第五章 调优案例分析与实战

1.调优案例

考虑到虚拟机故障处理和调优主要面向各类服务端应用，而大部分Java程序员较少有机会直接接触生产环境的服务器。一些调优案例如下（详细情况参照书籍）：

• 高性能硬件上的程序部署策略
• 集群间同步导致的内存溢出
• 堆外内存导致的溢出错误
• 外部命令导致系统缓慢
• 服务器JVM进程崩溃
• 不恰当数据结构导致内存占用过大
• 由Windows虚拟内存导致的长时间停顿

2.Eclipse运行速度调优

系统调优的工作都是针对服务端应用而言，规模越大的系统，就越需要专业的调优运维团队参与，步骤如下所示：

• 调优前的程序运行状态
• 升级JDK 1.6的性能变化及兼容问题
• 编译时间和类加载时间的优化
• 调整内存设置控制垃圾收集频率
• 选择收集器降低延迟

第六章 类文件结构

Class类文件结构

• Class文件是一组以8字节为基础单位的二进制流
• 各个数据项目严格按照顺序紧凑排列在class文件中
• 中间没有任何分隔符，这使得class文件中存储的内容几乎是全部程序运行的程序。

Java虚拟机规范规定，Class文件格式采用类似C语言结构体的伪结构来存储数据，这种结构只有两种数据类型：无符号数和表。
无符号数
属于基本数据类型，主要可以用来描述数字、索引符号、数量值或者按照UTF-8编码构成的字符串值，大小使用u1、u2、u4、u8分别表示1字节、2字节、4字节和8字节。
表
是由多个无符号数或者其他表作为数据项构成的复合数据类型，所有的表都习惯以“_info”结尾。表主要用于描述有层次关系的复合结构的数据，比如方法、字段。需要注意的是class文件是没有分隔符的，所以每个的二进制数据类型都是严格定义的。具体的顺序定义如下：

在class文件中，主要分为魔数、Class文件的版本号、常量池、访问标志、类索引（还包括父类索引和接口索引集合）、字段表集合、方法表集合、属性表集合。

魔数

1. 每个Class文件的头4个字节称为魔数（Magic Number）
2. 唯一作用是用于确定这个文件是否为一个能被虚拟机接受的Class文件。
3. Class文件魔数的值为0xCAFEBABE。如果一个文件不是以0xCAFEBABE开头，那它就肯定不是Java class文件。

很多文件存储标准中都使用魔数来进行身份识别，譬如图片格式，如gif或jpeg等在文件头中都存有魔数。使用魔术而不是使用扩展名是基于安全性考虑的——扩展名可以随意被改变!!!

Class文件的版本号
紧接着魔数的4个字节是Class文件版本号，版本号又分为：

1. 次版本号(minor_version): 前2字节用于表示次版本号
2. 主版本号(major_version): 后2字节用于表示主版本号。
   这个的版本号是随着jdk版本的不同而表示不同的版本范围的。Java的版本号是从45开始的。如果Class文件的版本号超过虚拟机版本，将被拒绝执行。
   0X0034（对应十进制的50）：JDK1.8
   0X0033（对应十进制的50）：JDK1.7
   0X0032（对应十进制的50）：JDK1.6
   0X0031（对应十进制的49）：JDK1.5　　
   0X0030（对应十进制的48）：JDK1.4　　
   0X002F（对应十进制的47）：JDK1.3　　
   0X002E（对应十进制的46）：JDK1.2
   ps：0X表示16进制

常量池
紧接着魔数与版本号之后的是常量池入口.常量池简单理解为class文件的资源从库

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

2. 是占用Class文件空间最大的数据项目之一

3. 是在文件中第一个出现的表类型数据项目

从1开始计数。Class文件结构中只有常量池的容量计数是从1开始的，第0项腾出来满足后面某些指向常量池的索引值的数据在特定情况下需要表达"不引用任何一个常量池项目"的意思，这种情况就可以把索引值置为0来表示(留给JVM自己用的)。但尽管constant_pool列表中没有索引值为0的入口，缺失的这一入口也被constant_pool_count计数在内。例如，当constant_pool中有14项，constant_poo_count的值为15。

常量池之中主要存放两大类常量：

• 字面量: 比较接近于Java语言层面的常量概念，如文本字符串、被声明为final的常量值等
• 符号引用: 属于编译原理方面的概念，包括了下面三类常量:
  • 类和接口的全限定名
  • 字段的名称和描述符
  • 方法的名称和描述符

Java代码在进行Java编译的时候，并不像C和C++那样有"连接"这一步骤，而是在虚拟机加载Class文件的时候进行动态连接。也就是说，在Class文件中不会保存各个方法和字段的最终内存布局信息，因此这些字段和方法的符号引用不经过转换的话是无法被虚拟机使用的。当虚拟机运行时，需要从常量池获得对应的符号引用，再在类创建时或运行时解析并翻译到具体的内存地址之中。

constant_pool_count：占2字节，本例为0x0016，转化为十进制为22，即说明常量池中有21个常量（只有常量池的计数是从1开始的，其它集合类型均从0开始），索引值为1~21。第0项常量具有特殊意义，如果某些指向常量池索引值的数据在特定情况下需要表达“不引用任何一个常量池项目”的含义，这种情况可以将索引值置为0来表示

constant_pool：表类型数据集合，即常量池中每一项常量都是一个表，共有14种(JDK1.7前只有11种)结构各不相同的表结构数据。这14种表都有一个共同的特点，即均由一个u1类型的标志位开始，可以通过这个标志位来判断这个常量属于哪种常量类型，常量类型及其数据结构如下表所示：

譬如utf-8类型的表结构数据

譬如fieldref类型的表结构数据

譬如class类型的表结构数据

譬如nameandtype类型的表结构数据

ps：什么是描述符？
成员变量(包括静态成员变量和实例变量) 和方法都有各自的描述符。
对于字段而言，描述符用于描述字段的数据类型；
对于方法而言，描述符用于描述字段的数据类型、参数列表、返回值。
在描述符中，基本数据类型用大写字母表示，对象类型用“L对象类型的全限定名”表示，数组用“[数组类型的全限定名”表示。
描述方法时，将参数根据上述规则放在()中，()右侧按照上述方法放置返回值。而且参数之间无需任何符号。

访问标志（2字节）
常量池之后的数据结构是访问标志(access_flags)，这个标志主要用于识别一些类或接口层次的访问信息，主要包括：

• 是否final
• 是否public，否则是private
• 是否是接口
• 是否可用invokespecial字
• 节码指令
• 是否是abstact
• 是否是注解
• 是否是枚举

access_flags一共有16个标志位可以使用，当前只定义了其中8个（JDK1.5增加后面3种），没有使用到标志位一律为0。

类索引、父类索引和接口索引集合
这三项数据主要用于确定这个类的继承关系。

其中类索引(this_class)和父类索引(super_class)都是一个u2类型的数据，而接口索引(interface)集合是一组u2类型的数据。(多实现单继承)

• 类索引(this_class)，用于确定这个类的全限定名，占2字节
• 父类索引(super_class)，用于确定这个类父类的全限定名（Java语言不允许多重继承，故父类索引只有一个。除了java.lang.Object类之外所有类都有父类，故除了java.lang.Object类之外，所有类该字段值都不为0），占2字节
• 接口索引计数器(interfaces_count)，占2字节。如果该类没有实现任何接口，则该计数器值为0，并且后面的接口的索引集合将不占用任何字节，
• 接口索引集合(interfaces)，一组u2类型数据的集合。用来描述这个类实现了哪些接口，这些被实现的接口将按implements语句（如果该类本身为接口，则为extends语句）后的接口顺序从左至右排列在接口的索引集合中

this_class、super_class与interfaces按顺序排列在访问标志之后，它们中保存的索引值均指向常量池中一个CONSTANT_Class_info类型的常量，通过这个常量中保存的索引值可以找到定义在CONSTANT_Utf8_info类型的常量中的全限定名字符串

字段表集合

• fields_count：字段表计数器，即字段表集合中的字段表数据个数，占2字节。本测试类其值为0x0001，即只有一个字段表数据，也就是测试类中只包含一个变量（不算方法内部变量）
• fields：字段表集合，一组字段表类型数据的集合。字段表用于描述接口或类中声明的变量，包括类级别（static）和实例级别变量，不包括在方法内部声明的变量
  在Java中一般通过如下几项描述一个字段：字段作用域（public、protected、private修饰符）、是类级别变量还是实例级别变量（static修饰符）、可变性（final修饰符）、并发可见性（volatile修饰符）、可序列化与否（transient修饰符）、字段数据类型（基本类型、对象、数组）以及字段名称。在字段表中，变量修饰符使用标志位表示，字段数据类型和字段名称则引用常量池中常量表示。

字段表包含的固定数据项到descriptor_index结束，之后跟随一个属性表集合用于存储一些附加信息。
字段表集合中不会列出从父类或父接口中继承的字段，但是可能列出原本Java代码之中不存在的字段，如：内部类为了保持对外部类的访问性，自动添加指向外部类实例的字段。Java语言中字段是不能重载的，2个字段无论数据类型、修饰符是否相同，都不能使用相同的名称；但是对于字节码，只要字段描述符不同，字段重名就是合法的。

方法表集合
methods_count：方法表计数器，即方法表集合中的方法表数据个数。占2字节，其值为0x0002，即测试类中有2个方法
methods：方法表集合，一组方法表类型数据的集合。方法表结构和字段表结构一样。
2个字节为属性计数器，其值为0x0001，说明这个方法的属性表集合中有一个属性（详细说明见后面“属性表集合”）
属性名称为接下来2个字节0x0009，指向常量池中第9个常量，Code。
接下来4个字节为0x0000002F，表示Code属性值的字节长度为47。
接下来2个字节为0x0001，表示该方法的操作数栈的深度最大值为1。
接下来2个字节依然为0x0001，表示该方法的局部变量占用空间为1。
接下来4个字节为0x00000005，则紧接着的5个字节0x2AB70001B1为该方法编译后生成的字节码指令。
接下来2个字节为0x0000，说明Code属性异常表集合为空。
接下来2个字节为0x0002，说明Code属性带有2个属性，
接下来2个字节0x000A即为Code属性第一个属性的属性名称，指向常量池中第10个常量：LineNumberTable。
接下来4个字节为0x00000006，表示LineNumberTable属性值所占字节长度为6。
接下来2个字节为0x0001，line_number_table中只有一个line_number_info表，start_pc为0x0000，line_number为0x0003，LineNumberTable属性结束。
接下来2位0x000B为Code属性第二个属性的属性名，指向常量池中第11个常量：LocalVariableTable。该属性值所占的字节长度为0x0000000C=12。
接下来2位为0x0001，说明local_variable_table中只有一个local_variable_info表，按照local_variable_info表结构，start_pc为0x0000，length为0x0005，name_index为0x000C，指向常量池中第12个常量：this，descriptor_index为0x000D，指向常量池中第13个常量：LTestClass;，index为0x0000。

ps：
如果子类没有重写父类的方法，方法表集合中就不会出现父类方法的信息；有可能会出现由编译器自动添加的方法（如：最典型的，实例类构造器）在Java语言中，重载一个方法除了要求和原方法拥有相同的简单名称外，还要求必须拥有一个与原方法不同的特征签名（由于特征签名不包含返回值，故Java语言中不能仅仅依靠返回值的不同对一个已有的方法重载；但是在Class文件格式中，特征签名即为方法描述符，只要是描述符不完全相同的2个方法也可以合法共存，即2个除了返回值不同之外完全相同的方法在Class文件中也可以合法共存。
注意：Java代码的方法特征签名只包括方法名称、参数顺序、参数类型。 而字节码的特征签名还包括方法返回值和受异常表。

属性表集合
起始2个字节为0x0001，说明有一个类属性。
接下来2个字节为属性的名称，0x0010，指向常量池中第16个常量：SourceFile。
接下来4个字节为0x00000002，说明属性体长度为2字节。
最后2个字节为0x0011，指向常量池中第27个常量：TestClass.java，即这个Class文件的源码文件名为TestClass.java
与Class文件中其它数据项对长度、顺序、格式的严格要求不同，属性表集合不要求其中包含的属性表具有严格的顺序，并且只要属性的名称不与已有的属性名称重复，任何人实现的编译器可以向属性表中写入自己定义的属性信息。虚拟机在运行时会忽略不能识别的属性，为了能正确解析Class文件，虚拟机规范中预定义了虚拟机实现必须能够识别的9项属性（预定义属性已经增加到21项）：

ps：在调试是可以通过SourceFile来关联相关的类。

大总结的PS：
1，全限定名：将类全名中的“.”替换为“/”，为了保证多个连续的全限定名之间不产生混淆，在最后加上“;”表示全限定名结束。例如：“com.test.Test"类的全限定名为"com/test/Test;”
2，简单名称：没有类型和参数修饰的方法或字段名称。例如："public void add(int a,int b){…}“该方法的简单名称为"add”，“int a = 123;“该字段的简单名称为"a”
3，描述符：描述字段的数据类型、方法的参数列表（包括数量、类型和顺序）和返回值。根据描述符规则，基本数据类型和代表无返回值的void类型都用一个大写字符表示，而对象类型则用字符L加对象全限定名表示

对于数组类型，每一维将使用一个前置的“[”字符来描述，如：“int[]“将被记录为”[I”,“String[][]“将被记录为”[[Ljava/lang/String;”
用描述符描述方法时，按照先参数列表，后返回值的顺序描述，参数列表按照参数的严格顺序放在一组”()“之内，如：方法"String getAll(int id,String name)“的描述符为”(I,Ljava/lang/String;)Ljava/lang/String;”
4，Slot，虚拟机为局部变量分配内存所使用的最小单位，长度不超过32位的数据类型占用1个Slot，64位的数据类型（long和double）占用2个Slot

第七章 虚拟机类加载机制

1.类加载过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。

其中准备、验证、解析3个部分统称为连接（Linking）。
加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：

它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。

每个阶段的详解如下：

加载
在加载阶段（可以参考java.lang.ClassLoader的loadClass()方法），虚拟机需要完成以下3件事情：

1. 通过一个类的全限定名来获取定义此类的二进制字节流（并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等）；
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；

加载阶段和连接阶段（Linking）的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
验证阶段大致会完成4个阶段的检验动作：

1. 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以魔术0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
2. 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
3. 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
   符号引用验证：确保解析动作能正确执行。
4. 验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：

public static int value=123;

那变量value在准备阶段过后的初始值为0而不是123.因为这时候尚未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。
至于“特殊情况”是指：

public static final int value=123;    //final类型的会在准备阶段进行初始值赋值，因为后续不会被改变

，即当类字段的字段属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标注为final之后，value的值在准备阶段初始化为123而非0。

解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

初始化
类初始化阶段是类加载过程的最后一步，到了初始化阶段，才真正开始执行类中定义的java程序代码。在准备极端，变量已经付过一次系统要求的初始值，而在初始化阶段，则根据程序猿通过程序制定的主管计划去初始化类变量和其他资源，或者说：初始化阶段是执行类构造器()方法的过程.
()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块static{}中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。如下：

public class Test
{   
	static{        
        i=0;        
        System.out.println(i);//这句编译器会报错：Cannot reference a field before it is defined（非法向前应用）    
    }    
	static int i=1;
}

()方法与实例构造器()方法不同，它不需要显示地调用父类构造器，虚拟机会保证在子类()方法执行之前，父类的()方法方法已经执行完毕，回到本文开篇的举例代码中，结果会打印输出：SSClass就是这个道理。
由于父类的()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。

class Parent {
    public static int A = 1;

    static {
        A = 2;
    }
}

class Sub extends Parent {
    public static int B = A;

    public static void main(String[] args) {
        System.out.println(Sub.B);
    }
}

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

接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成()方法。但接口与类不同的是，执行接口的()方法不需要先执行父接口的()方法。

只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的()方法。

**虚拟机会保证一个类的()方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行()方法完毕。**如果在一个类的()方法中有耗时很长的操作，就可能造成多个线程阻塞，在实际应用中这种阻塞往往是隐藏的。

2.类加载器

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

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

public class ClassLoaderTest {
    public static void main(String[] args) throws Exception {
        ClassLoader myLoader = new ClassLoader() {
            @Override
            public Class<?> loadClass(String name) throws ClassNotFoundException {//自定义类加载器
                try {
                    String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
                    InputStream is = getClass().getResourceAsStream(fileName);
                    if (is == null) {
                        return super.loadClass(name);
                    }
                    byte[] b = new byte[is.available()];
                    is.read(b);
                    return defineClass(name, b, 0, b.length);
                } catch (IOException e) {
                    throw new ClassNotFoundException(name);
                }
            }
        };
        Object obj = myLoader.loadClass("chatper_2.ClassLoaderTest").newInstance();
        System.out.println(obj.getClass());
        System.out.println(obj instanceof chatper_2.ClassLoaderTest);//返回的是一个false，因为和系统本身的
    }
}

2.1 双亲委派模型

站在Java虚拟机的角度来看，只存在两种不同的类加载器：

• 启动类加载器（BootstrapClassLoader），这个类加载器使用C++语言实现 [1] ，是虚拟机自身的一部分；
• 其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader.

1. 启动类加载器（Bootstrap Class Loader）：前面已经介绍过，这个类加载器负责加载存放在\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。
2. 扩展类加载器（Extension Class Loader）:开发者可以直接在程序中使用扩展类加载器来加载Class文件。
3. 应用程序类加载器（Application Class Loader）:它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

各种类加载器之间的层次关系被称为类加载器的**“双亲委派模型（Parents DelegationModel）”**。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

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

3.java模块化系统

模块化的关键目标——可配置的封装隔离机制

JDK 9的模块不仅仅像之前的JAR包那样只是简单地充当代码的容器，除了代码外，Java的模块定义还包含以下内容：

• 依赖其他模块的列表。
• 导出的包列表，即其他模块可以使用的列表。
• 开放的包列表，即其他模块可反射访问模块的列表。
• 使用的服务列表。
• 提供服务的实现列表。

1. 显式声明依赖的模块类型，在启动时就验证这些以来是否能够支撑正常运行。如果没有模块化，系统在运行时进行类加载的时候去寻找依赖资源时才会报错。因此模块化避免了很大一部分由于类型依赖而引发的运行时异常。
2. 解决了原来类路径上跨JAR文件的public类型的可访问性问题。JDK 9中的public类型不再意味着程序的所有地方的代码都可以随意访问到它们，模块提供了更精细的可访问性控制，必须明确声明其中哪一些public的类型可以被其他哪一些模块访问，这种访问控制也主要是在类加载过程中完成的。

依赖规则：

• JAR文件在类路径的访问规则：所有类路径下的JAR文件及其他资源文件，都被视为**自动打包在一个匿名模块（Unnamed Module）**里，这个匿名模块几乎是没有任何隔离的，它可以看到和使用类路径上所有的包、JDK系统模块中所有的导出包，以及模块路径上所有模块中导出的包。
• 模块在模块路径的访问规则：具名模块看不见传统JAR包的内容。
• JAR文件在模块路径的访问规则：如果把一个传统的、不包含模块定义的JAR文件放置到模块路径中，它就会变成一个自动模块（Automatic Module）。尽管不包含module-info.class，但自动模块将默认依赖于整个模块路径中的所有模块，因此可以访问到所有模块导出的包，自动模块也默认导出自己所有的包。

JDK 9中虽然仍然维持着三层类加载器和双亲委派的架构，但类加载的委派关系也发生了变动。当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载，也许这可以算是对双亲委派的第四次破坏。

第八章 虚拟机字节码执行引擎

代码编译的结果从本地机器码转变为字节码，是存储格式发展的一小步，却是编程语言发展的一大步。

执行引擎是Java虚拟机核心的组成部分之一。

所有的Java虚拟机的执行引擎输入、输出都是一致的：输入的是字节码二进制流，处理过程是字节码解析执行的等效过程，输出的是执行结果

8.1 运行时栈帧结构

Java虚拟机以方法作为最基本的执行单元，“栈帧”（Stack Frame）则是用于支持虚拟机进行方法调用和方法执行背后的数据结构，它也是虚拟机运行时数据区中的虚拟机栈（Virtual MachineStack） [1] 的栈元素。

每一个栈帧都包括了局部变量表、操作数栈、动态连接、方法返回地址和一些额外的附加信息。在编译Java程序源码的时候，栈帧中需要多大的局部变量表，需要多深的操作数栈就已经被分析计算出来，并且写入到方法表的Code属性之中。换言之，一个栈帧需要分配多少内存，并不会受到程序运行期变量数据的影响，而仅仅取决于程序源码和具体的虚拟机实现的栈内存布局形式。

一个线程中方法调用可能很长，很多方法都处于执行状态。对于执行引擎来说，只有处于栈顶的栈帧才是有效的，称为当前栈帧（Current Stack Frame），与之相关联的方法称为当前方法（Current Method）。

在概念模型上，典型的栈帧主要由

• 局部变量表（Local Stack Frame）
• 操作数栈（Operand Stack）
• 动态链接（Dynamic Linking）
• 返回地址（Return Address）组成，如下图所示：

接下来我们分别讲解栈帧中这四部分的具体结构。

1、局部变量表

局部标量表 是一组变量值的存储空间，用于存放 方法参数 和 局部变量。在Class 文件的方法表的 Code 属性的 max_locals 指定了该方法所需局部变量表的最大容量。

**变量槽 （Variable Slot）**是局部变量表的最小单位，没有强制规定大小为 32 位，虽然32位足够存放大部分类型的数据。一个 Slot 可以存放boolean、byte、char、short、int、float、reference 和 returnAddress 8种类型。其中 reference 表示对一个对象实例的引用，通过它可以得到对象在Java 堆中存放的起始地址的索引和该数据所属数据类型在方法区的类型信息。returnAddress 则指向了一条字节码指令的地址。 对于64位的 long 和 double 变量而言，虚拟机会为其分配两个连续的 Slot 空间。

虚拟机通过索引定位的方式使用局部变量表。之前我们知道，局部变量表存放的是方法参数和局部变量。当调用方法是非static 方法时，局部变量表中第0位索引的 Slot 默认是用于传递方法所属对象实例的引用，即 “this” 关键字指向的对象。分配完方法参数后，便会依次分配方法内部定义的局部变量。

为了节省栈帧空间，局部变量表中的 Slot 是可以重用的。当离开了某些变量的作用域之后，这些变量对应的 Slot 就可以交给其他变量使用。这种机制有时候会影响垃圾回收行为。

2、操作数栈

操作数栈（Operand Stack）也常称为操作栈，是一个后入先出栈。在Class 文件的Code 属性的 max_stacks 指定了执行过程中最大的栈深度。Java 虚拟机的解释执行引擎称为”基于栈的执行引擎“，这里的栈就是指操作数栈。

方法执行中进行算术运算或者是调用其他的方法进行参数传递的时候是通过操作数栈进行的。

在概念模型中，两个栈帧是相互独立的。但是大多数虚拟机的实现都会进行优化，令两个栈帧出现一部分重叠。令下面的部分操作数栈与上面的局部变量表重叠在一块，这样在方法调用的时候可以共用一部分数据，无需进行额外的参数复制传递。

3、动态连接

每个栈帧都包含一个执行运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接（Dynamic Linking）。

Class 文件中存放了大量的符号引用，字节码中的方法调用指令就是以常量池中指向方法的符号引用作为参数。这些符号引用一部分会在类加载阶段或第一次使用时转化为直接引用，这种转化称为静态解析。另一部分将在每一次运行期间转化为直接引用，这部分称为动态连接。

4、方法返回地址

当一个方法开始执行以后，只有两种方法可以退出当前方法：

• 当执行遇到返回指令，会将返回值传递给上层的方法调用者，这种退出的方式称为正常完成出口（Normal Method Invocation Completion），一般来说，调用者的PC计数器可以作为返回地址。
• 当执行遇到异常，并且当前方法体内没有得到处理，就会导致方法退出，此时是没有返回值的，称为异常完成出口（Abrupt Method Invocation Completion），返回地址要通过异常处理器表来确定。

当方法返回时，可能进行3个操作：

1. 恢复上层方法的局部变量表和操作数栈
2. 把返回值压入调用者调用者栈帧的操作数栈
3. 调整 PC 计数器的值以指向方法调用指令后面的一条指令

5、附加信息

虚拟机规范并没有规定具体虚拟机实现包含什么附加信息，这部分的内容完全取决于具体实现。在实际开发中，一般会把动态连接，方法返回地址和附加信息全部归为一类，称为栈帧信息。

8.2 方法调用

8.2.1解析（resolution）

所有方法调用中的目标方法在Class文件里面都是一个常量池中的引用，在类加载的解析阶段，会将其中的一部分符号引用转化为直接引用。这种解析能成立的前提是：方法在程序真正执行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。换句话说，调用目标在程序代码写好、编译器进行编译时就必须确定下来，这类方法的调用称为解析。

在Java语言中符合“编译期可知，运行期不可变”这个要求的方法，主要包括静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问，这两种方法各自的特点决定了他们不可能通过继承或别的方式重写其他版本，因此他们适合在类加载阶段进行解析。

静态方法、私有方法、实例构造器、父类方法。这些方法称为非虚方法，它们在类加载的时候就会把符号引用解析为该方法的直接引用。

与之相反，其他方法称为虚方法（除去final方法）

• invokestatic：调用静态方法。
• invokespecial：用于调用构造器方法、私有方法、父类方法。
• invokevirtual：用于调用类的所有虚方法。
• invokeinterface：用于调用接口方法。
• invokedynamic：先在运行时动态解析出调用点限定符所引用的方法，然后再执行该方法，invokedynamic指令的分派逻辑是由用户所设定的引导方法决定的。
  解析调用一定是个静态的过程，在编译期间就完全确定，在类装载的解析阶段就会把涉及的符号引用全部转变为可确定的直接引用，不会延迟到运行期再去完成。

8.2.2 分派（dispatch）

静态分派

public class StaticDispatch {
    static abstract class Human {
    }

    static class Man extends Human {
    }

    static class Woman extends Human {
    }

    public void sayHello(Human guy) {
        System.out.println("hello,guy!");
    }

    public void sayHello(Man guy) {
        System.out.println("hello,gentleman!");
    }

    public void sayHello(Woman guy) {
        System.out.println("hello,lady!");
    }

    public static void main(String[] args) {
        Human man = new Man();
        Human woman = new Woman();
        StaticDispatch sr = new StaticDispatch();
        sr.sayHello(man);
        sr.sayHello(woman);
    }
}

我们把上面代码中的“Human”称为变量的**“静态类型”（Static Type），或者叫“外观类型”（Apparent Type），后面的“Man”则被称为变量的“实际类型”（Actual Type）或者叫“运行时类型”（Runtime Type）**。静态类型和实际类型在程序中都可以发生一些变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型在编译器可知；而实际类型变化的结果在运行期才确定，编译器在编译期并不知道一个对象的实际类型是什么。

	Human man=new Man();
	sayHello(man);
	sayHello((Man)man);//类型转换，静态类型变化，我们知道转型后的静态类型一定是Man
	man=new Woman(); //实际类型变化,实际类型却是不确定的
	sayHello(man);
	sayHello((Woman)man);//类型转换，静态类型变化 

编译器在重载时是通过参数的静态类型而不是实际类型作为判定的依据。并且静态类型在编译期可知，因此，编译阶段，Javac编译器会根据参数的静态类型决定使用哪个重载版本。

所有依赖静态类型来定位方法执行版本的分派动作称为静态分派。静态分派的典型应用就是方法重载。

静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机来执行的，而是由编译器来完成。

但是，字面量没有显示的静态类型，它的静态类型只能通过语言上的规则去理解和推断。

public class Overload {
    public static void sayHello(Object arg) {
        System.out.println("hello Object");
    }

    public static void sayHello(int arg) {
        System.out.println("hello int");
    }

    public static void sayHello(long arg) {
        System.out.println("hello long");
    }

    public static void sayHello(Character arg) {
        System.out.println("hello Character");
    }

    public static void sayHello(char arg) {
        System.out.println("hello char");
    }

    public static void sayHello(char... arg) {
        System.out.println("hello char ...");
    }

    public static void sayHello(Serializable arg) {
        System.out.println("hello Serializable");
    }

    public static void main(String[] args) {
        sayHello('a');
    }
}

动态分派

public class DynamicDispatch {
    static abstract class Human {
        protected abstract void sayHello();
    }

    static class Man extends Human {
        @Override
        protected void sayHello() {
            System.out.println("man say hello");
        }
    }

    static class Woman extends Human {
        @Override
        protected void sayHello() {
            System.out.println("woman say hello");
        }
    }

    public static void main(String[] args) {
        Human man = new Man();
        Human woman = new Woman();
        man.sayHello();
        woman.sayHello();
        man = new Woman();
        man.sayHello();
    }
}

显然，这里不可能再根据静态类型来决定，因为静态类型同样是Human的两个变量man和woman在调用sayHello()方法时执行了不同的行为，并且变量man在两次调用中执行了不同的方法。导致这个现象的原因很明显，是这两个变量的实际类型不同，Java虚拟机是如何根据实际类型来分派方法执行版本的呢？
我们从invokevirtual指令的多态查找过程开始说起，invokevirtual指令的运行时解析过程大致分为以下几个步骤：

1、找到操作数栈顶的第一个元素所指向的对象的实际类型，记作C。
2、如果在类型C中找到与常量中的描述符和简单名称相符合的方法，然后进行访问权限验证，如果验证通过则返回这个方法的直接引用，查找过程结束；如果验证不通过，则抛出java.lang.IllegalAccessError异常。
3、否则未找到，就按照继承关系从下往上依次对类型C的各个父类进行第2步的搜索和验证过程。
4、如果始终没有找到合适的方法，则跑出java.lang.AbstractMethodError异常。

由于invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型，所以两次调用中的invokevirtual指令把常量池中的类方法符号引用解析到了不同的直接引用上，这个过程就是Java语言方法重写的本质。我们把这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。

事实上，在Java里面只有虚方法存在，字段永远不可能是虚的，换句话说，字段永远不参与多态，哪个类的方法访问某个名字的字段时，该名字指的就是这个类能看到的那个字段。当子类声明了与父类同名的字段时，虽然在子类的内存中两个字段都会存在，但是子类的字段会遮蔽父类的同名字段。

public class FieldHasNoPolymorphic {
    static class Father {
        public int money = 1;

        public Father() {
            money = 2;
            showMeTheMoney();
        }

        public void showMeTheMoney() {
            System.out.println("I am Father, i have $" + money);
        }
    }

    static class Son extends Father {
        public int money = 3;

        public Son() {
            money = 4;
            showMeTheMoney();
        }

        public void showMeTheMoney() {
            System.out.println("I am Son, i have $" + money);
        }
    }

    public static void main(String[] args) {
        Father gay = new Son();
        System.out.println("This gay has $" + gay.money);
    }
}

虚拟机动态分派的实现

public class Dispatch {
    static class QQ {
    }

    static class _360 {
    }

    public static class Father {
        public void hardChoice(QQ arg) {
            System.out.println("father choose qq");
        }

        public void hardChoice(_360 arg) {
            System.out.println("father choose 360");
        }
    }

    public static class Son extends Father {
        public void hardChoice(QQ arg) {
            System.out.println("son choose qq");
        }

        public void hardChoice(_360 arg) {
            System.out.println("son choose 360");
        }
    }

    public static void main(String[] args) {
        Father father = new Father();
        Father son = new Son();
        father.hardChoice(new _360());
        son.hardChoice(new QQ());
    }
}

前面介绍的分派过程，作为对虚拟机概念模型的解析基本上已经足够了，它已经解决了虚拟机在分派中"会做什么"这个问题。

但是，虚拟机”具体是如何做到的“，可能各种虚拟机实现都会有些差别。

由于动态分派是非常频繁的动作，而且动态分派的方法版本选择过程需要运行时在类的方法元数据中搜索合适的目标方法，因此虚拟机的实际实现中基于性能的考虑，大部分实现都不会真正的进行如此频繁的搜索。面对这种情况，最常用的”稳定优化“手段就是为类在方法区中建立一个虚方法表**（Virtual Method Table，也称为vtable）**，使用虚方法表索引来代替元数据查找以提高性能。

虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方法表里面的地址入口和父类相同方法的地址入口是一致的，都是指向父类的实际入口。如果子类中重写了这个方法，子类方法表中的地址将会替换为指向子类实际版本的入口地址。

为了程序实现上的方便，具有相同签名的方法，在父类、子类的虚方法表中具有一样的索引序号，这样当类型变换时，仅仅需要变更查找的方法表，就可以从不同的虚方法表中按索引转换出所需要的入口地址。

方法表一般在类加载阶段的连接阶段进行初始化，准备了类的变量初始值后，虚拟机会把该类的方法表也初始化完毕。

8.3 基于栈的解释器执行过程

8.3.1 解释执行

Java被人定位于“解释执行”的语言。在jdk1.0时，定义还算准确，但后来当主流虚拟机中都包含了即时编译器后，Class文件中的代码
大部分的程序代码到物理机的目标代码或虚拟机能执行的指令集之前，都需要经过以下过程：

如今，基于物理机、Java虚拟机，或者非Java的其他高级语言虚拟机的语言，大多数都会遵循这种基于现代经典编译原理的思路，在执行前先对程序源码进行词法分析和语法分析处理，把源码转为抽象语法树。

在Java中，Javac编译器完成了程序代码经过词法分析、语法分析到抽象语法树，再遍历语法树生成线性的字节码指令流的过程，因为这一部分是在Java虚拟机之外进行的，而解释器在虚拟机的内部，所以Java程序的编译就是半独立的。

8.3.2 基于栈的指令集架构

Java编译器输出的指令流，基本上是一种基于栈的指令集架构，指令流中的指令大部分都是零地址指令，他们依赖操作数栈进行工作。

基于栈的指令集主要优点就是可移植，使用栈架构指令集，用户程序不会直接使用寄存器，就可以由虚拟机实现来自行决定把一些访问最频繁的数据放到寄存器中以获取尽量好的的性能。

栈架构指令集的主要缺点是执行速度相对来说会稍慢一些，主要是因为指令数量和内存访问导致的。

8.3.3 基于栈指令的解释器执行过程

public int calc() {
    int a = 100;
    int b = 200;
    int c = 300;
    return (a + b) * c;
}

字节码指令

public int calc();
    Code
    Stack=2.Locals=4,Args_size=1
    0:     bitpush  100
    2:     istroe_1
    3:     sipush   200
    6:     istroe_2
    7:     sipush   300
    10:    istore_3
    11:    iload_1
    12:    iload_2
    13:    iadd
    14:    iload_3
    15:    imul
    16:    ireturn

javap提示这段需要栈深度为2的操作数栈和4个Slot的局部变量空间。

首先执行偏移地址为0的指令，bipush指令将单字节的整型常量池推入操作数栈，100指的是推送的常量值。

执行偏移地址为2的指令，istroe_1指令是将操作数栈顶的值出栈并存放到第1个局部变量Slot中，后续4条指令都是在做同样事情。

iload_1指令是将局部变量表第1个Slot中的整型值复制到操作数栈顶。

iload_2指令同样是将第2个Slot中整型值复制到操作数栈顶。

iadd指令的作用是将操作数栈中两个数出栈，做加法，然后将结果重新入栈。

iload_3是将局部变量表中第3个Slot入栈，此时操作数栈中为两个整数。

ireturn指令是方法返回指令之一，将结束方法执行返回操作数栈顶值

上面的过程只是一种概念模型，虚拟机最终会对执行过程进行一些优化来提高性能。主要是虚拟机中解析器和即使编译器都会对输入的字节码进行优化

类执行机制

JVM是基于堆栈的虚拟机。JVM为每个新创建的线程都分配一个堆栈.也就是说,对于一个Java程序来说，它的运行就是通过对堆栈的操作来完成的。堆栈以帧为单位保存线程的状态。JVM对堆栈只进行两种操作:以帧为单位的压栈和出栈操作。

JVM执行class字节码，线程创建后，都会产生程序计数器（PC）和栈（Stack），程序计数器存放下一条要执行的指令在方法内的偏移量，栈中存放一个个栈帧，每个栈帧对应着每个方法的每次调用，而栈帧又是有局部变量区和操作数栈两部分组成，局部变量区用于存放方法中的局部变量和参数，操作数栈中用于存放方法执行过程中产生的中间结果。栈的结构如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Oved0M1d-1667799912753)(https://gitee.com/Liudakang/markdown-pic/raw/master/20131106003939906)]

第九章 类加载及执行子系统的案例与实战

一. 案例分析

Tomcat：正统的类加载器架构

主流的Java Web服务器，如Tomcat、Jetty、WebLogic、WebSphere或其他服务器，都实现了自己定义的类加载器（一般都不止一个）。因为一个功能健全的Web服务器，要解决如下问题：

• 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离。服务器应当保证两个应用程序的类库可以互相独立使用。

• 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以互相共享。如果部分类库不能共享，虚拟机的方法区就会很容易出现过度膨胀的风险。

服务器需要尽可能地保证自身的安全不受部署的Web应用程序影响。基于安全考虑，服务器所使用的类库应该与应用程序的类库互相独立。

支持JSP应用的Web服务器，大多数需要支持HotSwap功能。我们知道，JSP文件最终要编译成Java Class 才能由虚拟机执行，但JSP文件由于其纯文本存储的特性，运行时修改的概率远远大于第三方类库或程序自身Class文件。

由于存在上述问题，在部署Web应用时，单独的一个ClassPath就无法满足需求了，所以各种Web服务器都“不约而同”地提供了好几个ClassPath路径供用户存放第三方类库，这些路径一般都以“lib”或“classes”命名。不同路径的类库，具备不同的访问范围和服务对象。
　　在Tomcat目录结构中，有3组目录（“/common/”、“/server/”和“/shared/”）可以存放Java类库，另外加上Web应用程序自身目录“WEB-INF/”，一共4组，把Java类库放置在这些目录中的含义分别是：

• 放置在/common目录中： 类库可被Tomcat和所有的Web应用程序共同使用。
• 放置在/server目录中：类库可被Tomcat使用，对所有Web应用程序都不可见。
• 放置在/shared目录中：类库可被所有的Web应用程序共同使用，但对Tomcat不可见。
• 放置在/WebApp/WEB-INF目录中：类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见。

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

　　

从图中的委派关系，可以看出，CommonClassLoader能加载的类都可以被CatelinaClassLoader和SharedClassLoader使用，而CatelinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。
　　WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
　　而JasperLoader的加载范围则仅仅是这个JSP文件所编译出来的哪一个Class，它出现的目的就是为了被抛弃：当服务器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。
　　注意：对于Tomcat6.x的版本，只有指定了 tomcat/conf/catalina.properties 配置文件的 server.loader 和share.loader 项才会真正建立对应的 *ClassLoader实例，否则会用到这两个类加载器的地方使用CommonClassLoader的实例来代替，默认配置中没有设置这两个loader 项。

OSGI：灵活的类加载器架构

在OSGI里面，Bundle之间的依赖关系从传统的上层模块依赖底层模块转变为平级模块之间的依赖。
　　OSGI特点，要归功于它灵活的类加载架构。OSGI的Bundle类加载器之间只有规则，没有固定的委派关系。

字节码生成技术与动态代理的实现

相信许多Java开发人员都是用过动态代理，例如 java.lang.reflect.Proxy 或实现过 java.lang.reflect.InvocationHandler 接口。

interface IHello {
    void sayHello();
}

static class Hello implements IHello {
    @Override
    public void sayHello() {
        System.out.println("hello world");
    }
}

static class DynamicProxy implements InvocationHandler {
    Object originalObj;

    Object bind(Object originalObj) {
        this.originalObj = originalObj;
        return Proxy.newProxyInstance(originalObj.getClass().getClassLoader(), originalObj.getClass().getInterfaces(), this);
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if (method.getName() == "sayHello") {
            System.out.println("tigao");
            method.invoke(originalObj, args);
            System.out.println(1123);
        }
        return originalObj;
    }
}

public static void main(String[] args) {
    IHello hello = (IHello) new DynamicProxy().bind(new Hello());
    hello.sayHello();
}

这个代理类的实现代码也很简单，它为传入接口中的每一个方法，以及从java.lang.Object中继承来的equals()、hashCode()、toString()方法都生成了对应的实现，并且统一调用了InvocationHandler对象的**invoke()**方法（代码中的“this.h”就是父类Proxy中保存的InvocationHandler实例变量）来实现这些方法的内容，各个方法的区别不过是传入的参数和Method对象有所不同而已，所以无论调用动态代理的哪一个方法，实际上都是在执行InvocationHandler::invoke()中的代理逻辑。

Retrotranslator：跨越JDK版本

把JDK1.5 中编写的代码放到 JDK1.4 或 1.3 的环境去部署使用。为了解决这个问题，一种名为“Java逆转移植”的工具（Java Backporting Tools）应运而生，Retrotranslator 是这类工具中较为出色的一个。

第十章 前端编译与优化

Java代码的编译和执行的整个过程大概是：

1. 开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件)

2. 再然后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者是被即时代码发生器有选择的转换成机器码执行。

Java代码编译是由Java源码编译器来完成，也就是Java代码到JVM字节码（.class文件）的过程。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xg8TjBxx-1667799912754)(https://gitee.com/Liudakang/markdown-pic/raw/master/image-20220323150555148.png)]

Java字节码的执行是由JVM执行引擎来完成，流程图如下所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4GBuPqjL-1667799912754)(https://gitee.com/Liudakang/markdown-pic/raw/master/image-20220323150739974.png)]

JVM的编译器的种类：

• 前端编译器：把.java变成.class的过程。如Sun的Javac,Eclipse JDT中的增量式编译器。

• JIT编译器（即时编译器）：运行期把字节码转变成机器码的过程。

• AOT编译器（提前编译器）：静态提前编译，直接将*.java文件编译本地机器码的过程。

Javac的编译过程

Javac编译动作的入口是com.sun.tools.javac.main.JavaCompiler类

从Javac代码的总体结构来看，编译过程大致可以分为1个准备过程和3个处理过程，它们分别如下
所示。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mwJ7zRVc-1667799912754)(https://gitee.com/Liudakang/markdown-pic/raw/master/image-20220323150850978.png)]

1. 准备过程：初始化插入式注解处理器。

2. 解析与填充符号表过程，包括：

   • 词法、语法分析。将源代码的字符流转变为标记集合，构造出抽象语法树。
   • 填充符号表。产生符号地址和符号信息。

3. 插入式注解处理器的注解处理过程：插入式注解处理器的执行阶段，本章的实战部分会设计一
   个插入式注解处理器来影响Javac的编译行为。

4. 分析与字节码生成过程，包括：

   • 标注检查。对语法的静态信息进行检查。
   • 数据流及控制流分析。对程序动态运行过程进行检查。
   • 解语法糖。将简化代码编写的语法糖还原为原有的形式。
   • 字节码生成。将前面各个步骤所生成的信息转化成字节码。

   最后生成的class文件由以下部分组成：

   ① 结构信息：包括class文件格式版本号及各部分的数量与大小的信息

   ② 元数据：对应于Java源码中声明与常量的信息。包含类/继承的超类/实现的接口的声明信息、域与方法声明信息和常量池

   ③ 方法信息：对应Java源码中语句和表达式对应的信息。包含字节码、异常处理器表、求值栈与局部变量区大小、求值栈的类型记录、调试符号信息

词法分析、语法分析

**词法分析：**将源代码的字符流转变成标记（Token）集合，标记是编译过程的最小元素，如“int a = b+2"包含了6个标记，分别是int，a，=，b，+，2。

**语法分析：**根据Token序列构造语法抽象树的过程,抽象语法树（AST）是一种用来描述程序语法结构的树形表示方式，语法树的每一个节点都代表一个语法结构，例如包，类型，修饰符，接口，返回值甚至代码注释。

填充符号表
完成抽象语法树之后，下一步就是填充符号表的过程，即enterTrees()方法。符号表是由一组符号地址和符号信息构成的表格，类似于哈希表中K-V值对的形式。符号表所登记的信息在编译的不同阶段都要用到。

注解处理器
注解处理器在运行期发挥作用，有了注解处理器的标准API后，我们的代码才有可能干涉编译器的行为。

语义分析与字节码生成
**语法分析之后，编译器获得了程序代码的抽象语法树表示，语法树能表示一个结构正确的源代码抽象。**而语义分析的主要任务是对结构上正确的源程序进行上下文有关性质的审查，如进行类型审查。在Javac编译过程中，语法分析过程分为标注检查以及数据及控制流分析两个步骤，分别对应着attribute()和flow()方法完成。

• 标注检查
  标注检查步骤检查的内容包括诸如变量使用前是否被声明，变量与赋值之间的数据是否能够匹配等。此过程还有一个重要的步骤称为折叠，如int a = 1+2。语法树上能看到字面量“1”，“2”以及操作符“+”，但在折叠后就变成了“3”。

• 数据流及控制分析

  数据流及控制分析是对程序上下文逻辑更近一步的验证，它可以检查出诸如程序局部变量在使用前是否与赋值，方法的每条路径是否都有返回值。

• 解语法糖

  语法糖是指在计算机语言中添加某种语法，这种语法对语言的功能并没有影响。JAVA是一种"低糖语言”，常用的语法糖主要是之前提到的泛型、变长参数、自动装箱/拆箱等。虚拟机运行时不支持这些语法，它们在编译期还原回简单的基础语法结构，这个过程称为解语法糖。解语法糖的过程是由desuger()方法触发的。

• 字节码生成
  字节码生成阶段不仅仅是把前面各个步骤所生成的信息（语法树、符号表）转化为字节码写入磁盘中，编译器还进行了少量代码添加和转换工作。

JAVA语法糖

1.泛型与类型擦除

Java的泛型只存在于程序源码中，在编译后的字节码文件中，就已经替换成原来的原生类型，也称为裸类型，并且在相应的地方插入了强制转型代码。因此，对于运行期的Java语言来说，ArrayList与ArrayList就是同一个类，所以泛型技术实际上是Java语言的一颗语法糖，Java语言中的泛型实现方法称为类型擦除，基于这种方法实现的泛型称为伪泛型。

故当List和List作为参数时，擦除使得两者的特征签名变得一模一样，有时可能导致拥有该两个方法参数的方法无法重载。

值得注意的是：当出现上述的情况的时候，如果返回值不一样的话，该两个方法是可以存在于一个Class文件中的，总结一下，两个方法如果有相同的名称和特征签名，但返回值不同，那它们也是合法地，可以共存于一个Class文件中。

擦除法所谓的擦除，仅仅是对方的Code属性中的字节码进行擦除，实际上元数据中还是保留了泛型信息，这也是我们能通过反射手段取得参数化类型的根本依据。

2.自动装箱、拆箱与遍历循环

自动装箱、拆箱在编译之后就被转换成了相应的包装和还原方法，如Integer.valueOf()与Integer,intValue()方法，而遍历循环则把代码还原成了迭代器的实现，这也是为何遍历循环需要被遍历类实现Iterable接口的原因。

包装类的“==”运算在不遇到算术运算的情况下不会自动拆箱，以及它们equals()方法不处理数据转型的关系。

3.条件编译

Java语言使用条件为常量的if语句，此代码中的if语句不同于其他Java代码，它在编译阶段就会被运行，生成的字节码之中只包含条件正确的部分。
Java语言中条件编译的实现，也是Java语言的一颗语法糖，根据布尔常量值的真假，编译器将会把分支中不成立的代码块消除掉，这是在解语法糖阶段实现的。

第十一章 晚期（运行期）优化

如果我们把字节码看作是程序语言的一种**中间表示形式（Intermediate Representation，IR）**的话，那编译器无论在何时、在何种状态下把Class文件转换成与本地基础设施（硬件指令集、操作系统）相关的二进制机器码，它都可以视为整个编译过程的后端。

概述

在部分的商用虚拟机（Sun HotSpot、IBM J9）中，Java 程序最初是通过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码” （Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，下文中简称 JIT 编译器）。
即时编译器并不是虚拟机必需的部分，Java 虚拟机规范并没有规定 Java 虚拟机内必需要有即时编译器存在，更没有限定或指导即时编译器应该如何去实现。但是，即时编译器编译性能的好坏、代码优化程度的高低却是衡量一款商用虚拟机优秀与否的最关键指标之一，它也是虚拟机内中最核心且最能体现虚拟机技术水平的部分。在本章中，我们将走进虚拟机的内部，探索即时编译器的运作过程。
由于 Java 虚拟机规范没有具体的约束规则去限制即时编译器应该如何实现，所以这部分功能完全是与虚拟机具体实现（Implementation Specific）相关的内容，如无特殊说明，本章提及的编译器、即时编译器都是指 HotSpot 虚拟机内部的即时编译器，虚拟机也是特指 HotSpot 虚拟机。不过，本章的大部分内容是描述即时编译器的行为，涉及编译器实现层面的内容较少，而主流虚拟机中即时编译器的行为又有很多相似和想通之处，因此，对其他虚拟机来说也具有较高的参考意义。

HotSpot 虚拟机内的即时编译器

在本节中，我们将要了解 HotSpot 虚拟机内的即时编译器的运作过程，同时，还要解决以下几个问题：

• 为何 HotSpot 虚拟机要使用解释器与编译器并存的架构？
• 为何 HotSpot 虚拟机要实现两个不同的即时编译器？
• 程序何时使用解释器执行？何时使用编译器执行？
• 哪些程序代码会被编译为本地代码？如何编译为本地代码？
• 如何从外部观察即时编译器的编译过程和编译结果？

解释器与编译器

尽管并不是所有的 Java 虚拟机都采用解释器与编译器并存的架构，但许多主流的商用虚拟机，如 HotSpot、J9 等，都同时包含解释器与编译器。

• 解释器与编译器两者各有优势：
  • 当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。
  • 在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。

​ 当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。同时，解释器还可以作为编译器激进优化时的一个 “逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现 “罕见陷阱”（Uncommon Trap）时可以通过逆优化（Deoptimization）退回到解释状态继续执行（部分没有解释器的虚拟机中也会采用不进行激进优化的 C1（注：在虚拟机中习惯将 Client Compiler 称为 C1，将 Server Compiler 称为 C2） 编译器担任 “逃生门” 的角色），因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作

HotSpot 虚拟机中内置了两个即时编译器、分别称为 Client Compiler 和 Server Compiler 或者简称为 C1 编译器和 C2 编译器（也叫 Opto 编译器）。目前主流的 HotSpot 虚拟机（Sun 系列 JDK 1.7 及之前版本的虚拟机）中，默认采用解释器与其中一个编译器直接配合的方式工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot 虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用 “-client” 或 “-server” 参数去强制指定虚拟机运行在 Client 模式或 Server 模式。

无论采用的编译器是 Client Compiler 还是 Server Compiler，解释器与编译器搭配使用的方式在虚拟机中成为 “混合模式” （Mixed Mode），用户可以使用参数 “-Xint” 强制虚拟机运行于 “解释模式”（Interpreted Mode），这是编译器完全不介入工作，全部代码都使用解释方式执行。另外，也可以使用参数 “-Xcomp” 强制虚拟机运行于 “编译模式”（Compiled Mode），这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程，可以通过虚拟机的 “-version” 命令的输出结果显示出这 3 种模式，如代码清单 11-1 所示，请注意黑体字部分。

由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长：而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机还会逐渐启用分层编译（Tiered Compilation）的策略，分层编译的概念在 JDK 1.6 时期出现，后来一直处于改进阶段，最终在 JDK-7 的 Server 模式虚拟机中作为默认编译策略被开启。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

• 第0层。程序纯解释执行，并且解释器不开启性能监控功能（Profiling）。
• 第1层。使用客户端编译器将字节码编译为本地代码来运行，进行简单可靠的稳定优化，不开启性能监控功能。
• 第2层。仍然使用客户端编译器执行，仅开启方法及回边次数统计等有限的性能监控功能。
• 第3层。仍然使用客户端编译器执行，开启全部性能监控，除了第2层的统计信息外，还会收集如分支跳转、虚方法调用版本等全部的统计信息。
• 第4层。使用服务端编译器将字节码编译为本地代码，相比起客户端编译器，服务端编译器会启用更多编译耗时更长的优化，还会根据性能监控信息进行一些不可靠的激进优化。

编译对象与触发条件

上文中提到过，在运行过程中会被即时编译器编译的 “热点代码” 有两类，即：

• 被多次调用的方法。
• 被多次执行的循环体。

对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的 JIT 编译方式。

对于后一种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法（而不是单独的循环体）作为编译对象。这种编译方式因为编译发生在方法执行过程之中，因此形象地称之为栈上替换（On Stack Replacement，简称为 OSR 编译，即方法栈帧还在栈上，方法就被替换了）。

判断一段代码是不是热点代码，是不是需要触发即时编译，这样的行为称为热点探测（Hot Spot Detection），其实进行热点探测并不一定要知道方法具体被调用了多少次，目前主要的热点探测判定方式有两种（注：还有其他热点代码的探测方式，如基于“踪迹”（Trace）的热点探测再最近相当流行，像 Firefox 中的 TraceMonkey 和 Dalvik 中新的 JIT 编译器都用了这种热点探测方式），分别如下。

• 基于采样的热点探测（Sample Based Hot Spot Detection）：采用这种方法的虚拟机会周期性地检查各个线程的栈顶，如果发现某个（或某些）方法经常出现在栈顶，那这个方法就是 “热点方法”。基于采样的热点探测的好处是实现简单、高效，还可以很容易地获取方法调用关系（将调用堆栈展开即可），缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。
• 基于计数器的热点探测（Counter Based Hot Spot Detection）：采用这种方法的虚拟机会为每个方法（甚至是代码块）建立计数器，统计方法的执行次数，如果执行次数超过一定的阈值就认为它是 “热点方法”。这种统计方法实现起来麻烦一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对来说更加精确和严谨。

在 HotSpot 虚拟机中使用的是第二种——基于计数器的热点探测方法，因此它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发 JIT 编译。

方法调用计数器

顾名思义，这个计数器就用于统计方法被调用的次数，它的默认阈值在 Client 模式下是 1500。在 Server 模式下是 10 000 次，这个阈值可以通过虚拟机参数-XX：CompileThreshold来人为设定。

1. 当一个方法被调用时，会先检查该方法是否存在被 JIT 编译过的版本。

   • 如果存在，则优先使用编译后的本地代码来执行。

   • 如果不存在已被编译过的版本，则将此方法的调用计数器值加 1，然后判断方法调用计数器与回边计数器值之和是否查过方法调用计数器的阈值。

     • 如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。
     • 如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法调用入口地址就会被系统自动改成新的，下一次调用该方法时就会使用已编译的版本。

如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数 -XX: -UseCounterDecay 来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用 -XX: CounterHalfLifeTime 参数设置半衰周期的时间，单位是秒。

回边计数器

它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为 “回边”（Back Edge）。显然，建立回边计数器统计的目的就是为了触发 OSR 编译。

计数器的阈值在不同类型的编译器上计算不同

当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会有限执行已编译的代码，否则就把回边计数器的值加 1，然后判断方法调用计数器与回边计数器之和是否超过回边计数器的阈值。当超过阈值的时候，将会提交一个 OSR 编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果

编译过程

在默认设置下，无论是方法调用产生的即时编译请求，还是 OSR 编译请求，**虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。**用户可以通过设置将编译过程同步化
那么在后台执行编译的过程中，编译器做了什么事情呢？Server Compiler 和 Client Compiler 两个编译器的编译过程是不一样的。对于 Client Compiler 来说，它是一个简单快速的一段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。

在第一个阶段，一个平台独立的前端将字节码构造成一种高级中间代码表示（High-Level Intermediate Representation，HIR）。HIR 使用静态单分配（Static Single Assignment，SSA）的形式来代表代码值，这可以使得一些在 HIR 的构造过程之中和之后进行的优化动作更容易实现。在此之前编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成 HIR 之前完成。

在第二个阶段，一个平台相关的后端从 HIR 中产生低级中间代码表示（Low-Level Intermediate Representation，LIR），而在此之前会在 HIR 上完成另外一些优化，如空值检查消除、范围检查消除等，以便让 HIR 达到更高效的代码表示形式。

最后阶段是在平台相关的后端使用线性扫描算法（Linear Scan Register Allocation）在 LIR 上分配寄存器，并在 LIR 上做窥孔（Peephole）优化，然后产生机器代码。Client Compiler 的大致执行过程如图 11-4 所示。

而 Server Compiler 则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也是一个充分优化过的高级编译器，几乎能达到 GNU C++ 编译器使用 -O2 参数时的优化强度，它会执行所有经典的优化动作，如无用代码消除（Dead Code Elimination）、循环展开（Loop Unrolling）、循环表达式外提（Loop Expression Hoisting）、消除公共子表达式（Common Subexpression Elimination）、常量传播（Constant Propagation）、基本块重排序（Basic Block Reordering）等，还会实施一些与 Java 语言特性密切相关的优化技术，如范围检查消除（Range Check Elimination）、空值检查消除（Null Check Elimination，不过并非所有的控制检查消除都是依赖编译器优化的，有一些是在代码运行过程中自动优化了）等。另外，还可能根据解释器或 Client Compiler 提供的性能监控信息，进行一些不稳定的激进优化，如守护内联（Guarded Inlining）、分支频率预测（Branch Frequency Prediction）等。本章的下半部分将会挑选上述的一部分优化手段进行分析和讲解。
Server Compiler 的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构（如 RISC）上的大寄存器集合。以即时编译的标准来看，Server Compiler 无疑是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于 Client Compiler 编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以也有很多非服务端的应用选择使用 Server 模式的虚拟机运行。
在本节中，涉及了许多编译原理和代码优化中的概念名词，没有这方面基础的读者，阅读起来会感觉到抽象和理论化。有这种感觉并不奇怪，JIT 编译过程本来就是一个虚拟机中最体现技术水平也是醉复杂的部分，不可能一较短的篇幅就介绍得很详细，另外，这个过程对 Java 开发来说是透明的，程序员平时无法感知它的存在，还好 HotSpot 虚拟机提供了两个可视化的工具，让我们可以 “看见” JIT 编译器的优化过程，在稍后笔者将演示这个过程。

编译优化技术

Java 程序员有一个共识，以编译方式执行本地代码比解释方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个很重要的原因就是虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器之中（在 JDK 1.3 之后，javac 就去除了 -O 选项，不会生成任何字节码级别的优化代码了）。因此一般来说，即时编译器产生的本地代码会比 javac 产生的字节码更加优秀。下面，笔者将介绍一些 HotSpot 虚拟机的即时编译器在生成代码时采用的代码优化技术。

优化技术概览

在 Sun 官方的 Wiki 上，HotSpot 虚拟机设计团队列出了一个相对比较全面的、在即时编译器中采用的优化技术列表（见表 11-1），其中有不少经典编译器的优化手段，也有许多针对 Java 语言（准确地说是针对运行在 Java 虚拟机上的所有语言）本身进行的优化技术，本节将对这些技术进行概括性的介绍，在后面几节中，再挑选若干重要且典型的优化，与读者一起看看优化前后的代码产生了怎样的变化。

• 语言无关的经典优化技术之一：公共子表达式消除。
• 语言相关的经典优化技术之一：数组范围检查消除。
• 最重要的优化技术之一：方法内联。
• 最前沿的优化技术之一：逃逸分析。

公共子表达式消除

公共子表达式消除是一个普遍应用于各种编译器的经典优化技术，它的含义是：如果一个表达式 E 已经计算过了，并且从先前的计算到现在 E 中所有变量的值都没有发生变化，那么 E 的这次出现就成为了公共子表达式。对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替 E 就可以了。如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除（Local Common Subexpression Elimination），如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除（Global Common Subexpression Elimination）。举个简单的例子来说明它的优化过程，假设存在如下代码：

int d = (c * b) * 12 + a + (a + b * c);
1
如果这段代码交给 Javac 编译器则不会进行任何优化，那生成的代码将如代码清单 11-11 所示，是完全遵照 Java 源码的写法直译而成的。
当这段代码进入到虚拟机即时编译器后，它将进行如下优化：编译器检测到 “cb” 与 “bc” 是一样的表达式，而且在计算期间 b 与 c 的值是不变的。因此，这条表达式就可能被视为：

int d = E * 12 + a + (a + E);

这时，编译器还可能（取决于那种虚拟机的编译器以及具体的上下文而定）进行另外一种优化：代数化简（Algebraic Simplification），把表达式变为：

int d = E * 13 + a * 2;

表达式进行变换之后，再计算起来就可以节省一些时间了。如果读者还对其他的经典编译优化技术感兴趣，可以参考《编译原理》（俗称 “龙书”，推荐使用 Java 的程序员阅读 2006 年版的 “紫龙书”）中的相关章节。

数组边界检查消除

数组边界检查消除（Array Bounds Checking Elimination）是即时编译器中的一项语言相关的经典优化技术。我们知道 Java 语言是一门动态安全的语言，对数组的读写访问也不像 C、C++ 那样在本质上是裸指针操作。如果有一个数组 foo[]，在 Java 语言中访问数组元素 foo[i] 的时候系统将会自动进行上下界的范围检查，即检查 i 必须满足 i >= 0 && i < foo.length 这个条件，否则将会抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException。这对软件开发者来说是一件很好的事情，即使程序员没有专门编写防御代码，也可以避免大部分的溢出攻击。但是对于虚拟机的执行子系统来说，每次数组元素的读写都带有一次隐含的条件判定操作，对于拥有大量数组访问的程序代码，这无疑也是一种性能负担。
无论如何，为了安全，数组边界检查肯定是必须做的，但数组边界是不是必须在运行期间一次不漏地检查则是可以 “商量” 的事情。例如下面这个简单的情况：数组下标是一个常量，如 foo[3]，只要在编译期根据数组流分析来确定 foo.length 的值，并判断下标 “3” 没有越界，执行的时候就无须判断了。更加常见的情况是数组访问发生在循环之中，并且使用循环遍历来进行数组访问，如果编译器只要通过数据流分析就可以判定循环变量的取值范围永远在区间[0, foo.length)之内，那在整个循环中就可以把数组的上下界检查消除，这可以节省很多次的条件判断操作。
将这个数组边界检查的例子放在更高的角度来看，大量的安全检查令编写 Java 程序比编写 C/C++ 程序容易很多，如数组越界会得到 ArrayIndexOutOfBoundsException 异常，空指针访问会得到 NullPointException，除数为零会得到 ArithmeticException 等，在 C/C++ 程序中出现类似的问题，一不小心就会出现 Segment Fault 信号或者 Windows 编程中常见的 “xxx 内存不能为 Read/Wrie” 之类的提示，处理不好程序就和直接崩溃退出了。但这些安全检查也导致了相同的程序，Java 要比 C/C++ 做更多的事情（各种检查判断），这些事情就成为一种隐式开销，除了如数组边界检查优化这种尽可能把运行期检查提到编译期完成的思路之外，另外还有一种避免思路——隐式异常处理，Java 中空指针检查和算术运算中除数为零的检查都采用了这种思路。举个例子，例如程序中访问一个对象（假设对象叫 foo）的某个属性（假设属性叫 value），那以 Java 伪代码来表示虚拟机访问 foo.value 的过程如下。

if (foo != null) {  
    return foo.value;  
else {  
    throw new NullPointException();  
}  

在使用隐式异常优化之后，虚拟机会把上面伪代码所表示的访问过程变为如下伪代码。

[java] view plain cop

try {  
     return foo.value;  
} catch (segment_fault) {  
    uncommon_trap();  
}  

虚拟机会注册一个 Segment Fault 信号的异常处理器（伪代码中的 uncommon_trap()），这样当 foo 不为空的时候，对 value 的访问是不会额外消耗一次对 foo 判空的开销的。代价就是当 foo 真的为空时，必须转入到异常处理器中恢复并抛出 NullPointException 异常，这个过程必须从用户态转到内核态中处理，结束后再回到用户态，速度远比一次判空检查慢。当 foo 极少为空的时候，隐式异常优化是值得的，但假如 foo 经常为空的话，这样的优化反而会让程序更慢，还好 HotSpot 虚拟机足够 “聪明”，它会根据运行期收集到的 Profile 信息自动选择最优方案。
与语言相关的其他消除操作还有不少，如自动装箱消除（Autobox Elimination）、安全点消除（Safepoint Elimination）、消除反射（Dereflection）等，笔者就不再一一介绍了。

方法内联

在前面的讲解之中我们提到过方法内联，它是编译器最重要的优化手段之一，除了消除方法调用的成本之外，它更重要的意义是为其他优化手段建立良好的基础，如代码清单 11-12 所示的简单例子就揭示了内联对其他优化手段的意义：事实上 testInline() 方法的内部全部都是无用的代码，如果不做内联，后续即使进行了无用代码消除的优化，也无法发现任何 “Dead Code”，因为如果分开来看，foo() 和 testInline() 两个方法里面的操作都可能是有意义的。

方法内联的优化行为看起来很简单，不过是把目标方法的代码 “复制” 到发起调用的方法之中，避免发生真实的方法调用而已。但实际上 Java 虚拟机中的内联过程远远没有那么简单，因为如果不是即时编译器做了一些特别的努力，按照经典编译原理的优化理论，大多数的 Java 方法都无法进行内联。

无法内联的原因其实在《虚拟机字节码执行引擎》中讲解 Java 方法解析和分派调用的时候就已经介绍过。只有使用 invokespecial 指令调用的私有方法、实例构造器、父类方法以及使用invokestatic 指令进行调用的静态方法才是在编译期进行解析的，除了上述 4 种方法之外，其他的 Java 方法调用都需要在运行时进行方法接收者的多态选择，并且都可能存在多于一个版本的方法接收者（最多再除去被 final 修饰的方法这种特殊情况，尽管它使用 invokevirtual 指令调用，但也是非虚方法，Java 语言规范中明确说明了这点），简而言之，Java 语言中默认的实例方法是虚方法。
对于一个虚方法，编译期做内联的时候根本就无法确定应该使用哪个方法版本，如果以代码清单 11-7 中把 “b.get()” 内联为 “b.value” 为例的话，就是不依赖上下文就无法确定 b 的实际类型是什么。假如有 ParentB 和 SubB 两个具有继承关系的类，并且子类重写了父类的 get() 方法，那么，是要执行父类的 get() 方法还是子类的 get() 方法，需要在运行期才能确定，编译期无法得出结论。

由于 Java 语言提倡使用面向对象的编程方式进行编程，而 Java 对象的方法默认就是虚方法，因此 Java 间接鼓励了程序员使用大量的虚方法来完成程序逻辑。根据上面的分析，如果内联与虚方法之间产生 “矛盾”，那该怎么办呢？是不是为了提高执行性能，就要到处使用 final 关键字去修饰方法呢？

为了解决虚方法的内联问题，Java 虚拟机设计团队想了很多办法，首先是引入了一种名为 “类型继承关系分析”（Class Hierarchy Analysis，CHA）的技术，这是一种基于整个应用程序的类型分析技术，它用于确定在目前已加载的类中，某个接口是否有多于一种的实现，某个类是否存在子类、子类是否为抽象类等信息。

编译器在进行内联时，

• 如果是非虚方法，那么直接进行内联就可以了，这时候的内联是有稳定前提保障的。
• 如果遇到虚方法，则会向 CHA 查询此方法在当前程序下是否有多个目标版本可供选择，
  • 如果查询结果只有一个版本，那也可以进行内联，不过这种内联就属于激进优化，需要预留一个 “逃生门”（Guard 条件不成立时的 Slow Path），称为守护内联（Guarded Inlining）。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接收者的继承关系发生变化的类，那这个内联优化的代码就可以一直使用下去。但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。
  • 如果向 CHA 查询出来的结果是多个版本的目标方法可供选择，则编译器还将会进行最后一次努力，使用内联缓存（Inline Cache）来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存状态为空，当第一次调用发生后，缓存记录下方法接收者的版本信息，并且每次进行方法调用时都比较接收者版本，如果以后进来的每次调用的方法接收者版本都是一样的，那这个内联还可以一直用下去。如果发生了方法接收者不一致的情况，就说明程序真正使用了虚方法的多态特性，这时才会取消内联，查找虚方法表进行方法分派。

所以说，在许多情况下虚拟机进行的内联都是一种激进优化，激进优化的手段在高性能的商用虚拟机中很常见，除了内联之外，对于出现概率很小（通过经验数据或解释器收集到的性能监控信息确定概率大小）的隐式异常、使用概率很小的分支等都可以被激进优化 “移除”，如果真的出现了小概率事件，这时才会从 “逃生门” 回到解释状态重新执行。

逃逸分析

逃逸分析（Escape Analysis）是目前 Java 虚拟机中比较前沿的优化技术，它与类型继承关系分析一样，并不是直接优化代码的手段，而是为其他优化手段提供依据的分析技术。
逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸。甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。

如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到这个对象，则可能为这个变量进行一些高效的优化，如下所示。

• 栈上分配（Stack Allocation）：Java 虚拟机中，在 Java 堆上分配创建对象的内存空间几乎是 Java 程序员都清楚的常识了，Java 堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就可以访问堆中存储的对象数据。虚拟机的垃圾收集系统可以回收堆中不再使用的对象，但回收动作无论是筛选可回收对象，还是回收和整理内存都需要耗费时间。如果确定一个对象不会逃逸出方法之外，那让这个对象在栈上分配内存，对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小很多。
• 同步消除（Synchronized Elimination）：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以消除掉。
• 标量替换（Scalar Replacement）：标量（Scalar）是指一个数据已经无法再分解成更小的数据来表示了，Java 虚拟机中的原始数据类型（int、long 等数值类型以及 reference 类型等）都不能再进一步分解，它们就可以称为标量。相对的，如果一个数据可以继续分解，那它就称作聚合量（Aggregate），Java 中的对象就是最典型的聚合量。**如果把一个 Java 对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。**如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的告诉寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。

第十二章　Java内存模型与线程

并发处理的广泛应用是Amdahl定律代替摩尔定律 [1] 成为计算机性能发展源动力的根本原因，也是人类压榨计算机运算能力的最有力武器。

概述

衡量一个服务性能的高低好坏，**每秒事务处理数（Transactions Per Second，TPS）**是重要的指标之一，它代表着一秒内服务端平均能响应的请求总数，而TPS值与程序的并发能力又有非常密切的关系。对于计算量相同的任务，程序线程并发协调得越有条不紊，效率自然就会越高；反之，线程之间频繁争用数据，互相阻塞甚至死锁，将会大大降低程序的并发能力。

硬件的效率与一致性

将运算需要使用的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处
理器就无须等待缓慢的内存读写了。

缓存一致性（Cache Coherence）。在多路处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存（Main Memory），这种系统称为共享内存多核系统（Shared Memory Multiprocessors System）

“内存模型”一词，它可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机器可以拥有不一样的内存模型，而Java虚拟机也有自己的内存模型，并且与这里介绍的内存访问操作及硬件的缓存访问操作具有高度的可类比性。

Java内存模型

主内存与工作内存

Java内存模型的主要目的是定义程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。（只关注虚拟机对于变量在内存中的存取）

主内存主要对应于Java堆中的对象实例数据部分

工作内存则对应于虚拟机栈中的部分区域

内存间交互操作

一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存这一类的实现细节

操作

8种操作来完成。Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。

• lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
• unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量
  才可以被其他线程锁定。
• read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以
  便随后的load动作使用。
• load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的
  变量副本中。
• use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚
  拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
• assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收的值赋给工作内存的变量，
  每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
• store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随
  后的write操作使用。
• write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的
  变量中。

规则

• 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内
  存不接受，或者工作内存发起回写了但主内存不接受的情况出现。
• 不允许一个线程丢弃它最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回
  主内存。
• 不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存
  中。
• 一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或
  assign）的变量，换句话说就是对一个变量实施use、store操作之前，必须先执行assign和load操作。
• 一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执
  行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
• 如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量
  前，需要重新执行load或assign操作以初始化变量的值。
• 如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个
  被其他线程锁定的变量。
• 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。

对于volatile型变量的特殊规则

一个变量被定义成volatile之后，它将具备两项特性：

• 第一项是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。

由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁
（使用synchronized、java.util.concurrent中的锁或原子类）来保证原子性：

总体来说，需要必须同时满足下面两个条件时才能保证并发环境的线程安全：

（1）对变量的写操作不依赖于当前值（比如 i++），或者说是单纯的变量赋值（boolean flag = true）、只要一个线程可以进行修改值，其他线程只是用来读取

（2）该变量没有包含在具有其他变量的不变式中，也就是说，不同的volatile变量之间，不能互相依赖。只有在状态真正独立于程序内其他内容时才能使用volatile

使用volatile变量的第二个语义是禁止指令重排序优化

在访问volatile 变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此volatile变量是一种比sychronized关键字更轻量级的同步机制。volatile适合这种场景：一个变量被多个线程共享，线程直接给这个变量赋值。

当对非volatile 变量进行读写的时候，每个线程先从内存拷贝变量到CPU缓存中。如果计算机有多个CPU，每个线程可能在不同的CPU上被处理，这意味着每个线程可以拷贝到不同CPU cache中。而声明变量是volatile的，JVM 保证了每次读变量都从内存中读，跳过CPU cache这一步。

指令重排序优化

指令1把地址A中的值加10

指令2把地址A中的值乘以2

指令3把地址B中的值减去3

这时指令1和指令2是有依赖的，它们之间的顺序不能重排——(A+10)**2与A*2+10显然不相等

指令3可以重排到指令1、2之前或者中间，只要保证处理器执行后面依赖到A、B值的操作时能获取正确的A和B值即可。

Map configOptions;
char[] configText;
// 此变量必须定义为volatile
volatile boolean initialized = false;
// 假设以下代码在线程A中执行
// 模拟读取配置信息，当读取完成后
// 将initialized设置为true,通知其他线程配置可用
configOptions = new HashMap();
configText = readConfigFile(fileName);
processConfigOptions(configText, configOptions);
initialized = true;
// 假设以下代码在线程B中执行
// 等待initialized为true，代表线程A已经把配置信息初始化完成
while (!initialized) {
sleep();
}
// 使用线程A中初始化好的配置信息
doSomethingWithConfig();

如果指令重排序优化会造成，赋值的语句会因为优化导致提前运行，这样另一个线程就会提前读到这个true

原子性、可见性与有序性

1.原子性（Atomicity）

基本数据类型的访问、读写都是具备原子性的

2.可见性（Visibility）

可见性就是指当一个线程修改了共享变量的值时，其他线程能够立即得知这个修改。

Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此。

synchronized和final。同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）”这条规则获得的。

被final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把“this”的引用传递出去（this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那么在其他线程中就能看见final字段的值。

3.有序性（Ordering）

如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。

volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。

先行发生原则

“先行发生”（Happens-Before）-判断数据是否存在竞争，线程是否安全的非常有用的手段。

先行发生是Java内存模型中定义的两项操作之间的偏序关系，比如说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。

这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来，则它们就没有顺序性保障，虚拟机可以对它们随意地进行重排序。

• 程序次序规则（Program Order Rule）：在一个线程内，按照控制流顺序，书写在前面的操作先行
  发生于书写在后面的操作。注意，这里说的是控制流顺序而不是程序代码顺序，因为要考虑分支、循
  环等结构。
• 管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。这
  里必须强调的是“同一个锁”，而“后面”是指时间上的先后。
• volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量
  的读操作，这里的“后面”同样是指时间上的先后。
• 线程启动规则（Thread Start Rule）：Thread对象的start()方法先行发生于此线程的每一个动作。
• 线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检
  测，我们可以通过Thread::join()方法是否结束、Thread::isAlive()的返回值等手段检测线程是否已经终止
  执行。
• 线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread::interrupted()方法检测到是否有中断发生。
• 对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的
  finalize()方法的开始。
• 传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出
  操作A先行发生于操作C的结论。

Java与线程

并发不一定要依赖多线程（如PHP中很常见的多进程并发），但是在Java里面谈论并发，基本上都与线程脱不开关系。

线程和进程的区别

线程在进程下行进（单纯的车厢无法运行）

一个进程可以包含多个线程（一辆火车可以有多个车厢）

不同进程间数据很难共享（一辆火车上的乘客很难换到另外一辆火车，比如站点换乘）

同一进程下不同线程间数据很易共享（A车厢换到B车厢很容易）

进程要比线程消耗更多的计算机资源（采用多列火车相比多个车厢更耗资源）

进程间不会相互影响，一个线程挂掉将导致整个进程挂掉（一列火车不会影响到另外一列火车，但是如果一列火车上中间的一节车厢着火了，将影响到所有车厢）

进程可以拓展到多机，进程最多适合多核（不同火车可以开在多个轨道上，同一火车的车厢不能在行进的不同的轨道上）

进程使用的内存地址可以上锁，即一个线程使用某些共享内存时，其他线程必须等它结束，才能使用这一块内存。（比如火车上的洗手间）－“互斥锁”

进程使用的内存地址可以限定使用量（比如火车上的餐厅，最多只允许多少人进入，如果满了需要在门口等，等有人出来了才能进去）－“信号量”

线程的实现

实现线程主要有三种方式：

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

1.内核线程实现

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

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

2.用户线程实现

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

广义上来讲，一个线程只要不是内核线程，都可以认为是用户线程（User Thread，UT）的一种。

狭义上来讲，的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到用户线程的存在及如何实现的。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态

所有的线程操作都需要由用户程序自己去处理。线程的创建、销毁、切换和调度都是用户必须考虑的问题

3.混合实现

在这种混合实现下，既存在用户线程，也存在轻量级进程。用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统支持的轻量级进程则作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级进程来完成，这大大降低了整个进程被完全阻塞的风险。

Java线程调度

线程调度是指系统为线程分配处理器使用权的过程

• 协同式（Cooperative Threads-Scheduling）
  • 线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上去。
  • 切换操作对线程自己是可知的
• 抢占式（Preemptive Threads-Scheduling）
  • 每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定。

线程优先级

Java语言一共设置了10个级别的线程优先级（Thread.MIN_PRIORITY至Thread.MAX_PRIORITY）

在两个线程同时处于Ready状态时，优先级越高的线程越容易被系统选择执行。

我们并不能在程序中通过优先级来完全准确判断一组状态都为Ready的线程将会先执行哪一个

因为不同操作系统对与线程优先级的区别以及优化操作是不一致的。

状态转换

Java语言定义了6种线程状态，在任意一个时间点中，一个线程只能有且只有其中的一种状态，并且可以通过特定的方法在不同状态之间转换。

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

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

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

  • 没有设置Timeout参数的Object::wait()方法；
  • 没有设置Timeout参数的Thread::join()方法；
  • LockSupport::park()方法。

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

  • Thread::sleep()方法；
  • 设置了Timeout参数的Object::wait()方法；
  • 设置了Timeout参数的Thread::join()方法；
  • LockSupport::parkNanos()方法；
  • LockSupport::parkUntil()方法。

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

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

Java与协程

内核线程的切换开销是来自于保护和恢复现场的成本，即使是改换为用户线程也是不可避免这些必要的开销来保证运行的正常。

“协程”（Coroutine）

Java的解决方案

纤程（Fiber）

新并发模型下，一段使用纤程并发的代码会被分为两部分——

• 执行过程（Continuation）
  • 主要用于维护执行现场，保护、恢复上下文状态
• 调度器（Scheduler）
  • 负责编排所有要执行的代码的顺序。

第13章　线程安全与锁优化

线程安全

“当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那就称这个对象是线程安全的。”

我们可以将Java语言中各种操作共享的数据分为以下五类：

不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。

• 不可变

  • 只要一个不可变的对象被正确地构建出来（即没有发生this引用逃逸的情况），那其外部的可见状态永远都
    不会改变，永远都不会看到它在多个线程之中处于不一致的状态。“不可变”带来的安全性是最直接、最纯粹的。

• 绝对线程安全

方法调用端做额外的同步措施

尽管对象的方式上进行了同步加锁，但是在方法的调用端并不能保证数据的正确性。

public static void main(String[] args) {
        while (true) {
            for (int i = 0; i < 10; i++) {
                vector.add(i);
            }
            Thread removeThread = new Thread(new Runnable() {
                @Override
                public void run() {
                    synchronized (vector) {
                        for (int i = 0; i < vector.size(); i++) {
                            vector.remove(i);
                        }
                    }
                }
            });
            Thread printThread = new Thread(new Runnable() {
                @Override
                public void run() {
                    synchronized (vector) {
                        for (int i = 0; i < vector.size(); i++) {

                        }
                    }
                }
            });
            removeThread.start();
            printThread.start();
//不要同时产生过多的线程，否则会导致操作系统假死
            while (Thread.activeCount() > 20) ;
        }
    }

上述代码当中调用端使用的时候会发现size（）的问题，因为在不同线程里面读到的数据是不同的。以致于但想删除一个数时，这个数已经被删除过了。

• 相对线程安全-通常意义下的线程安全

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

• 线程兼容

可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用。

线程对立是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用代码。

线程安全的实现方法

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

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

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

---

最基本的互斥同步手段就是synchronized关键字

synchronized关键字经过Javac编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。

在执行monitorenter指令时，首先要去尝试获取对象的锁。

• 如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行monitorexit指令时会将锁计数器的值减一。
  • 一旦计数器的值为零，锁随即就被释放了。
• 如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。

产生问题：

在这个锁为释放之前，会导致后续的线程调用堵塞。因为synchronized是会一直等到该线程解锁。

使用lock（）以及unlock（）进行人为的加锁解锁

重入锁（ReentrantLock）是Lock接口最常见的一种实现

高级功能：

• 等待可中断：当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待

• 公平锁：多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁

• 锁绑定多个条件：一个ReentrantLock对象可以同时绑定多个Condition对象。在synchronized中，锁对象的wait()跟它的notify()或者notifyAll()方法配合可以实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外添加一个锁

非阻塞同步

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

互斥同步属于一种悲观的并发策略，其总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题

基于冲突检测的乐观并发策略

通俗地说就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止。这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被称为非阻塞同步（Non-Blocking Synchronization），使用这种措施的代码也常被称为无锁（Lock-Free）编程。

CAS指令需要有三个操作数，分别是内存位置（在Java中可以简单地理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）。CAS指令执行时，当且仅当V符合A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断。

存在一个逻辑漏洞：如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然为A值，那就能说明它的值没有被其他线程改变过了吗？这是不能的，因为如果在这段期间它的值曾经被改成B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的**“ABA问题”**

无同步方案

要保证线程安全，也并非一定要进行阻塞或非阻塞同步，同步与线程安全两者没有必然的联系

同步只是保障存在共享数据争用时正确性的手段，如果能让一个方法本来就不涉及共享数据，那它自然就不需要任何同步措施去保证其正确性

可重入代码（Reentrant Code）

可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误，也不会对结果有所影响。

代码是否具备可重入性

如果一个方法的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。

线程本地存储（Thread Local Storage）

如果一段代码中所需要的数据必须与其他代码共享，那就看这些共享数据的代码是否能保证在同一个线程中执行。如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内–一个请求对应一个服务器线程

锁优化

自旋锁与自适应自旋

互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成

我们就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程。

自适应自旋

前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定

• 上一个线程成功获得，并且在运行当中，认为该次有较大几率获得，进行相对更长时间的自旋
• 成功次数不多，有可能直接放弃获得这个锁。

锁消除

如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须再进行。

//在编程时，看似未同步的程序
public String concatString(String s1, String s2, String s3) {
return s1 + s2 + s3;
}
//在javac转化后会变成
public String concatString(String s1, String s2, String s3) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
sb.append(s3);
return sb.toString();
}

StringBuffer.append()是一个同步块，锁住sb本身。但是发现当前变量只在concatString中出现，并没有对外进行逃逸，其他线程也没有访问到这个变量，因此即便这里有锁也会进行消除，忽略这个锁。

锁粗化

编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变少，即使存在锁竞争，等待锁的线程也能尽可能快地拿到锁。

如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体之中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗

如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部

轻量级锁

在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方为这份拷贝加了一个Displaced前缀，即Displaced Mark Word）

虚拟机将使用CAS操作尝试把对象的Mark Word更新为指向Lock Record的指针

• 如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后两个比特）将转变为“00”，表示此对象处于轻量级锁定状态。
• 如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。
  • 虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧
    • 如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了
    • 否则就说明这个锁对象已经被其他线程抢占了。
• 如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志的状态值变为“10”，此时Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态。

偏向锁