深入理解jvm虚拟机二

缺乏、安全感 2022-01-12 00:59 400阅读 0赞

在上一篇[深入理解jvm虚拟机一][jvm]中说了Jvm几种垃圾回收算法，针对年代不同，Jvm为我们提供了几种垃圾收集器。

# 垃圾收集器 #

Java为我们提供了很多垃圾收集器，Young为新生代所选择的，Tenured为老年代所选，可以相互配合使用，没有最好的收集器，只有最适合的。如图所示：

## Serial（单线程、复制算法） ##

Serial是最基本的垃圾回收器，它是一个单线程的收集器，不但只会使用一个CPU或一条线程去完成垃圾收集，更重要的是它在进行收集时，必须暂停其他所有的线程，直到垃圾回收完毕，因为不需要线程间切换，可以获得更高效的执行效率，因此**它也是Java虚拟机运行在Client模式下默认新生代垃圾收集器**。

## ParNew（Serial+多线程） ##

ParNew其实是Serial多线程版本，也是使用复制算法，除了使用多线程进行垃圾收集以外，其他跟Serial一样，在进行垃圾收集过程中也需要停止所有其他线程操作，默认开启跟CPU数目相同的线程数（**ParallelGCThreads**设置数量）。**它是多数Java虚拟机运行在Server模式下默认新生代垃圾收集器。**

## Parallel Scavenge （多线程复制算法、高效） ##

Parallel也是新生代的垃圾回收器，同样才用复制算法，但是它是重点**关注一个可控制的吞吐量**（CPU 用于运行用户代码 的时间/CPU 总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），可以有效提高CPU使用率，尽快的完成运算，偏向于后台计算而不需要太多交互，**自适应调节策略也是 Parallel 与 ParNew 的一个重要区别**。

## Serial Old （单线程标记整理算法 ） ##

Serial Old是Serial垃圾收集器的老年代版本，同样是一个单线程的收集器，使用标记整理算法，主要是运行在Client模式下老年代的垃圾收集器，如果在Server模式下，还有两个功能：在 JDK1.5 之前版本中与新生代的 Parallel Scavenge 收集器搭配使用；作为年老代CMS备用垃圾收集器，在并发收集发生“Concurrent Mode Failure”时使用。

## Parallel Old （多线程标记整理算法） ##

Parallel Old是Parallel老年代垃圾回收器，使用多线程标记整理算法，在Jdk1.6以前Parallel只能配合Serial Old使用，无法保证整体的吞吐量，Parallel Old 是为了提高老年代吞吐量而提供的。

## CMS（多线程标记清除算法） ##

Concuuent mark sweep是一种年老代垃圾收集器，主要**目标是获取最短垃圾回收停顿时间**，和其他老年代标记整理不一样，它使用的多线程标记清除，最短垃圾回收停顿时间可以为频繁交互的程序提高用户体验。整个过程为以下四步

**1. 初始标记：只是标记roots能直接关联到的对象，速度很快，需要暂停其他线程。 2. 并发标记：进行roots跟踪的过程，和用户线程一起工作，不需要暂停其他线程。 3. 重新标记：为了修正在并发标记时，用户操作产生变动的一部分对象引用标记记录，需要暂停其他线程。 4. 并发清除：清除不可达对象，和用户线程一起工作，不需要暂停其他线程。** 由于是使用是标记清除，可能出现“**Concurrent Mode Failure**”失败而导致一次Full GC，由于CMS在并发清除的时候还会有垃圾进来，如果CMS预留空间无法满足程序需要，虚拟机就会启动备用方案：**临时启用Serial old收集器回收老年代资源**，这样停顿时间就会更长，因此还需要留有空间来存储垃圾，不能等到老年代被填满了在进行GC，设置**CMSInitiatingOccupancyFraction**（默认是92），只有达到这个峰值才会进行垃圾回收，配合**UseCMSInitiatingOccupancyOnly**一起使用，只有CMSInitiatingOccupancyFraction设置后才会生效，如果不指定CMSInitiatingOccupancyFraction，JVM仅在第一次使用设定值，后续则自动调整。 **CMS无法浮动垃圾会产生碎片**，如果碎片很多，无法放入大对象，不得不提前触发一次Full GC，为了防止这种情况出现，CMS提供了**UseCMSCompactAtFullConllection**开关参数（默认开启），用于顶不住要Full GC的时候来进行内存碎片整合。由于碎片整合是无法并发的，空间问题解决了但是停顿时间就长了，还需要设置**CMSFullGCBeforeCompaction**（默认0次，表示每次次Full GC的时候都会压缩），这个参数设置多少次不压缩Full GC后，然后来一次带压缩的。

