JVM虚拟机简介 | JVM运行时的数据区 | 对象的分配、布局和访问 | 垃圾收集器和内存分配策略

本文链接：https://blog.csdn.net/qq_43167873/article/details/121809063

深入理解JVM虚拟机

1.JVM简介

1. 什么是JVM？

JVM - （Java Virtual Environment ，Java虚拟环境），是Java虚拟机，是用来执行java字节码的虚拟计算机，Java程序是需要在虚拟机上运行的，不同的平台有自己的虚拟机，因此Java可以实现跨平台

2.JVM、JRE和JDK的关系是什么？

JRE - （Java Runtime Environment ，Java运行时环境），是Java程序所必须的环境的集合，包括Java虚拟机和Java程序所需要的核心类库等。核心类库有java.lang包：包含了Java程序必不可少的系统类
JDK - （Java Development Kit ，Java开发工具包），提供给Java开发人员使用，其中包含了Java开发工具，也包括了JRE。如果这台机只运行Java程序，则不需要安装JDK只需要安装JRE即可

3.Java的跨平台性

跨平台：由Java编写的程序可以在不同的操作系统上运行：一次编写，多处运行。
原理：编译之后的字节码文件和平台无关，需要在不同的操作系统上安装一个对应版本的虚拟机(JVM)
实现原理：只要该系统可以安装相应的虚拟机，那么该系统就可以运行Java程序

2.JVM运行时的数据区

Java 虚拟机在执行 Java 程序的过程中会把它管理的内存划分为若干个不同的数据区域。每个区域都有各自的作用。

分析 JVM 内存结构，主要就是分析 JVM 运行时数据存储区域。JVM 的运行时数据区主要包括：堆、栈、方法区、程序计数器等。而 JVM 的优化问题主要在线程共享的数据区中：堆、方法区。

私有

程序计数器

程序计数器，是一块较小的内存空间，记录的是正的是正在执行的虚拟机字节码指令的地址。字节码解释器工作时，就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，完成程序的流程控制。
JVM多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的。在一个确定的时刻，一个处理器（或者说多核处理器的一个内核）只会执行一条线程中的命令。因此，为了正常的切换线程(上下文切换)，每个线程都会有一个独立的程序计数器，各线程的程序计数器不会互相影响。这个私有的程序计数器所占的这块内存即是线程的“私有内存”。
如果线程正在执行的是一个java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果是正在执行一个本地方法，那么还珠格格计数器的值则为空

Java 虚拟机栈

Java 虚拟机栈由一个个栈帧组成，每个方法被执行时，Java 虚拟机都会同步创建一个栈帧。一个方法从开始被调用到执行完毕，对应的就是，一个栈帧在虚拟机中入栈到出栈的过程。

栈帧 - Stack Frame,用于存储局部变量表，操作数栈，动态连接，方法出口等信息。

局部变量表：存放编译期间可知的各种 Java 虚拟机基本数据类型(int, boolean, char, short, byte, long, float, double)，对象引用和 returnAddress 类型（指向了一条字节码指令的地址）。这些数据类型在局部变量表中以局部变量槽来表示，在编译期间，局部变量所需的空间就会完成分配，动态运行期间不会改变所需的空间。

当进入一个方法时，这个方法需要再栈帧中分配多大的局部变量空间是完全确定的。
操作数栈：操作数栈就是用来操作的，例如代码中有个 i = 6*6，他在一开始的时候就会进行操作，读取我们的代码，进行计算后再放入局部变量表中去
动态链接：假如我方法中，有个 service.add()方法，要链接到别的方法中去，这就是动态链接，存储链接的地方。
出口：出口是什呢，出口正常的话就是return 不正常的话就是抛出异常

本地方法栈：

为虚拟机使用到的本地方法native 方法服务，其余的同 Java 虚拟机栈。

公有

Java 堆

Java堆是虚拟机管理的内存中最大的一块存储区域，是被线程共享的一块区域。
Java堆在虚拟机启动时创建，是垃圾收集器管理的内存区域。垃圾收集器就是根据GC算法，收集堆上对象所占用的内存空间（收集的是对象占用的空间而不是对象本身）。
Java堆的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存
Java堆可以分为:新生代和老年代
线程共享的Java堆中可以划分出多个线程私有的分配缓冲区，无论怎么划分，都与存放内容无关，无论哪个区域，存储的都是对象实例，进一步的划分都是为了更好的回收内存，或者更快的分配内存。
根据Java虚拟机规范，堆所在的物理内存区间可以是不连续的，只要逻辑连续就可以。实现时既可以是固定大小，也可以是可扩展的。如果堆无法扩展时，就会抛出OutOfMemoryError异常。

