首页 > > 程序设计 > Java技术 >

深入理解Java虚拟机---简笔

2019-08-26 06:17:48来源：博客园阅读 ()

深入理解Java虚拟机---简笔

Evernote Export

1.走进Java

JDK（Java程序设计语言、Java虚拟机、Java API） JRE（Java SE API子集、Java虚拟机） JVM

2.Java内存区域

程序计数器：记录线程执行字节码的行号指示器。

字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。

Java虚拟机栈：描述Java方法执行的内存模型： Java虚拟机栈是由一个个栈帧组成，而每个栈帧存储局部变量表、操作数栈、动态链接、方法出口等。

局部变量表所需内存空间在编译期完成分配，之后不会改变；存放数据类型（boolean、byte、char、short、int、float、long、double）、对象引用
会抛出StackOverflowError和OutOfMemoryError

本地方法栈：为Native方法服务

StackOverflowError和OutOfMemoryError

Java堆（GC堆）：存放对象实例、数组

新生代（Eden，From Survivor，To Survivor）、老年代
OutOfMemoryError

方法区：类信息、常量、静态变量、即时编译器编译后的代码等

也需要垃圾清理
运行时常量池：存放编译期的字面量和符号引用；JDK1.7及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。
OutOfMemoryError

2.1 对象创建过程：

虚拟机收到new指令
检查常量池中能否定位到一个类的符号引用
检查符号引用代表的类是否加载、解析和初始化过，没有就进行类的加载过程
为新生对象分配内存
将分配到的内存空间初始化为零值（不包括对象头）
对象头的储存信息设置
<init>初始化方法赋值

①类加载检查：虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程。 ②分配内存：在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。 **内存分配的两种方式：（补充内容，需要掌握）分配方式有 “指针碰撞” 和 “空闲列表” 两种，选择那种分配方式由 Java 堆是否规整决定。而 Java 堆内存是否规整，取决于 GC 收集器的算法是"标记-清除"，还是"标记-整理"（也称作"标记-压缩"），值得注意的是，复制算法内存也是规整的 **内存分配并发问题（补充内容，需要掌握）在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全： *** CAS+失败重试： CAS 是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。 *** TLAB：为每一个线程预先在Eden区分配一块儿内存，JVM在给线程中的对象分配内存时，首先在TLAB分配，当对象大于TLAB中的剩余内存或TLAB的内存已用尽时，再采用上述的CAS进行内存分配 ③初始化零值：内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。 ④设置对象头：初始化零值完成之后，虚拟机要对对象进行必要的设置，例如这个对象是那个类的实例、如何才能找到类的元数据信息、对象的哈希吗、对象的 GC 分代年龄等信息。这些信息存放在对象头中。另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。 ⑤执行 init 方法：在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始，<init> 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后接着执行 <init> 方法，将对象属性值进行显示初始化并执行构造方法（调用子类<init> 方法之前会先调用父类<init> 方法） 存在继承的情况下，初始化顺序为：

父类（静态变量、静态语句块）
子类（静态变量、静态语句块）
父类（实例变量、普通语句块）——>父类（构造函数）
子类（实例变量、普通语句块）——>子类（构造函数）

2.2 对象的内存布局：对象头、实例数据、对齐填充

对象头：【一】运行时数据/MarkWord（32bit/64bit）：HashCode、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等；【二】类型指针：对象指向他的类元数据的指针
实例数据：对象真正存储的有效信息，也是在程序中所定义的各种类型的字段内容。
对齐填充：占位符（对象大小必须是8字节的整数倍）

2.3 对象的访问：Java程序需要通过栈上的reference操作具体对象

句柄：如果使用句柄的话，那么Java堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息；
直接指针：如果使用直接指针访问，那么 Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference 中存储的直接就是对象的地址。
这两种对象访问方式各有优势。使用句柄来访问的最大好处是 reference 中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而 reference 本身不需要修改。使用直接指针访问方式最大的好处就是速度快，它节省了一次指针定位的时间开销。

2.4 String 类和常量池 1 String 对象的两种创建方式： String str1 = "abcd"; String str2 = new String("abcd"); System.out.println(str1==str2);//false 第一种方式是在常量池中拿对象，第二种方式是直接在堆内存空间创建一个新的对象。

2 String 类型的常量池比较特殊。它的主要使用方法有两种：

直接使用双引号声明出来的 String 对象会直接存储在常量池中。
如果不是用双引号声明的 String 对象，可以使用 String 提供的 intern 方法。String.intern() 是一个 Native 方法，它的作用是：如果运行时常量池中已经包含一个等于此 String 对象内容的字符串，则返回常量池中该字符串的引用；如果没有，则在常量池中创建与此 String 内容相同的字符串，并返回常量池中创建的字符串的引用。

String s1 = new String("计算机"); String s2 = s1.intern(); String s3 = "计算机"; System.out.println(s2);//计算机 System.out.println(s1 == s2);//false，因为一个是堆内存中的String对象一个是常量池中的String对象， System.out.println(s3 == s2);//true，因为两个都是常量池中的String对象 3 String 字符串拼接

尽量避免多个字符串拼接，因为这样会重新创建对象。如果需要改变字符串的话，可以使用 StringBuilder 或者 StringBuffer。