## G1（多线程标记整理算法） ##

Garbage first（UseG1GC ）收集器是当今收集器技术发展的最前沿成果之一，它是一款面向服务端应用的垃圾回收器，相对比CMS，G1是两个优点：**1.基于标记-整理，不会产生碎片。2.可以非常精确控制停顿时间（XX:MaxGCPauseMillis），在不牺牲吞吐量的情况下，实现低停顿垃圾回收**。它将整个堆分为若干个大小相等的独立区域（Region）（Eden区 Survivor区 Old区 Humongous区）Humongous为放至巨型对象，虽然保留新生代和老年代概念，但是不再是物理隔离，它们都是一部分Region（不需要连续）的集合。

# 类加载机制 #

## 加载时机 ##

类从加载到虚拟机内存中开始，到从内存中卸载，它的整个生命周期包括：**加载、连接（验证、准备、解析）、初始化、使用、卸载。** 加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类加载必须按照这种顺序来加载，而解析就不一定了，它在某些情况下可以在初始化后再开始，符合Java语言的运行时绑定。

### 加载 ###

**会在内存中生成一个这个类的Class对象，作为方法区这个类的各种数据入口**。这里的并不是从Class文件中获取，既可以从ZIP包中读取（jar、war），也可以在运行时动态生成，也可以从其他文件生成（JSP转为Class对象）。

### 验证 ###

**是为了确保Class文件的字节流包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身**。分为四个阶段完成： **1. 文件格式验证：验证字节流是否符合Class文件格式规范。 2. 元数据验证：验证字节流的信息是否符合Java语言规范要求。 3. 字节码验证：确定程序语义是合法的、符合逻辑的。 4. 符合引用验证：对常量池中符号引用的信息进行匹配性校验。**

### 准备 ###

**是为类变量分配内存并初始值的阶段。** 类变量即被static修饰的变量，不包括实例变量。注意这里所说的初始值概念，比如一个类变量定义为：public static int a = 8080；实际上变量 a 在准备阶段过后的初始值为 0 而不是 8080，将 v 赋值为 8080 的 put static 指令是程序被编译后，存放于类构造器**client**方法之中。但是注意如果声明为：public static **final** int a = 8080；在编译阶段会为 a 生成 ConstantValue 属性，在准备阶段虚拟机会根据 ConstantValue 属性将 a 赋值为 8080。

### 解析 ###

**虚拟机将常量池中的符合引用替换为直接引用**。符号引用可以看成一个标识，比如一个方法、接口等，直接引用则是指向内存中的地址。

### 初始化 ###

类加载最后一个阶段，除了加载可以自定义累加器之外，其他都是由JVM自动完成，到了初始化阶段，才开始真正的执行类中Java代码。特别注意以下情况并**不会触发初始化**： **1. 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。 2. 定义对象数组，不会触发该类的初始化。 3. 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。 4. 通过类名获取 Class 对象，不会触发类的初始化。 5. 通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。 6. 通过 ClassLoader 默认的 loadClass 方法，也不会触发初始化动作。**

> 第一种情况：
> 
> 输出结果： I am father 1

> 第二种情况：
> 
> 无任何输出

> 第三种情况
> 
> 输出结果：1

## 类加载器 ##

对于一个类来说，都需要由加载它的类加载器和这个类本身一同确立在Java虚拟机中的唯一性。在比较两个类是否相等，只有在同一个类加载器加载的情况下才有意义。JVM提供了三种类加载器：

### 启动类加载器（Bootstrap ClassLoader） ###

负责加载JAVA\_HOME\\lib目录中的或通过设置-XbootClassPath参数指定的路径中的，并且是虚拟机识别（按文件名识别）的类库加载到虚拟机内存中。

### 扩展类加载器（Extension ClassLoader） ###

负责加载JAVA\_HOME\\lib\\ext目录中的或者通过 java.ext.dirs系统变量指定路径中的类库。

### 应用程序类加载器（Application ClassLoader） ###

负责加载用户路径（ClassPath）下的类库。 **JVM通过双亲委派模型进行类加载**，当然我们也可以继承ClassLoader实现自定义类加载器。

# 双亲委派 #