方法区

方法区和堆一样是各个线程所共享的内存区域
方法区用于存储已经被虚拟机加载的类型信息，常量，静态变量，即时编译器编译后的代码缓存等数据。
方法区存在于永久代，可以说方法区是接口，是规范，永久代是 HotSpot 虚拟机给出的实现

运行时常量池

运行时常量池是方法区的一部分，Class文件中有类的版本，字段，方法，接口等描述信息外，还有一项信息就是常量池表，用于存放编译期生成的各种字面量和符号引用。这部分内容将在类加载后存放到方法区的运行时常量池中。运行时常量池具有动态性，运行期间也可以将新的常量放入。
这种被特性被开发人员用的较多的事String类和intern()类

直接内存

直接内存不是虚拟机运行时数据区的一部分，也不是java虚拟机规范中定义的内存区域。但是既然是内存，肯定还是受本机总内存（包括RAM以及SWAP区或者分页文件）大小以及处理器寻址空间的限制。
在JDK1.4 中新加入了NIO(New Input/Output)类，引入了一种基于通道(Channel)与缓冲区（Buffer）的I/O 方式，它可以使用native 函数库直接分配堆外内存，然后通脱一个存储在Java堆中的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native（本地）堆中来回复制数据。

直接内存和堆内存的区别

直接内存申请空间耗费很高的性能，堆内存申请空间耗费比较低
直接内存的IO读写的性能要优于堆内存，在多次读写操作的情况相差非常明显

3.虚拟机对象分配、布局和访问

3.1对象的创建

类加载检查 :

当Java虚拟机遇到一条字节码new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

分配内存：

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务实际上便等同于把一块确定大小的内存块从Java堆中划分出来。

假设Java堆中内存是绝对规整的，所有被使用过的内存都被放在一边，空闲的内存被放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间方向挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”（Bump ThePointer）
但如果Java堆中的内存并不是规整的，已被使用的内存和空闲的内存相互交错在一起，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为“空闲列表”（Free List）

Java堆的分配方式有：指针碰撞和空闲列表，具体使用哪种方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有空间压缩整（Compact）的能力决定

问题：对象创建在虚拟机中是非常频繁的行为，即使仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的。

解决：一种是对分配内存空间的动作进行同步处理（加锁）——实际上虚拟机是采用CAS配上失败重试的方式保证更新操作的原子性；

另外一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local AllocationBuffer，TLAB），哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，只有本地缓冲区用完了，分配新的缓存区时才需要同步锁定。虚拟机是否使用TLAB，可以通过-XX：+/-UseTLAB参数来设定。

初始化内存空间 :

内存分配完成之后，虚拟机必须将分配到的内存空间（但不包括对象头）都初始化为零值。这步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值。

对象头进行设置：

接下来，Java虚拟机还要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头（Object Header）之中。根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。狗

构造函数：

在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了。但是从Java程序的视角看来，对象创建才刚刚开始——构造函数，即Class文件中的()方法还没有执行，所有的字段都为默认的零值，对象需要的其他资源和状态信息也还没有按照预定的意图构造好。

3.2. 对象的内存布局

对象在堆内存中的存储布局可以划分为三个部分：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

对象头 Header:

对象头包括两类数据：对象自身的运行时数据和类型指针。

运行时数据： 如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳、对象分代年龄，这部分信息称为“Mark Word”；Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据自己的状态复用自己的存储空间。

第二部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例；

如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据。因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小，但是从数组的元数据中无法确定数组的大小。

实例数据

实例数据是对象真正存储的有效信息，也就是我们在程序代码中所定义的各种类型的字段内容，包括从父类继承的。这部分的存储顺序会受到 HotSpot 虚拟机默认的分配策略参数和字段在 Java 源码中定义顺序的影响。

对齐填充

对齐填充其实不是必然的，作用就是在占位符，保证对象的起始地址是 8 字节的整数倍。也就是说，任何对象的大小都必须是 8 字节的整数倍，这个是 HotSpot 虚拟机的自动内存管理系统的要求。

