深入理解jvm虚拟机二-CSDN博客

在上一篇深入理解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 方法，也不会触发初始化动作。