String str1 = "str"; String str2 = "ing"; String str3 = "str" + "ing";//常量池中的对象 String str4 = str1 + str2; //在堆上创建的新的对象 String str5 = "string";//常量池中的对象 System.out.println(str3 == str4);//false System.out.println(str3 == str5);//true System.out.println(str4 == str5);//false

String s1 = new String("abc");这句话创建了几个对象？创建了两个对象。先有字符串"abc"放入常量池，然后 new 了一份字符串"abc"放入Java堆(字符串常量"abc"在编译期就已经确定放入常量池，而 Java 堆上的"abc"是在运行期初始化阶段才确定)，然后 Java 栈的 str1 指向Java堆上的"abc"。

4.Integer常量池

Integer i = value;如果i是在-128到127之间，不会去堆中创建对象，而是直接返回IntegerCache中的值;如果值不在上面范围内则会从堆中创建对象。"=" 走的是valueOf()方法,valueOf(int)会走缓存。
Integer i2 = new Integer(xxxx);不管参数的value是多少都会从堆中创建对象，与IntegerCache没关系。
Integer.valueOf() 返回一个表示指定的 int 值的 Integer 实例。内部是“如果i在-128~127之间直接返回IntegerCache中的Integer实例，否则使用构造方法 Integer(int)创建新的实例”，该方法有可能通过缓存经常请求的值而显著提高空间和时间性能。
1. Integer.parseInt(string s)的作用就是把字符串s解析成有符号的int基本类型
2. Integer.valueOf(s)把字符串s解析成Integer对象类型，返回的integer包装类型可以调用对象中的方法。

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

引用计数法：对象中添加一个计数器，有一个地方引用它的时候就+1；无法解决循环引用可达性分析法：通过一系列“GC Roots”的对象作为起点开始向下搜索

虚拟机栈中引用的对象
本地方法栈中Native方法引用的对象
方法区中类静态属性引用的对象
方法区中常量引用的对象

强引用：强引用就是指在程序代码之中普遍存在的，类似“Object.obj=new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象软引用：是用来描述一些还有用但并非必需的对象。对于软引用关联着的对象，在系统将要发生内在溢出异常之前，将会把这些象回收范围之中进行第一次回收。在JDK1.2之后，提供了SoftReference 类来实现软引用。弱引用：也是用来描述非必需对象的，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JK1.2之后，提供了WeakReferernee类来实现弱引用。虚引用：也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收收到个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

对象死亡：至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GCRoots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize方法。当对象没有覆盖finalize()方法，或者finalize方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。如果这个对象被判定为有必要执行finalize方法，那么这个对象将会放置在一个叫做F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行它。 finalize方法:是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可;finalize()方法只会调用一次。

方法区回收：永久代的垃圾收集主要回收两部分内容=废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。判定一个类是否是“无用的类”：

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

垃圾收集算法：

标记-清除：“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。（效率低、产生空间碎片）
复制算法：内存按容量划分为小相等的两块，每次使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一上面，然后再把已使用过的内存空间一次清理掉。（缩小了可使用的内存；优化 Eden：fromSurvivor：toSurvivor=8：1：1）
标记-整理：标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存；
分代收集：新生代---复制算法；老年代---标记整理算法

垃圾收集器：

serial收集器：单线程、stop the world

ParNew收集器：serial收集器的多线程版本

Parallel Scavenge：复制算法、吞吐量

控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis 参数；直接设置吞吐量大小的-XX：GCTimeRatio参数。

Serial Old收集器：Serial的老年代版本 Parallel Old收集器： Parallel Scavenge的老年代版本 CMS收集器（Concurrent Mark Sweep)：获取最短回收停顿时间、标记清除算法、并发收集、低停顿；产生空间碎片、无法处理浮动垃圾、对CPU资源敏感

初始标记（eMS initial mark）：暂停所有的其他线程，标记一下GC.Roots能直接关联到的对象，速度很快（STW）
并发标记（CMS concurrent mark）：同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
重新标记（CMS remark）：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录（STW），这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
并发清除（CMS concurrent sweep)：开启用户线程，同时GC线程开始对为标记的区域做清扫。

G1收集器：面向服务端应用、并行与并发、分代收集、标记整理算法、低停顿

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了GF收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region)，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。 G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。

初始标记（Initial Marking)
并发标记（Concurrent Marking)
最终标记（Final Marking)
筛选回收（Live Data Counting and Evacuation)：筛选回收阶段首先对各个Rcgion的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划

对象分配：

对象优先在Eden上分配；空间不足Minor GC
大对象直接进入老年代
长期存活对象进入老年代

空间分配担保：在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否天手新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandiePromotionFailure设置值是否允诈担保失败；如果允许，那么会继续检查老年最犬可用的连续空间是否大于历次晋升到老年代对象的平均大示，如果大于；将尝试着进行三次Minor.GC，尽管这次MinorGC是有风险的：如果小于，或HandlePromotionFailure.设置不允许冒险，那这时也要改为进行次FullGC。

4.虚拟机性能监控与故障处理工具

JDK命令工具：

