java并发编程-JVM架构与GC

作为一名Java开发者，掌握JVM的体系结构也是很有必要的，了解底层的东西，有助于更好的理解和掌握程序运行中的原理。JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收堆和一个存储方法域。 JVM屏蔽了与具体操作系统平台相关的信息，使Java程序只需生成在Java虚拟机上运行的目标代码（字节码）,就可以在多种平台上不加修改地运行。JVM在执行字节码时，实际上最终还是把字节码解释成具体平台上的机器指令执行。JVM伴随Java程序的开始而开始，程序的结束而停止。一个Java程序会开启一个JVM进程，一台计算机上可以运行多个程序，也就可以运行多个JVM进程。JVM将线程分为两种：守护线程和普通线程。守护线程是JVM自己使用的线程，比如垃圾回收（GC）就是一个守护线程。普通线程一般是Java程序的线程，只要JVM中有普通线程在执行，那么JVM就不会停止。

虚拟机

JRE由Java API和JVM组成，JVM通过类加载器(Class Loader)加类Java应用，并通过Java API进行执行。

虚拟机(VM: Virtual Machine)是通过软件模拟物理机器执行程序的执行器。最初Java语言被设计为基于虚拟机器在而非物理机器，重而实现一次编写，到处运行的目的，尽管这个目标几乎被世人所遗忘。所以，JVM可以在所有的硬件环境上执行Java字节码而无须调整Java的执行模式。

JVM的基本特性：

• 基于栈(Stack-based)的虚拟机: 不同于Intel x86和ARM等比较流行的计算机处理器都是基于寄存器(register)架构，JVM是基于栈执行的。
• 符号引用(Symbolic reference): 除基本类型外的所有Java类型(类和接口)都是通过符号引用取得关联的，而非显式的基于内存地址的引用。
• 垃圾回收机制: 类的实例通过用户代码进行显式创建，但却通过垃圾回收机制自动销毁。
• 通过明确清晰基本类型确保平台无关性: 像C/C++等传统编程语言对于int类型数据在同平台上会有不同的字节长度。JVM却通过明确的定义基本类型的字节长度来维持代码的平台兼容性，从而做到平台无关。
• 网络字节序(Network byte order): Java class文件的二进制表示使用的是基于网络的字节序(network byte order)。为了在使用小端(little endian)的Intel x86平台和在使用了大端(big endian)的RISC系列平台之间保持平台无关，必须要定义一个固定的字节序。JVM选择了网络传输协议中使用的网络字节序，即基于大端(big endian)的字节序。

Sun 公司开发了Java语言，但任何人都可以在遵循JVM规范的前提下开发和提供JVM实现。所以目前业界有多种不同的JVM实现，包括Oracle Hostpot JVM和IBM JVM。Google公司使用的Dalvik VM也是一种JVM实现，尽管其并未完全遵循JVM规范。与基于栈机制的Java 虚拟机不同的是Dalvik VM是基于寄存器的，Java 字节码也被转换为Dalvik VM使用的寄存器指令集。

JRE、JDK和JVM的关系

1. *JRE（Java Runtime Environment， Java运行环境）: *是Java的运行环境，所有的程序都要在JRE下才能够运行。包括JVM和Java核心类库和支持文件。
2. *JDK（Java Development Kit，Java开发工具包）: *用来编译、调试Java程序的开发工具包。包括Java工具（javac/java/jdb等）和Java基础的类库（java API ）。
3. JVM（Java Virtual Machine， Java虚拟机）：是JRE的一部分。JVM主要工作是解释自己的指令集（即字节码）并映射到本地的CPU指令集和OS的系统调用。Java语言是跨平台运行的，不同的操作系统会有不同的JVM映射规则，使之与操作系统无关，完成跨平台性。

使用JDK（调用JAVA API）开发JAVA程序后，通过JDK中的编译程序（javac）将Java程序编译为Java字节码，在JRE上运行这些字节码，JVM会解析并映射到真实操作系统的CPU指令集和OS的系统调用。下图表示了JDK、JRE和JVM三者间的关系：

JVM架构

JVM被分为三个主要的子系统：（1）类加载器子系统（2）运行时数据区（3）执行引擎

类装载子系统

