2. 深入java虚拟机

第二部分 自动内存管理机制

2. java内存区域

    程序计数器（线程私有，一个线程一个，可以看作当前线程所执行字节码的行号指示器）

    虚拟机栈（线程私有，每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。）

    本地方法栈（线程私有，为虚拟机使用到的Native方法服务）

    java堆  （共享，对象和数组，垃圾回收的主要区域）

    方法区  （线程共享，存储已被虚拟机加载的类信息，常量，静态变量，即时编译器编译后的代码）(这区域的内存回收目标主要是针对常量池的回收和对类型的卸载)

        运行时常量池    （编译期生成的字面量和符号引用，翻译出来的直接引用）

    直接内存    （不是java虚拟机规范中定义的内存，可以使用native函数库分配堆外内存，通过java堆中的对象操作这块内存）

栈帧：用于存储局部变量表、操作数栈、动态链接、方法出口等信息

局部变量表存储了编译期可知的各种基本数据类型，引用类型和returnAddress类型（一个字节码指令的地址）

PermGen 最终被移除，方法区移至 Metaspace，字符串常量移至 Java Heap

很多文章里喜欢把方法区等同与永久代，永久代既然没了，方法区也就没了。但我认为方法区只是一种逻辑上的概念，永久代指物理上的堆内存的一块空间，这块实际的空间完成了方法区存储字节码、静态变量、常量的功能等等。既然如此，现在元空间也可以认为是新的方法区的实现了。

方法区也叫永久代。在过去（自定义类加载器还不是很常见的时候），类大多是”static”的，很少被卸载或收集，因此被称为“永久的(Permanent)”。虽然Java
虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java
堆区分开来。同时，由于类class是JVM实现的一部分，并不是由应用创建的，所以又被认为是“非堆(non-heap)”内存。HotSpot
虚拟机的设计团队选择把GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEA JRockit、IBM J9
等）来说是不存在永久代的概念的

JDK8 之前，Hotspot 中方法区的实现是永久代（Perm），JDK8 开始使用元空间（Metaspace），以前永久代所有内容的字符串常量移至堆内存，其他内容移至元空间，元空间直接在本地内存分配。

对象揭秘

对象的创建：

1. new ，查找类的引用，找不到则加载类
2. 分配内存（指针碰撞或空闲列表）
3. 初始零值
4. 对象头（哪个类的实例，哈希码，gc年龄等）设置
5. 初始化值

对象的内存布局（对象头，实例数据，填充数据）
对象头包括两部分信息，

1. 用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等
2. 类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例

对象的访问定位（句柄和直接引用（快））

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

对象已死吗（引用）

引用计数器法（存在循环引用的问题）
可达性分析算法（GC Roots）
	虚拟机栈（栈帧中的本地变量表）中引用的对象
	方法区中类静态属性引用的对象
	方法区中常量引用的对象
	本地方法栈中JNI（即一般说的Native方法）引用的对象

引用

jdk1.2之前：如果reference类型的数据中存储的数值代表另外一块内存中的起始地址，就称这块内存代表着一块引用
jdk1.2之后
	强引用
	软引用：还有用但并非必需的对象，在系统将要发生内存溢出之前，会将这些对象列进回收范围之内进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常
	弱引用：关联的对象只能生存到下一次垃圾回收之前
	虚引用：无法通过虚引用取得对象实例，唯一作用是被垃圾回收时收到一个系统通知

生存还是死亡

两次标记过程
第一次标记且筛选，可达性分析发现没有与GC roots相连接的引用链，第一次标记且筛选，筛选是判断有没有必要执行finalize（）方法（判断依据是若没有重写finalize或者finalize已经被执行过则没必要执行），
若有必要（若无必要，就删除），放入F-Queue队列，gc对F_Queue的对象进行第二次，如果还没有引用，就被删除

回收方法区

垃圾收集效率较低，回收废旧的类和常量

垃圾收集算法

 标记-清除算法   （效率不高，内存碎片）
 复制算法    新生代使用 （eden和survivor默认比例8：1：1，将eden和survivor存活的对象一次性复制到另一个survivor空间，但是没法保证每次回收只有不多于10%的对象存活，此时对象需要放入老年代）
 标记-整理算法   老年代使用（与标记-清除算法一样，但不是清除，而是让存活对象往一端移动，然后清理掉端边界以外的内存）
 分代收集算法    将内存分为新生代（使用复制算法）和老年代（使用标记清除或标记整理算法）几块