jps：JVM Process Status Tool,显示指定系统内所有的HotSpot 虚拟机进程
jstat：JVM Statistics Monitoring Tool,用于收集HotSpot 虚拟机各方面的运行数据。 jstat -gccause vmid:输出已使用空间占各自总空间的百分比；
jinfo：Configuration Info for Java,显示虚拟机配置信息
jmap：Memory Map for Java,生成虚拟机的内存转储快照（hcapdump文件） jmap -heap vmid:显示堆的详细信息，如参数配置，分代状况;jmap -histo vmid:显示堆中对象统计信息，包括类，实例数量，合计容量。
jhat：JVM Heap Dump Browser，用手分析 heapdump文件，它会建立一个HTFP/HTM-服务器，让用户可以在浏览器上查看分析结果。
jstack：Stack Trace for Java,显示虚拟机的线程快照

JDK可视化工具：

JConsole：
- 1.启动：通过JDK/bin目录下的“jconsole.exe”启动；
- 2.内存监控：“内存”页签相当于可视化的jstat命令，用于监视受收集器管理的虚拟机内存（Java堆和永久代)的变化趋势。
- 3.线程监控：如果上面的“内存”页签相当于可视化的jstat命令的话，“线程”页签的功能相当于可视化的jstack命令，遇到线程停顿时可以使用这个页签进行监控分析。
VisualVM：？？？？
- 1.启动与插件安装
- 2.生成、浏览堆转储快照
- 3.分析程序性能

5.调优案例分析

jvm调优思路：第一步：jps 获取jvm id；第二步：获取jvm垃圾收集器种类第三步：查看gc次数和时间，分析原因来优化 gc次数频繁：①、内存回收率低导致短时间内回收次数多；②、内存大小太小; gc时间长：①、内存过大；②、内存扩展导致时间长（固定内存大小）选择适合的收集器也可大幅度优化jvm。二、优化思路注意点： 1、64位jdk的性能测试结果普遍低于32位jdk； 2、64位jdk由于指针膨胀和数据类型对齐补白导致消耗的内存比32位大； 3、使用nio时，堆外内存不足导致内存溢出。？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

第三部分-虚拟机执行子系统

6.类文件结构

Java程序*.java —— Java编译器 —— 字节码*.class —— java虚拟机

Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在class文件之中，中间没有添加任何分隔符；可以说.class文件是不同的语言在 Java 虚拟机之间的重要桥梁，同时也是支持 Java 跨平台很重要的一个原因。根据 Java 虚拟机规范，类文件由单个 ClassFile 结构组成： ClassFile { u4 magic; //Class 文件的标志 u2 minor_version;//Class 的小版本号 u2 major_version;//Class 的大版本号 u2 constant_pool_count;//常量池的数量 cp_info constant_pool[constant_pool_count-1];//常量池 u2 access_flags;//Class 的访问标记 u2 this_class;//当前类 u2 super_class;//父类 u2 interfaces_count;//接口 u2 interfaces[interfaces_count];//一个类可以实现多个接口 u2 fields_count;//Class 文件的字段属性 field_info fields[fields_count];//一个类会可以有个字段 u2 methods_count;//Class 文件的方法数量 method_info methods[methods_count];//一个类可以有个多个方法 u2 attributes_count;//此类的属性表中的属性数 attribute_info attributes[attributes_count];//属性表集合 } Class文件字节码结构组织示意图

魔数 u4 magic; //Class 文件的标志每个 Class 文件的头四个字节称为魔数（Magic Number）,它的唯一作用是确定这个文件是否为一个能被虚拟机接收的 Class 文件。程序设计者很多时候都喜欢用一些特殊的数字表示固定的文件类型或者其它特殊的含义。 Class 文件版本 u2 minor_version;//Class 的小版本号 u2 major_version;//Class 的大版本号紧接着魔数的四个字节存储的是 Class 文件的版本号：第五和第六是次版本号，第七和第八是主版本号。高版本的 Java 虚拟机可以执行低版本编译器生成的 Class 文件，但是低版本的 Java 虚拟机不能执行高版本编译器生成的 Class 文件。所以，我们在实际开发的时候要确保开发的的 JDK 版本和生产环境的 JDK 版本保持一致。常量池 u2 constant_pool_count;//常量池的数量 cp_info constant_pool[constant_pool_count-1];//常量池紧接着主次版本号之后的是常量池，常量池的数量是 constant_pool_count-1（常量池计数器是从1开始计数的，将第0项常量空出来是有特殊考虑的，索引值为0代表“不引用任何一个常量池项”）。常量池主要存放两大常量：字面量和符号引用。字面量比较接近于 Java 语言层面的的常量概念，如文本字符串、声明为 final 的常量值等。而符号引用则属于编译原理方面的概念。包括下面三类常量：

类和接口的全限定名
字段的名称和描述符
方法的名称和描述符

常量池中每一项常量都是一个表，这14种表有一个共同的特点：开始的第一位是一个 u1 类型的标志位 -tag 来标识常量的类型，代表当前这个常量属于哪种常量类型．访问标志在常量池结束之后，紧接着的两个字节代表访问标志，这个标志用于识别一些类或者接口层次的访问信息，包括：这个 Class 是类还是接口，是否为 public 或者 abstract 类型，如果是类的话是否声明为 final 等等。当前类索引,父类索引与接口索引集合 u2 this_class;//当前类 u2 super_class;//父类 u2 interfaces_count;//接口 u2 interfaces[interfaces_count];//一个雷可以实现多个接口类索引用于确定这个类的全限定名，父类索引用于确定这个类的父类的全限定名，由于 Java 语言的单继承，所以父类索引只有一个，除了 java.lang.Object 之外，所有的 java 类都有父类，因此除了 java.lang.Object 外，所有 Java 类的父类索引都不为 0。接口索引集合用来描述这个类实现了那些接口，这些被实现的接口将按implents(如果这个类本身是接口的话则是extends) 后的接口顺序从左到右排列在接口索引集合中。字段表集合 u2 fields_count;//Class 文件的字段的个数 field_info fields[fields_count];//一个类会可以有个字段字段表（field info）用于描述接口或类中声明的变量。字段包括类级变量以及实例变量，但不包括在方法内部声明的局部变量。 field info(字段表) 的结构:

access_flags: 字段的作用域（public ,private,protected修饰符），是实例变量还是类变量（static修饰符）,可否被序列化（transient 修饰符）,可变性（final）,可见性（volatile 修饰符，是否强制从主内存读写）。
name_index: 对常量池的引用，表示的字段的名称；
descriptor_index: 对常量池的引用，表示字段和方法的描述符；
attributes_count: 一个字段还会拥有一些额外的属性，attributes_count 存放属性的个数；
attributes[attributes_count]: 存放具体属性具体内容。

上述这些信息中，各个修饰符都是布尔值，要么有某个修饰符，要么没有，很适合使用标志位来表示。而字段叫什么名字、字段被定义为什么数据类型这些都是无法固定的，只能引用常量池中常量来描述。方法表集合 u2 methods_count;//Class 文件的方法的数量 method_info methods[methods_count];//一个类可以有个多个方法 methods_count 表示方法的数量，而 method_info 表示的方法表。 Class 文件存储格式中对方法的描述与对字段的描述几乎采用了完全一致的方式。方法表的结构如同字段表一样，依次包括了访问标志、名称索引、描述符索引、属性表集合几项。 method_info(方法表的) 结构:

属性表集合 u2 attributes_count;//此类的属性表中的属性数 attribute_info attributes[attributes_count];//属性表集合在 Class 文件，字段表，方法表中都可以携带自己的属性表集合，以用于描述某些场景专有的信息。与 Class 文件中其它的数据项目要求的顺序、长度和内容不同，属性表集合的限制稍微宽松一些，不再要求各个属性表具有严格的顺序，并且只要不与已有的属性名重复，任何人实现的编译器都可以向属性表中写入自己定义的属性信息，Java 虚拟机运行时会忽略掉它不认识的属性。

7.虚拟机类加载机制

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的。类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification)、准备（Preparation）、解析（Resolution)、初始化（lnitialization）、使用（Using)和卸载（Unloading)7个阶段。其中验证、准备、解析3个部分统称为连接（Linking)