3.3 对象的访问定位

对象访问有两种方式，Java 通过栈上的 reference 数据来操作堆上的具体对象。

对象访问的两种方式为句柄和直接指针

句柄方式，Java 堆中将可能会划分除一块内存来作为句柄池，然后 reference 储存句柄池的地址，句柄中包含了指向对象实例数据的指针，和对象类型数据的指针。
直接指针 reference 中放的是对象地址

优缺点：

句柄方式比较稳定：Java栈本地变量中的reference中存储的时稳定的句柄地址，对象被移动时，只会改变句柄中的实例数据指针，不需要修改 reference 本身。

直接指针的话好处就是访问速度更快，对象访问在Java中十分频繁，由于少了一次指针定位的开销，因此这类开销积少成多也是一项极为可观的执行成本

4. 垃圾收集器和内存分配策略

4.1 为什么我们还要去了解垃圾收集和内存分配？

答案很简单：当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些“自动化”的技术实施必要的监控和调节。

Java内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑如何回收的问题，当方法结束或者线程结束时，内存自然就跟随着回收了。

而Java堆和方法区这两个区域则有着很显著的不确定性：一个接口的多个实现类需要的内存可能会不一样，一个方法所执行的不同条件分支所需要的内存也可能不一样，只有处于运行期间，我们才能知道程序究竟会创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。垃圾收集器所关注的正是这部分内存该如何管理。

4.2 GC的使用

System.gc(); // 手动回收垃圾

finalize方法作用

finalize()方法是在每次执行GC操作之前时会调用的方法，可以用它做必要的清理工作。
它是在Object类中定义的，因此所有的类都继承了它。子类覆盖finalize()方法以整理系统资源或者执行其他清理工作。finalize()方法是在垃圾收集器删除对象之前对这个对象调用的。

4.3 如何判断对象是否存活

引用计数算法

在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

观地说，引用计数算法（Reference Counting）虽然占用了一些额外的内存空间来进行计数，但它的原理简单，判定效率也很高，在大多数情况下它都是一个不错的算法。但是在主流的Java虚拟机中并没有选择这个方法来管理内存。

主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。

* testGC()方法执行后，objA和objB会不会被GC呢？
* @author zzm
*
/
public class ReferenceCountingGC {
public Object instance = null;
private static final int _1MB = 1024 * 1024;
	/**
	*
	这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否有回收过
	*/
	private byte[] bigSize = new byte[2 * _1MB];
	
	public static void testGC() {
	ReferenceCountingGC objA = new ReferenceCountingGC();
	ReferenceCountingGC objB = new ReferenceCountingGC();
	objA.instance = objB;
	objB.instance = objA;
	objA = null;
	objB = null;
	// 假设在这行发生GC，objA和objB是否能被回收？
	System.gc();
	}
}

可达性分析算法

当前主流的商用程序语言（Java、C#，上溯至前面提到的古老的Lisp）的内存管理子系统，都是通过可达性分析（Reachability Analysis）算法来判定对象是否存活的。这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

对象object 5、object 6、object 7虽然互有关联，但是它们到GC Roots是不可达的，因此它们将会被判定为可回收的对象。

在Java技术体系里面，固定可作为GC Roots的对象包括以下几种：

在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。
在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
所有被同步锁（synchronized关键字）持有的对象。
反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

4.4 新生代、老年代和永久带

在新生代中，每次垃圾收集时都发现有大批对象死去，而每次回收后存活的少量对象，将会逐步晋升到老年代中存放。

在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old )。
老年代就一个区域。
新生代 ( Young ) 又被划分为三个区域：Eden、From Survivor、To Survivor，这样划分的目的是让JVM能够更好的管理内存中的对象。
默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )，即：新生代 ( Young ) = 1/3 的堆空间大小。老年代 ( Old ) = 2/3 的堆空间大小。
新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时，将Eden和Survivor中仍
然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1，也即每次新生代中可用内存空间为整个新生代容量的90%（Eden的80%加上一个Survivor的10%），只有一个Survivor空间，即10%的新生代是会
被“浪费”的。
永久代就是JVM的方法区。在这里都是放着一些被虚拟机加载的类信息，静态变量，常量等数据。这个区中的东西比老年代和新生代更不容易回收。

【解释名词的含义】

部分收集（Partial GC）：指目标不是完整收集整个Java堆的垃圾收集，其中又分为：