在JAVA虚拟机中，负责查找并装载类型的那部分被称为类装载子系统。JAVA虚拟机有两种类装载器：启动类装载器和用户自定义类装载器。前者是JAVA虚拟机实现的一部分，后者则是Java程序的一部分。由不同的类装载器装载的类将被放在虚拟机内部的不同命名空间中。类装载器子系统涉及Java虚拟机的其他几个组成部分，以及几个来自java.lang库的类。比如，用户自定义的类装载器是普通的Java对象，它的类必须派生自java.lang.ClassLoader类。ClassLoader中定义的方法为程序提供了访问类装载器机制的接口。此外，对于每一个被装载的类型，JAVA虚拟机都会为它创建一个java.lang.Class类的实例来代表该类型。和所有其他对象一样，用户自定义的类装载器以及Class类的实例都放在内存中的堆区，而装载的类型信息则都位于方法区。类装载器子系统除了要定位和导入二进制class文件外，还必须负责验证被导入类的正确性，为类变量分配并初始化内存，以及帮助解析符号引用。类加载系统主要分为三个部分，而且类的加载动作必须严格按以下顺序进行：

装载：装载过程负责找到二进制字节码并加载至JVM中，JVM通过类名、类所在的包名通过ClassLoader来完成类的加载，同样，也采用以上三个元素来标识一个被加载了的类：类名+包名+ClassLoader实例ID，因此不同类加载器加载相同的类是不同的。有继承，将先在加载父类。

连接：链接过程负责对二进制字节码的格式进行：校验、解析类中调用的接口、类。校验是防止不合法的.class文件，然后 对类中的所有属性、调用方法进行解析，以确保其需要调用的属性、方法存在，以及具备应的权限（例如public、private域权限等），会造成NoSuchMethodError、NoSuchFieldError等错误信息。

• 验证：确保被导入类型的正确性。（java可以自定义安全策略等）
• 准备：为类的静态变量分配内存，并将其初始化为默认值
• 解析：把类中的符号引用转化为直接引用

初始化：初始化过程即为执行类中的静态初始化代码、构造器代码以及静态属性的初始化。在四种情况下初始化过程会被触发执行。1.调用了new；2.反射调用了类中的方法；3.子类调用了初始化（先执行父类静态代码和静态成员，再执行子类静态代码和静态变量，然后调用父类构造器，最后调用自身构造器。）；4. JVM启动过程中指定的初始化类。 类加载系统使用双亲委派模型来确保每个类被正确的加载。每个类装载器都有自己的命名空间，其中维护着由它装载的类型。所以一个Java程序可以多次装载具有同一个全限定名的多个类型。这样一个类型的全限定名就不足以确定在一个Java虚拟机中的唯一性。因此，当多个类装载器都装载了同名的类型时，为了惟一地标识该类型，还要在类型名称前加上装载该类型（指出它所位于的命名空间）的类装载器标识。

运行时数据区

运行时数据区域被划分为五个主要组件：

Java堆（Heap）： 对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。 Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做GC堆。如果从内存回收的角度看，由于现在收集器基本都是采用的分代收集算法。根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

Java堆（Heap）：方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。每个JVM只有一个方法区，它是一个共享的资源。根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

程序计数器（Program Counter Register）：程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。 此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

JVM栈（JVM Stacks）：与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。栈帧被分为三个子实体

• 局部变量数组： 包含多少个与方法相关的局部变量并且相应的值将被存储在这里。
• 操作数栈： 如果需要执行任何中间操作，操作数栈作为运行时工作区去执行指令。
• 帧数据： 方法的所有符号都保存在这里。在任意异常的情况下，catch块的信息将会被保存在帧数据里面。

本地方法栈（Native Method Stacks）：本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（譬如Sun HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

执行引擎

执行引擎在执行Java代码时候可能会有解释执行和编译执行两种选择，也可能两者兼备，甚至还可能会包含几个不同级别的编译器执行引擎。

1. 解释执行：解释器能快速的解释字节码，但执行却很慢。 解释器的缺点就是,当一个方法被调用多次，每次都需要重新解释。
2. 编译执行：JIT编译器消除了解释器的缺点。执行引擎利用解释器转换字节码，但如果是重复的代码则使用JIT编译器将全部字节码编译成本机代码。本机代码将直接用于重复的方法调用，这提高了系统的性能。