解析在某些时候可能会出现在初始化解读之后，比如运行时绑定必须进行初始化的情况（对一个类的主动引用）：

1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时
2）使用java.lang.reflect包的方法对类进行反射调用的时候
3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main)方法的那个类），虚拟机会先初始化这个主类。
5）当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

加载：

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

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

文件格式验证
元数据验证
字节码验证
符号引用验证

准备：（这里有赋值）

类变量分配内存（方法区中）：内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中；
设置类变量初始值：初始值“通常情况”下是数据类型的零值。
为static final属性的变量赋值；

解析：虚拟机将常量池内的符号引用替换为直接引用的过程

符号引用（Symbolic References)：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。
直接引用（Direct References)：直接引用可以是直接指向目标的指针、相对偏移量是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的。如果有了直接引用，那引用的目标必定已经在内存中存在。

初始化：（这里有赋值）真正开始执行类中定义的Java程序代码（或者说是字节码）。根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器<clinit>方法的过程。

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句(static}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。
<clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。
<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>0方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>）方法不需要先执行父接口的<clinit>（）方法。只在当父接口中定义的变量使用时，父接口才会初始化。
虚拟机会保证一个类的<clinit>(）方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。

类加载器：类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。双亲委派模型：

启动类加载器（Bootstrap ClassLoader)：前面已经介绍过，这个类将器负责将存放<JAVA_HOME>lib目录中的，或者被-Xbootclasspath参数所指定的路径中的
扩展类加载器（Extension ClassLoader）：它负责加载<JAVA_HOME>lib\ext目录中的，或者被 java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
应用程序类加载器（Application ClassLoader)：这个类加载器是ClassLoader中的getSystemClassLoader()方法它负责加载用户类路径(ClassPath)上所指定的类库；开发者可以直接使用这个类加载器

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自记去尝试加载这个类而是把这个请求委派给父类加载器丢完成，每一个层次的类加载器都是如此：因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己丢加载。好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，对Java本身的基础类形成一个保护。例如类 java.larng.Object，它存放在 rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。

8.虚拟机字节码执行引擎