新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。目前只有CMS收集器会有单独收集老年代的行为。另外请注意“Major GC”这个说法现在有点混淆，在不同资料上常有不同所指，读者需按上下文区分到底是指老年代的收集还是整堆收集。
混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收
集器会有这种行为。

整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。

为什么要这样分代：

其实主要原因就是可以根据各个年代的特点进行对象分区存储，更便于回收，采用最适当的收集算法：

新生代中，每次垃圾收集时都发现大批对象死去，只有少量对象存活，便采用了复制算法，只需要付出少量存活对象的复制成本就可以完成收集。
而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须采用“标记-清理”或者“标记-整理”算法。

新生代又分为Eden和Survivor （From与To，这里简称一个区）两个区。加上老年代就这三个区。数据会首先分配到Eden区当中（当然也有特殊情况，如果是大对象那么会直接放入到老年代（大对象是指需要大量连续内存空间的java对象）。当Eden没有足够空间的时候就会触发jvm发起一次Minor GC，如果对象经过一次Minor-GC还存活，并且又能被Survivor空间接受，那么将被移动到Survivor空间当中。并将其年龄设为1，对象在Survivor每熬过一次Minor GC，年龄就加1，当年龄达到一定的程度（默认为15）时，就会被晋升到老年代中了，当然晋升老年代的年龄是可以设置的。

Minor GC 触发条件一般为：

eden区满时，触发MinorGC。即申请一个对象时，发现eden区不够用，则触发一次MinorGC。
新创建的对象大小 > Eden所剩空间

Major GC和Full GC 触发条件一般为：

Major GC通常是跟full GC是等价的
每次晋升到老年代的对象平均大小>老年代剩余空间
MinorGC后存活的对象超过了老年代剩余空间
永久代空间不足
执行System.gc()
CMS GC异常
堆内存分配很大的对象

4.5 垃圾回收机制策略

标记-清除算法

算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。一般用于老年代中使用。

它的主要缺点有两个：

第一个是执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低；
第二个是内存空间的碎片化问题，标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作

标记清除算法的应用场景：

该算法一般应用于老年代,因为老年代的对象生命周期比较长。

标记-复制算法

它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

优点：

对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。这样实现简单，运行高效。

缺点：

如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销

是将可用内存缩小为了原来的一半，空间浪费未免太多了一点。

复制算法的应用场景：

复制算法一般是使用在新生代中，因为新生代中的对象一般都是朝生夕死的，存活对象的数量并不多，这样使用复制算法进行拷贝时效率比较高。

新生代中一般在Eden –>Survivor Space 与To Survivor之间实行复制算法。不过jvm在应用复制算法时，并不是把内存按照1:1来划分的，这样太浪费内存空间了。一般的jvm都是8:1。也即是说，Eden区:From区:To区域的比例是始终有90%的空间是可以用来创建对象的,而剩下的10%用来存放回收后存活的对象。

标记-整理法

标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。

标记-清除算法与标记-整理算法的本质差异在于前者是一种非移动式的回收算法，而后者是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策：

如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行，这就更加让使用者不得不小心翼翼地权衡其弊端了，像这样的停顿被最初的虚拟机设计者形象地描述为“Stop The World”。

但如果跟标记-清除算法那样完全不考虑移动和整理存活对象的话，弥散于堆中的存活对象导致的空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决

标记–整理算法优点：

解决标记清除算法出现的内存碎片问题，

标记–整理算法缺点：

压缩阶段，由于移动了可用对象，需要去更新引用。

标记–整理算法应用场景：

该算法一般应用于老年代,因为老年代的对象生命周期比较长。

分代算法-和稀泥式

这种算法，根据对象的存活周期的不同将内存划分成几块，新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。可以用抓重点的思路来理解这个算法。

新生代对象朝生夕死,对象数量多，只要重点扫描这个区域，那么就可以大大提高垃圾收集的效率。另外老年代对象存储久，无需经常扫描老年代，避免扫描导致的开销。

新生代

在新生代，每次垃圾收集器都发现有大批对象死去，只有少量存活，采用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。
老年代

而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须“标记清除法或者标记整理算法进行回收。

4.6 垃圾收集器

如果两个收集器之间存在连线，就说明它们可以搭配使用，图中收集器所处的区域，则表示它是属于新生代收集器抑或是老年代收集器
Serial、ParNew、Parallel Scavenge、CMS、Serial Old、Parallel Old、G1