当主流的虚拟机中都包含了即时编译器后，Class文件中的代码到底会被解释执行还是编译执行，只有虚拟机自己才能准确判断。Javac编译器完成了程序代码经过词法分析、语法分析到抽象语法树，再遍历语法树生成线性的字节码指令流的过程。因为这一动作是在Java虚拟机之外进行的，而解释器在虚拟机的内部，所以Java程序的编译是半独立的实现。Java程序最初是通过解释器进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁，就会把这些代码认定为“热点代码”（Hot Spot Code）。为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器成为即时编译器（Just In Time Compiler，JIT编译器）当程序需要快速启动和执行时，解释器首先发挥作用，省去编译的时间，立即执行当程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码，可以提高执行效率如果内存资源限制较大（部分嵌入式系统），可以使用解释执行节约内存，反之可以使用编译执行来提升效率。同时编译器的代码还能退回成解释器的代码。编译器主要分为四个部分，分别如下：

• 中间代码生成器： 生成中间代码
• 代码优化器： 负责优化上面生成的中间代码
• 目标代码生成器：负责生成机器代码或本机代码
• 探测器(Profiler)： 一个特殊的组件，负责寻找被多次调用的方法。

执行引擎中最频繁的就是方法调用，方法调用的主要任务就是确定被调用方法的版本(即调用哪一个方法),该过程不涉及方法具体的运行过程.按照调用方式共分为两类:

1. 解析调用时是静态的过程,在编译期间就完全确定目标方法。
2. 分派调用则即可能是静态,也可能是动态的,根据分派标准可以分为单分派和多分派。两两组合有形成了静态单分派、静态多分派、动态单分派、动态多分派

简单理解来说静态分派的典型应用是方法的重载，动态分派的典型应用是方法的重写。至于单分派和多分派就是方法的接收者与方法的参数统称为方法的宗量。根据分派基于多少种宗量，可以将分派划分为单分派和多分派两种。单分派是根据一个宗量对目标方法进行选择，多分派则是根据多于一个宗量对目标方法进行选择。至此，除了垃圾回收器，JVM的各个部分基本都说到了，下面将着重了解垃圾收集器，它是一个重要的组件，正是由于它的存在才使得Java开发者不用像C++开发者那样去管理令人头皮发麻的运行时内存，同时它也是JVM调优的重要阵地。下图是整个JVM的架构图

对象的内存分布

在 HotSpot 虚拟机中，分为 3 块区域：对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)

1. 对象头(Header)：包含两部分，第一部分用于存储对象自身的运行时数据，如哈希码、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等，32 位虚拟机占 32 bit，64 位虚拟机占 64 bit。官方称为 Mark Word。第二部分是类型指针，即对象指向它的类的元数据指针，虚拟机通过这个指针确定这个对象是哪个类的实例。另外，如果是 Java 数组，对象头中还必须有一块用于记录数组长度的数据，因为普通对象可以通过 Java 对象元数据确定大小，而数组对象不可以。
2. 实例数据(Instance Data)：程序代码中所定义的各种类型的字段内容(包含父类继承下来的和子类中定义的)。
3. 对齐填充(Padding)：不是必然需要，主要是占位，保证对象大小是某个字节的整数倍。

当对象被创建了后，Java程序需要通过栈上的reference引用来操作堆上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置，所以对象访问方法也是取决于虚拟机的实现而决定的。目前主流的访问方式有 句柄访问 和 指针访问 两种。

句柄访问：Java 堆中会分配一块内存作为句柄池。reference 存储的是句柄地址。详情见图。

指针访问：reference 中直接存储对象地址

使用句柄的最大好处是 reference 中存储的是稳定的句柄地址，在对象移动(GC)是只改变实例数据指针地址，reference 自身不需要修改。直接指针访问的最大好处是速度快，节省了一次指针定位的时间开销。如果是对象频繁 GC 那么句柄方法好，如果是对象频繁访问则直接指针访问好。

垃圾回收