执行引擎是Java虚拟机最核心的组成部分之一。“虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、硬件、指令集和操作系统层面上的，而虚拟机的执行引擎则是由自己实现的，因此可以自行制定指令集与执行引擎的结构体系，并且能够执行那些不被硬件直接支持的指令集格式。运行时栈帧结构：栈帧（Stack Frame)是用于支持虚拟机进行方法调用和方法执行的数据结构，它是虚拟机运行时数据区中的虚拟机栈（Virtual Machine Stack)的栈元素。栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用开始至执行完成的过程，都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。局部变量表局部变量表（Local Variable Table)是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。在Java程序编译为Class文件时，就在方法的Code属性的max locals数据项中确定了该方法所需要分配的局部变量表的最大容量。局部变量和成员变量不一样，局部变量必须要进行赋初始值，没有赋值的局部变量是无法引用的操作数栈操作数栈（Operand Stack）也常称为操作栈，它是一个后入先出（Last In First Out，LIFO)栈。同局部变量表一样，操作数栈的最大深度也在编译的时候写入到Code属性的max_stacks数据项中。操作数栈的每一个元素可以是任意的Java数据类型，包括long和double。32位数据类型所占的栈容量为1，64位数据类型所占的栈容量为2。当一个方法刚刚开始执行的时候，这个方法的操作数栈是空的，在方法的执行过程中，会有各种字节码指令往操作数栈中写入和提取内容，也就是出栈/入栈操作。Java虚拟机是基于栈的执行引擎，其中栈就是指操作数栈

方法调用：

方法调用并不等同于方法执行，方法调用阶段唯一的任务就是确定被调用方法的版本（即调用哪一个方法），暂时还不涉及方法内部的具体运行过程。在程序运行时，进行方法调用是最普遍、最频繁的操作，但Class文件的编译过程中不包含传统编译中的连接步骤，一切方法调用在Class文件里面存储的都只是符号引用，而不是方法在实际运行时内存布局中的大口地址（相当于之前说的直接引用）。

1.解析调用

继续前面关于方法调用的话题，所有方法调用中的日标方法在Class文件里面都是一个常量池中的符号引用，在类加载的解析阶段，会将其中的一部分符号引用转化为直接引用，这种解析能成立的前提是：方法在程序真正运行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。换句话说，调用目标在程序代码写好、编译器进行编译时就必须确定下来。这类方法的调用称为解析（Resolution)。
在Java语言中符合“编译期可知，运行期不可变”这个要求的方法，主要包括静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问，这两种方法各自的特点决定了它们都不可能通过继承或别的方式重写其他版本，因此它们都适合在类加载阶段进行解析。
静态方法、私有方法、实例构造器、父类方法4类在类加载阶段将符号引用转化为直接引用

解析调用一定是个静态的过程，在编译期间就完全确定，在类装载的解析阶段就会把涉及的符号引用全部转变为可确定的直接引用，不会延迟到运行期再去完成。

2.分派调用分派（Dispatch)调用则可能是静态的也可能是动态的，根据分派依据的宗量数可分为单分派和多分派。这两类分派方式的两两组合就构成了静态单分派、静态多分派、动态单分派、动态多分派4种分派组合情况。

2.1静态分派--与方法重载相关，依赖静态类型来判断和执行方法

Human man = new Man()；我们把上面代码中的“Human”称为变量的静态类型（Static Type)，或者叫做的外观类型（Apparent Type)，后面的“Man”则称为变量的实际类型（Actual Type)，静态类型和实际类型在程序中都可以发生一些变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的；而实际类型变化的结果在运行期才可确定，编译器在编译程序的时候并不知道一个对象的实际类型是什么。 //实际类型变化 Human man=new Man(); man=new Woman()； //静态类型变化 sr.sayHel1o((Man)man) sr.sayHello((Woman)man) 虚拟机（准确地说是编译器)在重载时是通过参数的静态类型而不是实际类型作为判定依据的。并且静态类型是编译期可知的，因此，在编译阶段，Javac编译器会根据参数的静态类型决定使用哪个重载版本；所有依赖静态类型来定位方法执行版本的分派动作称为静态分派。静态分派的典型应用是方法重载。静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机来执行的。

2.2动态分派--与方法重写相关，指的就是多态性

运行期确定执行方法的实际类型

2.3单分派与多分派