而它们所处区域，则表明其是属于新生代还是老年代的收集器：

新生代收集器：Serial、ParNew、Parallel Scavenge
老年代收集器：CMS、Serial Old、Parallel Old
整堆收集器：G1

垃圾回收器详解

Serial

Serial 收集器：新生代。发展历史最悠久的收集器。它是一个单线程收集器，它只会使用一个 CPU 或者线程去完成垃圾收集工作，而且在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

特点：

新生代收集器，使用复制算法收集新生代垃圾。
单线程的收集器，GC工作时，其它所有线程都将停止工作。
简单高效，适合单 CPU 环境。单线程没有线程交互的开销，因此拥有最高的单线程收集效率。

使用方式：

//如何设置JVM参数底下会讲解：这里只是列举一部分参数：

设置垃圾收集器："-XX:+UseSerialGC" --添加该参数来显式的使用改垃圾收集器；

ParNew

ParNew 收集器：新生代。Serial 的多线程版本，即同时启动多个线程去进行垃圾收集。

特点：

新生代收集器。ParNew垃圾收集器是Serial收集器的多线程版本，采用复制算法。
除了多线程外，其余的行为、特点和Serial收集器一样。
只有它能与 CMS 收集器配合使用。
但在单个CPU环境中，不比Serail收集器好，多线程使用它比较好。

使用方式：

//如何设置JVM参数底下会讲解：这里只是列举一部分参数：

设置垃圾收集器："-XX:+UseParNewGC" --强制指定使用ParNew；
设置垃圾收集器： “-XX:+UseConcMarkSweepGC” --指定使用CMS后，会默认使用ParNew作为新生代收集器；
设置垃圾收集器参数："-XX:ParallelGCThreads" --指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同；

Parallel Scavenge

Parallel Scavenge 收集器：新生代。和 ParNew 的关注点不一样，该收集器更关注吞吐量，尽快地完成计算任务。

特点：

新生代收集器。
采用复制算法。
多线程收集。
与ParNew 不同的是：高吞吐量为目标，（减少垃圾收集时间，让用户代码获得更长的运行时间）

使用方式：

//如何设置JVM参数底下会讲解：这里只是列举一部分参数：

设置垃圾收集器："-XX:+UseParallelGC" --添加该参数来显式的使用改垃圾收集器；
设置垃圾收集器参数："-XX:MaxGCPauseMillis" --控制垃圾回收时最大的停顿时间(单位ms)
设置垃圾收集器参数："-XX:GCTimeRatio" --控制程序运行的吞吐量大小吞吐量大小=代码执行时间/(代码执行时间+gc回收的时间)
设置垃圾收集器参数："-XX:UseAdaptiveSizePolicy" --内存调优交给虚拟机管理

Serial Old

Serial Old 收集器：Serial 的老年代版本，使用标记 - 整理算法。

特点：

老年代收集器，采用"标记-整理"算法。
单线程收集。

使用方式：

//如何设置JVM参数底下会讲解：这里只是列举一部分参数：

在JDK1.5及之前，与Parallel Scavenge收集器搭配使用，
在JDK1.6后有Parallel Old收集器可搭配。
现在的作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

Parallnel old

Parallnel old 收集器，多线程：Parallel 的老年代版本，使用标记 - 整理算法。

特点：

针对老年代。
采用"标记-整理"算法。
多线程收集。
但在单个CPU环境中，不比Serial Old收集器好，多线程使用它比较好。

使用方式：

//如何设置JVM参数底下会讲解：这里只是列举一部分参数：

设置垃圾收集器："-XX:+UseParallelOldGC"：指定使用Parallel Old收集器；

CMS

CMS 收集器：老年代。是一种以获取最短回收停顿时间为目标的收集器，适用于互联网站或者 B/S 系统的服务端上。

特点：

针对老年代，采用标记-清楚法清除垃圾；
基于"标记-清除"算法(不进行压缩操作，产生内存碎片)；
以获取最短回收停顿时间为目标；
并发收集、低停顿；
垃圾收集线程与用户线程（基本上）可以同时工作

CMS收集器有3个明显的缺点：

对CPU资源非常敏感
无法处理浮动垃圾，可能出现"Concurrent Mode Failure"失败
产生大量内存碎片

