《深入理解JAVA虚拟机》学习笔记

学习用书为：深入理解Java虚拟机 JVM高级特性与最佳实践（周志明 著）

走进java

JDK：java程序设计语言、java虚拟机、java API类库三者的统称。
JRE：java se API子集和JAVA虚拟机
JAVA体系的四个平台：JAVA Card，Java ME， Java SE， Java EE

自动内存管理机制

程序计数器：
(1)为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
(2)如果执行的是native方法，这个计数器值为空。
java虚拟机栈
(1)生命周期与线程相同
(2)当进入一个方法时，这个方法需要在帧中分配多大的变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
(3)会抛出两种error：StackOverflowError和OutOfMemoryError
本地方法栈：
(1)为虚拟机使用到的Native方法服务
(2)也会抛出StackOverflowError和OutOfMemoryError
Java堆：
(1)在虚拟机启动时创建
(2)几乎所有对象实例都在这里分配内存
(3)垃圾收集器管理的主要区域，也称为“GC堆”
(4)会抛出OutOfMemoryError
方法区：
(1)存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据
(2)别名“非堆”
(3)可以选择不实现垃圾回收
(4)会抛出OutOfMemoryError
运行时常量池(方法区的一部分)：
(1)java虚拟机规范没有做任何细节的要求
(2)会抛出OutOfMemoryError
直接内存：
(1)避免了在java堆和native堆中来回复制数据
(2)会抛出OutOfMemoryError

对象的创建：
分配内存两种方法：
（1）指针碰撞：java堆中内存是绝对规整的时候（比如Serial，ParNew等带Cpmpact过程的收集器时）
（2）空闲列表：java堆中内存并不是规整的时候（比如使用CMS这种基于Mark-Sweep算法的收集器时）

如何保证内存分配的线程安全性
（1）对分配内存空间的动作进行同步处理
（2）把内存分配的动作按照线程划分在不同的空间之中进行

对象的访问定位
(1)句柄访问：在对象被移动时只会改变句柄中示例数据指针，reference本身不需要修改
(2)直接指针访问：速度更快（Sun HotSpot采用的方法）

JAVA堆溢出方法
不断创建对象

虚拟机栈和本地方法溢出
不断创建线程
ps：如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。

方法区和运行时常量池溢出
不断使用String的intern方法增加常量池中的内容
使用CGLib字节码增强和动态语言、大量JSP或动态产生JSP文件应用、基于OSGi的应用。

本机直接内存溢出
一直分配内存就会抛出OutOfMemoryError异常

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

4种垃圾收集算法及7种垃圾收集器
垃圾收集算法
程序计数器、虚拟机栈、本地方法栈3个区域随线程而生而灭，不需要过多考虑回收的问题。
java堆和方法区的内存分配和回收都是动态的，垃圾收集器所关注的是这部分的内存

对象的自我拯救
没有与GC roots相连的引用链，会被第一次标记并进行一次筛选。
finalize方法是对象拯救自己的最后一次机会，只要重新与引用链上的任何一个对象建立关联即可。

引用
强引用 Object obj = new Object();
弱引用 SoftReference
虚引用 WeakReference

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

垃圾收集算法
1、标记-清除算法
2、复制算法
3、标记-整理算法
4、分代收集算法

HotSpot算法的实现
1、枚举根节点是必须要停顿的。不可出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。
2、在“特定的位置”记录了些信息，这些位置称为安全点，程序只有到达安全点才能开始GC
3、如何在GC开始时让进程都跑到安全点：（1）抢先式中断（2）主动式中断
4、安全区域可以看作是扩展了的安全点，在这个区域任何地方开始GC都是安全的

JVM的垃圾收集器

1、Serial收集器
最基本、发展历史最悠久的收集器
单线程的
只会使用一个CPU或一条收集线程去完成垃圾收集工作
收集时必须暂停其他所有的工作线程
简单而高效，因为它没有线程交互的开销
运行在Client模式下的虚拟机来说是一个很好的选择。

2、ParNew收集器
其实就是Serial收集器的多线程版本
除了Serial收集器之外，目前只有它能和CMS收集器配合工作

3、Parallel Scavenge收集器
它的目标与其他收集器不同，是为了达到一个可控制的吞吐量。
自适应调节策略也是它和ParNew收集器的一个重要区别

4、Serial Old收集器
是Serial的老年代版本，也是单线程的
使用“标记-整理”算法
两大用途（1）与jdk1.5以及之前的版本中与Parallel Scavenge搭配使用（2）作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

5、Parallel Old收集器
是Parallel Scavenge收集器的老年代版本
使用多线程和“标记-整理”算法
在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器组合

6、CMS收集器
是一种以获取最短回收停顿时间为目标的收集器
基于“标记-清除”算法
运行过程的四个步骤
（1）初始标记 仅仅标记一下GC roots能直接关联到的对象
（2）并发标记 进行GC Roots Tracing的过程
（3）重新标记 修正并发标记期间，因用户程序继续运作而导致标记变动那部分对象的标记记录
（4）并发清除
缺点：
（1)CMS收集器对CPU资源非常敏感，在并发阶段会因为占用了一部分线程（CPU资源）而导致应用程序变慢，总吞吐量降低
（2）CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生
（3）CMS收集器是基于“标记-清除”算法实现的，收集结束会有大量空间碎片产生