hotspot算法实现

可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行——这点是导致GC进行时必须停顿所有Java执行线程的重要原因之一

执行系统停顿下来后，并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用。在HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在oopmap的帮助下，能快速完成gc roots的枚举

安全点
HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的位置”记录了这些信息，这些位置称为安全点（Safepoint），即可能导致引用关系发生变化的点，即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停

，“长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生Safepoint。

垃圾收集器 （收集算法的实现）

serial收集器 （串行，单线程，虚拟机运行在Client模式下的默认新生代收集器）

parNew收集器 （serial的多线程版本，cms默认的配合的收集器）

parallel scavenge收集器（与parNew很像，多线程，新生代，复制算法）关注点不同，关注吞吐量而不是减少gc卡顿，后台运算不需太多交互

   有个 -XX:UseAdaptiveSizePolicy参数

serial old收集器 （serial的老年代版本）

parallel old收集器（parallel scavenge的老年代版本）

CMS收集器（以最短回收停顿时间为目标，用户体验好），分为四个阶段，其中并发标记和并发清理过程与用户线程一起执行

G1收集器（垃圾回收范围缩小到一个个region）

内存分配与回收策略

对象优先在eden区中分配

大对象直接进入老年代

长期存活的对象将进入老年代

   通过一次minor GC年龄增加1，默认增加到15移入老年代，可通过-XX:MaxTenuringThreshold=数值 配置

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

4.2 jdk命令行工具
jps：与top或者ps -aux |grep java 显示的效果一样，但是需要有文件的读写权限，否则显示不了

jstat：显示虚拟机统计信息，如gc状况（jstat -gc 17236）

jinfo：java配置信息（实时查看和调整虚拟机运行参数）（jinfo -flag SurvivorRatio 17236）

jmap：java内存映像工具（生成堆dump文件）（jmap -dump:file=zgh 17236）

jstack：java堆栈分析工具（生成线程快照）（jstack 17236）

4.3 jdk的可视化工具
JConsole

JVisualVM

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

6. 类文件结构

无关性的基石

字节码命令所能提供的语义描述能力肯定会比Java语言本身更加强大。因此，有一些Java语言本身无法有
效支持的语言特性不代表字节码本身无法有效支持

class文件结构

1. 魔数（文件类型，类似windows的后缀名）和class文件版本（支持的jdk版本）
2. Class文件是一组以8位字节为基础单位的二进制流,实际上它并不一定以磁盘文件的形式存在

7. 类加载机制

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
与那些在编译时需要进行连接工作的语言不同，在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略虽然会令类加载时稍微增加一些性能开销，但是会为Java应用程序提供高度的灵活性，Java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。例如，如果编写一个面向接口的应用程序，可以等到运行时再指定其实际的实现类；用户可以通过Java预定义的和自定义类加载器，让一个本地的应用程序可以在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分，这种组装应用程序的方式目前已广泛应用于Java程序之中。从最基础的Applet、JSP到相对复杂的OSGi技术，都使用了Java语言运行期类加载的特性。

解析可能在初始化之后（动态绑定，晚绑定）

触发初始化的要求：对一个类进行主动引用

接口与类初始化的不同之处：对接口初始化时，不要求其父接口已经初始化，只有在真正使用时才进行初始化

加载

在加载阶段，虚拟机需要完成以下3件事情：
1）通过一个类的全限定名来获取定义此类的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在内存中生成一个代表这个类的java.lang.Class对象，作为程序访问这个类的各种数据的访问入口。

验证

目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
1）文件格式验证
2）元数据验证（语义分析，是否有父类，是不是抽象类，实现了所有方法）
3）字节码验证（类型转换，跳转）
4）符号引用验证（访问性，符号找到相应的类）

准备

准备阶段是正式为类变量（static）分配内存并设置类变量初始值（零值）的阶段

解析

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

初始化

类加载器

双亲委派模型

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

类加载器被破坏的场景