说起垃圾回收（GC），大部分人都把这项技术当做Java语言的伴生产物。事实上，GC的历史比Java久远，早在1960年Lisp这门语言中就使用了内存动态分配和垃圾回收技术。 JAVA GC（Garbage Collection，垃圾回收）机制是区别C++的一个重要特征，C++需要开发者自己实现垃圾回收的逻辑，而JAVA开发者则只需要专注于业务开发，因为垃圾回收这件繁琐的事情JVM已经为我们代劳了，从这一点上来说，JAVA还是要做的比较完善一些。但这并不意味着我们不用去理解GC机制的原理，因为如果不了解其原理，可能会引发内存泄漏、频繁GC导致应用卡顿,甚至出现OOM等问题，因此我们需要深入理解其原理，才能编写出高性能的应用程序，解决性能瓶颈。在Java中垃圾回收主要针对堆区，垃圾收集器在对堆区和方法区进行回收前，首先要确定这些区域的对象哪些可以被回收，哪些暂时还不能回收，这就要用到判断对象是否存活的算法！

堆区的查找算法

JVM中判断对象是否存活的算法主要有两种。1. 引用计数法，2. 根搜索算法

(1) . 引用计数法：引用计数是垃圾收集器中的早期策略。在这种方法中，堆中每个对象实例都有一个引用计数。当一个对象被创建时，就将该对象实例分配给一个变量，该变量计数设置为1。当任何其它变量被赋值为这个对象的引用时，计数加1（a = b,则b引用的对象实例的计数器+1），但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时，它引用的任何对象实例的引用计数器减1。引用计数法的优点是引用计数收集器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利，而缺点也很明显，它不能解决循环引用的问题。

(2) . 可达性分析：此算法是从离散数学中的图论引入的，程序把所有的引用关系看作一张图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点，无用的节点将会被判定为是可回收的对象。

根搜索算法的核心在于GC Root，在Java语言中，可作为GC Root的对象包括下面几种：

• 虚拟机栈中引用的对象（栈帧中的本地变量表）；
• 方法区中类静态属性引用的对象；
• 方法区中常量引用的对象；
• 本地方法栈中JNI（Native方法）引用的对象。

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判定对象是否存活都与“引用”有关。在Java语言中，将引用又分为强引用、软引用、弱引用、虚引用4种，这四种引用强度依次逐渐减弱。

• 强引用：类似 Object obj = new Object() 这类引用都是强引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象，即使抛出OOM异常。
• 软引用：用来描述一些还有用但并非必须的对象，只有当JVM内存不足时才会被回收
• 弱引用：也是用来描述非必需对象的，但是它的强度比软引用更弱一些。只要GC,就会立马回收，不管内存是否充足。
• 虚引用：也叫幽灵引用或幻影引用，是最弱的一种引用关系。可以忽略不计，JVM完全不会在乎虚引用。它唯一的作用就是做一些跟踪记录，辅助finalize函数的使用。

方法区的查找算法

方法区存储内容是否需要回收与堆区的判断方法有一些区别。方法区主要回收的内容有：废弃常量和无用的类。对于废弃常量也可通过引用的可达性来判断，但是对于无用的类则需要同时满足下面三个条件：

• 该类所有的实例都已经被回收；
• 加载该类的ClassLoader已经被回收；
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

GC算法

标记-清除算法（Mark-Sweep）

如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，标记完毕后再扫描整个空间中未被标记的对象进行回收。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。标记-清除算法不需要进行对象的移动，只需对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。此外空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

复制算法（Copying）

复制算法的提出是为了克服句柄的开销和解决内存碎片的问题。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，持续复制长生存期的对象则导致效率降低。

标记-整理算法(Mark-compact)

复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样。在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题

分代收集算法

GC分代的基本假设：绝大部分对象的生命周期都非常短暂，存活时间短。分代收集（Generational Collection）算法，把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每时每刻都大量的对象创建和死亡，处于新生代的对象可以说是朝生夕死，每次垃圾收集时都有大批对象死去，只有少量存活，适用于复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。堆内存由年轻代和老年代组成，而年轻代内存又被分成三部分，Eden空间、From Survivor空间、To Survivor空间,默认情况下年轻代按照8:1:1的比例来分配

年轻代（Young Generation）的回收算法 (回收主要以复制算法为主)

