本文共 93371 字，大约阅读时间需要 311 分钟。
文章目录
第一章 走近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 Counter Register）：是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
- 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.对象的创建
虚拟机中，创建对象的步骤如下所示：- 虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
- 在类加载检查通过后，接下来虚拟机将为新生对象分配内存。为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。内存分配根据Java堆中的内存摆放，分为两种：
- 指针碰撞（Bump the Pointer）：如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。
- 空闲列表（Free List）：如果Java堆中内存并不是规整的，已使用的内存和空闲的内存相互交错，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。
除此之外，还要保证对象创建在虚拟机中是线程安全的（并发情况下）。解决这个问题有两种方案：
- 对分配内存空间的动作进行同步处理——实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性；
- 把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB）。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。虚拟机是否使用TLAB，可以通过 -XX:+/-UseTLAB参数来设定。
- 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（布包括对象头），如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。
- 接下来，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头（Object Header）之中。
- 一般来说（由字节码中是否跟随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）：根据对象存活周期的不同将内存划分为极快。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。
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文件的版本号、常量池、访问标志、类索引（还包括父类索引和接口索引集合）、字段表集合、方法表集合、属性表集合。 魔数
- 每个Class文件的头4个字节称为魔数（Magic Number）
- 唯一作用是用于确定这个文件是否为一个能被虚拟机接受的Class文件。
- Class文件魔数的值为0xCAFEBABE。如果一个文件不是以0xCAFEBABE开头，那它就肯定不是Java class文件。
很多文件存储标准中都使用魔数来进行身份识别，譬如图片格式，如gif或jpeg等在文件头中都存有魔数。使用魔术而不是使用扩展名是基于安全性考虑的——扩展名可以随意被改变!!!
Class文件的版本号
紧接着魔数的4个字节是Class文件版本号，版本号又分为：
- 次版本号(minor_version): 前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文件的资源从库
- 是Class文件结构中与其它项目关联最多的数据类型
- 是占用Class文件空间最大的数据项目之一
- 是在文件中第一个出现的表类型数据项目
由于常量池中常量的数量是不固定的，所以在常量池的入口需要放置一项u2类型的数据，代表常量池容量计数值(constant_pool_count)。
从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件事情：- 通过一个类的全限定名来获取定义此类的二进制字节流（并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等）；
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；
加载阶段和连接阶段（Linking）的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。
验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。 验证阶段大致会完成4个阶段的检验动作：- 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以魔术0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
- 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
- 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
- 符号引用验证：确保解析动作能正确执行。
验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：public static int value=123;
那变量value在准备阶段过后的初始值为0而不是123.因为这时候尚未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。
至于“特殊情况”是指：public static final int value=123，即当类字段的字段属性是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就是这个道理。
由于父类的()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。 ()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生产()方法。 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成()方法。但接口与类不同的是，执行接口的()方法不需要先执行父接口的()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的()方法。 虚拟机会保证一个类的()方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行()方法完毕。如果在一个类的()方法中有好事很长的操作，就可能造成多个线程阻塞，在实际应用中这种阻塞往往是隐藏的。package jvm.classload; public class DealLoopTest{ static class DeadLoopClass { static{ if(true){ System.out.println(Thread.currentThread()+"init DeadLoopClass"); while(true) { } } } } public static void main(String[] args) { Runnable script = new Runnable(){ public void run(){ System.out.println(Thread.currentThread()+" start"); DeadLoopClass dlc = new DeadLoopClass(); System.out.println(Thread.currentThread()+" run over"); } }; Thread thread1 = new Thread(script); Thread thread2 = new Thread(script); thread1.start(); thread2.start(); }} 运行结果：（即一条线程在死循环以模拟长时间操作，另一条线程在阻塞等待）
Thread[Thread-0,5,main] startThread[Thread-1,5,main] startThread[Thread-0,5,main]init DeadLoopClass
需要注意的是，其他线程虽然会被阻塞，但如果执行()方法的那条线程退出()方法后，其他线程唤醒之后不会再次进入()方法。同一个类加载器下，一个类型只会初始化一次。
将上面代码中的静态块替换如下：static { System.out.println(Thread.currentThread() + "init DeadLoopClass"); try { TimeUnit.SECONDS.sleep(10); } catch (InterruptedException e) { e.printStackTrace(); } } 运行结果：
Thread[Thread-0,5,main] startThread[Thread-1,5,main] startThread[Thread-1,5,main]init DeadLoopClass (之后sleep 10s)Thread[Thread-1,5,main] run overThread[Thread-0,5,main] run over
虚拟机规范严格规定了有且只有5中情况（jdk1.7）必须对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：
- 遇到new,getstatic,putstatic,invokestatic这失调字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
- 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
- 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
- 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
- 当使用jdk1.7动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic,REF_putstatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出触发其初始化。
开篇已经举了一个范例：通过子类引用付了的静态字段，不会导致子类初始化。
这里再举两个例子。- 通过数组定义来引用类，不会触发此类的初始化：（SuperClass类已在本文开篇定义）
public class NotInitialization{ public static void main(String[] args) { SuperClass[] sca = new SuperClass[10]; }} 运行结果：（无）
7. 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化：public class ConstClass{ static { System.out.println("ConstClass init!"); } public static final String HELLOWORLD = "hello world";} public class NotInitialization{ public static void main(String[] args) { System.out.println(ConstClass.HELLOWORLD); }} 运行结果：hello world
2.加载：被动引用和主动引用
主动引用：
(1) 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候，读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。 (2) 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。 (3) 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。 (4)当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类 (5)使用jdk1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄。并且这个方法句柄所对应的类没有进行过初始化。 只有上述五种情况会触发初始化，也称为对一个类进行主动引用，除此以外，所有其他方式都不会触发初始化，称为被动引用。 被动引用： （1）对于静态字段，只有直接定义这个字段的类才会被初始化,因此，通过子类来调用父类的静态字段，只会触发父类的初始化,但是这是要看不同的虚拟机的不同实现 （2）创建动作由字节码指令newarray触发,此时数组越界检查也会伴随数组对象的所有调用过程，越界检查并不是封装在数组元素访问的类中，而是封装在数组访问的xaload,xastore字节码指令中 （3）对常量ConstClass.value 的引用实际都被转化为NotInitialization类对自身常量池的引用，这两个类被编译成class后不存在任何联系3.类加载器和双亲委派模型
类与类加载器
类加载器只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。
对于任意一个类，都需要由类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。
即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。
双亲委派模型
类加载器分类
1、从Java虚拟机的角度来讲，只存在两种：（1） 启动类加载器：使用C++实现，是虚拟机自身的一部分。
（2） 所有其它的类加载器：由Java实现，独立于虚拟机外部，并且全部继承自抽象类：java.lang.ClassLoader。2、从Java开发人员的角度来看，绝大部分Java程序都会使用以下3种系统提供的来加载器：
（1） 启动类加载器：负责将存放在\lib目录中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar）类库加载到虚拟机内存中。
启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。
（2） 扩展类加载器：
负责加载\lib\ext目录中的所有类库，开发者可以直接使用扩展类加载器。
（3）应用程序类加载器（系统类加载器）：由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。
负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器。
如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
类加载器的双亲委派模型
双亲委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的一种类加载器实现方式。
双亲委派模型的工作过程
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一层次的类加载器都是如此，因此所有的加载请求，最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
双亲委派模型的优点
使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。
相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
双亲委派模型的实现
实现双亲委派模型的代码都集中在java.lang.ClassLoader的loadClass()方法之中：// protected synchronized Class loadClass(String name, boolean resolve) throws **ClassNotFoundException** { // First, check if the class has already been loaded // 首先，检查请求的类是否已经被加载过了 Class c = findLoadedClass(name); if (c == null) { try { if (parent != null) { // 调用父加载器的loadClass()方法 c = parent.loadClass(name, false); } else { // 若父加载器为空则默认使用启动类加载器作为父加载器（只有启动类加载器父类为null） c = findBootstrapClassOrNull(name); } } catch (**ClassNotFoundException** e) { // 如果父类加载器抛出ClassNotFoundException 说明父类加载器无法完成加载请求 // ClassNotFoundException thrown if class not found // from the non-null parent class loader } if (c == null) { // If still not found, then invoke findClass in order // to find the class. // 在父类加载器无法加载的时候再调用自身的findClass方法进行类加载 c = findClass(name); } } if (resolve) { resolveClass(c); } return c; } 4.双亲委派模型的破坏
双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前–即JDK1.2发布之前。由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则是JDK1.0时候就已经存在，面对已经存在 的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。为了向前兼容，JDK1.2之后的java.lang.ClassLoader添加了一个新的proceted方法findClass()，在此之前，用户去继承java.lang.ClassLoader的唯一目的就是重写loadClass()方法，因为虚拟在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法的唯一逻辑就是去调用自己的loadClass()。JDK1.2之后已不再提倡用户再去覆盖loadClass()方法，应当把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里，如果父类加载器加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派模型的。
双亲委派模型的第二次“被破坏”是这个模型自身的缺陷所导致的，双亲委派模型很好地解决了各个类加载器的基础类统一问题(越基础的类由越上层的加载器进行加载)，基础类之所以被称为“基础”，是因为它们总是作为被调用代码调用的API。但是，如果基础类又要调用用户的代码，那该怎么办呢。 这并非是不可能的事情，一个典型的例子便是JNDI服务，它的代码由启动类加载器去加载(在JDK1.3时放进rt.jar)，但JNDI的目的就是对资源进行集中管理和查找，它需要调用独立厂商实现部部署在应用程序的classpath下的JNDI接口提供者(SPI, Service Provider Interface)的代码，但启动类加载器不可能“认识”之些代码，该怎么办？ 为了解决这个困境，Java设计团队只好引入了一个不太优雅的设计：线程上下文件类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个；如果在应用程序的全局范围内都没有设置过，那么这个类加载器默认就是应用程序类加载器。了有线程上下文类加载器，JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型，但这也是无可奈何的事情。Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI,JDBC,JCE,JAXB和JBI等。 双亲委派模型的第三次“被破坏”是由于用户对程序的动态性的追求导致的，例如OSGi的出现。在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为网状结构第八章 虚拟机字节码执行引擎
1.栈帧
栈帧（Stack Frame） 是用于虚拟机执行时方法调用和方法执行时的数据结构，它是虚拟栈数据区的组成元素。每一个方法从调用到方法返回都对应着一个栈帧入栈出栈的过程。
每一个栈帧在编译程序代码的时候所需要多大的局部变量表，多深的操作数栈都已经决定了，并且写入到方发表的 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 就可以交给其他变量使用。这种机制有时候会影响垃圾回收行为。
考虑下面两段代码（需加上 -verbose:gc参数）：
代码一：
public static void main(String[] args){ { byte[] placeholder = new byte[64*1024*1024]; } System.gc(); } 运行结果：
[GC 602K->378K(15872K), 0.0603803 secs][Full GC 378K->378K(15872K), 0.0323107 secs][Full GC 66093K->65914K(81476K), 0.0074124 secs]
代码二：
public static void main(String[] args){ { byte[] placeholder = new byte[64*1024*1024]; } int a = 0; System.gc(); } 运行结果：
[GC 602K->378K(15872K), 0.0018270 secs][Full GC 378K->378K(15872K), 0.0057871 secs][Full GC 66093K->378K(81476K), 0.0054067 secs]
分析：通过结果可以知道，代码一和代码二内的 placeholder 变量在 System.gc() 执行后理应被回收了，可是结果却是只有代码二被回收了，这是为什么呢？
答： 这是因为代码一中 placeholder 虽然离开了作用域，但之后没有任何局部变量对其进行读写，也就是说其占用的 Slot 没有被复用，也就是说 placeholder 占用的内存仍然有引用指向它，因而它没有被回收。而代码二中的变量a由于复用了 placeholder 的 Slot ，导致 placeholder 引用被删除，因此占用的内存空间被回收
《Practical Java》一书中把”不使用的对象应手动赋值为 null “作为一条推荐的编码规则，这并不是一个完全没有意义的操作。但是不应该对 赋 null 值有过多的依赖，主要有两点原因：
从编码的角度来讲，用恰当的变量作用域来控制变量的回收才是最优雅的解决方法。
从执行角度将，使用赋值 null 的操作优化内存回收是建立在对字节码执行引擎概念模型基础上的，但是概念模型与实际执行模型可能完全不同。在使用解释器执行时，通常离概念模型还比较接近，但是一旦经过JIT 编译为本地代码才是虚拟机执行代码的主要方式，赋 null 值在JIT编译优化之后会被完全消除，这时候赋 null 值是完全没有意义的。（其实，上面代码一在 JIT 编译为本地代码之后，gc() 之后内存也会被自动回收）2、操作数栈
操作数栈（Operand Stack）也常称为操作栈，是一个后入先出栈。在Class 文件的Code 属性的 max_stacks 指定了执行过程中最大的栈深度。Java 虚拟机的解释执行引擎称为”基于栈的执行引擎“，这里的栈就是指操作数栈。方法执行中进行算术运算或者是调用其他的方法进行参数传递的时候是通过操作数栈进行的。
在概念模型中，两个栈帧是相互独立的。但是大多数虚拟机的实现都会进行优化，令两个栈帧出现一部分重叠。令下面的部分操作数栈与上面的局部变量表重叠在一块，这样在方法调用的时候可以共用一部分数据，无需进行额外的参数复制传递。
3、动态连接
每个栈帧都包含一个执行运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态连接（Dynamic Linking）。Class 文件中存放了大量的符号引用，字节码中的方法调用指令就是以常量池中指向方法的符号引用作为参数。这些符号引用一部分会在类加载阶段或第一次使用时转化为直接引用，这种转化称为静态解析。另一部分将在每一次运行期间转化为直接引用，这部分称为动态连接。
4、方法返回地址
当一个方法开始执行以后，只有两种方法可以退出当前方法：当执行遇到返回指令，会将返回值传递给上层的方法调用者，这种退出的方式称为正常完成出口（Normal Method Invocation Completion），一般来说，调用者的PC计数器可以作为返回地址。
当执行遇到异常，并且当前方法体内没有得到处理，就会导致方法退出，此时是没有返回值的，称为异常完成出口（Abrupt Method Invocation Completion），返回地址要通过异常处理器表来确定。 当方法返回时，可能进行3个操作：恢复上层方法的局部变量表和操作数栈
把返回值压入调用者调用者栈帧的操作数栈 调整 PC 计数器的值以指向方法调用指令后面的一条指令5、附加信息
虚拟机规范并没有规定具体虚拟机实现包含什么附加信息，这部分的内容完全取决于具体实现。在实际开发中，一般会把动态连接，方法返回地址和附加信息全部归为一类，称为栈帧信息。2.解析（resolution）
所有方法调用中的目标方法在Class文件里面都是一个常量池中的引用，在类加载的解析阶段，会将其中的一部分符号引用转化为直接引用。这种解析能成立的前提是：方法在程序真正执行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。换句话说，调用目标在程序代码写好、编译器进行编译时就必须确定下来，这类方法的调用称为解析。
在Java语言中符合“编译期可知，运行期不可变”这个要求的方法，主要包括静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问，这两种方法各自的特点决定了他们不可能通过继承或别的方式重写其他版本，因此他们适合在类加载阶段进行解析。
静态方法、私有方法、实例构造器、父类方法。这些方法称为非虚方法，它们在类加载的时候就会把符号引用解析为该方法的直接引用。与之相反，其他方法称为虚方法（除去final方法）
- invokestatic：调用静态方法。
- invokespecial：用于调用构造器方法、私有方法、父类方法。
- invokevirtual：用于调用类的所有虚方法。
- invokeinterface：用于调用接口方法。
- invokedynamic：先在运行时动态解析出调用点限定符所引用的方法，然后再执行该方法，invokedynamic指令的分派逻辑是由用户所设定的引导方法决定的。
解析调用一定是个静态的过程，在编译期间就完全确定，在类装载的解析阶段就会把涉及的符号引用全部转变为可确定的直接引用，不会延迟到运行期再去完成。
下面我们看一段代码：/** * 方法静态解析演示 * * @author cxt */public class StaticResolution { //静态方法 public static void say1() { } //final方法 public final void say2() { } //一般虚方法 public void say3() { } //重载say3 public void say3(int i) { } public static void main(String[] args) { StaticResolution.say1(); StaticResolution sr = new StaticResolution(); sr.say2(); sr.say3(); sr.say3(10); } } 我们看一下字节码：
// class version 51.0 (51)// access flags 0x21public class StaticResolution { // compiled from: StaticResolution.java // access flags 0x1 public () : void L0 LINENUMBER 8 L0 ALOAD 0: this INVOKESPECIAL Object. () : void RETURN L1 LOCALVARIABLE this StaticResolution L0 L1 0 MAXSTACK = 1 MAXLOCALS = 1 // access flags 0x9 public static say1() : void L0 LINENUMBER 12 L0 RETURN MAXSTACK = 0 MAXLOCALS = 0 // access flags 0x11 public final say2() : void L0 LINENUMBER 17 L0 RETURN L1 LOCALVARIABLE this StaticResolution L0 L1 0 MAXSTACK = 0 MAXLOCALS = 1 // access flags 0x1 public say3() : void L0 LINENUMBER 22 L0 RETURN L1 LOCALVARIABLE this StaticResolution L0 L1 0 MAXSTACK = 0 MAXLOCALS = 1 // access flags 0x1 public say3(int) : void L0 LINENUMBER 26 L0 RETURN L1 LOCALVARIABLE this StaticResolution L0 L1 0 LOCALVARIABLE i int L0 L1 1 MAXSTACK = 0 MAXLOCALS = 2 // access flags 0x9 public static main(String[]) : void L0 LINENUMBER 29 L0 INVOKESTATIC StaticResolution.say1 () : void L1 LINENUMBER 30 L1 NEW StaticResolution DUP INVOKESPECIAL StaticResolution. () : void ASTORE 1 L2 LINENUMBER 31 L2 ALOAD 1: sr INVOKEVIRTUAL StaticResolution.say2 () : void L3 LINENUMBER 32 L3 ALOAD 1: sr INVOKEVIRTUAL StaticResolution.say3 () : void L4 LINENUMBER 33 L4 ALOAD 1: sr BIPUSH A // '\n' (LF) INVOKEVIRTUAL StaticResolution.say3 (int) : void L5 LINENUMBER 34 L5 RETURN L6 LOCALVARIABLE args String[] L0 L6 0 LOCALVARIABLE sr StaticResolution L2 L6 1 MAXSTACK = 2 MAXLOCALS = 2} 我们看一下main方法的字节码，可知say1方法是static方法，所有它的方法调用指令为invokestatic，再者他是一个静态解析过程，我们可以从字节码清除地看出来**StaticResolution.say1 ()**字样。
say2()是一个final方法，不可以重载，重写，虽然是一个invokevirtual方法但是他也是静态解析的。
say3()也是invokevirtual方法，但也是静态解析的。
say3(int i)是say3()的一个重载方法，但是重载是在编译期就确定到底要调用哪个方法，所以也是静态解析。
3.分派（dispatch）
静态分派
public class StaticDispatch { static abstract class Human{ } static class Man extends Human{ } static class Woman extends Human{ } public static void sayHello(Human guy){ System.out.println("hello,guy!"); } public static void sayHello(Man guy){ System.out.println("hello,gentlemen!"); } public static void sayHello(Woman guy){ System.out.println("hello,lady!"); } public static void main(String[] args) { Human man=new Man(); Human woman=new Woman(); sayHello(man); sayHello(woman); }} 输出：
hello,guy! hello,guy!Human man=new Man();
我们把“Human”称为变量的静态类型，后面的“Man”称为变量的实际类型，静态类型和实际类型在程序中都可以发生一些变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型在编译器可知；而实际类型变化的结果在运行期才确定，编译器在编译期并不知道一个对象的实际类型是什么。
Human man=new Man(); sayHello(man); sayHello((Man)man);//类型转换，静态类型变化，我们知道转型后的静态类型一定是Man man=new Woman(); //实际类型变化,实际类型却是不确定的 sayHello(man); sayHello((Woman)man);//类型转换，静态类型变化
输出：
hello,guy! hello,gentlemen! hello,guy! hello,lady!编译器在重载时是通过参数的静态类型而不是实际类型作为判定的依据。并且静态类型在编译期可知，因此，编译阶段，Javac编译器会根据参数的静态类型决定使用哪个重载版本。
所有依赖静态类型来定位方法执行版本的分派动作称为静态分派。静态分派的典型应用就是方法重载。
静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机来执行的，而是由编译器来完成。
但是，字面量没有显示的静态类型，它的静态类型只能通过语言上的规则去理解和推断。
public class LiteralTest { /**/ public static void sayHello(char arg){ System.out.println("hello char"); } 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 main(String[] args) { sayHello('a'); } } 输出：
hello char将重载方法从上向下依次注释，将会得到不同的输出。
如果编译器无法确定要自定转型为哪种类型，会提示类型模糊，拒绝编译。
import java.util.Random; public class LiteralTest { /**/ public static void sayHello(String arg){ //新增重载方法 System.out.println("hello String"); } public static void sayHello(char arg){ System.out.println("hello char"); } 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 main(String[] args) { Random r=new Random(); String s="abc"; int i=0; sayHello(r.nextInt()%2!=0?s:i);//编译错误 sayHello(r.nextInt()%2!=0?'a':false);//编译错误 } } 动态分派
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(); }} 输出：
man say hello! woman say hello! woman say hello!显然，这里不可能再根据静态类型来决定，因为静态类型同样是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语言方法重写的本质。我们把这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。
虚拟机动态分派的实现
前面介绍的分派过程，作为对虚拟机概念模型的解析基本上已经足够了，它已经解决了虚拟机在分派中"会做什么"这个问题。
但是，虚拟机”具体是如何做到的“，可能各种虚拟机实现都会有些差别。
由于动态分派是非常频繁的动作，而且动态分派的方法版本选择过程需要运行时在类的方法元数据中搜索合适的目标方法，因此虚拟机的实际实现中基于性能的考虑，大部分实现都不会真正的进行如此频繁的搜索。面对这种情况，最常用的”稳定优化“手段就是为类在方法区中建立一个虚方法表（Virtual Method Table，也称为vtable），使用虚方法表索引来代替元数据查找以提高性能。
虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方法表里面的地址入口和父类相同方法的地址入口是一致的，都是指向父类的实际入口。如果子类中重写了这个方法，子类方法表中的地址将会替换为指向子类实际版本的入口地址。
为了程序实现上的方便，具有相同签名的方法，在父类、子类的虚方法表中具有一样的索引序号，这样当类型变换时，仅仅需要变更查找的方法表，就可以从不同的虚方法表中按索引转换出所需要的入口地址。
方法表一般在类加载阶段的连接阶段进行初始化，准备了类的变量初始值后，虚拟机会把该类的方法表也初始化完毕。
4.基于栈的解释器执行过程
解释执行
Java被人定位于“解释执行”的语言。在jdk1.0时，定义还算准确，但后来当主流虚拟机中都包含了即使编译器后，Class文件中的代码 大部分的程序代码到物理机的目标代码或虚拟机能执行的指令集之前，都需要经过以下过程：
在Java中，Javac编译器完成了程序代码经过词法分析、语法分析到抽象语法树，再遍历语法树生成线性的字节码指令流的过程，因为这一部分是在Java虚拟机之外进行的，而解释器在虚拟机的内部，所以Java程序的编译就是半独立的。
基于栈的指令集架构
Java编译器输出的指令流，基本上是一种基于栈的指令集架构，指令流中的指令大部分都是零地址指令，他们依赖操作数栈进行工作。基于栈的指令集主要优点就是可移植，使用栈架构指令集，用户程序不会直接使用寄存器，就可以由虚拟机实现来自行决定把一些访问最频繁的数据放到寄存器中以获取尽量好的的性能。
栈架构指令集的主要缺点是执行速度相对来说会稍慢一些，主要是因为指令数量和内存访问导致的。
基于栈指令的解释器执行过程
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指的是推送的常量值。
iload_1指令是将局部变量表第1个Slot中的整型值复制到操作数栈顶。
iload_2指令同样是将第2个Slot中整型值复制到操作数栈顶。
iload_3是将局部变量表中第3个Slot入栈，此时操作数栈中为两个整数。
上面的过程只是一种概念模型，虚拟机最终会对执行过程进行一些优化来提高性能。主要是虚拟机中解析器和即使编译器都会对输入的字节码进行优化
第九章 类加载及执行子系统的案例与实战
一. 案例分析
1. 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 项。2. OSGI：灵活的类加载器架构
在OSGI里面，Bundle之间的依赖关系从传统的上层模块依赖底层模块转变为平级模块之间的依赖。 OSGI特点，要归功于它灵活的类加载架构。OSGI的Bundle类加载器之间只有规则，没有固定的委派关系。3. 字节码生成技术与动态代理的实现
相信许多Java开发人员都是用过动态代理，例如 java.lang.reflect.Proxy 或实现过 java.lang.reflect.InvocationHandler 接口。 下面一个例子，在方法前面打印一句“welcome”。public interface IHello { void sayHello(); void sayHi();}public class Hello implements IHello{ @Override public void sayHello() { System.out.println("hello world"); } @Override public void sayHi() { System.out.println("hi world"); }}public 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 { System.out.println("welcome"); return method.invoke(originalObj,args); }}public class DynamicProxyTest { public static void main(String[] args) { IHello hel = (IHello) new DynamicProxy().bind(new Hello()); hel.sayHello(); hel.sayHi(); }} 运行结果
welcomehello worldwelcomehi world
4. Retrotranslator：跨越JDK版本
把JDK1.5 中编写的代码放到 JDK1.4 或 1.3 的环境去部署使用。为了解决这个问题，一种名为“Java逆转移植”的工具（Java Backporting Tools）应运而生，Retrotranslator 是这类工具中较为出色的一个。二. 实战：自己动手实现远程执行功能
我们将使用前面学到的关于类加载及虚拟机执行子系统的知识去实现在服务端执行临时代码的能力。
1. 目标 首先，在实现“在服务端执行临时代码”这个需求之前，先明确一下本次实战的具体目标，我们希望最终的产品是这样的：- 不依赖JDK版本，能在目前普遍使用的JDK中部署。
- 不改变原有服务端程序的部署，不依赖任何第三方类库。
- 不侵入原有程序，即无需改动原程序的任何代码，也不会对原有程序运行带来任何影响。
- “临时代码”应当具备足够的自由度，不需要依赖热定的类或实现特定的接口。
- “临时代码”的执行结果能返回到客户端，执行结果可以包括程序中输出的信息及抛出的异常等。
2. 思路
在程序实现的过程中，我们需要解决以下3个问题：- 如何编译提交到服务器的Java代码？
- 如何执行编译后的Java代码？
- 如何收集Java代码的执行结果？
3. 实现
第一个类用于实现“同一个类的代码可以被多次加载”这个需求，具体代码如下：package org.swift.framework.RemotePlugin;/** * 为了多次载入执行类而加入的加载器 * 把defineClass方法开放出来，只有外部显式调用的时候才会使用到loadByte方法 * 由虚拟机调用时，仍然按照原有的双亲委派规则使用loadClass方法进行加载 * zww */public class HotSwapClassLoader extends ClassLoader { public HotSwapClassLoader() { super(HotSwapClassLoader.class.getClassLoader()); //使用父类的加载器 } public Class loadByte(byte[] classByte) { return defineClass(null, classByte, 0, classByte.length); }} HotSwapClassLoader 所做的事情仅仅是公开父类中的defineClass（） ，这个类加载器的类查找范围与它的父类加载器是完全一致的。
第二个类实现将 java.lang.System 替换为我们自己定义的HackSystem 类的过程，它直接修改符合Class 文件格式的 byte[] 数组中的常量池部分，将常量池中指定内容的 CONSTANT_Utf8_info 常量替换为新的字符串。
package org.swift.framework.RemotePlugin;/** * 修改Class文件，暂时只提供修改常量池常量的功能 */public class ClassModifier { /** * Class文件中常量池的起始偏移 */ private static final int CONSTANT_POOL_COUNT_INDEX = 8; /** * CONSTANT_Utf8_info 常量的tag标志 */ private static final int CONSTANT_Utf8_info = 1; /** * 常量池中11种常量所占的长度，CONSTANT_Utf8_info型常量除外，因为不是定长的 */ private static final int[] CONSTANT_ITEM_LENGTH = { -1, -1, -1, 5, 5, 9, 9, 3, 3, 5, 5, 5, 5}; private static final int u1 = 1; private static final int u2 = 2; private byte[] classByte; public ClassModifier(byte[] classByte) { this.classByte = classByte; } public byte[] modifyUTF8Constant(String oldStr, String newStr) { int cpc = getConstantPoolCount(); //常量的数量 int offset = CONSTANT_POOL_COUNT_INDEX + u2; //CONSTANT_POOL 起始位置 for (int i = 0; i < cpc; i++) { int tag = ByteUtils.bytes2Int(classByte, offset, u1); //获取常量型 if (tag == CONSTANT_Utf8_info) { //判断常量型类型是否是CONSTANT_Utf8_info int len = ByteUtils.bytes2Int(classByte, offset + u1, u2); offset += (u1 + u2); String str = ByteUtils.bytes2String(classByte, offset, len); if (str.equalsIgnoreCase(oldStr)) { byte[] strBytes = ByteUtils.string2Bytes(newStr); byte[] strLen = ByteUtils.int2Bytes(newStr.length(), u2); classByte = ByteUtils.bytesReplace(classByte, offset - u2, u2, strLen); classByte = ByteUtils.bytesReplace(classByte, offset, len, strBytes); return classByte; } else { offset += len; } } else { offset += CONSTANT_ITEM_LENGTH[tag]; } } return classByte; } /** * 获取常量池中常量的数量 * @return */ private int getConstantPoolCount() { return ByteUtils.bytes2Int(classByte, CONSTANT_POOL_COUNT_INDEX, u2); }} ByteUtils 工具的实现：
package org.swift.framework.RemotePlugin;public class ByteUtils { public static int bytes2Int(byte[] b, int start, int len) { int sum = 0; int end = start + len; for (int i = start; i < end; i++) { // 因为当系统检测到byte可能会转化成int或者说byte与int类型进行运算的时候， // 就会将byte的内存空间高位补1（也就是按符号位补位）扩充到32位 // 如果b[i]为负数时：例如：10000001 & 11111111 ==》 1111111111111111111111111 10000001 & 11111111 = 000000000000000000000000 10000001 int n = ((int)b[i]) & 0xff; n <<= (--len) * 8; sum = n + sum; } return sum; } public static byte[] int2Bytes(int value, int len) { byte[] b = new byte[len]; for (int i = 0; i < len; i++) { b[len - i - 1] = (byte) ((value >> 8 * i) & 0xff); } return b; } public static String bytes2String(byte[] b, int start, int len) { return new String(b, start, len); } public static byte[] string2Bytes(String str) { return str.getBytes(); } public static byte[] bytesReplace(byte[] originalBytes, int offset, int len, byte[] replaceBytes) { // || |~offset| ~len || || byte[] newBytes = new byte[originalBytes.length - len + replaceBytes.length]; System.arraycopy(originalBytes, 0, newBytes, 0, offset); //替换位置之前 System.arraycopy(replaceBytes, 0, newBytes, offset, replaceBytes.length); //替换的位置 System.arraycopy(originalBytes, offset + len, newBytes, offset + replaceBytes.length, originalBytes.length - offset -len); //替换的位置之后 return newBytes; }} 经过ClassModifier 处理后的 byte[] 数据才会传给 HotSwapClassLoader.loadByte() 方法进行类加载
最后一个类就是前面提到的代替 java.lang.System 的 HackSystem ，这个类除了把 out 和 err 两个静态变量修改了，其他都来自于 System类的 public方法。
package org.swift.framework.RemotePlugin;import java.io.ByteArrayOutputStream;import java.io.InputStream;import java.io.PrintStream;/** * 为JavaClass 劫持 java.lang.System 提供支持 * 除了 out 和 err 外，其余的都直接转发给 System 处理 */public class HackSystem { public final static InputStream in = System.in; private static ByteArrayOutputStream buffer = new ByteArrayOutputStream(); public final static PrintStream out = new PrintStream(buffer); public final static PrintStream err = out; public static String getBufferString() { return buffer.toString(); } public static void clearBuffer() { buffer.reset(); } public static void setSecurityManager(final SecurityManager s) { System.setSecurityManager(s); } public static SecurityManager getSecurityManager() { return System.getSecurityManager(); } public static long currentTimeMillis() { return System.currentTimeMillis(); } //下面所有的方法都与 java.lang.System 的名称一样 //实现都是字节调System的对应方法 //因版面原因，省略其他方法} 至此，4个支持类已经讲解完毕，我们来看看最后一个类 JavaClassExecuter ，它是提供外部调用的入口
package org.swift.framework.RemotePlugin;import java.lang.reflect.InvocationTargetException;import java.lang.reflect.Method;/** * JavaClass 执行工具 */public class JavaClassExecuter { /** * 执行外部传过来的代表一个Java类的byte数组 * 将输入类byte数组中代表 java.lang.System的CONTANT_Utf8_info常量修改为劫持后的HackSystem类 * 执行方法为该类的 main 方法，输出结构为该类向System.out/err输出的信息 * @param classByte * @return */ public static String execute(byte[] classByte) { HackSystem.clearBuffer(); ClassModifier classModifier = new ClassModifier(classByte); //修改Class字节码，把HackSystem 替代 System byte[] modiBytes = classModifier.modifyUTF8Constant("java.lang.System", "org.swift.framework.RemotePlugin.HackSystem"); HotSwapClassLoader loader = new HotSwapClassLoader(); Class clazz = loader.loadByte(modiBytes); try { //调用其main方法 Method method = clazz.getMethod("main", new Class[] { String[].class}); method.invoke(null, new String[] { null}); } catch (Exception e) { e.printStackTrace(HackSystem.out); } return HackSystem.getBufferString(); }} 4. 验证
任意写一个Java类，只需要向外System.out 信息即可，同事放到指定路径 C://TestClass.class ,然后建立一个Jsp 文件，在浏览器可以看到这个类的运行结果。package org.swift.framework.RemotePlugin;public class TestClass { public static void main(String[] args) { System.out.println("this is a test class"); }}<%@ page import="java.lang.*" %><%@ page import="java.io.*" %><%@ page import="org.swift.framework.RemotePlugin.*" %><% InputStream is = new FileInputStream("C:/TestClass.class"); byte[] b = new byte[is.available()]; is.read(b); is.close(); out.println("");%> 其中主要需要学习的就是对 class文件的内容进行修改替换，并可以正常提供使用。
第十章 早期（编译期）优化
JVM编译器优化
JVM的编译器的种类：-
前端编译器：把.java变成.class的过程。如Sun的Javac,Eclipse JDT中的增量式编译器。
-
JIT编译器：把字节码转变成机器码的过程。
-
AOT编译器：静态提前编译，直接将*.java文件编译本地机器码的过程。
Javac的编译过程
Javac编译动作的入口是com.sun.tools.javac.main.JavaCompiler类
解析与填充符号
解析步骤由parseFiles()方法完成，包括了词法分析和语法分析两个过程。词法分析、语法分析
词法分析：将源代码的字符流转变成标记（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()方法不处理数据转型的关系。
条件编译
Java语言使用条件为常量的if语句，此代码中的if语句不同于其他Java代码，它在编译阶段就会被运行，生成的字节码之中只包含条件正确的部分。 Java语言中条件编译的实现，也是Java语言的一颗语法糖，根据布尔常量值的真假，编译器将会把分支中不成立的代码块消除掉，这是在解语法糖阶段实现的。第十一章 晚期（运行期）优化
概述
在部分的商用虚拟机（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） 编译器担任 “逃生门” 的角色），因此，在整个虚拟机执行架构中，解释器与编译器经常配合工作，如图 11-1 所示。
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 所示，请注意黑体字部分。C:\Users\mk>java -version java version "1.7.0_60" Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode) C:\Users\mk>java -Xint -version java version "1.7.0_60" Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, interpreted mode) C:\Users\mk>java -Xcomp -version java version "1.7.0_60" Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, compiled mode)
由于即时编译器编译本地代码需要占用程序运行时间，要编译出优化程度更高的代码，所花费的时间可能更长：而且想要编译出优化程度更高的代码，解释器可能还要替编译器收集性能监控信息，这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot 虚拟机还会逐渐启用分层编译（Tiered Compilation）的策略，分层编译的概念在 JDK 1.6 时期出现，后来一直处于改进阶段，最终在 JDK 的 Server 模式虚拟机中作为默认编译策略被开启。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：
- 第 0 层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第 1 层编译。
- 第 1 层，也称为 C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑。
- 第 2 层（或 2 层以上），一称为 C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。
实施分层编译后，Client Compiler 和 Server Compiler 将会同时工作，许多代码都可能会被多次编译，用 Client Compiler 获取更高的编译速度，用 Server Compiler 来获取更高的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。
编译对象与触发条件
上文中提到过，在运行过程中会被即时编译器编译的 “热点代码” 有两类，即：
- 被多次调用的方法。
- 被多次执行的循环体。
前者很好理解，一个方法被调用得多了，方法体内代码执行的次数自然就多，它成为 “热点代码” 是理所当然的。而后者则为了解决一个方法只被调用过一次或少量的几次，但是方法体内部存在循环次数较多的循环体内部存在循环次数较多的循环体的问题，这样循环次数较多的循环体的问题，这样循环体的代码也被重复执行多次，因此这些代码也应该认为是 “热点代码”。
对于第一种情况，由于是由方法调用触发的编译，因此编译器理所当然地会以整个方法作为编译对象，这种编译也是虚拟机中标准的 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来人为设定。当一个方法被调用时，会先检查该方法是否存在被 JIT 编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加 1，然后判断方法调用计数器与回边计数器值之和是否查过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。 如果不做任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法调用入口地址就会被系统自动改成新的，下一次调用该方法时就会使用已编译的版本。整个 JIT 编译的交互过程如图 11-2 所示。
如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（Counter Half Life Time）。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数 -XX: -UseCounterDecay 来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码。另外，可以使用 -XX: CounterHalfLifeTime 参数设置半衰周期的时间，单位是秒。 现在我们再来看看另一个计数器——回边计数器，它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为 “回边”（Back Edge）。显然，建立回边计数器统计的目的就是为了触发 OSR 编译。 关于回边计数器的阈值，虽然 HotSpot 虚拟机也提供了一个类似于方法调用计数器阈值 -XX: CompileThreshold 的参数 -XX: BackEdgeThreashold 供用户设置，但是当前的虚拟机实际上并未使用此参数，因此我们需要设置另外一个参数-XX: OnStackReplacePercentage 来简介调整回边计数器的阈值，其计算公式如下。 -
虚拟机运行在 Client 模式下，回边计数器阈值计算公式为：
方法调用计数器阈值（CompileThreshold）× OSR 比率（OnStackReplacePercentage）/ 100 其中 OnStackReplacePercentage 默认值为 933，如果都取默认值，那 Client 模式虚拟机的回边计数器的阈值为 13995。 -
虚拟机运行在 Server 模式下，回边计数器阈值的计算公式为：
方法调用计数器阈值（CompileThreshold）× （OSR 比率（OnStackReplacePercentage）- 解释器监控比率（InterpreterProfilePercentage）） / 100 其中 OnStackReplacePercentage 默认值为 140，InterpreterProfilePercentage 默认值为 33，如果都取默认值，那 Server 模式虚拟机回边计数器的阈值为 10700。 当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否有已经编译好的版本，如果有，它将会有限执行已编译的代码，否则就把回边计数器的值加 1，然后判断方法调用计数器与回边计数器之和是否超过回边计数器的阈值。当超过阈值的时候，将会提交一个 OSR 编译请求，并且把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果，整个执行过程如图 11-3 所示。
与方法计数器不同，回边计数器没有计数热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出的时候，它还会把方法计数器的值也调整到溢出状态，这样下次再进入该方法的时候就会执行标准编译过程。
最后需要提醒一点，图 11-2 和 图 11-3 都仅仅描述了 Client VM 的即时编译方式，对于 Server VM 来说，执行情况会比上面的描述更复杂一些。从理论上了解过编译对象和编译触发条件后，我们再从 HotSpot 虚拟机的源码中观察一下，在 MethodOop.hpp（一个 methodOop 对象代表了一个 Java 方法）中，定义了 Java 方法在虚拟机中的内存布局，如下所示：
// |------------------------------------------------------| // | header | // | klass | // |------------------------------------------------------| // | constMethodOop (oop) | // |------------------------------------------------------| // | methodData (oop) | // | interp_invocation_count | // |------------------------------------------------------| // | access_flags | // | vtable_index | // |------------------------------------------------------| // | result_index (C++ interpreter only) | // |------------------------------------------------------| // | method_size | max_stack | // | max_locals | size_of_parameters | // |------------------------------------------------------| // |intrinsic_id| flags | throwout_count | // |------------------------------------------------------| // | num_breakpoints | (unused) | // |------------------------------------------------------| // | invocation_counter | // | backedge_counter | // |------------------------------------------------------| // | prev_time (tiered only, 64 bit wide) | // | | // |------------------------------------------------------| // | rate (tiered) | // |------------------------------------------------------| // | code (pointer) | // | i2i (pointer) | // | adapter (pointer) | // | from_compiled_entry (pointer) | // | from_interpreted_entry (pointer) | // |------------------------------------------------------| // | native_function (present only if native) | // | signature_handler (present only if native) | // |------------------------------------------------------|
在这个内存布局中，一行长度为 32 bit，从中可以清楚地看到方法调用计数器和回边计数器所在的位置和长度。还有 from_compiled_entry 和 from_interpreted_entry 这两个方法的入口。
编译过程
在默认设置下，无论是方法调用产生的即时编译请求，还是 OSR 编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。用户可以通过参数 -XX: -BackgroundCompilation 来禁止后台编译，在禁止后台编译后，一旦达到 JIT 的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，知道编译过程完成后再开始执行编译器输出的本地代码。
那么在后台执行编译的过程中，编译器做了什么事情呢？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 编译器的优化过程，在稍后笔者将演示这个过程。查看及分析即时编译结果
一般来说，虚拟机的即时编译过程对用户程序是完成透明的，虚拟机通过解释执行代码还是编译执行代码，对于用户来说并没有什么影响（执行结果没有影响，速度上会有很大差别）。在大多数情况下用户也没有必要知道。但是虚拟机也提供了一些参数用来输出即时编译和某些优化手段（如方法内联）的执行状况，本节将介绍如何从外部观察虚拟机的即时编译行为。
本节中提到的运行参数有一部分需要 Debug 或 FastDebug 版虚拟机的支持，Product 版的虚拟机无法使用这部分参数。如果读者使用的是根据本书第 1 章的内容自己编译的 JDK，注意将 SKIP_DEBUG_BUILD 或 SKIP_FASTDEBUG_BUILD 参数设置为 false，也可以在 OpenJDK 网站上直接下载 FastDebug 班的 JDK（从 JDK 6u25 之后 Oracle 官网就不再提供 FastDebug 的 JDK 下载了）。注意，本节中所有的测试都基于代码清单 11-2 所示的 Java 代码。[java] view plain copypublic static final int NUM = 15000; public static int doubleValue(int i) { // 这个空循环用于后面演示 JIT 代码优化过程 for (int j = 0; j < 100000; j++); return i * 2; } public static long calcSum() { long sum = 0; for (int i = 1; i <= 100; i++) { sum += doubleValue(i); } return sum; } public static void main(String[] args) { for (int i = 0; i < NUM; i++) { calcSum(); } } 首先运行这段代码，并且确认这段代码是否触发了即时编译，要知道某个方法是否被编译过，可以使用参数 -XX: +PrintCompilation要求虚拟机在即时编译时将被编译成本地代码的方法名称打印出来，如代码清单 11-3 所示（其中带有 “%” 的输出说明是由回边计数器触发的 OSR 编译）。
[java] view plain copyVM option'+PrintCompilation' 310 1 java.lang.String：charAt（33 bytes） 329 2 org.fenixsoft.jit.Test：calcSum（26 bytes） 329 3 org.fenixsoft.jit.Test：doubleValue（4 bytes） 332 1%org.fenixsoft.jit.Test：main@5（20 bytes）
从代码清单 11-3 输出的确认信息中可以确认 main()、calcSum() 和 doubleValue() 方法已经被编译，我们还可以加上参数 -XX: +PrintInlinint 要求虚拟机输出方法内联信息，如代码清单 11-4 所示。
VM option'+PrintCompilation' VM option'+PrintInlining' 273 1 java.lang.String：charAt（33 bytes） 291 2 org.fenixsoft.jit.Test：calcSum（26 bytes） @9 org.fenixsoft.jit.Test：doubleValue inline（hot） 294 3 org.fenixsoft.jit.Test：doubleValue（4 bytes） 295 1%org.fenixsoft.jit.Test：main@5（20 bytes） @5 org.fenixsoft.jit.Test：calcSum inline（hot） @9 org.fenixsoft.jit.Test：doubleValue inline（hot）
从代码清单 11-4 的输出中可以看到方法 doubleValue() 被内联编译到 calcSum() 中，而 calcSum() 又被内联到方法 main() 中，所以虚拟机再次执行 main() 方法的时候（举例而已，main() 方法并不会运行两次），calcSum() 和 doubleValue() 方法都不会再被调用，它们的代码逻辑都被直接内联到 main() 方法中了。
编译优化技术
Java 程序员有一个共识，以编译方式执行本地代码比解释方式更快，之所以有这样的共识，除去虚拟机解释执行字节码时额外消耗时间的原因外，还有一个很重要的原因就是虚拟机设计团队几乎把对代码的所有优化措施都集中在了即时编译器之中（在 JDK 1.3 之后，javac 就去除了 -O 选项，不会生成任何字节码级别的优化代码了）。因此一般来说，即时编译器产生的本地代码会比 javac 产生的字节码更加优秀。下面，笔者将介绍一些 HotSpot 虚拟机的即时编译器在生成代码时采用的代码优化技术。
优化技术概览
在 Sun 官方的 Wiki 上，HotSpot 虚拟机设计团队列出了一个相对比较全面的、在即时编译器中采用的优化技术列表（见表 11-1），其中有不少经典编译器的优化手段，也有许多针对 Java 语言（准确地说是针对运行在 Java 虚拟机上的所有语言）本身进行的优化技术，本节将对这些技术进行概括性的介绍，在后面几节中，再挑选若干重要且典型的优化，与读者一起看看优化前后的代码产生了怎样的变化。
上述的优化技术看起来很多，而且从名字看都显得有点 “高深莫测”，虽然实现这些优化也许确实有些难度，但大部分技术理解起来都并不困难。为了消除读者对这些优化技术的陌生感，笔者举一个简单的例子，即通过大家熟悉的 Java 代码变化来展示其中几种优化技术是如何发挥作用的（仅适用 Java 代码来表示而已）。首先从原始代码开始，如代码清单 11-6 所示。
static class B{ int value; final int get() { return value; } } public void foo() { y = b.get(); // ...do stuff... z = b.get(); sum = y + z; } 首先需要明确的是，这些代码优化变换是建立在代码的某种中间表示或机器码之上的，绝不是建立在Java 源码之上的，为了展示方便，笔者使用了 Java 语言的语法来表示这些优化技术所发挥的作用。
代码清单11-6 的代码已经非常简单了，但是仍然有许多优化的余地。第一步进行方法内联（Method Inlining），方法内联的重要性要高于其他优化措施，它的主要目的有两个，一是去除方法调用的成本（如建立栈帧等）。二是为其他优化建立良好的基础，方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获取更好的优化效果。因此，各种编译器一般都会把内联优化放在优化序列的最靠前位置。内联后的代码如代码清单 11-7 所示。public void foo() { y = b.value; // ...do stuff... z = b.value; sum = y + z; } 第二步进行冗余访问消除（Redundant Loads Elimination），假设代码中间注释掉的 “do stuff…” 所代表的操作不会改变 b.value 的值，那就可以把 “z = b.value” 替换为 “z = y”，因为上一句 “y = b.value” 已经保证了变量 y 与 b.value 是一致的，这样就可以不再去访问对象 b 的局部变量了。如果把 b.value 看做是一个表达式，那也可以把这项优化看成是公共子表达式消除（Common Subexpression Elimination），优化后的代码如代码清单 11-8 所示。
public void foo() { y = b.value; // ...do stuff... z = y; sum = y + z; } 第三步我们进行复写传播（Copy Propagation），因为在这段程序的逻辑中并没有必要使用一个额外的变量 “z”，它与变量 “y” 是完全相等的，因此可以使用 “y” 来代替 “z”。复写传播之后程序如代码清单 11-9 所示。
public void foo() { y = b.value; // ...do stuff... y = y; sum = y + y; } 第四步我们进行无用代码消除（Dead Code Elimination）。无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码，因此，它又形象地称为 “Dead Code”，在代码清单 11-9 中，“y = y” 是没有意义的，把它消除后的程序如代码清单 11-10 所示。
public void foo() { y = b.value; // ...do stuff... sum = y + y; } 经过四次优化之后，代码清单 11-10 与代码清单 11-6 所达到的效果是一致的，但是前者比后者省略了许多语句（体现在字节码和机器码指令上的差距会更大），执行效率也会更高。编译器的这些优化技术实现起来也许比较复杂，但是要理解它们的行为对于一个普通的程序员来说是没有困难的，接下来，我们将继续查看如下的几项最有代表性的优化技术是如何运作的，它们分别是：
- 语言无关的经典优化技术之一：公共子表达式消除。
- 语言相关的经典优化技术之一：数组范围检查消除。
- 最重要的优化技术之一：方法内联。
- 最前沿的优化技术之一：逃逸分析。
公共子表达式消除
公共子表达式消除是一个普遍应用于各种编译器的经典优化技术，它的含义是：如果一个表达式 E 已经计算过了，并且从先前的计算到现在 E 中所有变量的值都没有发生变化，那么 E 的这次出现就成为了公共子表达式。对于这种表达式，没有必要花时间再对它进行计算，只需要直接用前面计算过的表达式结果代替 E 就可以了。如果这种优化仅限于程序的基本块内，便称为局部公共子表达式消除（Local Common Subexpression Elimination），如果这种优化的范围涵盖了多个基本块，那就称为全局公共子表达式消除（Global Common Subexpression Elimination）。举个简单的例子来说明它的优化过程，假设存在如下代码：
int d = (c * b) * 12 + a + (a + b * c);
如果这段代码交给 Javac 编译器则不会进行任何优化，那生成的代码将如代码清单 11-11 所示，是完全遵照 Java 源码的写法直译而成的。
iload_2 // b imul // 计算b * c bipush 12 // 推入12 imul // 计算（c * b）*12 iload_1 // a iadd // 计算（c * b）*12+a iload_1 // a iload_2 // b iload_3 // c imul // 计算b * c iadd // 计算a+b * c iadd // 计算（c * b）*12+a+（a+b * c） istore 4
当这段代码进入到虚拟机即时编译器后，它将进行如下优化：编译器检测到 “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() 两个方法里面的操作都可能是有意义的。
public static void foo (Object obj) { if (obj != null) { System.out.println("do something"); } } public static void testInline(String[]args) { Object obj = null; foo (obj); } 方法内联的优化行为看起来很简单，不过是把目标方法的代码 “复制” 到发起调用的方法之中，避免发生真实的方法调用而已。但实际上 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 对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序真正执行的时候将可能不创建这个对象，而改为直接创建它的若干个被这个方法使用到的成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，有很大的概率会被虚拟机分配至物理机器的告诉寄存器中存储）分配和读写之外，还可以为后续进一步的优化手段创建条件。
关于逃逸分析的论文在 1999 年就已经发表，但直到 Sun JDK 1.6 才实现了逃逸分析，而且直到现在这项优化尚未足够成熟，仍有很大的改进余地。不成熟的原因主要是不能保证逃逸分析的性能收益必定高于它的消耗。如果要完全准确地判断一个对象是否会逃逸，需要进行数据流敏感的一系列复杂分析，从而确定程序各个分支执行时对此对象的影响。这是一个相对高耗时的过程，如果分析完后发现没有几个不逃逸的对象，那这些运行期耗用的时间久白白浪费了，所以目前虚拟机只能采用不那么准确，但时间压力相对较小的算法来完成逃逸分析。还有一点是，基于逃逸分析的一些优化手段，如上面提到的 “栈上分配”，由于 HotSpot 虚拟机目前的实现方式导致栈上分配实现起来比较复杂，因此在 HotSpot 中暂时还没有做这项优化。
在测试结果中，实施逃逸分析后的程序在 MicroBenchmarks 中往往能运行出不错的成绩，但是在实际的应用程序，尤其是大型程序中反而发现实施逃逸分析可能出现效果不稳定的情况，或因分析过程耗时但却无法有效判别出非逃逸对象而导致性能（即时编译的收益）有所下降，所以在很长的一段时间里，即时是 Server Compiler，也默认不开启逃逸分析，甚至在某些版本（如 JDK 1.6 Update 18）中还曾经短暂地完全禁止了这项优化。 如果有需要，并且确认对程序运行有益，用户可以使用参数 -XX: +DoEscapeAnalysis 来手动开启逃逸分析，开启之后可以通过参数 -XX: +PrintEscapeAnalysis 来查看分析结果。有了逃逸分析支持之后，用户可以使用参数 -XX: +EliminateAllocations 来开启标量替换，使用+XX: +EliminateLocks 来开启同步消除，使用参数-XX: +PrintEliminateAllocations 来查看标量的替换情况。 尽管目前逃逸分析的技术仍不失十分成熟，但是它却是即时编译器优化技术的一个重要发展方向，在今后的虚拟机中，逃逸分析技术肯定会支撑起一系列实用有效的优化技术。Java 与 C/C++ 的编译器对比
大多数程序员都认为 C/C++ 会比 Java 语言块，甚至觉得从 Java 语言诞生以来 “执行速度缓慢” 的帽子就应当扣在它的头顶，这种观点的出现是由于 Java 刚出现的时候即时编译技术还不成熟，主要靠解释器执行的 Java 语言性能确实比较低下。但目前即时编译技术已经十分成熟，Java 语言有可能在速度上与 C/C++ 一争高下吗？要想知道这个问题的答案，让我们从两者的编译器谈起。
Java 与 C/C++ 的编译器对比实际上代表了最经典的即时编译器与静态编译器的对比，很大程度上也决定了 Java 与 C/C++ 的性能对比的结果，因为无论是 C/C++ 还是 Java 代码，最终编译之后被机器执行的都是本地机器码，哪种语言的性能更高，除了它们自身的 API 库实现得好坏以外，其余的比较就成了一场 “拼编译器” 和 “拼输出代码质量” 的游戏。当然，这种比较也是剔除了开发效率的片面对比，语言间孰优孰劣、谁块谁慢的问题都是很难有结果的争论，下面我们就回到正题，看看这两种语言的编译器各有何种优势。 Java 虚拟机的即时编译器与 C/C++ 的静态优化编译器相比，可能会由于下列这些原因而导致输出的本地代码有一些劣势（下面列举的也包括一些虚拟机执行子系统的性能劣势）： 第一，因为即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。如果编译速度不能达到要求，那用户将在启动程序或程序的某部分察觉到重大延迟，这点使得即时编译器不敢随便引入大规模的优化技术，而编译的时间成本在静态优化编译器中并不是主要的关注点。 第二，Java 语言是动态的类型安全语言，这就意味着需要由虚拟机来确保程序不会违反语言语义或访问非结构化内存。从实现层面上看，这就意味着虚拟机必须频繁地进行动态检查，如实例方法访问时检测空指针、数组元素访问时检测上下文范围、类型转换时检测继承关系等。对于这类程序代码没有明确写出的检查行为，尽管编译器会努力进行优化，但是总体上仍然要消耗不少的运行时间。 第三，Java 语言中虽然没有 virtual 关键字，但是使用虚方法的频率却远远大于 C/C++ 语言，这意味着运行时对方法接收者进行多态选择的频率要远远大于 C/C++ 语言，也意味着即时编译在进行一些优化（如前面提到的方法内联）时的难度要远大于 C/C++ 的静态优化编译器。 第四，Java 语言是可以动态扩展的语言，运行时加载新的类可能改变程序类型的继承关系，这使得很多全局的优化都难以进行，因为编译器无法看见程序的全貌，许多全局的优化措施都只能以激进优化的方式来完成，编译器不得不时刻注意并随着类型的变化而在运行时撤销或重新进行一些优化。 第五，Java 语言中对象的内存分配都是堆上进行的，只有方法中的局部变量才能在栈上分配。而 C/C++ 的对象则有多种内存分配方式，既可能在堆上分配，又可能在栈上分配，如果可以在栈上分配线程私有的对象，将减轻内存回收的压力。另外，C/C++ 中主要由用户程序代码来回收分配的内存，这就不存在无用对象筛选的过程，因此效率上（仅指运行效率，排除了开发效率）也比垃圾收集机制要高。 上面说了一大堆 Java 语言相对 C/C++ 的劣势，不是说 Java 就真的不如 C/C++ 了，相信读者也注意到了，Java 语言的这些性能上的劣势都是为了换取开发效率上的优势而付出的代价，动态安全、动态扩展、垃圾回收这些 “拖后腿” 的特性都是为 Java 语言的开发效率做出了很大贡献。 何况，还有许多优化是 Java 的即时编译器能做而 C/C++ 的静态优化编译器不能做或者不好做的。例如，在 C/C++ 中，别名分析（Alias Analysis）的难度就要远高于 Java。Java 的类型安全保证了在类似如下代码中，只要 ClassA 和 ClassB 没有继承关系，那对象 objA 和 objB 就绝不可能是同一个对象，即不会是同一块内存两个不同别名。void foo(ClassA objA, ClassB objB) { objA.x = 123; objB.y = 456; // 只要 objB.y 不是 objA.x 的别名，下面就可以保证输出为 123 print(objA.x); } 确定了 objA 和 objB 并非对方的别名后，许多与数据依赖相关的优化才可以进行（重排序、变量代换）。具体到这个例子中，就是无须担心 objB.y 其实与 objA.x 指向同一块内存，这样就可以安全地确定打印语句中的 objA.x 为 123。
Java 编译器另外一个红利是由它的动态性所带来的，由于 C/C++ 编译器所有优化都在编译期完成，以运行期性能监控为基础的优化措施它都无法进行，如调用频率预测（Call Frequency Prediction）、分支频率预测（Branch Frequency Prediction）、裁剪未被选中的分支（Untaken Branch Pruning）等，这些都会成为 Java 语言都有的性能优势。第十二章 Java内存模型与线程
Java内存模型
主内存与工作内存
Java内存模型主要目标：定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量（Variable）与Java编程中的变量略有区别，它包括实例变量/静态字段和构成数组对象的元素，不包括局部变量和方法参数（线程私有）。为获得较好的执行效能，Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交换，也没有限制即时编译器调整代码执行顺序这类权利。 Java内存模型规定所有变量都存储在主存（Main Memory）中（虚拟机内存的一部分）。每条线程还有自己的工作内存（Working Memory），线程的工作内存保存了被线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取/赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主存来完成。 这里的主内存/工作内存与Java内存区域中的Java栈/堆/方法区并不是同一个层次的内存划分。如果两者一定要勉强对应起来，那从变量/主内存/工作内存的定义来看，主内存主要对应于Java堆中对象的实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。从更低的层次来说，主存就是硬件的内存，而为获取更好的运算速度，虚拟机及硬件系统可能会让工作内存优先存储于寄存器和高速缓存。
内存间交互操作
主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、从工作内存同步回主内存之类的实现细节，Java内存模型中定义了以下8种操作来完成：
Lock（锁定）：作用于主内存的变量，将主内存该变量标记成当前线程私有的，其他线程无法访问它把一个变量标识为一条线程独占的状态。 Unlock（解锁）：作用于主内存的变量，把一个处于锁定状态的变量释放出来，才能被其他线程锁定。 Read（读取）：作用于主内存的变量，把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。 Load（加载）：作用于工作内存中的变量，把read操作从内存中得到的变量值放入工作内存的变量副本中。 Use（使用）：作用于工作内存中的变量，把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。 Assgin（赋值）：作用于工作内存中的变量，把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。 Store（存储）：作用于工作内存中的变量，把工作内存中一个变量的值传递到主内存中，以便随后的write操作使用。 Write（写入）：作用于主内存中的变量，把store操作从工作内存中得到的变量的值放入主内存的变量中。 如果把一个变量从主内存复制到工作内存，按顺序执行read和load操作；如果把变量从工作内存同步回主内存，按顺序执行store和write操作。Java内存模型还规定在执行上述8种基本操作时必须满足如下规则： 不允许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可以说是Java虚拟机提供的最轻量级的同步机制。
当一个变量被定义成volatile后，它将具备两种特性： 第一是保证对所有线程的可见性，“可见性”指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。 关于volatile变量的可见性的误解：“volatile变量对所有线程立即可见的，对volatile变量所有的写操作都能立刻反映到其他线程中，换句话说，volatile变量在各个线程中是一致的，所以基于volatile变量的运算在并发下是安全的”。这句话的论据部分并没有错，但是其论据并不能得出“基于volatile变量的运算在并发下是安全的”这个结论。 volatile变量在各个线程中的工作内存中不存在一致性问题（在各个线程的工作内存中volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在不一致问题），但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的。package com.jvm.thread;/** * volatile变量自增运算测试 * @author xl69628 * */public class VolatileTest { public static volatile int race = 0; private static final int THREADS_COUNT = 20; public static void increase(){ race++; } public static void main(String[] args) { Thread[] threads = new Thread[THREADS_COUNT]; for(int i = 0; i < THREADS_COUNT; i++){ threads[i] = new Thread(new Runnable() { @Override public void run() { for(int i = 0; i < 10000; i++){ increase(); } } }); threads[i].start(); } //等待所有累加线程都结束 while (Thread.activeCount() > 1) { Thread.yield(); } System.out.println(race); //如果代码正确并发，输出结果为200000。但是每次运行都不会得到期望的结果。 }} G:\javaee\workspace\Test\bin\com\jvm\thread>javap -c VolatileTest警告: 二进制文件VolatileTest包含com.jvm.thread.VolatileTestCompiled from "VolatileTest.java"public class com.jvm.thread.VolatileTest { public static volatile int race; static { }; Code: 0: iconst_0 1: putstatic #13 // Field race:I 4: return public com.jvm.thread.VolatileTest(); Code: 0: aload_0 1: invokespecial #18 // Method java/lang/Object." ":()V 4: return public static void increase(); Code: 0: getstatic #13 // Field race:I 3: iconst_1 4: iadd 5: putstatic #13 // Field race:I 8: return public static void main(java.lang.String[]); Code: 0: bipush 20 2: anewarray #25 // class java/lang/Thread 5: astore_1 6: iconst_0 7: istore_2 8: goto 37 11: aload_1 12: iload_2 13: new #25 // class java/lang/Thread 16: dup 17: new #27 // class com/jvm/thread/VolatileTest$1 20: dup 21: invokespecial #29 // Method com/jvm/thread/VolatileTest$1." ":()V 24: invokespecial #30 // Method java/lang/Thread." ":(Ljava/lang/Runnable;)V 27: aastore 28: aload_1 29: iload_2 30: aaload 31: invokevirtual #33 // Method java/lang/Thread.start:()V 34: iinc 2, 1 37: iload_2 38: bipush 20 40: if_icmplt 11 43: goto 49 46: invokestatic #36 // Method java/lang/Thread.yield:()V 49: invokestatic #39 // Method java/lang/Thread.activeCount:()I 52: iconst_1 53: if_icmpgt 46 56: getstatic #43 // Field java/lang/System.out:Ljava/io/PrintStream; 59: getstatic #13 // Field race:I 62: invokevirtual #49 // Method java/io/PrintStream.println:(I)V 65: return} 问题就出现在自增运算“race++”之中，用javap反编译这段代码，发现只有一行代码的increase()方法在Class文件中由4条字节码指令构成（return指令不是由race++产生的，这条指令可以不计算），从字节码层面容易分析并发失败的原因了：当getstatic指令把race的值取到操作栈顶时，volatile关键字保证了race的值在此时是正确的，但是在执行iconst_1, iadd这些指令时，其他线程可能已经把race的值加大了，而操作栈顶的值就变成了过期的数据，所以putstatic指令执行后就可能把较小的race值同步回主内存中。
客观地说，此时使用字节码来分析并发问题，仍然是不严谨的，因为即使编译出来只有一条指令，也并不意味执行这条指令就是一个原子操作。一条字节码指令在解释执行时，解释器将要运行许多行代码才能实现它的语义，如果是编译执行，一条字节码指令也可能转化成若干条本地机器码指令，此处使用 -XX:+PrintAssembly 参数输出反编译来分析会更加严谨一些。 由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁（使用synchronized或java.util.concurrent中的原子类）来保证原子性： 1）运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。 2）变量不需要与其他的状态变量共同参与不变约束。 使用volatile变量的第二个语义是禁止指令重排序优化，普通变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，这也就是Java内存模型中描述的所谓的“线程内表现为串行的语义”（WithinThread As-If-Serial Semantics）。 在众多保障并发安全工具中选用volatile的意义：在某些情况下，volatile的同步机制的性能确实要优先于锁（使用synchronized关键字或java.util.concurrent包里面的锁），但是由于虚拟机对锁实行的许多消除和优化，使得很难量化地认为volatile就会比synchronized快多少。volatile变量的读操作的性能消耗与普通变量几乎没有差别，但写操作可能会慢一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此，大多数场景下volatile的总开销仍然要比锁低，我们在volatile与锁之中选择的唯一依据仅仅是volatile的语义能否满足使用场景的需求。 java内存模型中对volatile变量定义的特殊规则。假定T表示一个线程，V和W分别表示volatile型变量，那么在进行read、load、use、assign、store和write操作时需要满足如下规则： 1）只有当线程T对变量V执行的前一个动作为load时，T才能对V执行use；并且，只有T对V执行的后一个动作为use时，T才能对V执行load。T对V的use，可以认为是和T对V的load。read动作相关联，必须连续一起出现（这条规则要求在工作内存中，每次使用V前都必须先从主内存刷新最新的值，用于保证能看见其他线程对V修改后的值）。 2）只有当T对V的前一个动作是assign时，T才能对V执行store；并且，只有当T对V执行的后一个动作是store时，T才能对V执行assign。T对V的assign可以认为和T对V的store、write相关联，必须连续一起出现（这条规则要求在工作内存中，每次修改V后都必须立刻同步回主内存中，用于保证其他线程看到自己对V的修改）。 3）假定动作A是T对V实施的use或assign动作，假定动作F是和动作A相关联的load或store动作，假定动作P是和动作F相应的对V的read或write动作；类似的，假定动作B是T对W实施的use或assign动作，假定动作G是和动作B相关联的load或store动作，假定动作Q是和动作G相应的对W的read或write动作。如果A先于B，那么P先于Q（这条规则要求volatile修饰的变量不会被指令的重排序优化，保证代码的执行顺序与程序的顺序相同）。对long和double型变量的特殊规则
允许虚拟机将没有被volatile修饰的64位数据类型（long和double）的读取操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的load、store、read和write这4个操作的原子性，就点就是long和double的非原子协定（Nonatomic Treatment of double and long Variables）。
如果多个线程共享一个为声明为volatile的long或double类型变量，并同时对他们进行读取和修改操作，那么有些线程可能会读取到一个即非原值，也不是其他线程修改值得代表了“半个变量”的数值。 不过这种读取带“半个变量”的情况非常罕见（在目前商用虚拟机中不会出现），因为Java内存模型虽然允许虚拟机不把long和double变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为具有原子性的操作，而且还“强烈建议”虚拟机这样实现。原子性、可见性和有序性
原子性（Atomicity）：由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write，我们大致可以认为基本数据类型的访问具备原子性（long和double例外）。
如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足需求，尽管虚拟机未把lock和unlock操作直接开放给用户，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，这两个字节码指令反应到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。 可见性（Visibility）：指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。 除了volatile，Java还有两个关键字能实现可见性，synchronized和final。同步块的可见性是由“对一个变量执行unlock操作之前，必须把此变量同步回主内存中（执行store和write操作）”这条规则获得的，而final关键字的可见性是指：被final修饰的字段在构造器中一旦被初始化完成，并且构造器没有把“this”的引用传递出去（this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那么其他线程中就能看见final字段的值。//变量i与j都具备可见性，它们无须同步就能被其他线程正确访问 public static final int i; public final int j; static{ i = 0; //do something } { //也可以选择在构造函数中初始化 j = 0; //do something } 有序性（Ordering）：Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另外一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”（Within-Thread As-if-Serial Semantics），后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。
Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一时刻只允许一条线程对其进行lock操作”这条规则获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。先行发生原则
先行发生是Java内存模型中定义的两项操作之间的偏序关系，如果操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包括修改了内存中共享变量的值/发送了消息/调用了方法等。
i = 1；//在线程A中执行 j = i;//在线程B中执行 i = 2;//在线程C中执行 //A先于B，但是C与B没有先行关系，B存在读取过期数据风险，不具备多线程安全性
**下面是Java内存模型下一些“天然的”先行发生关系，无须任何同步器协助就已经存在，可直接在编码中使用。**如果两个操作之间的关系不在此列，并且无法从下列规则推倒出来，它们就没有顺序性的保障，虚拟机可以对它们进行随意地重排序。
1）程序次序规则（Program Order Rule）：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地来说应该是控制流顺序而不是程序代码顺序，因为要考虑分支/循环结构。 2）管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一锁的lock操作。这里必须强调的是同一锁，而“后面”是指时间上的先后顺序。 3）volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”是指时间上的先后顺序。 4）线程启动规则（Thread Start Rule）：Thread对象的start()方法先行发生于此线程的每一个动作。 5）线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束/Thread.isAlive()的返回值等手段检测到县城已经终止执行。 6）线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。 7）对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始。 8）传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那么操作A先行发生于操作C。 时间上的先后顺序与先行发生原则之间基本没有太大的关系，所以我们衡量并发安全问题时不要受时间顺序的干扰，一切必须以先行发生原则为准。Java与线程
并发不一定依赖多线程，但是Java里面谈论并发，大多数与线程脱不开关系。
线程的实现
主流操作系统都提供了线程实现，Java语言则提供了在不同硬件和操作系统平台对线程的同一处理，每个java.lang.Thread类的实例就代表了一个线程。Thread类与大部分Java API有着显著的差别，它的所有关键方法都被声明为Native。在Java API中一个Native方法可能就意味着这个方法没有使用或无法使用平台无关的手段实现。正因为这个原因，我们这里的“线程的实现”而不是“Java线程的实现”。 实现线程主要三种方式：- 使用内核线程实现 内核线程（Kernel Thread， KLT）就是直接由操作系统内核（Kernel，下称内核）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程都可以看作是内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就叫多线程内核（Multi-Thread Kernel）。 程序一般不会直接去使用内核线程，而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process， LWP），轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，**因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1：1的关系称为一对一的线程模型。 轻量级进程的局限性：由于是基于内核线程实现的，所以各种进程操作，如创建/析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态（User Mode）和内核态（Kernel Mode）中来回切换；每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程需要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程是有限的。
- 使用用户线程实现 狭义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到线程存在的实现。用户线程的建立/同步/销毁和调度完全在用户态完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态，因此操作快速且低消耗，也可以支持规模更大的线程数量，部分高性能数据库中的多线程就是由用户线程实现的。这种进程与用户线程之间1：N的关系称为一对多的线程模型。
- 使用用户线程加轻量级进程混合实现 既存在用户线程，也存在轻量级进程。
Java线程调度
线程调度是指系统为线程分配处理器使用权的过程。主要调度方式两种：
使用协同调度的多线程系统，线程执行时间由线程本身控制，线程把自己的工作执行完后，要主动通知系统切换到另外一个线程上去。优点：实现简单。缺点：执行时间不可控制。 使用抢占调用的多线程系统，每个线程由系统分配执行时间，线程的切换不由线程本身决定。Java使用的就是这种线程调度方式。 Java提供10个级别的线程优先级设置，不过，线程优先级不靠谱，因为Java线程是被映射到系统的原生线程上实现的，所以线程调度最终还是由操作系统决定。状态转换
Java语言定义了5种进程状态，在任意一个时间点，一个线程只能有且只有其中一种状态：
新建（New）：创建尚未启动的线程处于这种状态。 运行（Runable）：包括操作系统线程状态中的Running和Ready，处于此状态的线程可能正在运行，也可能等待着CPU为它分配执行时间。 无限期等待（Waiting）：处于这种状态的线程不会被分配CPU执行时间，它们要等待其他线程显示地唤醒。以下方法会让线程陷入无限期的等待状态： 没有设置Timeout参数的Object.wait()方法。 没有设置Timeout参数的Thread.join()方法。 LockSupport.park()方法。 限期等待（Timed Waiting）：处于这种状态的线程也不会被分配CPU执行时间，不过无须等待被其他线程显示地唤醒，在一定时间后由系统自动唤醒。以下方法会让线程陷入限期的等待状态： Thread.sleep()方法。 设置了Timeout参数的Object.wait()方法。 设置了Timeout参数的Thread.join()方法。 LockSupport.parkNanos()方法。 LockSupport.parkUntil()方法。 阻塞（Blocked）：线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待获取一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生；“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序进入等待进入同步块区域的时候，线程将进入这种状态。 结束（Terminated）：已终止线程的线程状态，线程已经结束执行。
第十三章 线程安全与锁优化
线程安全
当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方法进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那么这个对象是线程安全的。
Java语言中的线程安全
这里讨论的线程安全，就限定于多个线程之间存在共享数据访问的这个前提。
按照线程安全的“安全程度”由强到弱排序，可以把Java中各个操作共享的数据分为以下5类： 1 不可变 不可变（Immutable）的对象一定是线程安全的。 如果共享数据是一个基本数据类型，定义时使用final关键字修饰可保证它不可变。 如果共享数据是一个对象，那就需要保证对象的行为不会对其状态产生任何影响才行。其中最简单的是把对象中带有状态的变量都声明为final，这样在构造函数结束后，它就是不可变的。 Java API中符合不可变要求的类型：java.lang.String/java.lang.Number部分子类等。 2 绝对线程安全 绝对线程安全满足线程安全的定义。Java API中标注自己是线程安全的类，大多数时候都不是绝对的线程安全。package com.jvm.thread;import java.util.Vector;public class VectorTest { private static Vector vector = new Vector<>(); public static void main(String[] args) throws InterruptedException { while (true) { for(int i = 0; i < 10; i++){ vector.add(i); } Thread removeThread = new Thread(new Runnable() { public void run() { for(int i = 0; i < vector.size(); i++){ vector.remove(i); } } }); Thread printThread = new Thread(new Runnable() { public void run() { for(int i = 0; i < vector.size(); i++){ try { Thread.sleep(1000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } System.out.println(vector.get(i)); } } }); removeThread.start(); printThread.start(); } }} 运行将发生java.lang.ArrayIndexOutOfBoundsException异常。尽管Vector的get()/remove()和size()方法都是同步的，但是在多线程环境中，如果不在方法调用端做额外的同步措施，使用这段代码仍然是不安全的。
package com.jvm.thread;import java.util.Vector;/** * 加入同步以保证Vector访问的线程安全 * @author xl69628 * */public class VectorTest { private static Vector vector = new Vector<>(); public static void main(String[] args) throws InterruptedException { while (true) { for(int i = 0; i < 10; i++){ vector.add(i); } Thread removeThread = new Thread(new Runnable() { public void run() { synchronized (vector) { for(int i = 0; i < vector.size(); i++){ vector.remove(i); } } } }); Thread printThread = new Thread(new Runnable() { public void run() { synchronized (vector) { for(int i = 0; i < vector.size(); i++){ try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(vector.get(i)); } } } }); removeThread.start(); printThread.start(); } }} 3 相对线程安全
相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单独的操作时线程安全的，我们在调用时不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确定。 Java中，大部分线程安全类都属于这种类型，Vector/HashTable/Collections的synchronizedCollection()方法包装的集合等。 4 线程兼容 线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中安全使用。Java API中大部分类都是线程兼容的。 5 线程对立 是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。通常是有害的，应当尽量避免。 一个线程对立的例子是Thread类的suspend()和resume()方法，如果两个线程同时持有一个线程对象，一个尝试去中断线程，另一个尝试去恢复线程，如果并发进行的话，无论调用是否进行了同步，目标线程都是存在死锁风险的，如果suspend()中断的线程就是即将要执行resume()的那个线程，那就肯定要产生死锁了。正是因为此原因，此两方法已被JDK废弃了。线程安全的实现方法
代码编写如何实现线程安全和虚拟机如何实现同步与锁这两者都会涉及。
1.互斥同步 互斥同步（Mutual Exclusion & Synchronization）是常见的一种并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（MuTex）和信号量（Semaphore）都是主要的互斥实现方式。因此，在这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。 在Java中，最基本的互斥同步手段是synchronized关键字，synchronized关键字经过编译后，会在同步代码块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果程序中synchronized指明了对象参数，那就是这个对象的reference；如果没有指明，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。 虚拟机规范要求，在执行monitorenter指令时，首先尝试获取对象的锁。如果对象没有被锁定或者当前线程已经拥有了那么对象的锁，把锁的计数器加1，执行monitorexit时，将锁计数减1，当锁计数器为0时，锁被释放。如果获取对象锁失败，当前线程将阻塞等待。public String concatString(String s1, String s2, String s3){ StringBuilder sb = new StringBuilder(); sb.append(s1); sb.append(s2); sb.append(s3); return sb.toString(); } 还可以使用java.util.concurrent（以下称JUC）包中的重入锁（ReentrantLock）来实现同步。相比synchronized，ReentrantLock增加了一些高级功能，主要以下3项：等待可中断、可实现公平锁，以及锁可以绑定多个条件。
等待可中断：当持有的锁的线程长期不释放锁时，正在等待的线程可以选择放弃等待，改为处理其他事情，对处理执行时间长的同步块很有帮助。 公平锁：多个线程等待同一锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的，ReentrantLock默认也是非公平，但可以通过构造函数要求使用公平锁。 绑定多个条件：一个ReentrantLock对象可以同时绑定多个Condition对象，而synchronized中，锁对象的wait()和notify()或notifyAll()可以实现一个隐含的条件，如果要和多于一个的条件关联时，就不得不额外添加一个锁，而ReentrantLock则无须这样，只要多次调用newCondition()即可。2.非阻塞同步
互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步（Blocking Synchronized）。处理问题方式上，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施（例如加锁），那肯定会出现问题，无论共享数据是否真的出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有阻塞的线程需要等待唤醒等操作。 随着硬件指令集的发展，有了另外一种选择：基于冲突检测的乐观并发策略，就是先进性操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步称为非阻塞同步（Non-Blocking Synchronization）。 我们需要操作和冲突检测这两个步骤具备原子性，只能靠硬件来完成，硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成，这类执行常用的有： 测试并设置（Test and Set）。 获取并增加（Fetch and Increment）。 交换（Swap）。 比较并交换（Compare and Swap，以下称CAS）。 加载链接/条件存储（Load Linked/Store Conditional，以下称LL/SC）。3.无同步方案
要保证线程安全，并不是一定就要进行同步，两者并没有因果关系。同步只是保证共享数据争用时正确性的手段，如果一个方法本来就不涉及共享数据，自然就无须任何同步措施去保证正确定。因此会有一些代码天生就是线程安全的。两类：可重入代码（Reentrant Code）：这种代码也叫纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一断代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误。所有可重入代码都是线程安全的。可重入代码有一些共同特征，例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都是由参数中传入、不调用非可重入的方法等。判断代码具备可重入的简单原则：如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，就满足可重入性的要求，当然也是线程安全的。
线程本地存储（Thread Local Storage）：如果一段代码中所需要的数据必须与其他代码共享，那就看这些共享数据的代码是否能保证在同一个线程中执行？如能，就把共享数据的可见性范围限制在同一个线程之内，这样，就无须同步也能保证线程之前不出现数据争用问题。 符合这种特点的应用：大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会讲消费过程尽量在一个线程中消费完；经典Web交互模型中的“一个请求对应一个服务线程”（Thread-per-Request）的处理方式，这种处理方式的广泛应用使得很多Web服务端应用都可以使用线程本地存储来解决线程安全问题。 Java中，如果一个变量要被多个线程访问，可以使用volatile关键字声明它为“易变的”；如果一个变量被某个线程独享，可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。每一个线程的Thread对象中都有一个ThreadLcoalMap对象，该对象存储了一组易ThreadLocal.threadLocalHashCode为键，以本地线程变量为值得K-V键值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值，使用这个值就可以在线程K-V键值对中找回对应的本地线程变量。锁优化
自旋锁与自适应自旋
在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得如果物理机器上有一个以上的处理器，我们可以让后面申请锁的那个线程“稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，只需让线程执行一个忙循环（自旋），就项技术就是所谓的自旋锁。 自旋等待不能代替阻塞，且先不说对处理器量的要求，自旋等待本身虽然避免了线程切换的开销，但它要占用处理器的时间，因此，如果锁被占用的时间短，自旋等待效果好，反之，自旋的线程只会白白消耗处理器资源，而不做任何有用工作，带来性能上的浪费。因此，自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有获得锁，就应当使用传统的方式挂起线程。自旋次数的默认值是10次，用户可以使用参数 -XX:PerBlockSpin 来修改。 JDK1.6引入了自适应的自旋锁。自旋的时间是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就认为这次自旋也很可能成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得，在以后获得这个锁时将可能省略自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虚拟机就变得越来越“聪明”了。锁消除
是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去，从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然无须进行。 许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许超过我们的想象。public String concatString(String s1, String s2, String s3){ return s1 + s2 + s3; } 由于String是一个不可变类，对字符串的连接操作总是通过生成新的String对象来进行，因此Javac编译器会对String连接做自动优化。在JDK1.5前，会转换为StringBuffer对象的append()操作，在JDK1.5及以后版本，会转换为StringBuilder对象的连续append()操作。上段代码可能会变成下面的样子。
public String concatString(String s1, String s2, String s3){ StringBuilder sb = new StringBuilder(); sb.append(s1); sb.append(s2); sb.append(s3); return sb.toString(); } 每个StringBuilder.append()中都有一个同步块，锁是sb对象。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString()的内部。也就是sb的所有引用永远不会“逃逸”到concatString()外，其他线程无法访问到它，所以虽然这里有锁，但是可以被安全地消除掉，在即时编译后，这段代码会忽略所有的同步而直接执行。
锁粗化 大部分情况下，我们在编写代码时，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域才进行同步，如果存在锁竞争，那等待锁的线程也可能尽快拿到锁。 但是如果一系列的连续操作都是对同一对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。 上段代码连续的append()就属于这种情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，以上段代码为例，就是扩展到第一个append()之前直至最后一个append()之后，这样只需要加锁一次就可以了。 轻量级锁 轻量级锁是JDK1.6中加入的新型锁机制。轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统重量级锁使用操作系统互斥量产生的性能消耗。 轻量级锁提升程序性能的依据是“对于绝大多数的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁比传统锁更慢。 偏向锁 偏向锁是JDK1.6引入的锁优化，目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。 这个锁会偏向于第一个获得它的线程，如果接下来的执行过程中，该锁没有被其他线程获取，则持有偏向锁的线程将永远不需要再进行同步。 偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡（Trade Off）性质的优化，它对程序运行不一定有利，如果程序中大多数的锁都总是被多个不同的线程访问，那偏向锁局势多余的。在具体问题具体分析的前提下，有时使用参数 -XX:-UseBiasedLocking 来禁止偏向锁优化反而可以提升性能。转载地址：http://micen.baihongyu.com/