7、G1收集器
G1是一款面向服务端应用的垃圾收集器
特点：
（1）并行和并发
（2）分代收集 能独立管理整个GC堆
（3）空间整合 G1运作期间不会产生内存空间碎片
（4）可预测的停顿
在G1中，新生代和老年代不再是物理隔离的，他们都是一部分Region的集合。
在后台会维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region
G1收集器中，虚拟机都是使用Remembered Set来避免全堆扫描的
G1收集器运作的几个步骤
（1）初始标记
（2）并发标记
（3）最终标记
（4）筛选回收
其过程与CMS收集器的有许多相似之处。

内存分配与回收策略
对象主要分配在新生代的Eden区上，少数情况下也可能会直接分配在老年代中
分配规则不是百分百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中的与内存相关的参数的设置

对象优先在Eden分配，当Eden区没有足够空间进行分配时，虚拟机将会发起一次Minor GC
大对象（需要大量连续内存空间的JAVA对象）直接进入老年代，经常出现大对象容易导致内存还有不少空间时就提前出发垃圾收集以获取足够的连续空间来“安置”他们
长期存活的对象将进入老年代：对象在Eden出生并且经过第一次Minor GC仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设1。对象每在Survivor中熬过一次Minor GC年龄+1，当它的年龄增加到一定程度，就会晋升到老年代中。
如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代。
空间分配担保：在发生Minor GC之前，虚拟机会先检查老年代最大可用连续空间是否大于新生代所有对象的总空间，如果成立则Minor GC是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure是否允许担保失败，如果允许则虚拟机检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小，如果大于则尝试一次Minor GC，尽管这是风险的。如果小于，或者HandlePromotionFailure不允许，则改为进行一次Full GC

新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为JAVA对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快
老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC。经常会伴随着至少一次的Minor GC（不是绝对的）。Major GC的速度一般会比Minor GC慢10倍以上。

虚拟机类加载机制

在java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这会令类加载时稍微增加一些性能和开销，这为java应用程序提供高度的灵活性。java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。

生命周期：加载、验证、准备、解析、初始化、使用、卸载。

对于初始化，严格规定了有且只有五种情况必须立即对类进行“初始化”（对一个类的主动引用）
（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 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
ps：接口中不能使用static{}语句块。

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

加载阶段既可以①使用系统提供的引导类加载器来完成，也可以②由用户自定义的类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式（重写一个类加载器的loadClass()方法）

数组类本身不通过类加载器创建，它是由java虚拟机直接创建的
加载阶段与连接阶段的部分内容是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始

二、验证
这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机要求，并且不会危害虚拟机自身的安全。
（1）文件格式验证
这个阶段的目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个java类型信息的要求。
这个阶段是基于二进制字节流进行的，通过了这个阶段字节流才会进入内存的方法区中进行存储。后面的三个阶段都是基于方法区的存储结构进行的，不会再直接操作字节流。
（2）元数据验证
是对字节码描述的信息进行语义分析，以保证其描述的信息符合java语言规范的要求。
主要目的是对类的元数据信息进行语义校验，保证不存在不符合java语言规范的元数据信息
（3）字节码验证
主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。这个阶段是对类的方法体进行校验分析。
但是一个方法体通过了字节码验证，也不能说明其一定就是安全的。（Halting Problem）
在JDK1.6经过优化后，只需检查StackMapTable属性中的记录是否合法即可。这样将字节码验证的类型推导转变为类型检查从而节省一些时间。
JDK1.7之后，对于主版本号大于50的Class文件，使用 类型检查来完成数据流分析校验则是唯一选择。

三、准备
这阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量的内存都将在方法区中进行分配
这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在java堆中。（通常情况下初始值是零值。特殊情况：类字段的字段属性表中存在ConstantValue属性（比如final））

四、解析
这阶段是虚拟机将常量池内的符号引用替换为直接引用的过程
符号引用：以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。
直接引用：可以试直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。

对于一个符号引用进行多次解析请求是常见的事情，虚拟机实现可以对第一次解析的结果进行缓存从而避免解析动作重复进行（invokedynamic指令除外）
invokedynamic指令的目的本来就是用于动态语言支持，“动态”的含义就是必须等到程序实际运行到这条指令的时候，解析动作才能进行。其余可触发解析的指令都是”静态“的。

1.类或接口的解析
2.字段解析
3.类方法解析
4.接口方法解析

五、初始化
在此阶段才真正执行类中定义的java程序代码
<clinit>()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现顺序所决定的。
静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的语句块可以赋值但不能访问。
虚拟机会确保子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕

<clinit>()对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法
接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义变量被使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步。

类加载器
虚拟机设计团队把加载阶段中的”通过一个类的全限定名来获取定义此类的二进制字节流“这个动作放到java虚拟机外部去实现，以便让应用程序自己确定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”

对于每一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

双亲委派模型
两种不同的类加载器
（1）启动类加载器：C++实现，是虚拟机的一部分
（2）所有其他的类加载器：java语言实现，独立于虚拟机外部，并且都继承自抽象类java.lang.ClassLoader

启动类加载器：加载<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机是别的类库。无法被java程序直接引用
扩展类加载器：加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。开发者可以直接使用扩展类加载器
应用程序类加载器：加载用户类路径（ClassPath）上所指定的类库。开发者可以直接使用扩展类加载器

双亲委派模型：除了顶层的启动类架子啊其外，其余的类加载器都应到由自己的父亲类加载器。这里的父子关系一般不会以继承的关系实现，而都使用组合关系来复用父加载器的代码。

所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载（越基础的类由越上层的加载器进行加载）。

破坏双亲委派模型
JNDI服务：线程上下文类加载器
为了程序的动态性：代码热替换（HotSwap），模块热部署（Hot Deployment）。