• 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。
• 新生代内存按照8:1:1的比例分为一个Eden区和两个Survivor(From，To)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将Eden区存活对象复制到From区，然后清空Eden区，当From区也存放满了时，则将Eden区和From区存活对象复制到To区，然后清空Eden和From区，此时From区是空的，然后将From区和To区交换，即保持To区为空， 如此往复。
• 当To区不足以存放 Eden和From的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC(Major GC)，也就是新生代、老年代都进行回收。
• 新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。

年老代（Old Generation）的回收算法（回收主要以Mark-Compact为主）

• 在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
• 内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

JVM初始分配的堆内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的堆内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx 相等以避免在每次GC 后调整堆的大小。

垃圾收集器

• Serial收集器：串行收集器是最古老，最稳定以及效率高的收集器，可能会产生较长的停顿，只使用一个线程去回收。新生代、老年代使用串行回收；新生代复制算法、老年代标记-压缩；垃圾收集的过程中会Stop The World（服务暂停），可以通过 -XX:+UseSerialGC 来强制指定。
• ParNew收集器：ParNew收集器其实就是Serial收集器的多线程版本，在多核CPU环境下有着比Serial更好的表现。新生代并行，老年代串行；新生代复制算法、老年代标记-压缩，可通过 -XX:+UseParNewGC 来指定使用此收集器，通过 -XX:ParallelGCThreads 来限制线程数量
• Parallel Scavenge收集器：并行收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%， 吞吐量= 用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。是server级别默认采用的GC方式，可用 -XX:+UseParallelGC 来强制指定，用 -XX:ParallelGCThreads=4 来指定线程数。
• Parallel Old收集器：Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和标记－整理算法。这个收集器是在JDK 1.6中才开始提供。通过 -XX:+UseParallelOldGC 指定。
• CMS收集器：高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择。缺点是会产生大量空间碎片、并发阶段会降低吞吐量。通过-XX:+UseConcMarkSweepGC 指定使用CMS收集器；-XX:+CMSFullGCsBeforeCompaction 设置进行几次Full GC后，进行一次碎片整理；-XX:ParallelCMSThreads 设定CMS的线程数量，一般情况约等于可用CPU数量。
• G1收集器：G1是目前技术发展的最前沿成果之一，HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与CMS收集器相比G1收集器有以下特点。空间整合：G1收集器采用标记整理算法，不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。可预测停顿：是G1的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。

GC触发的条件

大部分情况下，对象会在新生代的Eden区中分配空间，当Eden区没有足够大小的连续空间来分配给新创建的对象时，JVM将会触发一次Minor GC。在发生Minor GC之前，JVM会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则JVM会查看HandlePromotionFailure设置值是否允许担保失败。若允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时要改为进行一次Full GC。

• Minor GC：发生在新生代，回收新生代中的垃圾，速度很快但也很频繁

• Major GC：发生在老年代，比Minor GC慢10倍以上；通常会伴随一次Minor GC

• Full GC：回收所有区域，包括堆内存、方法区（Java 8之前的“永久代”，Java 8开始取代永久代的“元空间”）和直接内存。Full GC因为需要对整个堆进行回收，所以速度慢，工作线程的暂停时间长。而且Full Gc过程会发生stop the world。因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于Full GC的调节。有如下原因可能导致Full GC：

  1. 老年代空间（Tenured）被写满

     老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误： java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

  2. 显示的调用System.gc()方法

     此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI（Java远程方法调用）调用System.gc。

  3. 方法区空间被写满

     JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永久代或者永生区（Java8以后永久代被Metaspace取代，Metaspace使用的是本地内存，而非堆内存），Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息： java.lang.OutOfMemoryError: PermGen space为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。

  4. GC担保失败

     在发生MinorGC前,检查老年代是否有连续空间，如果有连续空间则继续执行，如果没有，则根据设置：XX:-HandlePromotionFailure 指定，如果设置为开启，那么继续检查当前老年代最大可用连续空间大于历次Minor GC的平均晋升大小，如果大于，则进行MinorGC，否则进行FullGC。如果HandlePromotionFailure 不设置直接进行FullGC。

GC的参数

堆内存调优

