1.JVM概述
JVM（Java virtual Machine）指以软件的方式模拟具有完整硬件系统功能、运行在一个完全隔离环境中的完整计算机系统 ，是物理机的软件实现。
JVM是一种规范，实现产品常见有：Sun HotSpot VM、BEA JRockit VM、IBM J9 VM、Azul VM、Apache Harmony、Google Dalvik VM、Microsoft JVM... ，其中使用比较多的是sun（Oracle）公司的HotSpot。如我们可以通过java -version查看自己机器上安装的JVM类型
2.JVM内存模型
JVM由三部分构成，类加载器子系统，运行时数据区（内存结构），执行引擎
其中在运行时数据区中，方法区和堆是线程共享的，而java栈，本地方法栈和程序计数器，是线程独占的。
2.1 类装载子系统
1.类的加载过程
在java代码中，类的加载、连接和初始化过程都是在程序运行期间完成的，提供了更大的灵活性，增加了更多可能性。
- 加载：查找并加载类二进制数据的过程
- 连接
- 验证：确保被加载的类的正确性；
- 准备：为类的静态变量分配内存，并将其初始化为默认值；
- 解析：把类中的符号引用转换为直接引用；
- 初始化：为类中的静态变量赋予正确的初始值；
2.类加载器
类加载器的种类
- 启动类加载器(BootStrap)：负责加载JRE的核心类库，如jre目标下的rt.jar,charsets.jar等
- 扩展类加载器(Extension)：负责加载JRE扩展目录ext中JAR类包
- 系统(应用)类加载器(System)：负责加载ClassPath路径下的类包
- 用户自定义加载器：负责加载用户自定义路径下的类包
类加载机制
- 全盘负责委托机制：当一个ClassLoader加载一个类时，除非显示的使用另一个ClassLoader，该类所依赖和引用的类也由这个ClassLoader载入
- 父类委托机制：指先委托父类加载器寻找目标类，在找不到的情况下在自己的路径中查找并载入目标类。并非所有JVM实现中都使用该加载机制，只有HotSpot才使用该加载机制。
- 加载过程
3.加载阶段
类的加载是指将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在内存中创建一个java.lang.Class对象（规范并非说明Class文件对象位于哪里，HotSpot虚拟机将其放在了方法区中），用来封装类在方法区内的数据结构。类加载后，最终的产品是位于内存中的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。
在类加载过程中，可以从这些地方加载.class文件
- 从本地系统中直接加载；
- 通过网络下载.class文件；
- 从ZIP，jar等归档文件中加载.class文件；
- 从专有数据库中提取.class文件；
- 将Java源文件动态编译为.class文件；
4.连接阶段
验证：确保被加载的类的正确性
准备：为类的静态变量分配内存，并将其初始化为默认值
在准备阶段，Java虚拟机为类的静态变量分配内存，并设置默认的初始值，例如对于以下Sample类，在准备阶段，将为int类型的静态变量a分配4个字节的内存空间，并且默认值0，为long类型的静态变量b分配个字节的内存空间，并且赋予默认值0.
public class Simple {
private static int a=1;
public static long b;
static {
b=2;
}
}
解析：把类中的符号引用转化为直接引用。关于字节码文件的解析，见“JVM字节码文件”
5.初始化阶段
初始化：为类的静态变量赋予正确的初始值
类的初始化步骤：
- 假如这个类还没有被加载和连接，那就先进行加载和连接；
- 假如类存在直接父类，并且这个父类还没有被初始化，那就先初始化直接父类
- 假如类中存在初始化语句，那就依次执行这些初始化语句
类的初始化时机
主动使用：所有的java虚拟机实现必须要在每个类或接口被java程序“首次主动使用”时才初始化它们；
- 创建类的实例：new Object()
- 创建某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射: Class.forName
- 初始化一个类的子类，也表示对其父类的主动使用
- Java虚拟机启动是被标明为启动类的类（Java Test）
- JDK1.7开始提供的动态语言的支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic,REF_putStatic,REF_invokeStatic句柄对应的类没有初始化，则初始化
- 除此之外，其它使用方式都是被动使用，不会导致类的初始化。
被动使用
注意：当java虚拟机初始化一个类时，要求它的所有父类都已经被初始化，这条规则并不适用于接口。
- 在初始化一个类时，并不会先初始化它所实现的接口
- 在初始化一个接口时，并不会先初始化它的父接口
因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化，只有当程序首次使用特定接口的静态变量时，才会导致接口的初始化。
使用方法见：关于父接口和子接口子在初始化顺序上的关系
6.使用阶段
作者：KingdomCoder在类的使用过程中依然存在三步：对象实例化、垃圾收集、对象终结。
- 对象实例化：就是执行类中构造函数的内容，如果该类存在父类JVM会通过显示或者隐示的方式先执行父类的构造函数，在堆内存中为父类的实例变量开辟空间，并赋予默认的初始值，然后在根据构造函数的代码内容将真正的值赋予实例变量本身，然后，引用变量获取对象的首地址，通过操作对象来调用实例变量和方法 。
- 垃圾收集：当对象不再被引用的时候，就会被虚拟机标上特别的垃圾记号，在堆中等待GC回收
- 对象的终结：对象被GC回收后，对象就不再存在，对象的生命也就走到了尽头
链接：https://www.jianshu.com/p/97c3466eaec1
来源：简书
7.卸载阶段
即类的生命周期走到了最后一步，程序中不再有该类的引用，该类也就会被JVM执行垃圾回收，从此生命结束…
部分观点援引自“深入理解JVM 张龙”，详细笔记见“Java虚拟机--类的加载、连接、初始化”
该部分经常设置的考题
2.2 运行时数据区
对于该区域进行分析时主要考虑的地方是，用途，垃圾回收器的行为，异常类型。方法区和堆都属于线程共享区，其他三个区域属于线程私有区，只有线程共享区才存在垃圾回收行为。
2.2.1 方法区(线程共享)
类的所有字段和方法字节码，以及一些特殊方法如构造函数，接口代码也在此定义。简单说，所有定义的方法的信息都保存在该区域，静态变量+常量+类信息(构造方法/接口定义)+运行时常量池都存在方法区中，虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来。
通常和永久区关联在一起(Java7之前)，但具体的跟JVM的实现和版本有关。
发生的异常类型为OutOfMemoryError
垃圾回收期在该区域回收废弃的类、回收常量池中废弃的常量。
2.2.2 虚拟机栈(线程私有)
Java线程执行方法的内存模型，一个线程对应一个栈，每个方法在执行的同时都会创建一个栈帧（用于存储局部变量表，操作数栈，动态链接，方法出口等信息）不存在垃圾回收问题，只要线程一结束该栈就释放，生命周期和线程一致。
JVM对该区域规范了两种异常：
1) 线程请求的栈深度大于虚拟机栈所允许的深度，将抛出StackOverFlowError异常
2) 若虚拟机栈可动态扩展，当无法申请到足够内存空间时将抛出OutOfMemoryError，通过jvm参数–Xss指定栈空间，空间大小决定函数调用的深度
关于局部变量表
- 存放编译期间可知的基本数据类型，引用数据类型，returnAddress类型等。
- 在编译期间完成分配，当进入一个方法时，该方法在栈帧中分配多大的内存空间是固定的，在方法运行期间不会修改局部变量表的大小
2.2.3 本地方法栈(线程私有)
登记native方法，在Execution Engine执行时加载本地方法库
2.2.4 程序计数器(线程私有)
每个线程都有一个程序计数器，是线程私有的,就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。该区域是JVM规范中，唯一没有定义OutOfMemoryError的区域。
2.2.5 堆(线程共享)
虚拟机启动时创建，用于存放对象实例，几乎所有的对象（包含常量池）都在堆上分配内存，当对象无法再该空间申请到内存时将抛出OutOfMemoryError异常。同时也是垃圾收集器管理的主要区域。可通过 -Xmx –Xms 参数来分别指定最大堆和最小堆
1.新生区
新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存0区.若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢？
如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：
（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。
2.老年区
新生区经过多次GC仍然存活的对象移动到老年区。若老年区也满了，那么这个时候将产生MajorGC（FullGC），进行老年区的内存清理。若老年区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”
3.元数据区
- 元数据区取代了永久代(jdk1.8以前)，本质和永久代类似，都是对JVM规范中方法区的实现，区别在于元数据区并不在虚拟机中，而是使用本地物理内存，永久代在虚拟机中，永久代逻辑结构上属于堆，但是物理上不属于堆，堆大小=新生代+老年代。元数据区也有可能发生OutOfMemory异常。
- Jdk1.6及之前： 有永久代, 常量池在方法区
- Jdk1.7： 有永久代，但已经逐步“去永久代”，常量池在堆
- Jdk1.8及之后： 无永久代，常量池在元空间
- 元数据区的动态扩展，默认–XX:MetaspaceSize值为21MB的高水位线。一旦触及则Full GC将被触发并卸载没有用的类（类对应的类加载器不再存活），然后高水位线将会重置。新的高水位线的值取决于GC后释放的元空间。如果释放的空间少，这个高水位线则上升。如果释放空间过多，则高水位线下降。
- 为什么jdk1.8用元数据区取代了永久代？ 官方解释：移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代。
4.栈+堆+方法区的交互关系
该区域定义的异常行为：当对象无法在该空间申请到内存时，将抛出OutOfMemoryError异常
垃圾回收器在该区域的行为：在该区域回收废弃对象
2.3 执行引擎
读取运行时数据区的Java字节码并逐个执行
2.4 本地接口库
Java语言本身不能对操作系统底层进行访问和操作，但是可以通过JNI接口调用其他语言来实现对底层的访问。
本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合 C/C++程序，Java诞生的时候是C/C++横行的时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为Native的代码，它的具体做法是Native Method Stack中登记Native方法，在Execution Engine 执行时加载Native libraries。
目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用WebService等等，不多做介绍。
3.内存分配和垃圾回收
3.1 JVM内存分配
1.对象优先在Eden区分配
大多数情况下，对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
2.大对象直接进入到老年区
大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。
为什么要这样呢？
为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。
3.长期存活的对象将进入到老年区
采用分代收集算法时，虚拟机给每个对象一个对象年龄（Age）计数器。
如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为1.对象在 Survivor 中每熬过一次 MinorGC,年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
3.2 对于类、对象和常量回收标准
1.如何判断一个对象可被回收
引用计数器法：给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加1；当引用失效，计数器就减1；任何时候计数器为0的对象就是不可能再被使用的。这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。
可达性分析法：这个算法的基本思想就是通过一系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的。
关于GC Roots根节点：类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法栈的变量等等
通过finalize()方法最终判定对象是否存活
即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历再次标记过程。
标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链。
1). 第一次标记并进行一次筛选。
筛选的条件是此对象是否有必要执行finalize()方法。
当对象没有覆盖finalize方法，或者finzlize方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，对象被回收。
2). 第二次标记
如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个名为：F-Queue的队列之中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果一个对象finalize（）方法中执行缓慢，或者发生死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。
finalize()方法是对象脱逃死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize（）中成功拯救自己----只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了。
2.如何判断一个常量是废弃常量
运行时常量池主要回收的是废弃的常量。假如在常量池中存在字符串 "abc"，如果当前没有任何String对象引用该字符串常量的话，就说明常量 "abc" 就是废弃常量，如果这时发生内存回收的话而且有必要的话，"abc" 就会被系统清理出常量池。
3.如何判断一个类可被回收
方法区主要回收的是无用的类，判断一个类是无用的类的标准：
- 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
- 加载该类的 ClassLoader 已经被回收。
- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
虚拟机可以对满足上述3个条件的无用类进行回收，但仅仅是“可以回收”，而并不是和对象一样不使用了就会必然被回收。
3.3 垃圾收集算法
3.3.1 标记清除算法
算法分为“标记”和“清除”阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的收集算法，效率也很高，但是会带来两个明显的问题：
- 效率问题：效率比较低（递归与全栈对象遍历），而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差。
- 空间问题：标记清除后会产生大量不连续的碎片，导致JVM需要维护一张内存空间列表，用以记录内存的使用情况，这又是一种开销。
3.3.2 标记整理算法
根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一段移动，然后直接清理掉端边界以外的内存。
标记整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记整理算法要低于复制算法。
3.3.3 复制算法
为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
3.3.4 分代收集算法
当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
比如在新生代中，每次收集都会有大量对象死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。
小结：三种垃圾回收算法的比较
内存效率：复制算法>标记清除算法>标记整理算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。
内存整齐度：复制算法==标记整理算法>标记清除算法。
内存利用率：标记整理算法==标记清除算法>复制算法。
3.4 垃圾收集器
垃圾收集器种类
3.4.1 Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)
Serial（串行）收集器是最基本、历史最悠久的垃圾收集器。它是一个单线程收集器， “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束。
新生代采用复制算法，老年代采用标记-整理算法。
优点：简单而高效（与其他收集器的单线程相比）。Serial收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。
缺点：垃圾收集过程中，需要停止其他所有工作线程。
3.4.2 ParNew收集器
ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器完全一样。
新生代采用复制算法，老年代采用标记-整理算法。
它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器配合工作。
3.4.3 Parallel Scavenge收集器(-XX:+UseParallelGC(新生代),-XX:+UseParallelOldGC（老生代）)
Parallel Scavenge 收集器类似于ParNew 收集器，是Server 模式（内存大于2G，2个cpu）下的默认收集器。
Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量。
新生代采用复制算法，老年代采用标记-整理算法。
3.4.4 Serial Old收集器
Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案。
3.4.5 Parallel Old收集器
Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器。
3.4.6 CMS收集器(-XX:+UseConcMarkSweepGC(old) -XX:+UseParNewGC)
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它而非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：
- 初始标记： 暂停所有的其他线程(STW)，并记录下直接与root相连的对象，速度很快 ；
- 并发标记： 同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
- 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
- 并发清除： 开启用户线程，同时GC线程开始对未标记的区域做清扫。
主要优点：并发收集、低停顿。
主要缺点：
- 对CPU资源敏感（会和服务抢资源）；
- 无法处理浮动垃圾(在java业务程序线程与垃圾收集线程并发执行过程中又产生的垃圾，这种浮动垃圾只能等到下一次gc再清理了)；
- 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。
CMS的相关参数
-XX:+UseConcMarkSweepGC 启用cms
-XX:ConcGCThreads:并发的GC线程数（并非STW时间，而是和服务一起执行的线程数）
-XX:+UseCMSCompactAtFullCollection:FullGC之后做压缩（减少碎片）
-XX:CMSFullGCsBeforeCompaction:多少次FullGC之后压缩一次（因压缩非常的消耗时间，所以不能每次FullGC都做）
-XX:CMSInitiatingOccupancyFraction:触发FulGC条件（默认是92）
-XX:+UseCMSInitiatingOccupancyOnly:是否动态调节
-XX:+CMSScavengeBeforeRemark:FullGC之前先做YGC（一般这个参数是打开的）
-XX:+CMSClassUnloadingEnabled:启用回收Perm区（jdk1.7及以前）
3.4.7 G1收集器(-XX:+UseG1GC)
G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征.
G1将Java堆划分为多个大小相等的独立区域（Region），虽保留新生代和老年代的概念，但不再是物理隔阂了，它们都是（可以不连续）Region的集合。
分配大对象（直接进Humongous区，专门存放短期巨型对象，不用直接进老年代，避免Full GC的大量开销）不会因为无法找到连续空间而提前触发下一次GC。
被视为JDK1.7中HotSpot虚拟机的一个重要进化特征。它具备以下特点：
- 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。
- 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
- 空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
- 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内完成垃圾收集。
G1收集器的运作大致分为以下几个步骤：
- 初始标记（initial mark，STW）：在此阶段，G1 GC 对根进行标记。该阶段与常规的 (STW) 年轻代垃圾回收密切相关。
- 并发标记（Concurrent Marking）：G1 GC 在整个堆中查找可访问的（存活的）对象。
- 最终标记（Remark，STW）：该阶段是 STW 回收，帮助完成标记周期。
- 筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。
G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了GF收集器在有限时间内可以尽可能高的收集效率。
G1垃圾收集分类
YoungGC
-
- 新对象进入Eden区
- 存活对象拷贝到Survivor区
- 存活时间达到年龄阈值时，对象晋升到Old区
MixedGC
1.不是FullGC，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)
2.global concurrent marking （全局并发标记）
-
- Initial marking phase:标记GC Root，STW
- Root region scanning phase：标记存活Region
- Concurrent marking phase：标记存活的对象
- Remark phase :重新标记,STW
- Cleanup phase:部分STW
3.相关参数
-
- G1MixedGCLiveThresholdPercent Old区的region被回收的时候的存活对象占比
- G1MixedGCCountTarget：一次global concurrent marking之后，最多执行Mixed GC的次数
- G1OldCSetRegionThresholdPercent 一次Mixed GC中能被选入CSet的最多old区的region数量
4.触发的时机
-
- InitiatingHeapOccupancyPercent:堆占有率达到这个值则触发global concurrent marking，默认45%。
- G1HeapWastePercent:在global concurrent marking结束之后，可以知道区有多少空间要被回收，在每次YGC之后和再次发生Mixed GC之前，会检查垃圾占比是否达到了此参数，只有达到了，下次才会发生Mixed GC
3.4.8 如何选择垃圾收集器
- 优先调整堆的大小让服务器自己来选择
- 如果内存小于100M，使用串行收集器
- 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
- 如果允许停顿时间超过1秒，选择并行或者JVM自己选
- 如果响应时间最重要，并且不能超过1秒，使用并发收集器
下图有连线的可以搭配使用，官方推荐使用G1，因为性能高
4.JVM调优
JVM调优主要就是调整下面两个指标
-
- 停顿时间: 垃圾收集器做垃圾回收中断应用执行的时间。 -XX:MaxGCPauseMillis
- 吞吐量：垃圾收集的时间和总时间的占比：1/(1+n)，吞吐量为1-1/(1+n) 。 -XX:GCTimeRatio=n
4.1 GC调优步骤
打印GC日志
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./gc.log
Tomcat则直接加在JAVA_OPTS变量里
分析日志得到关键性指标
分析GC原因，调优JVM参数
1、Parallel Scavenge收集器(默认)
分析parallel-gc.log
调优：
第一次调优，设置Metaspace大小：增大元空间大小-XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=64M
第二次调优，增大年轻代动态扩容增量，默认是20(%)，可以减少young gc：-XX:YoungGenerationSizeIncrement=30
比较下几次调优效果：
吞吐量 最大停顿 平均停顿 Young gc Full gc
98.356% 120 ms 19 ms 19 2
99.252% 20 ms 10 ms 16 0
99.24% 17
2、配置CMS收集器
-XX:+UseConcMarkSweepGC
分析cms-gc.log
3、配置G1收集器
-XX:+UseG1GC
分析g1-gc.log
young GC：[GC pause (G1 Evacuation Pause) (young)
initial-mark：[GC pause (Metadata GC Threshold) (young) (initial-mark) (参数：InitiatingHeapOccupancyPercent)
mixed GC：[GC pause (G1 Evacuation Pause) (mixed) （参数：G1HeapWastePercent）
full GC：[Full GC (Allocation Failure) (无可用region)
（G1内部，前面提到的混合GC是非常重要的释放内存机制，它避免了G1出现Region没有可用的情况，否则就会触发Full GC事件。
CMS、Parallel、Serial GC都需要通过Full GC去压缩老年代并在这个过程中扫描整个老年代。G1的Full GC算法和Serial GC收集器完全一致。当一个Full GC发生时，整个Java堆执行一个完整的压缩，这样确保了最大的空余内存可用。G1的Full GC是一个单线程，它可能引起一个长时间的停顿时间，G1的设计目标是减少Full GC，满足应用性能目标。）
查看发生MixedGC的阈值：jinfo -flag InitiatingHeapOccupancyPercent 进程id
调优：
第一次调优，设置Metaspace大小：增大元空间大小-XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=64M
第二次调优，添加吞吐量和停顿时间参数：-XX:GCTimeRatio=80 -XX:MaxGCPauseMillis=100
分析工具：gceasy，GCViewer
4.2 G1调优相关
常用参数
- -XX:+UseG1GC 开启G1
- -XX:G1HeapRegionSize=n,region的大小，1-32M，2048个
- -XX:MaxGCPauseMillis=200 最大停顿时间
- -XX:G1NewSizePercent -XX:G1MaxNewSizePercent
- -XX:G1ReservePercent=10 保留防止to space溢出（）
- -XX:ParallelGCThreads=n SWT线程数（停止应用程序）
- -XX:ConcGCThreads=n 并发线程数=1/4*并行
最佳实践
年轻代大小：避免使用-Xmn、-XX:NewRatio等显示设置Young区大小，会覆盖暂停时间目标（常用参数3）
暂停时间目标：暂停时间不要太严苛，其吞吐量目标是90%的应用程序时间和10%的垃圾回收时间，太严苛会直接影响到吞吐量
是否需要切换到G1
50%以上的堆被存活对象占用
对象分配和晋升的速度变化非常大
垃圾回收时间特别长，超过1秒
G1调优目标
6GB以上内存
停顿时间是500ms以内
吞吐量是90%以上
4.3 GC常用参数
堆栈设置
-
- -Xss:每个线程的栈大小
- -Xms:初始堆大小，默认物理内存的1/64
- -Xmx:最大堆大小，默认物理内存的1/4
- -Xmn:新生代大小
- -XX:NewSize:设置新生代初始大小
- -XX:NewRatio:默认2表示新生代占年老代的1/2，占整个堆内存的1/3。
- -XX:SurvivorRatio:默认8表示一个survivor区占用1/8的Eden内存，即1/10的新生代内存。
- -XX:MetaspaceSize:设置元空间大小
- -XX:MaxMetaspaceSize:设置元空间最大允许大小，默认不受限制，JVM Metaspace会进行动态扩展。
垃圾回收统计信息
-
- -XX:+PrintGC
- -XX:+PrintGCDetails
- -XX:+PrintGCTimeStamps
- -Xloggc:filename
收集器设置
-
- -XX:+UseSerialGC:设置串行收集器
- -XX:+UseParallelGC:设置并行收集器
- -XX:+UseParallelOldGC:老年代使用并行回收收集器
- -XX:+UseParNewGC:在新生代使用并行收集器
- -XX:+UseParalledlOldGC:设置并行老年代收集器
- -XX:+UseConcMarkSweepGC:设置CMS并发收集器
- -XX:+UseG1GC:设置G1收集器
- -XX:ParallelGCThreads:设置用于垃圾回收的线程数
并行收集器设置
-
- -XX:ParallelGCThreads:设置并行收集器收集时使用的CPU数。并行收集线程数。
- -XX:MaxGCPauseMillis:设置并行收集最大暂停时间
- -XX:GCTimeRatio:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
- -XX:YoungGenerationSizeIncrement：年轻代gc后扩容比例，默认是20(%)
CMS收集器设置
-
- -XX:+UseConcMarkSweepGC:设置CMS并发收集器
- -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
- -XX:ParallelGCThreads:设置并发收集器新生代收集方式为并行收集时，使用的CPU数。并行收集线程数。
- -XX:CMSFullGCsBeforeCompaction:设定进行多少次CMS垃圾回收后，进行一次内存压缩
- -XX:+CMSClassUnloadingEnabled:允许对类元数据进行回收
- -XX:UseCMSInitiatingOccupancyOnly:表示只在到达阀值的时候，才进行CMS回收
- -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况
- -XX:ParallelCMSThreads:设定CMS的线程数量
- -XX:CMSInitiatingOccupancyFraction:设置CMS收集器在老年代空间被使用多少后触发
- -XX:+UseCMSCompactAtFullCollection:设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理
G1收集器设置
-
- -XX:+UseG1GC:使用G1收集器
- -XX:ParallelGCThreads:指定GC工作的线程数量
- -XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的幂)，默认将整堆划分为2048个分区
- -XX:GCTimeRatio:吞吐量大小，0-100的整数(默认9)，值为n则系统将花费不超过1/(1+n)的时间用于垃圾收集
- -XX:MaxGCPauseMillis:目标暂停时间(默认200ms)
- -XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)
- -XX:G1MaxNewSizePercent:新生代内存最大空间
- -XX:TargetSurvivorRatio:Survivor填充容量(默认50%)
- -XX:MaxTenuringThreshold:最大任期阈值(默认15)
- -XX:InitiatingHeapOccupancyPercen:老年代占用空间超过整堆比IHOP阈值(默认45%),超过则执行混合收集
- -XX:G1HeapWastePercent:堆废物百分比(默认5%)
- -XX:G1MixedGCCountTarget:参数混合周期的最大总次数(默认8)