1. jdk1.2才出现双亲委派，历史原因
2. spi服务（service provider interface），父类加载器请求子类加载器完成类加载动作，java中涉及spi的加载动作使用这种方式，如jdbc
3. 热部署需要打破双清委派模型（OSGI）

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

运行时栈帧结构

栈帧（Stack Frame）是用于支持虚拟机进行方法调用和方法执行的数据结构，它是虚拟机运行时数据区中的虚拟机栈（Virtual Machine Stack）的栈元素。栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息。每一个方法从调用开始至执行完成的过程，都对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。

1. 局部变量表（方法参数和方法内部定义的局部变量）
2. 操作数栈（算术运算，调用其他方法）
3. 动态连接（运行时符号引用转为直接引用）
4. 方法返回地址
5. 附加信息

方法调用

1. 解析（调用目标在程序代码写好、编译器进行编译时就必须确定下来。这类方法的调用称为解析）
2. 分派（继承、封装和多态）

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

解释执行（中间那条分支，java采用的）

基于栈的指令集(可移植，简单)与基于寄存器的指令集(快)
基于栈的解释器执行过程

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

Java语言的“编译期”其实是一段“不确定”的操作过程，因为它可能是指一个前端编译器（其实叫“编译器的前端”更准确一些）把*.java文件转变成*.class文件的过程；也可能是指虚拟机的后端运行期编译器（JIT编译器，Just In Time Compiler）把字节码转变成机器码的过程
Java中即时编译器在运行期的优化过程对于程序运行来说更重要，
前端编译器在编译期的优化过程对于程序编码来说关系更加密切

10. 早期（编译期）优化(javac编译器，生成字节码)

语法糖
自动拆箱，装箱

11. 晚期（运行期）优化（即时编译器，生成机器码）

解释器与编译器

解释器与编译器两者各有优势：当程序需要迅速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行。在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获取更高的执行效率。当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。

编译对象与触发条件

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

1. 被多次调用的方法。
2. 被多次执行的循环体。

热点探测（计数器）
基于计数器的热点探测方法，因此它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）。

编译过程

Client Compiler

Server Compiler
而Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，也
是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度，它会执行所
有经典的优化动作，

编译优化技术

概述

1. 方法内联（去除方法调用的成本（如建立栈帧等））
2. 冗余访问消除
3. 复写传播
4. 无用代码消除

代表性优化技术

1. 公共子表达式消除
2. 数组边界检查消除
3. 方法内联
   方法内联的优化行为看起来很简单，不过是把目标方法的代码“复制”到发起调用的方法之中，避免 发生真实的方法调用而已。但实际上Java虚拟机中的内联过程远远没有那么简单，因为如果不是即时编译器做了一些特别的努力，按照经典编译原理的优化理论，大多数的Java方法都无法进行内联。(对于一个虚方法，编译期做内联的时候根本无法确定应该使用哪个方法版本)
4. 逃逸分析
   逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他方法中，称为方法逃逸，如果能证明一个对象不会逃逸到方法或线程之外，也就是别的方法或线程无法通过任何途径访问到
   这个对象，则可能为这个变量进行一些高效的优化，如：
   1. 栈上分配（减少垃圾回收的压力）
   2. 同步消除（无法被其他线程访问，那这个变量的读写肯定就不会有竞争，不用加锁）
   3. 标量替换（把一个Java对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换）

Java与C/C++的编译器对比

Java与C/C++的编译器对比实际上代表了最经典的即时编译器与静态编译器的对比
Java语言的这些性能上的劣势都是为了换取开发效率上的优势而付出的代价，动态安全、动态扩展、垃圾回收这些“拖后腿”的特性都为Java语言的开发效率做出了很大贡献。

第五部分　高效并发

12. Java内存模型与线程

Java虚拟机规范中试图定义一种Java内存模型[1]（Java Memory Model,JMM）来屏蔽掉各种硬件和
操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果

12.3 Java内存模型

主内存与工作内存(类似上图主内存和高速缓存)

• 从变量、主内存、工作内存的定义来看，主内存主要对应于Java堆中的对象实例数据部分[6]，而工作内存则对应于虚拟机栈中的部分区域。
• 从更低层次上说，主内存就直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机（甚至是硬件系统本身的优化措施）可能 会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。

内存间交互操作（即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节）

对volatile特殊规则（保证此变量对所有线程的可见性，重排序）