对于JVM的GC调优有三个重要的核心参数：-Xms ，–Xmx， –Xss，其中-Xms –Xmx是堆内存的性能调优参数，一般两个设置是一样的，如果不一样，当Heap不够用，会发生内存抖动。一般都调大这两个参数，程序会启动的快一点，并且两个大小一样。-Xss是对每一个线程栈的性能调优参数,影响堆栈调用的深度。

• -Xms： 为jvm启动时分配的内存，比如-Xms200m，表示分配200M
• -Xmx： 为jvm运行过程中分配的最大内存，比如-Xms500m，表示jvm进程最多只能够占用500M内存
• -Xss： 为jvm启动的每个线程分配的内存大小，默认JDK1.4中是256K，JDK1.5+中是1M

关于堆内存JVM还提供了更详细的配置参数：

• -XX：NewRatio=4：设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
• –XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6，也就是From和To各占用了年轻代的1/6。如果分配不合理，Eden太大，这样产生对象很顺利，但是进行GC有一部分对象幸存下来，拷贝到To，空间小，就没有足够的空间，对象会被放在old Generation中。如果Survive空间大，会有足够的空间容纳GC后存活的对象，但是Eden区域小，会被很快消耗完，这就增加了GC的次数。
• –XX:NewSize：新生代初始化内存的大小(注意：该值需要小于-Xms的值)。
• –XX:MaxNewSize：新生代可被分配的内存的最大上限(注意：该值需要小于-Xmx的值)。
• -XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。

永久代调优

从JDK8开始，永久代(PermGen)的概念被废弃掉了，取而代之的是一个称为Metaspace的存储空间。Metaspace使用的是本地内存，而不是堆内存，也就是说在默认情况下Metaspace的大小只与本地内存大小有关。由于类的元数据可以在本地内存(native memory)之外分配,所以其最大可利用空间是整个系统内存的可用空间。这样，你将不再会遇到OOM错误，溢出的内存会涌入到交换空间。原永久的PermGen空间的状况，这部分内存空间将全部移除。JVM的参数：PermSize 和 MaxPermSize 会被忽略并给出警告（如果在启用时设置了这两个参数）。现在可以通过以下的几个参数对Metaspace进行控制。

• -XX:MetaspaceSize=N： 这个参数是初始化的Metaspace大小，该值越大触发Metaspace GC的时机就越晚。随着GC的到来，虚拟机会根据实际情况调控Metaspace的大小，可能增加上线也可能降低。在默认情况下，这个值大小根据不同的平台在12M到20M浮动。使用java -XX:+PrintFlagsInitial命令查看本机的初始化参数，-XX:Metaspacesize为21810376B（大约20.8M）。
• -XX:MaxMetaspaceSize=N：这个参数用于限制Metaspace增长的上限，防止因为某些情况导致Metaspace无限的使用本地内存，影响到其他程序。在本机上该参数的默认值为4294967295B（大约4096MB）。
• -XX:MinMetaspaceFreeRatio=N：当进行过Metaspace GC之后，会计算当前Metaspace的空闲空间比，如果空闲比小于这个参数，那么虚拟机将增长Metaspace的大小。在本机该参数的默认值为40，也就是40%。设置该参数可以控制Metaspace的增长的速度，太小的值会导致Metaspace增长的缓慢，Metaspace的使用逐渐趋于饱和，可能会影响之后类的加载。而太大的值会导致Metaspace增长的过快，浪费内存。
• -XX:MaxMetasaceFreeRatio=N：当进行过Metaspace GC之后， 会计算当前Metaspace的空闲空间比，如果空闲比大于这个参数，那么虚拟机会释放Metaspace的部分空间。在本机该参数的默认值为70，也就是70%。
• -XX:MaxMetaspaceExpansion=N：Metaspace增长时的最大幅度。在本机上该参数的默认值为5452592B（大约为5MB）。
• -XX:MinMetaspaceExpansion=N：Metaspace增长时的最小幅度。在本机上该参数的默认值为340784B（大约330KB为）。

回收器选择

JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。

1.吞吐量优先的并行收集器，并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等。典型配置：

• java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
  -XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
• java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC。-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。
• java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100。-XX:MaxGCPauseMillis=100：设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。
• java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy。-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。

