1、JVM 简析：
作为一名Java 使用者，掌握 JVM 的体系结构是很有必要的。
说起Java ，我们首先想到的是Java 编程语言，然而事实上，Java 是一种技术，它由四方面组成：Java 编程语言、Java 类文件格式、Java 虚拟机 和 Java 应用程序接口（Java API）。他们的关系图如下：
Java 平台由 Java 虚拟机和 Java 应用程序接口搭建，Java 语言则是进入这个平台的通道，用Java 语言编写并编译程序可以运行在这个平台上。这个平台的结构如下所示：运行期环境代表着Java平台，开发人员编写Java 代码（.java文件），然后将之编译成字节码（.class文件），再然后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者被即时代码发生器有选择的转换成机器码执行。
JVM 在它的生命周期中有一个明确的任务，那就是运行Java 程序，因此当Java 程序启动的时候，就产生JVM 的一个实例；当程序运行结束的时候，该实例也跟着消失了。在Java 平台的结构中，可以看出，JVM 在核心的位置，是程序与底层操作系统和硬件无关的关键。它的下方是移植接口，移植接口由两部分组成：适配器和Java 操作系统，其中依赖平台的部分称之为适配器；JVM 通过移植接口在具体的平台和操作系统上实现；JVM 的上方是Java 基本类库和扩展类库以及他们的API,利用Java API 编写的应用程序（application）和小程序（Java applet）可以再任何Java 平台上运行而无需考虑底层平台，就是因为有Java 虚拟机（JVM）实现了程序与操作系统的分离，从而实现了Java 的平台无关性。
下面，我们从JVM 的基本概念和运行过程这两个方面入手，来对它进行深入的研究。
2、JVM 基本概念
（1）基本概念：
JVM 是可运行Java 程序的假想计算机，包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收、堆和一个存储方法域。JVM 是运行在操作系统之上的，它与硬件没有直接的交互。
（2）运行过程：
我们都知道Java 源文件，通过编译器，能够产生相应的.class文件，也就是字节码文件，而字节码文件又通过Java 虚拟机的解释器，解释成特定机器上的机器码。
也就是如下：
① Java 源文件 ——> 编译器 ——> 字节码文件
② 字节码文件 ——> JVM ——> 机器码
每一种平台的解释器是不同的，但是实现的虚拟机是相同的，这也就是Java 为什么能跨平台的原因了，当一个程序开始运行，这时虚拟机就开始实例化了，多个程序启动就会存在多个虚拟机实例。程序退出或者关闭，则虚拟机实例消亡，多个虚拟机实例之间数据不能共享。
3、JVM 的体系结构
（1）Class Loader 类加载器
负责加载.class文件，class文件在文件开头有特定的文件标识，并且ClassLoader 负责class文件的加载。
类的生命周期：加载 ——> 验证 ——> 准备 ——> 解析 ——> 初始化 ——> 使用 ——> 卸载
1、加载：
① 通过一个类的全限定名，来获取此类的二进制字节码；
② 将这个字节码所代表的静态存储结构转化为方法区的运行时数据结构；
③ 在Java堆中生成一个代表这个类的Class对象，作为方法区这些数据的访问路口。
2、验证：文件格式验证、元数据验证、字节码验证等。
3、准备：准备阶段是正式为静态变量分配内存并设置静态变量初始值（各数据类型的零值）的阶段，这些内存将在方法区中进行分配。但是如果静态变量的字段属性为常量，则会初始化为指定的值，而不是零值。
4、解析：解析阶段是在虚拟机将符号引用替换为直接引用的过程。直接引用可以是直接指向目标的指针、相对偏移量。
5、初始化：为类的静态变量赋予指定的初始值。
6、使用：使用类之前，必须对类进行实例化，如new或者反射。只有实例化了，才能通过对象的引用来访问对象的实例。
7、卸载：执行垃圾回收。
在类的加载过程中，静态成员会优先加载；而普通成员则是使用的时候才会去加载。
加载顺序：
1. 虚拟机在首次加载 Java 类时，会对静态代码块、静态成员变量、静态方法进行一次初始化（静态间按顺序执行）。
2. 只有在调用 new 方法时才会创建类的实例。
3. 类实例创建过程：父子继承关系，先父类再子类。父类的静态->子类的静态->父类的初始化块->父类的构造方法->子类的初始化块->子类的构造方法
4. 类实例销毁时候：首先销毁子类部分，再销毁父类部分。
双亲委派机制：
JVM的类加载是通过ClassLoader及其子类来完成的，类的层次关系和加载顺序可以由下图来描述：
自上而下尝试加载，最下面的加载器没有加载到的话，则抛出ClassNotFoundException。
Bootstrap ClassLoader启动类加载器：加载
Extension ClassLoader扩展类加载器：加载
App ClassLoader应用程序类加载器：加载用户类路径 java -classpath 上所指定的类库，就是你项目配置的 jar 路径以及工程生成的 classes 的位置。
双亲委派机制的优势：
系统安全性：Java类随着加载它的类加载器一起具备了一种带有优先级的层次关系。比如，Java中的Object类，它存放在rt.jar之中,无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object在各种类加载环境中都是同一个类。如果不采用双亲委派模型，那么由各个类加载器自己去加载的话，那么系统中会存在多种不同的Object类。
（2） Native Interface 本地接口
本地接口的作用是融合的不同编程语言为Java 所用，它的初衷是融合C/C++ 程序，Java 诞生的时候C/C++ 横行的时候，要想立足，必须调用C/C++ 程序，于是就在内存中专门开辟了一块处理标记为native 的代码，它的具体做法是Native Method Stack 中登记native 方法，在Execution Engine 执行加载native libraries。
（3）Execution Engine 执行引擎
执行包在类装载的方法中的指令。
（4）Runtime data area 运行数据区
虚拟机内存，从整个计算机内存中开辟一块内存存储JVM 需要用到的对象、变量等，运行区数据又分为很多小区：方法区，虚拟机栈，本地方法栈，堆，程序计数器。
4、JVM 数据运行区详解（栈管理运行，堆管理存储）
说明：JVM 调优主要就是优化 Heap堆 和 Method Area 方法区，并且这两个区域是线程共享的数据区。
（1）Native Method Stack 本地方法栈
Native Method Stack 登记native 方法，在Execution Engine 执行加载native libraries。
（2）PC Register 程序计数器
每个线程都有一个程序计数器，就是一个指针，指向方法区中的方法字节码（下一个将要执行的指令代码），由执行引擎读取下一条指令。
（3）Method Area 方法区
方法区是被所有线程共享，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap(非堆)，目的是与 Java 堆区分开来。
对于 HotSpot 虚拟机而言，很多人更愿意把方法区称为"永久带"(Permanent Generation)，本质上两者并不等价，仅仅是因为 HotSpot 虚拟机的设计团队选择把 GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已。
运行时常量池
运行时常量池是方法区的一部分，Class 文件中除了有类的版本、字段、方法、接口等描述外，还有一项信息是常量池，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。
采用字面值的方式创建一个字符串时（如 String s1 = "abc"），JVM 首先会去字符串池中查找是否存在 "abc" 这个对象，如果不存在，则在字符串池中创建 "abc" 这个对象，然后将池中 "abc" 这个对象的引用地址返回给 "abc" 对象的引用 s1，这样 s1 会指向池中 "abc" 这个字符串对象；如果存在，则不创建任何对象，直接将池中 "abc" 这个对象的地址返回，赋给引用 s1。
注意：JDK1.8版本中，String 常量池 和 静态变量已经从方法区中的运行时常量池分离到堆中了。
（4）Stack 栈
① 栈是什么
栈也叫栈内存，主管Java 程序的运行，是在线程创建时创建，它的生命周期跟随线程的生命周期，线程结束栈内存也就释放，对于栈来说，不存在垃圾回收问题，只要线程一结束栈就Over，生命周期和线程一致，是线程私有的。
基本类型的变量和对象的引用变量都是在栈内存中分配的，但是对象的实例还是保存在堆中的。
② 栈存储什么？
栈帧中主要保存3类数据：
局部变量（Local Variables）：输入参数和输出参数以及方法类的变量；
栈操作（Operand Stack）：记录出栈、入栈的操作；
栈帧数据（Frame Data）：包括类文件、方法等等。
③ 栈运行原理
栈中的数据都是以栈帧（Stack Frame）的格式存在的，栈帧是一个内存区块。当一个方法被A 调用时就产生了一个栈帧F1，并被压入到栈中，A 方法又调用了B方法，于是产生栈帧F2 也被压入栈，B方法又调用了C 方法，于是产生栈帧F3 也被压入栈，依次执行完毕后，先弹出F3 栈帧，再弹出F2 栈帧，再弹出F1 栈帧。遵循“先进后出”原则。
当出现递归方法，参数个数过多、递归过深、递归没有出口时，就有可能报 StackOverflow 异常。
（5）Heap 堆（ParNew + CMS 组合为例）
堆这块区域是JVM 中最大的，实例对象（成员变量，方法）都是存在这个区域，这块区域是GC 主要的回收区，一个 JVM 实例只存在一个堆内存，堆内存大小是可以调节的。类加载器读取了类文件后，需要把类、方法放到堆内存中，以方便执行器执行，堆内存分为三部分：
① 新生代（ParNew 垃圾收集器为例）
新生代是类的诞生、成长、消亡的区域，一个类在这里产生、应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分：伊甸区（Eden space）和幸存区（Survivor pace），空间分配是 8:1:1，绝大多数的类都是在伊甸区被 new 出来的。幸存区有两个：0区（Survivor 0 space）和 1区（Survivor 1 space）。两个Survivor 区空间一样大，当Eden 区满了，则会触发普通GC，若 Eden 区中的对象经过垃圾回收没有被回收掉，会将Eden 区中的幸存对象移动到幸存区（0或1）。若该幸存区也满了，则继续触发普通 GC，然后将 eden 区和 survivor0 区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，这样在一段时间内，总会有一个空的survivor区。经过多次GC周期后，仍然存活下来的对象会被转移到年老代内存空间 。通常这是在年轻代有资格提升到年老代前通过设定年龄阈值来完成的。需要注意，Survivor的两个区是对称的，没先后关系。
显然，Survivor 区只是增加了对象在年轻代中逗留的时间，增加了被垃圾回收的可能性。若养老区也满了，那么这时候将产生Full GC，进行新生代+养老区的内存清理，FullGC 的过程当中，整个JVM是暂停的（所有的应用都被暂停掉）。若Full GC 之后发现依然无法进行对象的保存，就会产生 OOM 异常“OutOfMemoryError”。
新生代特点：每次垃圾回收时都有大量的对象需要被回收。垃圾回收器在新生代采用的收集算法是Copying(复制)方法：它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块面对内存用完了，就将还存活的对象复制到另外一块，然后再把已使用的内存空间一次清理掉。由于新生代有每次垃圾回收时都有大量的对象需要被回收的特点，所以采用Copying算法，复制的存活对象较少，性能比较好。但是Copying算法还是有缺陷的，那就是内存的使用率只有一半。
如果出现 java.lang.OutOfMemoryError: Java heap space 异常，说明Java 虚拟机的堆内存不够。可能产生的原因如下：
1、Java 虚拟机的堆内存设置不够，可以通过-Xms、-Xmx来调整；
2、代码中创建了大量大对象，并且长时间不能被垃圾回收器收集；
3、内存加载的数据量太大：一次性从数据库取太多数据；
4、集合类中有对对象的引用，使用后未清空，GC不能进行回收；
5、代码中存在循环产生过多的重复对象。
② 老年区（CMS 垃圾收集器为例）
年轻代中经过垃圾回收没有回收掉的对象将被Copy到年老代。
老年代的特点： 每次垃圾回收时只有少量的对象需要被回收。垃圾回收器在老年代采用的收集算法是 Mark-Sweep 算法（标记-清除算法）：为了解决 Copying 算法的缺陷，充分利用内存空间，提出了 Mark-Sweep 算法。它先将需要回收的对象进行标记，然后清理掉需要回收的对象内存。
标记-清除算法的主要缺点是，由于是直接清理掉需要回收的对象内存，所以会产生空间碎片。这样当分配新的对象而没有足够的连续内存空间时，就会使用 Full GC 来对整个堆空间进行压缩，从而影响性能。CMS 垃圾收集器有个优化的点是，当出现上述情况时，不直接使用 Full GC 来处理，而会采用标记-整理算法，来对未标记的存活对象进行移动，从而清理掉端界以外的内存。如下图：
③ 永久代
只有 HotSpot 虚拟机才有永久代的概念，永久代存放类的常量、静态变量等信息，是方法区的实现，可以直接理解为方法区，所以实际上，永久代不属于堆，而是方法区。对永久代的回收主要回收两部分内容：废弃常量和无用的类。
如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java 虚拟机对永久带Perm内存设置不够。原因有二：
1、程序启动需要加载大量的第三方jar包。例如：在一个Tomcat 下部署了太多的应用。
2、大量动态反射生成的类不断被加载，最终导致Perm 区被占满。
注意：JDK1.8 之后，不存在永久代，即没有 java.lang.OutOfMemoryError: PermGen space 这种错误。取而代之的是 Meta space（元空间）。之前存储在永久带的字符串常量，静态变量移到了堆中去了，元空间不存储在虚拟机中，而是存储在本地内存中。元空间存储的是 class 文件在 jvm 里的运行时数据结构，如 method，constantPool（运行时常量池）。
JDK8 取消永久代的考量：
永久代是 HotSpot 虚拟机特有的，是一个较小的内存空间，所以很容易出现内存不足的情况，导致频繁 Full GC，这是不合理的。故 JDK 8，依照 JRockit 虚拟机的设计，使用元空间替代了永久代，并且将其存放在本地内存中，从而避免了永久代的频繁 Full GC 现象。
CMS垃圾收集器(Major GC)的触发条件有以下几个：
1、如果没有设置-XX:+UseCMSInitiatingOccupancyOnly，虚拟机会根据收集的数据决定是否触发（建议带上这个参数）。
2、老年代使用率达到阈值 CMSInitiatingOccupancyFraction，默认 92%，前提是配置了第一个参数。
3、永久代的使用率达到阈值 CMSInitiatingPermOccupancyFraction，默认92%，前提是开启 CMSClassUnloadingEnabled并且配置了第一个参数。
4、新生代的晋升担保失败。
4、垃圾回收机制
垃圾回收：当一个对象没有引用指向它时，这个对象就成为无用的内存（垃圾），就必须进行回收，以便于后续其他对象的内存分配。
判断对象是否存活的方法——可达性分析：程序把所有的引用关系看做一张图，如果一个节点与GC Roots之间没有引用链存在，则该节点视为垃圾回收的对象。
可作为GC Roots对象的包括如下几种：
1、虚拟机栈（栈帧中的本地变量表）中引用的对象；
2、方法区中的静态变量引用的对象；
3、方法区中常量引用的对象；
4、本地方法栈中JNI(Java Native Interface)引用的对象。
5、内存调优简介
在说内存调优之前，我们先了解下内存泄漏和内存溢出。
内存泄漏：是指程序申请内存后，无法释放已申请的内存空间，一次内存泄漏似乎不会影响很大的影响，但是内存泄漏堆积后的后果就是内存溢出。
内存溢出：指程序申请内存时，没有足够的内存供申请者使用。
内存溢出的几种原因：
1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3.代码中存在死循环或循环产生过多重复的对象实体；
4.使用的第三方软件中的BUG；
5.启动参数内存值设定的过小（-Xms、-Xmx）。
调优参数：
说明：在Run Config中的 vm options 中输入“-XX:+PrintGCDtails”，可以看到堆内存运行情况：
（1） 堆大小设置
典型设置：
1、java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m：设置JVM 最大可用内存为3550M。
-Xms3550m：设置JVM 初始内存为3550m。此值可以设置与-Xmx 相同，以避免每次垃圾回收完成后JVM 重新分配内存。
-Xmn2g：设置新生代大小为2G。整个JVM内存大小 = 新生代大小 + 老年代大小 + 元空间。Sun 官方推荐配置为整个堆内存的3/8。
-Xss256K：每个线程默认会开启1M的堆栈，用于存放栈帧、调用参数、局部变量等，对大多数应用而言这个默认值太了，一般256K就足用。理论上，在内存不变的情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。
2、java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxTenuringThreshold=3
-XX:NewRatio = 4：设置新生代（包括Eden和两个Survivor 区）与老年代（出去元空间）的比值。设置为4，则新生代与老年代所占比值为1:4，新生代占整个堆内存的1/5。
-XX:SurvivorRatio = 4：设置新生代Eden 区与Survivor 区的大小比值。设置为4，则两个Survivor 区与一个Eden 区的比例为2:4，一个Survivor 区占整个年轻代的1/6。
-XX:MaxTenuringThreshold=3：设置垃圾最大年龄为3，即对象在Survivor 区存在的年龄为3（复制一次年龄+1）。如果设置为0，则年轻代对象不经过Survivor 区，直接进入老年代。对于老年代比较多的应用，可以提高效率。如果将此设置为一个较大的值，则年轻代对象会在Survivor 区进行多次复制，这样可以增加对象在年轻代存活的时间，增加在年轻代被回收的概率。此参数只有在串行GC时才有效。
（2）回收器选择
JVM 给了三种选择：串行收集器（单线程）、并行收集器、并发标记清除收集器（CMS），但是串行收集器只适用于小数据量的情况。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应的参数。JDK5.0以后，JVM会根据当前系统配置进行判断。
并行收集器是用多线程进行垃圾回收，回收期间会暂停应用程序的执行（stop the world）。而 CMS，也是多线程回收，虽然年轻代回收期间也会 stop the world，但在老年代 CMS 绝大多数情况是并发的，即 jvm 垃圾回收线程和应用程序的线程可以同时进行。老年代的某些阶段也会暂停应用程序，比如初始化标记和重新标记阶段。所以，CMS 适用于交互性高的一些程序，比如 Web 程序，而并行收集器适用于吞吐量高的一些场景。
CMS 回收器的缺点
1、空间碎片
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的串行 GC 方式进行回收，触发一次 full gc，导致一个漫长的暂停。
2、执行GC时间较长
老年代收集器必须扫描整个老年代空间，比如标记、清除、以及压缩。这就意味着 GC 执行工作的时间随着 java 堆空间的变化而线性的增加或者减少。
新一代垃圾收集器：Garbage First（G1）
G1 垃圾收集器是 JDK8 引入的新一代垃圾收集器，G1 将堆拆分成一系列分区。每个分区的大小是 2 的幂次方，在 1M—32M之间，即 1M、2M、4M、8M、16M、32M。JVM 划分大约2048个分区，所以每个分区的大小取决于 java 堆的分配大小。
在 G1 里，年轻代就是一系列的内存分区，这意味着不用再要求年轻代是一个连续的内存块。类似的，老年代也是一系列的分区组成。G1的垃圾收集周期主要分为 3 种类型：年轻代收集周期、多级并发标记周期和混合收集周期。还有一种单线程的暂停 full gc，它是 GC 在垃圾收集遇到转移失败的情况下所采取的安全保护机制，比如目标空间耗尽。
年轻代周期：
年轻代由 2 部分组成，一块是 G1 指定的 eden 分区，另一块是 survivor 分区。当 JVM 从 eden 分区中分配失败，也就是说 eden 分区已经被完全占满，这时会触发一次年轻代收集。年轻代收集首先会把所有存活对象从 eden 分区转移到 survivor 分区中。也就是我们经常说的“拷贝到 survivor”。从此时开始，任意一次年轻代收集都将把存活对象从整个年轻代（不论是 eden 分区还是 survivor 分区）晋升到新的 survivor 分区中。年轻代收集偶尔也会将一些存活对象晋升到老年代分区，这些对象已经到了预先设定的晋升阀值（默认为15，存放在对象头中）。
多级并发标记周期：
随着越来越多的对象被晋升到老年代，或者巨型对象被分配到巨型分区中，老年代的占用比例也越来越多。当老年代的占用比例（与整个堆相比）超过了阀值（默认为 45%），就会触发并发标记周期。
一个 G1 并发周期包含了几个阶段的活动：初始阶段、并发根分区扫描、并发标记、重新标记以及清除。
初始阶段的目的是收集所有的 GC Roots，它是对象图的起点。为了从应用线程中收集根引用，必须先暂停应用线程，所以初始标记阶段是 stop the world 方式的。
标记操作的同时还必须扫描和跟踪 survivor 分区里所有对象的引用（可达性分析），这也是并发根分区扫描所要做的事情。这个阶段，所有 java 线程都允许执行，所以不会发生应用暂停。
大部分标记工作是在并发标记阶段完成的。多个线程协同标示存活对象图。所有 java 线程都允许执行，所以不会发生应用暂停。
完成并发标记后就需要一个 stop the world 方式的阶段来完成最终的标记工作，这个阶段被称为“重新标记阶段”。因为上面的并发标记是允许 java 线程执行的，所以有可能会漏掉标记新的存活对象，需要一个 stop the world 的重新标记。
并发标记周期的最后阶段是清除阶段，在这个阶段，找出那些没有任何存活对象的分区将被回收，回收完后被添加到可用分区的队列里。
混合收集周期：
完成并发标记周期之后，G1 就能识别出最适合被回收的老年代分区集合，于是就会触发混合收集。
混合收集：混合 GC 就是在一次垃圾收集事件中，所有的年轻代分区以及一部分老年代分区将会被回收。
混合收集和年轻代收集是类似的，同时用拷贝的方式对存活的对象进行压缩。
巨型对象：
巨型对象就是指那些尺寸非常大的对象，他们至少占用一个分区的50%甚至更多的空间。这样一个对象不会使用通常用到的快速分配方式，它会在老年代的巨型分区（一个或多个相邻的堆分区）里直接分配。