方法的接收者与方法的参数统称为方法的宗量，根据分派基于多少种宗量，可以将分派划分为单分派和多分派两种。单分派是根据一个宗量对目标方法进行选择，多分派则是根据多于一个宗量对目标方法进行选择。Java语言是一门静态多分派，动态单分派的语言 /* *单分派、多分派演示 *Qauthor zzm / public class Dispatch( static class QQ{} static class _360{} public static class Father{ public void hardChoice(QQ arg){ system.out.println("father choose qg"); } public void hardChoice(_360 arg){ system.out.println("father choose 360"); } public static class Son extends Father{ public void hardChoice(QQ arg){ system.out.print1n("son choose qq"); } public void hardchoice(_360 arg){ system.out.printin("son choose 360"); } public static void main(Stringt]args){ Father father=new Father(); Father son=new Son(); father.hardchoice(new _360())）; son.hardchoice(new QQ()); } } 运行结果： father choose 360 son choose qq 我们来看看编译阶段编译器的选择过程，也就是静态分派的过程。这时选择目标方法的依据有两点：一是静态类型是Father还是Son，二是方法参数是QQ还是360。这次选择结果的最终产物是产生了两条invokevirtual指令，两条指令的参数分别为常量池中指向Father.hardChoice(360)及Father.hardChoice(QQ)方法的符号引用。因为是根据两个宗量进行选择，所以lava语言的静态分派属于多分派类型。再看看运行阶段虚拟机的选择，也就是动态分派的过程。在执行“son.hardChoice(new QQ）”这句代码时，更准确地说，是在执行这句代码所对应的invokevirtual指令时，由于编译期已经决定目标方法的签名必须为hardChoice（QQ)，虚拟机此时不会关心传递过来的参数“QQ”到底是“腾讯QQ”还是“奇瑞QQ”，因为这时参数的静态类型、实际类型都对方法的选择不会构成任何影响，唯一可以影响虚拟机选择的因素只有此方法的接受者的实际类型是Father还是Son。因为只有一个宗量作为选择依据，所以Java语言的动态分派属于单分派类型。根据上述论证的结果，我们可以总结一句：今天（直至还未发布的Java1.8）的Java语言是一门静态多分派、动态单分派的语言。

基于栈的字节码解释执行引擎

Java编译器输出的指令流，基本上是一种基于栈的指令集架构，与此相对的是基于寄存器的指令结构
基于栈的指令结构是可有移植，因为寄存器是和硬件强相关的
基于栈架构指令的主要缺点是执行速度相对较慢一点

第四部分-程序编译与代码优化

10.早期（编译期）优化

javac编译器

java语法糖泛型与类型擦除：

本质是参数化类型（Parametersized Type)的应用，也就是说所操作的数据类型被指定为一个参数。这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口和泛型方法。
Java语言中的泛型只在程序源码中存在，在编译后的字节码文件中，就已经替换为原来的原生类型（Raw Type，也称为裸类型）了，并且在相应的地方插入了强制转型代码，因此，对于运行期的 Java 语言来说，ArrayList<int>与ArrayList<String>就是同一个类，所以泛型技术实际上是Java语言的一颗语法糖，Java.语言中的泛型实现方法称为类型擦除；
泛型擦除前与泛型擦除后：

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

自动装箱、拆箱在编译之后被转化成了对应的包装和还原方法，如Integer.valueOf与Integer.intValue方法
foreach遍历循环则把代码还原成了迭代器的实现，这也是为何遍历循环需要被遍历的类实现lterable接口的原因。
包装类在不遇到算术运算的情况下不会自动拆箱

11.晚期（运行期）优化

java最初只有解释器，后台增加了即时编译器（JIT），能够对运行特别频繁的热点代码进行编译和优化
即时编译对于Java虚拟机规范来说不是必须的

？？？？？？？？？？？？

第五部分-高效并发

12.java内存模型与线程

Java内存模型JMM

Java内存模型的主要目标是定义程序中各个变量的访问规则；即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量（Variables）与java编程中所说的变量有所区别，它包括了实例字段、静态字段和构成数组对象的元素，但不包括局部变量与一方法参数，因为后者是线程私有的，不会被共享，自然就不会存在竞争问题。主内存与工作内存 Java内存模型规定所有的变量都存储在主内存（Main Memory中（此处的主内存：与介绍物理硬件时的主内存名字一样，两者也可以互相类比，但此处仅是虚拟机内存的一部分）。每条线程还自己的工作内存（Working Meimory，可与前面讲的处理器高速缓存类比），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝；线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量”。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成，线程、主内存、工作内存三者的交关系如图:

注：这里所讲的主内存、工作内存与Java内存区域中的Java堆、栈、方法区等并不是同一个层次的内存划分，这两者基本上是没有关系的：如果两者一定要勉强对应起来，那从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。从更低层次上说，主内存就直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机（甚至是硬件系统本身的优化措施）可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。

内存间交互操作关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java内存模型中定义了以下8种操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的（对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许有例外；

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

volatile 当一个变量定义为volatile之后，它将具备两种特性：

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

volatile实现原理：使用Violatile修饰的变量在汇编阶段，会多出一条lock前缀指令，它在多核处理器下回引发两件事情： 1. 将当前处理器缓存行的数据写回到系统内存 2. 这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效。通常处理器和内存之间都有几级缓存来提高处理速度，处理器先将内存中的数据读取到内部缓存后再进行操作，但是对于缓存写会内存的时机则无法得知，因此在一个处理器里修改的变量值，不一定能及时写会缓存，这种变量修改对其他处理器变得“不可见”了。但是，使用Volatile修饰的变量，在写操作的时候，会强制将这个变量所在缓存行的数据写回到内存中，但即使写回到内存，其他处理器也有可能使用内部的缓存数据，从而导致变量不一致，所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期，如果过期，就会将该缓存行设置成无效状态，下次要使用就会重新从内存中读取。在本节的最后，我们回头着下Java内存模型中对volatile变量定义的特殊规则。假定T表示个线程，y和w分别表示两个volatile 型变量：那么在进行read、load、use、asign、store 和write 操作时需要满足如下规则：

只有当线程对变量V执行的前一个动作是load的时候，线程才能对变量V执行use动作：并且只有当线程下对变量：V.执行的后一个动作是use的时候，线程干能对变量V执行ioad动作。线程T对变量的use动作可以认为是和线程对变量V的loadread动作相关联；必须连续一起出现（这条规则要求在工作内存中每次使用V前都必须先主内存刷新最新的值用主保证能看见其他线程对变量V.所做的修改后的值。
只有当线程T对变量V执行的前一个动作是assign 的时候，线程干能对变量V执行store 动作并更有当线程对变量V，执行的后。个动作是store的时候；线程T才能对英量V执行assign动作。线程T对变量V的assign 动作可以认为是和线程T对变：量：y的istores awrite动作相关联，.必须连续起普现（这条规则要求在工作内存中每次修改V后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量V所做的修改）。
假定动作A是线程T对变量V实施的use或assigm动作，：假定动作F是和动作A相关联的load或store动作，假定动作P是和动作下相应的对变量V的rcad或write动作：类似的，假定动作B是线程T对变量W实施的use或asign动作，假定动作G是和动作-B相关联的load或store动作，假定动作Q是和动作G相应的对变量W的read或 write动作。如果A先于B，那么P先于Q（这条规则要求volatile修饰的变量不会被指令重排序优化，保证代码的执行顺序与程序的顺序相同）。

原子性由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write，我们大致可以认为基本数据类型的访问读写是具备原子性的（例外就是long和double的非原子性协定，读者只要知道这件事情就可以了，无须太过在意这些几乎不会发生的例外情况）。如果应用场景需要一个更大范围的原子性保证（经常会遇到），Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块—synchronized关键字，因此在synchronized块之间的操作也具备原子性。

java 并发包中有一些并发框架也使用了自旋CAS的方式来实现原子操作

可见性（Visibility)：可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。上文在讲解 volatile变量的时候我们已详细讨论过这一点。Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此，可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。除了volatile之外，Java还有两个关键字能实现可见性，即synchronized和final。同步块的可见性是由“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）”这条规则获得的；而final关键字的可见性是指：被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把“this”的引用传递出去（this引用逃逸是一件很危险的事情，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那在其他线程中就能看见final字段的值。有序性（Ordering）： Java程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”（Within-Thread As-If-Serial Semantics)，后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。 Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一全变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行地进。

先行发生原则

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

java与线程线程是比进程更轻量级的调度执行单位；线程的引入，可以把一个进程的资源分配和执行调度分，各个线程既可以共享进程资源（内存地址、文件/o等），又可以独立调度（线程是CPU调度的基本单位）。实现线程主要有3种方式：使用内核线程实现、使用用户线程实现、使用用户线程加轻量级进程混合实现。. 1.使用内核线程实现内核线程（Kernel.Lever.Thread，KLT)就是直接由操作系统内核（Kermel，下称内核）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器：（Scheduler）对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统就有能力同时处理多件事情，支持多线程的内核就叫做多线程内核（Multi-Threads Kernel)。程序一般不会直接去使用内核线程，而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process，LWP)，轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1：1的关系称为一对一的线程模型，如图所示。

由于内核线程的支持，每个轻量级进程都成为一个独立的调度单元，即使有一个轻量级进程在系统调用中阻塞了，也不会影响整个进程继续工作，但是轻量级进程具有它的局限性：首先，由于是基于内核线程实现的，所以各种线程操作，如创建、析构及同步，都需要进行系统调用。而系统调用的代价相对较高，需要在用户态（User Mode)和内核态（KernelMode)中来回切换。其次，每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程的数量是有限的。

Java线程调度线程调度是指系统为线程分配处理器使用权的过程，主要调度方式有两种；分别是协同式线程调度（Cooperative Threads-Scheduling）和抢占式线程调度（Preemptive Threads-Scheduling)。

如果使用协同式调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上。协同式多线程的最大好处是实现简单，但是会导致一直阻塞；
如果使用抢占式调度的多线程系统，那么每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定（在Java中，Thread.yield可以让出执行时间，但是要获取执行时间的话，线程本身是没有什么办法的）。在这种实现线程调度的方式下，线程的执行时间是系统可控的，也不会有一个线程导致整个进程阻塞的问题，Java使用的线程调度方式就是抢占式调度。

13.线程安全与锁优化

线程安全：恰当的定义：“当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象是线程安全的”。按照线程安全的“安全程度”由强至弱来排序，我们可以将Java语言中各种操作共享的数据分为以下5类： 1不可变、2绝对线程安全、3相对线程安全、4线程兼容、5线程对立不可变在Java语言中不可变（Immutable)的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再采取任何的线程安全保障措施，只要一个不可变的对象被正确地构建出来（没有发生this引用逃逸的情况），那其外部的可见状态永远也不会改变，永远也不会看到它在多个线程之中处于不一致的状态。“不可变”带来的安全性是最简单和最纯粹的。

线程安全实现方法 1.互斥同步（悲观锁）——加锁互斥同步（MutuaFExclusion &Syncironization)是常见的一种并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区Critical Section)在斥量（Mutex）和信号量（Semaphore）都是主要的互斥实现方式。因此，在这4个字里面，互斥是因，同步是果：互斥是方法，同步是目的。

synchronized关键字
- 在Java中，最基本的同步手段就是synchronized关键字，synchronizcd 关键字经过编译之后，在字节码中会在同步块的前后分别形成monitorenter和monitorexit 这两个字节码指令，这两个字带码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果Java程序中的synchronized 明确指定了对象参数，那就是这个对象的reference；如果没有明确指定，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。
- 在执行monitorenter指令时，首先要尝试获取对象的锁（monitor）。如果这对象没被锁定，或者当前线程已经拥有了那个对象的锁；把锁的计数器加1；相应的在执行monitorexit指令时会将锁计数器减1；当计数器为0时锁就被释放。如果获取对象锁失败，那当前线程就要阻塞等待；直到对象锁被另外一个线程释放。首先，synclironized同步块对同一条线程来说是可重入的，不会出现把自己锁死的问题。其次同步块在已进人的线程执行完之前，会阻塞后面其他线程的进入。
- 任何对象都有一个monitor与之关联，当且一个monitor被持有后，它将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获得对象的锁。
java.util.concurrent（下文称J.U.C中的重入锁(ReentrantLock)来实现同步
- 在基本用法上，ReentrantLock.与synchronized很相似，他们都具备一祥的线程重入特性，只是代码写法上有点区别，一个表现为API层面的互斥锁：lock和unlock方法配合try/finally语句块来完成；另一个表现为原生语法层面的互斥锁。不过，相比：synchronized，ReentrantLock增加了些高级功能，主要有以下3项：等待可中断、可实现公平锁，以及锁可以绑定多个条件。
- 等待可中断是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情，可中断特性对处理执行时间非常长的同步块很有帮助。
- 公平锁是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的，ReentrantLock默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。
- 锁绑定多个条件是指一个ReentrantLock对象可以同时绑定多个Condition对象，而在svnchronizcd中，锁对象的wait）和notify0或notifyAll0方法可以实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外地添加一个锁，而ReentrantLock则无须这样做，只需要多次调用newCondition（）方法即可。

2.非阻塞同步（乐观锁）——CAS 互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步（Blocking Synchronization)。互斥同步属于一种悲观的并发策略，无论共享数据是否真的会出现竞争，它都要进行加锁、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。随着硬件指令集的发展，我们有了另外一个选择：基于冲突检测的乐观并发策略，通俗地说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争用，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断地重试，直到成功为止)，这种乐观的并发策略的许多实现都不需要把线程挂起。使用乐观并发策略需要“硬件指令集的发展”才能进行呢？因为我们需要操作和冲突检测这两个步骤具备原子性，靠什么来保证呢？如果这里再使用互斥同步来保证就失去意义了，所以我们只能靠硬件来完成这件事情，硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成。

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

3.无同步方案——天生线程安全的代码要保证线程安全，并不是一定就要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性的手段，如果一个方法本来就不涉及共享数据，那它自然就无须任何同步措施去保证正确性，因此会有一些代码天生就是线程安全的

可重入代码：可重入代码有一些共同的特征，例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都由参数中传入、不调用非可重入的方法等。我们可以通过一个简单的原则来判断代码是否具备可重入性：如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，那它就满足可重入性的要求，当然也就是线程安全的。
线程本地存储（Thrcad Local Storage)：如果一段代码中所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行？如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。
- 经典Web交互模型中的“一个请求对应一个服务器线程”（Thread-per-Request)的处理方式，这种处理方式的广泛应用使得很多Web服务端应用都可以使用线程本地存储来解决线程安全
- Java.lang.ThreadLocal类来实现线程本地存储的功能。每一个线程的Thread对象中都有一个ThreadLocalMap对象，这个对象存储了一组以ThreadLocal.threadLocalHashCode为键，以本地线程变量为值的K-V值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalllashCode值，使用这个值就可以在线程K-V值对中找回对应的本地线程变量。

锁优化自旋锁

如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。
在JDK1.6中引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。另外，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虚拟机就会变得越来越“聪明”了。

锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持。如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行

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

轻量级锁

轻量级锁是JDK1.6之中加入的新型锁机制，它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就称为“重量级”锁。首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
要理解轻量级锁，以及后面会讲到的偏向锁的原理和运作过程，必须从HotSpot 虚拟机的对象（对象头部分）的内存布局开始介绍。HotSpot虚拟机的对象头（Object Header)分为两部分信息，第一部分用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄（Generational GCAge)等，这部分数据的长度在32位和64位的虚拟机中分别为32bit和64bit，官方称它为“Mark Word”，它是实现轻量级锁和偏向锁的关键。另外一部分用于存储指向方法区对象类型数据的指针，如果是数组对象的话，还会有一个额外的部分用于存储数组长度。

轻量级锁CAS加锁

在代码进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态）-虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record)的空间，用于存储锁对象目前的Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word)，这时候线程堆栈与对象头的状态如图13-3所示。然后，虚拟机将使用CAS操作尝试将锁对象的：Mark Word 更新为指向栈帧中Lock Record的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后2bit)将转变为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图13-4所示。

如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程抢占了。如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。

轻量级锁CAS解锁

如果对象的Mark Word仍然指向着线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来，如果替换成功，整个同步过程就完成了。如果替换失败，说明有其他线程尝试过获取该锁，那就要在释放锁的同时，唤醒被挂起的线程。

偏向锁偏向锁也是JDK1.6中引入的一项锁优化，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。偏向锁的“偏”，就是偏心的“偏”、偏袒的“偏”，它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

偏向锁加锁

当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为“01”，即偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中，如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如Locking、Unlocking 及对Mark Word的 Update等）。

偏向锁升级和消除

当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向（RevokeBias)后恢复到未锁定（标志位为“01”)或轻量级锁定（标志位为“00”）：的状态；后续的同影操作就如上面介绍的轻量级锁那样执行。偏问锁、轻量级锁的状态转化及对象Mark Word的关系如图13-5所示