2.响应时间优先的并发收集器，并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。典型配置：

• java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC。-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。
  -XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。
• java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection。
  -XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
  -XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片

JVM的GC日志解读

JVM YoungGeneration下MinorGC日志详解

[GC (Allocation Failure) [PSYoungGen:2336K->288K(2560K)] 8274K->6418K(9728K), 0.0112926 secs] [Times:user=0.06 sys=0.00, real=0.01 secs]

PSYoungGen（是新生代类型，新生代日志收集器），2336K表示使用新生代GC前，占用的内存，->288K表示GC后占用的内存，(2560K)代表整个新生代总共大小。8274K（GC前整个JVM Heap对内存的占用）->6418K（MinorGC后内存占用总量）(9728K)（整个堆的大小）0.0112926 secs（Minor GC消耗的时间）] [Times: user=0.06 sys=0.00, real=0.01 secs] 用户空间耗时，内核空间耗时，真正的耗时时间。

JVM的GC日志Full GC日志每个字段彻底详解

[Full GC (Ergonomics) [PSYoungGen: 984K->425K(2048K)] [ParOldGen:7129K->7129K(7168K)] 8114K->7555K(9216K), [Metaspace:2613K->2613K(1056768K)], 0.1022588 secs] [Times: user=0.56 sys=0.02,real=0.10 secs]

[Full GC (Allocation Failure) [PSYoungGen: 425K->425K(2048K)][ParOldGen: 7129K->7129K(7168K)] 7555K->7555K(9216K), [Metaspace:2613K->2613K(1056768K)], 0.1003696 secs] [Times: user=0.64 sys=0.03,real=0.10 secs]

Full GC（表明是Full GC） (Ergonomics) [PSYoungGen:FullGC会导致新生代Minor GC产生]984K->425K(2048K)[ParOldGen:（老年代GC）7129K（GC前多大）->7129K（GC后，并没有降低内存占用，因为写的程序不断循环一直有引用）(7168K) （老年代总容量）] 8114K（GC前占用整个Heap空间大小）->7555K （GC后占用整个Heap空间大小） (9216K) （整个Heap大小，JVM堆的大小）, Metaspace: （java6 7是permanentspace，java8改成Metaspace，类相关的一些信息） 2613K->2613K(1056768K) （GC前后基本没变，空间很大）], 0.1022588 secs（GC的耗时，秒为单位）[Times: user=0.56 sys=0.02, real=0.10 secs]（用户空间耗时，内核空间耗时，真正的耗时时间）

Java8中的JVM的MetaSpace

Metaspace的使用C语言实现的，使用的是OS的空间，Native Memory Space可动态的伸缩，可以根据类加载的信息的情况，在进行GC的时候进行调整自身的大小，来延缓下一次GC的到来。可以设置Metaspace的大小，如果超过最大大小就会OOM，不设置如果把整个操作系统的内存耗尽了出现OOM，一般会设置一个足够大的初始值，安全其间会设置最大值。永久代发生GC有两种情况，类的所有的实例被GC掉，且class load不存。对于元数据空间 简化了GC， class load不存在了就需要进行GC。

Spring Boot的JVM参数调优

在使用spring boot时涉及到对微服务的JVM参数的调优，在此记录一下。对于spring boot项目调优的方式有两种。由于spring boot可以启动jar包的方式启动服务，因此一种比较通用的配置方式就是在启动服务脚本时配置JVM的参数，脚本如下

java -jar -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -Xms1024m -Xmx1024m -Xmn256m -Xss256k -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC test-0.0.1-SNAPSHOT.jar

第二种是通过 application.properties 或者 application.yml 文件设置。这里有一篇官方的的关于配置文件的文章，里面有详细的参数配置和注释，SpringBoot项目详细的配置文件修改文档。其中比较重要的有：

server.tomcat.max-connections=0 # Maximum number of connections that the server accepts and processes at any given time.
server.tomcat.max-http-header-size=0 # Maximum size, in bytes, of the HTTP message header.
server.tomcat.max-http-post-size=0 # Maximum size, in bytes, of the HTTP post content.
server.tomcat.max-threads=0 # Maximum number of worker threads.
server.tomcat.min-spare-threads=0 # Minimum number of worker threads.