使用方式：

//如何设置JVM参数底下会讲解：这里只是列举一部分参数：

设置垃圾收集器："-XX:+UseConcMarkSweepGC"：指定使用CMS收集器；

G1-JDK9

G1 收集器：分代收集器。当今收集器技术发展最前沿成果之一，是一款面向服务端应用的垃圾收集器。G1可以说是CMS的终极改进版，解决了CMS内存碎片、更多的内存空间登问题。虽然流程与CMS比较相似，但底层的原理已是完全不同。

特点：

能充分利用多CPU、多核环境下的硬件优势；
可以并行来缩短(Stop The World)停顿时间；
也可以并发让垃圾收集与用户程序同时进行；
分代收集，收集范围包括新生代和老年代
能独立管理整个GC堆（新生代和老年代），而不需要与其他收集器搭配；
能够采用不同方式处理不同时期的对象；
应用场景可以面向服务端应用，针对具有大内存、多处理器的机器；
采用标记-整理 + 复制算法来回收垃圾

使用方式：

//如何设置JVM参数底下会讲解：这里只是列举一部分参数：

设置垃圾收集器："-XX:+UseG1GC"：指定使用G1收集器；
设置垃圾收集器参数："-XX:InitiatingHeapOccupancyPercent"：当整个Java堆的占用率达到参数值时，开始并发标记阶段；默认为45；
设置垃圾收集器参数："-XX:MaxGCPauseMillis"：为G1设置暂停时间目标，默认值为200毫秒；
设置垃圾收集器参数："-XX:G1HeapRegionSize"：设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个Region

JVM常用参数配置

#常用的设置
-Xms：初始堆大小，JVM 启动的时候，给定堆空间大小。 

-Xmx：最大堆大小，JVM 运行过程中，如果初始堆空间不足的时候，最大可以扩展到多少。 

-Xmn：设置堆中年轻代大小。整个堆大小=年轻代大小+年老代大小+持久代大小。 

-XX:NewSize=n 设置年轻代初始化大小大小 

-XX:MaxNewSize=n 设置年轻代最大值

-XX:NewRatio=n 设置年轻代和年老代的比值。如: -XX:NewRatio=3，表示年轻代与年老代比值为 1：3，年轻代占整个年轻代+年老代和的 1/4 

-XX:SurvivorRatio=n 年轻代中 Eden 区与两个 Survivor 区的比值。注意 Survivor 区有两个。8表示两个Survivor :eden=2:8 ,即一个Survivor占年轻代的1/10，默认就为8

-Xss：设置每个线程的堆栈大小。JDK5后每个线程 Java 栈大小为 1M，以前每个线程堆栈大小为 256K。

-XX:ThreadStackSize=n 线程堆栈大小

-XX:PermSize=n 设置持久代初始值	

-XX:MaxPermSize=n 设置持久代大小
 
-XX:MaxTenuringThreshold=n 设置年轻带垃圾对象最大年龄。如果设置为 0 的话，则年轻代对象不经过 Survivor 区，直接进入年老代。

#下面是一些不常用的

-XX:LargePageSizeInBytes=n 设置堆内存的内存页大小

-XX:+UseFastAccessorMethods 优化原始类型的getter方法性能

-XX:+DisableExplicitGC 禁止在运行期显式地调用System.gc()，默认启用	

-XX:+AggressiveOpts 是否启用JVM开发团队最新的调优成果。例如编译优化，偏向锁，并行年老代收集等，jdk6纸之后默认启动

-XX:+UseBiasedLocking 是否启用偏向锁，JDK6默认启用	

-Xnoclassgc 是否禁用垃圾回收

-XX:+UseThreadPriorities 使用本地线程的优先级，默认启用	

等等等......

-XX:+UseSerialGC:设置串行收集器，年轻带收集器 

 -XX:+UseParNewGC:设置年轻代为并行收集。可与 CMS 收集同时使用。JDK5.0 以上，JVM 会根据系统配置自行设置，所以无需再设置此值。

-XX:+UseParallelGC:设置并行收集器，目标是目标是达到可控制的吞吐量

-XX:+UseParallelOldGC:设置并行年老代收集器，JDK6.0 支持对年老代并行收集。 

-XX:+UseConcMarkSweepGC:设置年老代并发收集器