long和double型变量

Java内存模型虽然允许虚拟机不把long和double变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为具
有原子性的操作，而且还“强烈建议”虚拟机这样实现

原子性、可见性与有序性

  - 原子性（基本数据类型的访问读写是具备原子性，synchronized）
  - 可见性（volatile，synchronized，final）
  - 有序性（volatile，synchronized） 

先行发生原则（操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被操作B观察到）

  - 程序次序原则（在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作）
  - 管程锁定规则（一个unlock操作先行发生于后面对同一个锁的lock操作）
  - volatile（对一个volatile变量的写操作先行发生于后面对这个变量的读操作）
  - 线程相关
  - 传递性

12.4 java与线程

线程的实现

Thread类与大部分的Java API有显著的差别，它的所有关键方法都是声明为Native的。在Java API中，一个Native方法往往意味着这个方法没有使用或无法使用平台无关的手段来实现

实现线程主要有3种方式：使用内核线程实现、使用用户线程实现和使用用户线程加轻量级进程混合实现。

1. 内核线程（Kernel-Level Thread,KLT）就是直接由操作系统内核（Kernel，下称内核）支持的线程，这种线程由内核来完成线程切换,但是程序一般不会直接去使用内核线程，而是去使用内核线程的一种高级接口——轻量级进程（LightWeight Process,LWP）,这种轻量级进程与内核线程之间1:1的关系称为一对一的线程模型
   
   缺点

• 基于内核线程，系统调用，上下文切换
• 每个轻量级进程都需要有一个内核线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程的数量是有限的

2. 使用用户线程（UT,User Thread）实现 （缺点：线程的创建、切换和调度都是需要考虑的问题）
   狭义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知线程存在的实现。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助
   
3. 使用用户线程加轻量级进程混合实现。

4. java线程的实现
   Windows版与Linux版都是使用一对一的线程模型实现的
   而在Solaris平台中，由于操作系统的线程特性可以同时支持一对一（通过Bound Threads或Alternate Libthread实现）及多对多（通过LWP/Thread Based Synchronization实现）的线程模

Java线程调度

1. 协同式线程调度（线程的执行时间由线程本身来控制）
   一个进程坚持不让出CPU执行时间就可能会导致整个系统崩溃
2. 抢占式线程调度（线程优先级，不太靠谱，原因是Java的线程是通过映射到系统的原生线程上来实现的，所以线程调度最终还是取决于操作系统）

13. 线程安全与锁优化

线程安全

Java语言中的线程安全

1. 不可变(final)
2. 绝对线程安全(Vector,所有的方法都被修饰成同步，也不意味着调用它的时候永远都不再需要同步手段了,并发读写)
3. 相对线程安全（Vector，HashTablle）
4. 线程兼容（并不是线程安全，HashMap）
5. 线程对立

线程安全的实现方法

1. 互斥同步（互斥是因，同步是果，synchronized，ReentrantLock悲观）
   ReentrantLock（等待可终端，公平锁，绑定多个条件）
2. 非阻塞同步（CAS，AtomicInteger）
3. 无同步方案 （可重入代码，只要输入了相同的数据，就都能返回相同的结果，ThreadLocal）

锁优化

1. 自旋锁与自适应自旋（阻塞线程，挂起线程和恢复线程的操作都需要转入内核态中完成，此时自旋更好）
   自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的
2. 锁消除（虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除）
   如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行
3. 锁粗化（如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。）
4. 轻量级锁（CAS，自旋换取锁，达到一定次数升级）

对象头两部分信息

• 对象自身的运行时数据，如哈希码，GC分代年龄，锁信息
• 存储指向方法区对象类型数据的指针
  

5. 偏向锁（如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步）
6. 重量级锁（synchronized，ReentrantLock）

参数

-Xms 初始内存

-Xmx 最大内存

-Xmn 新生代内存

-XX:PermSize JVM初始分配的非堆内存

-XX:MaxPermSize=128M JVM最大允许分配的非堆内存，按需分配

-XX:SurvivorRatio = 8 新生代Eden和Survivor比例8：1

-XX:PretenureSizeThreshold=数值 大于数值的对象直接在老年代分配

Minor GC 新生代GC

Major/Full GC 老年代GC