-XX:+UseG1GC:设置 G1 收集器，JDK1.9默认垃圾收集器

5. 类加载器

Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这个过程被称作虚拟机的类加载机制。

在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略让Java语言进行提前编译会面临额外的困难，也会让类加载时稍微增加一些性能开销，但是却为Java应用提供了极高的扩展性和灵活性，Java天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的

5.1 类加载的时机

个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段，其中验证、准备、解析三个部分统称为连接（Linking）。

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定)。

关于在什么情况下需要开始类加载过程的第一个阶段“加载”，《Java虚拟机规范》中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，《Java虚拟机规范》则是严格规定了有且只有六种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。能够生成这四条指令的典型Java代码场景有：
- 使用new关键字实例化对象的时候。
- 读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）
  的时候。
- 调用一个类型的静态方法的时候。
使用java.lang.reflect包的方法对类型进行反射调用的时候，如果类型没有进行过初始化，则需要先触发其初始化。
当初始化类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

详细参考深入理解Java虚拟机P265-267

5.2 加载

在加载阶段，Java虚拟机需要完成以下三件事情：

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

加载指的是将类的class文件读入到内存，并将这些静态数据转换成方法区中的运行时数据结构，并在堆中生成一个代表这个类的java.lang.Class对象，作为方法区类数据的访问入口，这个过程需要类加载器参与。

Java类加载器由JVM提供，是所有程序运行的基础，JVM提供的这些类加载器通常被称为系统类加载器。除此之外，开发者可以通过继承ClassLoader基类来创建自己的类加载器。

类加载器，可以从不同来源加载类的二进制数据，比如：本地Class文件、Jar包Class文件、网络Class文件等等等。

类加载的最终产物就是位于堆中的Class对象（注意不是目标类对象），该对象封装了类在方法区中的数据结构，并且向用户提供了访问方法区数据结构的接口，即Java反射的接口

5.3 连接

验证：

验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

准备;

准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段，从概念上讲，这些变量所使用的内存都应当在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域，在JDK 8及之后，类变量则会随着Class对象一起存放在Java堆中，这时候“类变量在方法区”就完全是一种对逻辑概念的表述了。

特殊情况，finla

解析：

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

符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定是已经加载到虚拟机内存当中的内容。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。
直接引用（Direct References）：直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

5.4 初始化

类的初始化阶段是类加载过程的最后一个步骤，之前介绍的几个类加载的动作里，除了在加载阶段用户应用程序可以通过自定义类加载器的方式局部参与外，其余动作都完全由Java虚拟机来主导控制。直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。

进行准备阶段时，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通过程序编码制定的主观计划去初始化类变量和其他资源

初始化阶段就是执行类构造器()方法的过程。()并不是程序员在Java代码中直接编写的方法，它是Javac编译器的自动生成物，

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

5.5 类加载器

Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”（Class Loader）。

类与类加载器的关系

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段。对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

双亲委派模型

站在Java虚拟机的角度来看，只存在两种不同的类加载器：一种是启动类加载器（BootstrapClassLoader），这个类加载器使用C++语言实现[1]，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

1 启动类/根类加载器（bootstrap class loader）

它用来加载 Java 的核心类，是用原生代码来实现的，并不继承自 java.lang.ClassLoader（负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。

2 扩展类加载器（extensions class loader）

扩展类加载器是指Sun公司(已被Oracle收购)实现的sun.misc.Launcher$ExtClassLoader类，由Java语言实现的，是Launcher的静态内部类，它负责加<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库，开发者可以直接使用标准扩展类加载器。

3 系统类加载器（system class loader）

被称为系统（也称为应用）类加载器，它负责在JVM启动时加载来自Java命令的-classpath选项、java.class.path系统属性，或者CLASSPATH换将变量所指定的JAR包和类路径。程序可以通过ClassLoader的静态方法getSystemClassLoader()来获取系统类加载器。如果没有特别指定，则用户自定义的类加载器都以此类加载器作为父加载器。由Java语言实现，父类加载器为ExtClassLoader。（Java虚拟机采用的是双亲委派模式即把请求交由父类处理，它一种任务委派模式，）

各种类加载器之间的层次关系被称为类加载器的“双亲委派模型（Parents DelegationModel）”。双亲委派模型要求除了顶层的启动类加载器外**，其余的类加载器都应有自己的父类加载器**。不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

工作过程：

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

好处：

Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。