JVM 相关汇总

jvm 概念

JVM（Java虚拟机）是一个抽象的计算模型。就如同一台真实的机器，它有自己的指令集和执行引擎，可以在运行时操控内存区域。目的是为构建在其上运行的应用程序提供一个运行环境。JVM可以解读指令代码并与底层进行交互：包括操作系统平台和执行指令并管理资源的硬件体系结构。

一种提供了 java 字节码文件运行的环境，独立与平台之上，包含jvm规范和jvm实现两大部分。

与jdk，jre区别： jdk 是一套泛指java开发的工具库（里面当然包含了jre和jvm）
jre 是java运行时环境，jvm+java标准库

jvm厂商有哪些？ oracleJDK 和openJDK 区别？

oraclejdk 和openjdk 都实现了java虚拟机的规范不同在于：

工具套件略有差别
某些协议与配置不同，如美国出口限制的加密算法等。
api 细微的差别；

使用哪个版本

目前LTS 有2个流行的版本： java8 和 java11 建议这两种选择
java11 有更强的性能，支持更多特性，也在近些年的维护和验证中处于稳定。
无论是哪个版本，请保证各个环境的jdk版本一致，可以减少不必要的兼容问题。

java字节码文件？

一种java 编译后的中间文件，.class 结尾。有jvm进行解释执行（类加载）

class文件一般包含以下：
版本号信息、常量池常量（符号常量）、类信息、字段信息、方法信息、调试信息等。

更多详细可以参考文件：class文件详解
 https://blog.csdn.net/qq_62767608/category_12440630.html

类加载过程

类加载的过程，其实就是解析class文件的过程，在过程中会将class文件定义的信息在内存中分配，class 的整个生命周期就是按照上面的顺序进行的，当然每个类并不是同一时间开始以上过程的，基于jvm对内存的优化，以及动态加载的特性，实际的类加载过程往往是混合交叉进行的。

加载阶段

类加载器ClassLoader根据类的全限定名通过不同的渠道以二进制流的方式获取字节码信息
类加载器在加载完类之后，Java虚拟机会将字节码中的信息保存到内存的方法区中。生成一个InstanceKlass对象，保存类的所有信息，里边还包含实现特定功能比如多态的信息。
同时，Java虚拟机还会在堆中生成一份与方法区中数据类似的java.lang.Class对象。作用是在Java代码中去获取类的信息以及存储静态字段的数据（JDK1.7 字符串常量池和静态变量从永久代移动了 Java 堆中） 加载阶段过后，字节码文件就已经被读取到了内存中，并且会创建一个代表该类的Class对象。

链接阶段

①验证
第一个环节是验证，验证的主要目的是检测Java字节码文件是否遵守了《Java虚拟机规范》中的约束。这个阶段一般不需要程序员参与。
②准备
准备阶段为静态变量（static）分配内存并设置初始值。准备阶段只会给静态变量赋初始值，而每一种基本数据类型和引用数据类型都有其初始值。但注意如果字段是final修饰的基本类型或者字符串常量（经过编译器优化），则会在准备阶段直接赋予最终值。
③解析
解析阶段主要是将常量池中的符号引用替换为直接引用。符号引用就是在字节码文件中使用编号来访问常量池中的内容。直接引用不再使用编号，而是使用内存中地址进行访问具体的数据。
初始化阶段

初始化阶段会执行字节码文件中 clinit 部分的字节码指令。
方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问

一般情况下，以下5中情况会立即对类进行初始化,其他时候可能不会触发初始化。

使用new关键字；
使用反射相关方法；
存在父类时要先初始化父类class
main方法所在类（程序入口）

这里的类初始化，并不是实例化的意思，类的初始化是为类成员分配和赋予初始值的过程是类生命周期的一个阶段。还没有到达对象实例化阶段。

有哪些类加载器？

启动类加载器
是最底层的类加载器，是虚拟机的一部分，它是由C++语言实现的，无法在Java代码中直接获取到，且没有父加载器(这里形容的是父子关系的层次结构，并非继承关系)，也没有继承java.lang.lassLoader类。

它主要负责加载由系统属性 “sun.boot.cass.path” 指定的路径下的核心类库(即<JAVA_HOME>/jre/lib)，包含了Object、String、Math、装箱类型、日期类等核心类

public class Demo {
    public static void main(String[] args) {
        //Bootstrap 引导类加载器
        //打印为null,是因为Bootstrap是C++实现的
        ClassLoader classLoader = Object.class.getClassLoader();
        System.out.println(classLoader);
 
        //查看引导类加载器会加载那些jar包
        URL[] urLs = Launcher.getBootstrapClassPath().getURLs();
        for (URL urL : urLs) {
            System.out.println(urL);
        }
    }
}

扩展类加载器（ExtClassLoader）

全类名:sum.misc.Launch$ExtClassLoader，Java语言实现。
扩展类加载器的父加载器是Bootstrap启动类加载器 (注:不是继承关系)
扩展类加载器负责加载<JAVA_HOME>\jre\lib\ext目录下的类库。

注: JDK9是jdk.internal.loader.ClassLoaders$PlatformClassLoader类

**应用程序类加载器（AppClassLoader）

全类名: sun.misc.Launcher$AppClassLoader
系统类加载器的父加载器是ExtClassLoader扩展类加载器 (注:不是继承关系)
系统类加载器负责加载 classpath环境变量所指定的类库，包括项目中自己编写的类文件以及第三方jar包中的类文件，是用户自定义类的默认类加载器。

** 双亲委派机制**

避免类的重复加载：当父加载器已经加载该类时，就没有必要子加载器再加载一遍，保证被加载类的唯一性。
避免核心类篡改：通过双亲委派机制，让顶层的类加载器去加载核心类，避免恶意代码替换JDK中的核心类库，比如 java.lang.String，确保核心类库的完整性和安全性。
** 自定义的类加载器**
Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

在自定义ClassLoader的子类时候，我们常见的会有两种做法:

重写loadClass()方法：这样会打破双亲委派模型，可能会导致一些Java的核心类无法加载，不建议重写

重写findClass()方法：是在双亲委派模型的框架下进行小范围的改动，建议重写

public class MyClassLoader extends ClassLoader {
 
    private String root;
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
 
        byte[] classData = loadClassData(name);
        if (classData == null) {
            throw new ClassNotFoundException();
        } else {
            return defineClass(name, classData, 0, classData.length);
        }
    }
 
    private byte[] loadClassData(String className) {
 
        String fileName = root + File.separatorChar
                + className.replace('.', File.separatorChar) + ".class";
        try {
            InputStream ins = Files.newInputStream(Paths.get(fileName));
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            int bufferSize = 1024;
            byte[] buffer = new byte[bufferSize];
            int length = 0;
            while ((length = ins.read(buffer)) != -1) {
 
                baos.write(buffer, 0, length);
            }
            return baos.toByteArray();
        } catch (IOException e) {
 
            e.printStackTrace();
        }
        return null;
    }
    public String getRoot() {
 
        return root;
    }
    public void setRoot(String root) {
 
        this.root = root;
    }
    public static void main(String[] args)  {
 
        MyClassLoader classLoader = new MyClassLoader();
        classLoader.setRoot("D:\\");
        Class<?> testClass = null;
        try {
            //需要为com.字节码文件.classloader.A 格式，否则defineClass方法会抛异常
            testClass = classLoader.loadClass("com.字节码文件.classloader.A");
            Object object = testClass.newInstance();
            System.out.println(object.getClass().getClassLoader());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

java9以后得类加载器

启动类加载器使用Java编写，位于jdk.internal.loader.ClassLoaders类中。 Java中的BootClassLoader继承自BuiltinClassLoader实现从模块中找到要加载的字节码资源文件（原先是从jar包中获取）。启动类加载器依然无法通过java代码获取到，返回的仍然是null，保持了统一。

扩展类加载器被替换成了平台类加载器（Platform Class Loader）。平台类加载器遵循模块化方式加载字节码文件，所以继承关系从URLClassLoader（从jar包中获取）变成了 BuiltinClassLoader，BuiltinClassLoader实现了从模块中加载字节码文件。平台类加载器的存在更多的是为了与老版本的设计方案兼容，自身没有特殊的逻辑。

jvm 运行时数据区

类加载的过程就是向运行数据区各个区域分配内存、初始化变量和方法的过程。
参考

程序计数器（线程私有）：

字节码行号指示器，用于标记当前线程执行到哪一个指令地址；
每个线程私有的；
不存在oom问题。

栈、本地方法栈（线程私有）:

栈是java方法的内存模型
出栈的过程就是一个方法被调用和执行完的过程，每个方法在被执行时都会创建一个栈桢，存放变量表，操作站，方法出口等信息。
线程私有的，与线程的生命周期一致；
本地方法栈与java的栈是类似的，只不过是存放的是 native 方法。
栈存在StackOverflowError异常，也存在oom异常

堆内存（线程共享）:

与栈不同的是，堆内存是由程序代码自由分配的一块内存空间。多数存放着实例对象，只要有内存地址，每个线程都可以访问（共享的）
-Xmx 、-Xms 设置，是java中最大的一块内存管理，GC 操作的地方。

Java服务端程序开发时，建议将-Xmx和-Xms设置为相同的值，这样在程序启动之后可使用的总内存就是最大内存，而无需向java虚拟机再次申请，减少了申请并分配内存时间上的开销，同时也不会出现内存过剩之后堆收缩的情况。

非堆内存：

方法区（线程共享，本地内存）：

和Java堆一样，是各个线程共享的内存区域，用于存储已被虚拟机加载的类型信息、常量、静态变量、及时编译器编译后的代码缓存等数据。

类信息：即 Class 类，如类名、访问修饰符、常量池、字段描述、方法描述等。

方法区也是多个线程共享的，并且存在垃圾回收机制；
当加载的类超过设定值时会存在OOM 异常（OutOfMemoryError: PermGen space 或OutOfMemoryError: Metaspace）

永久代，早期的jvm使用永久代来实现方法区，1.8之后已经弃用了，后面对标的是jvm中的元空间（metaspace,直接使用了本地内存)来实现方法区。

方法区的大小设定不必是固定的，可以交由jvm动态调整。

1 2	//java8后设置： -XX:MaxMetaspaceSize=2046

为什么永久代被元空间替代？

①整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整，而元空间使用的是本地内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。
②元空间里面存放的是类的元数据，这样加载多少类的元数据就不由 MaxPermSize 控制了, 而由系统的实际可用空间来控制，这样能加载的类就更多了。
③在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有一个叫永久代的东西, 合并之后就没有必要额外的设置这么一个永久代的地方了。

字符串常量池（原先在方法区1.7后分配到堆中）
为了提升性能和较少内存消耗，1.7后在堆中专门指定了字符串常量池和静态变量存储区域
可以通过 -XX:StringTableSize 参数来设置

原来在永久代中，由于gc频率过低不容易释放；
运行时常量池:
运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有常量池表（Constant Pool Table），用于存放编译期生成的各种字面量与符号引用，在类加载后存放到方法区。

类常量池、运行时常量池、字符串常量池的关系和区别？

类常量池与运行时常量池都存储在方法区，而字符串常量池在jdk7时就已经从方法区迁移到了java堆中。
在类编译过程中，会把类元信息放到方法区，类元信息的其中一部分便是类常量池，主要存放字面量和符号引用，而字面量的一部分便是文本字符，在类加载时将字面量和符号引用解析为直接引用存储在运行时常量池；
对于文本字符来说，它们会在解析时查找字符串常量池，查出这个文本字符对应的字符串对象的直接引用，将直接引用存储在运行时常量池；字符串常量池存储的是字符串对象的引用，而不是字符串本身。

垃圾收集 GC

Java中为了简化对象的释放，引入了自动的垃圾回收（Garbage Collection简称GC）机制。通过垃圾回收器来对不再使用的对象完成自动的回收，垃圾回收器主要负责对堆上的内存进行回收。其他很多现代语言比如C#、Python、Go都拥有自己的垃圾回收器。

方法区的垃圾回收

方法区中能回收的内容主要就是不再使用的类。
判定一个类可以被卸载。需要同时满足下面三个条件：

此类所有实例对象都已经被回收，在堆中不存在任何该类的实例对象以及子类对象。
加载该类的类加载器已经被回收。
该类对应的 java.lang.Class 对象没有在任何地方被引用。
由于我们自己编写的类是由应用程序类加载器加载的，而这个加载器在运行过程中是不会被回收的，所以我们自己编写的类只要被加载就不会被回收

heap 区域的回收

gc 基础算法

引用计数法
引用计数法会为每个对象维护一个引用计数器，当对象被引用时加1，取消引用时减1。引用计数法的优点是实现简单，但是它也存在缺点，主要有两点：

每次引用和取消引用都需要维护计数器，对系统性能会有一定的影响
存在循环引用问题，所谓循环引用就是当A引用B，B同时引用A时会出现对象无法回收的问题。

可达性分析算法

Java使用的是可达性分析算法来判断对象是否可以被回收。可达性分析将对象分为两类：垃圾回收的根对象（GC Root）和普通对象，对象与对象之间存在引用关系。

下图中A到B再到C和D，形成了一个引用链，可达性分析算法指的是如果从某个到GC Root对象是可达的，对象就不可被回收，而GC Root对象正常情况下是不会被回收的。

GCRoot对象包含哪些：

线程对象Thread
系统类加载器加载的class 对象，它会关联类中的静态变量。
监视器对象，用来保存同步锁synchronized关键字持有的对象。

5种对象引用：

强引用
可达性算法中描述的对象引用，一般指的是强引用，即是GCRoot对象对普通对象有引用关系，只要这层关系存在，普通对象就不会被回收。
软引用（多用于缓存机制)
继承 SoftReference、或者包装为软引用类型，当gc后内存不足还存在就会回收软引用类型。
弱引用
WeakReference实现弱引用。 gc时会被回收。
虚引用
虚引用是最弱的引用，在 Java 中使用 PhantomReference 进行定义。虚引用中唯一的作用就是用队列接收对象即将死亡的通知，必须和引用队列配合使用。

gc 算法的评估标准

①吞吐量
吞吐量指的是 CPU 用于执行用户代码的时间与 CPU 总执行时间的比值，即吞吐量 = 执行用户代码时间 / （执行用户代码时间 + GC时间）。吞吐量数值越高，垃圾回收的效率就越高，程序执行的效率也越高。

②最大暂停时间
最大暂停时间指的是所有在垃圾回收过程中的STW时间最大值。最大暂停时间越短，用户使用系统时受到的影响就越短。

③堆使用效率
不同垃圾回收算法，对堆内存的使用方式是不同的。比如标记清除算法，可以使用完整的堆内存。而复制算法会将堆内存一分为二，每次只能使用一半内存。

上述三种评价标准：堆使用效率、吞吐量，以及最大暂停时间不可兼得。
一般来说，堆内存越大，需要回收的对象可能就越多，最大暂停时间就越长。
如果想要减少最大暂停时间，可能会将很长的一次的回收拆分成多次，这样会做很多重复的准备工作，就会降低吞吐量。

垃圾回收算法没有最好与最坏，不同的垃圾回收算法，适用于不同的场景。

垃圾回收算法

①标记清除算法

标记清除算法的核心思想分为两个阶段：

标记阶段，将所有存活的对象进行标记。Java中使用可达性分析算法，从GC Root开始通过引用链遍历出所有存活对象。
清除阶段，从内存中删除没有被标记也就是非存活对象。

优缺点：

优点：实现简单，只需要在第一阶段给每个对象维护标志位，第二阶段删除对象即可。
缺点：
碎片化问题：由于内存是连续的，所以在对象被删除之后，内存中会出现很多细小的可用内存单元。如果我们需要的是一个比较大的空间，很有可能这些内存单元的大小过小无法进行分配。
分配速度慢。由于内存碎片的存在，需要维护一个空闲链表，极有可能发生每次需要遍历到链表的最后才能获得合适的内存空间。

②复制算法

复制算法的核心思想是：

准备两块空间From空间和To空间，每次在对象分配阶段，只能使用其中一块空间（From空间）
在垃圾回收GC阶段，将From中存活对象复制到To空间
将两块空间的From和To名字互换

优点：
吞吐量高：复制算法只需要遍历一次存活对象复制到To空间即可，比标记-整理算法少了一次遍历的过程，因而性能较好，但是不如标记-清除算法，因为标记清除算法不需要进行对象的移动

不会产生碎片化空间：复制算法在复制之后就会将对象按顺序放入To空间中，所以对象以外的区域都是可用空间，不存在碎片化内存空间。

缺点：
内存使用效率低：每次只能让一半的内存空间来为创建对象使用

③标记整理算法

标记整理算法也叫标记压缩算法，是对标记清理算法中容易产生内存碎片问题的一种解决方案。
核心思想分为两个阶段：

标记阶段，将所有存活的对象进行标记。Java中使用可达性分析算法，从GC Root开始通过引用链遍历出所有存活对象。
整理阶段，将存活对象移动到堆的一端。清理掉存活对象的内存空间。

优点：
①内存使用效率高：整个堆内存都可以使用，不会像复制算法只能使用半个堆内存
②不会发生碎片化：在整理阶段可以将对象往内存的一侧进行移动，剩下的空间都是可以分配对象的有效空间
-缺点：
整理阶段的效率不高：整理算法有很多种，比如Lisp2整理算法需要对整个堆中的对象搜索3次，整体性能不佳。可以通过TwoFinger、表格算法、ImmixGC等高效的整理算法优化此阶段的性能

④分代GC（重点）

现代优秀的垃圾回收算法，会将上述描述的垃圾回收算法组合进行使用，其中应用最广的就是分代垃圾回收算法(Generational GC)。
分代垃圾回收将整个内存区域划分为年轻代和老年代，年轻代又划分为Eden区（伊甸园区）和幸存者区（包括S0和S1）

可配置的项：

分代回收的流程：

1.分代回收时，创建出来的对象，首先会被放入Eden伊甸园区。

2.随着对象在Eden区越来越多，如果Eden区满，新创建的对象已经无法放入，就会触发年轻代的GC，称为 Minor GC或者Young GC。于是 Eden 的存活对象会放入 From Survivor 空间。

3.Minor GC 后，新对象依然会往 Eden 分配。

4.Eden 剩余内存空间越来越少，又会触发 Minor GC，于是 Eden 和 From Survivor 的存活对象会放入 To Survivor 空间。然后清除使用过的内存区域，交换From Survivor和To Survivor的角色，完成垃圾回收。注意：每次Minor GC中都会为对象记录他的年龄，初始值为0，每次GC完加1。

5.如果Minor GC后对象的年龄达到阈值（最大15，默认值和垃圾回收器有关），对象就会被晋升至老年代。

6.当老年代中空间不足，无法放入新的对象时，先尝试minor gc如果还是不足，就会触发Full GC，Full GC会对整个堆和方法区进行垃圾回收。如果Full GC依然无法回收掉老年代的对象，那么当对象继续放入老年代时，就会抛出Out Of Memory异常。

JVM什么样的对象直接进入老年代？

大对象直接进入老年代
大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。
大对象直接进入老年代的行为是由虚拟机动态决定的，它与具体使用的垃圾回收器和相关参数有关。大对象直接进入老年代是一种优化策略，旨在避免将大对象放入新生代，从而减少新生代的垃圾回收频率和成本。

长期存活的对象将进入老年代
在每个对象的头信息中，都包含一个年龄计数器。对象在经过一次minor gc之后，如果依然存活，并且能够被 survior 所容纳，那么这个年龄计数器就会+1，当计数器的值达到了默认值大小（一般默认值为15），就会进入到老年代。

通过动态年龄判断机制决定是否进入老年代
当 survior 区域的存活对象的总大小占用了 survior 区域大小的50%（可以通过参数指定），那么此时将按照这些对象的存活年龄从小到大排序，然后依次累加，当累加到对象大小超过50%，则将大于等于当前对象年龄的存活对象全部挪到老年代。

如果存在一种极端情况，某次回收，两个区域中还存活的对象空间超过了另外一个区域，这种情况下只好通过 分配担保机制 把新生代的对象提前转移到老年代中去，而此时该对象的年龄则不需要达到阈值。

什么是空间分配担保？
空间担保指的是老年代进行空间分配担保，在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间：
如果大于，则此次Minor GC是安全的
如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。

为什么要进行空间担保？
是因为新生代采用复制收集算法，假如大量对象在Minor GC后仍然存活（最极端情况为内存回收后新生代中所有对象均存活），而Survivor空间是比较小的，这时就需要老年代进行分配担保，把Survivor无法容纳的对象放到老年代。老年代要进行空间分配担保，前提是老年代得有足够空间来容纳这些对象，但一共有多少对象在内存回收后存活下来是不可预知的，因此只好取之前每次垃圾回收后晋升到老年代的对象大小的平均值作为参考。使用这个平均值与老年代剩余空间进行比较，来决定是否进行Full GC来让老年代腾出更多空间。

为什么分代GC算法要把堆分成年轻代和老年代？

可以通过调整年轻代和老年代的比例来适应不同类型的应用程序，提高内存的利用率和性能。
新生代和老年代使用不同的垃圾回收算法，新生代一般选择复制算法，老年代可以选择标记-清除和标记-整理算法，由程序员来选择灵活度较高。
分代的设计中允许只回收新生代（minor gc），如果能满足对象分配的要求就不需要对整个堆进行回收(full gc)，STW时间就会减少。

具体垃圾回收实现

根据具体应用场景选择适合自己的垃圾收集器, 没有哪一个收集器是绝对好和占优势的，只能从应用的场景和具体内存使用情况分析选择。

JDK 默认垃圾收集器：

JDK 8：Parallel Scavenge（新生代）+ Parallel Old（老年代）
JDK 9 ~ JDK20: G1

年轻代-Serial垃圾回收器
Serial是是一种单线程串行回收年轻代的垃圾回收器，采用复制算法回收。

优点：单CPU处理器下吞吐量非常出色
缺点：多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待
适用场景：Java编写的客户端程序或者硬件配置有限的场景

老年代-SerialOld垃圾回收器
SerialOld是Serial垃圾回收器的老年代版本，采用单线程串行回收，回收算法采用标记-整理算法

优点和缺点与Serial垃圾回收器一样
适用场景：①与Serial垃圾回收器搭配使用；②作为 CMS 收集器的后备方案
添加JVM参数-XX:+UseSerialGC，新生代、老年代都将使用串行回收器。

年轻代-ParNew垃圾回收器

ParNew垃圾回收器本质上是对Serial在多 CPU下的优化，使用多线程进行垃圾回收。

优点：多CPU处理器下停顿时间较短
缺点：吞吐量和停顿时间不如G1，所以在JDK9之后不建议使用
适用场景：JDK8及之前的版本中，与CMS老年代垃圾回收器搭配使用
添加JVM参数-XX:+UseParNewGC 新生代使用ParNew回收器，老年代使用串行回收器。
添加JVM参数-XX:+UseParNewGC XX:+UseConcMarkSweepGC 新生代使用ParNew回收器，老年代使用CMS回收器。

老年代-CMS(Concurrent Mark Sweep)垃圾回收器
CMS垃圾回收器关注的是系统的暂停时间，允许用户线程和垃圾回收线程在某些步骤中同时执行，减少了用户线程的等待时间。
从名字中的Mark Sweep这两个词可以看出，CMS 收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

初始标记：用极短的时间标记出GC Roots能直接关联到的对象，用户线程会被暂停。
并发标记：标记所有的对象，用户线程不需要暂停。
重新标记：由于并发标记阶段有些对象会发生了变化，存在错标、漏标等情况，需要重新标记，用户线程会被暂停。
并发清理：清理死亡的对象，用户线程不需要暂停。

优点：并发收集、低停顿
缺点：
①CMS使用了标记-清除算法，在垃圾收集结束之后会出现大量的内存碎片，当有不足以提供整块连续的空间给新对象/晋升为老年代对象时又会触发FullGC。
②无法处理浮动垃圾：在执行”并发清理”步骤时，用户线程也会同时产生一部分可回收对象，但是这部分可回收对象只能在下次执行清理时才会被回收。如果在清理过程中预留给用户线程的内存不足就会出现”Concurrent Mode Failure”，一旦出现此错误时便会切换到SerialOld收集方式。
③CMS收集器对CPU资源非常敏感，在并发阶段虽然不会导致用户线程停顿，但是会因为占用了一部分CPU资源，如果在CPU资源不足的情况下应用会有明显的卡顿。

年轻代-Parallel Scavenge垃圾回收器

Parallel Scavenge是JDK8默认的年轻代垃圾回收器，多线程并行回收，关注的是系统的吞吐量。具备自动调整堆内存大小的特点。

Parallel Scavenge允许手动设置最大暂停时间和吞吐量。

Oracle官方建议在使用这个组合时，不要设置堆内存的最大值，垃圾回收器会根据最大暂停时间和吞吐量自动调整内存大小。

设置最大暂停时间

-XX:MaxGCPauseMillis=n 设置每次垃圾回收时的最大停顿毫秒数。当我们把最大暂停时间设置更小时，Parallel Scavenge回收器会将堆内存减小，以减少最大停顿时间。

设置吞吐量

-XX:GCTimeRatio=n 设置吞吐量为n（用户线程执行时间 = n/n + 1）

自动调整内存大小（默认开启）

-XX:+UseAdaptiveSizePolicy设置可以让垃圾回收器根据吞吐量和最大停顿的毫秒数自动调整内存大小

注：比较短的最大暂停时间和比较高的吞吐量其实是矛盾的，所以如果同时设置了这两者，Parallel Scavenge回收器可能只能尽力达成其中一个目标。建议多次测试，将两者调成合理的值。

优点：吞吐量高，而且手动可控。为了提高吞吐量，虚拟机会动态调整堆的参数
缺点：不能保证单次的停顿时间
适用场景：后台任务，不需要与用户交互，并且容易产生大量的对象。比如：大数据的处理，大文件导出

老年代-Parallel Old垃圾回收器
Parallel Old是为Parallel Scavenge收集器设计的老年代版本，利用多线程并发收集。

优点：并发收集，在多核CPU下效率较高
缺点：暂停时间会比较长
适用场景：与Parallel Scavenge配套使用

添加JVM参数-XX:+UseParallelGC 或 -XX:+UseParallelOldGC可以使用 Parallel Scavenge + Parallel Old这种组合。

G1垃圾回收器（重点）

G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征.

JDK9及之后默认的垃圾回收器是G1（Garbage First）垃圾回收器。JDK9及之后强烈建议使用G1垃圾回收器。

Parallel Scavenge关注吞吐量，允许用户设置最大暂停时间，但是会减少年轻代可用空间的大小。
CMS关注暂停时间，但是吞吐量方面会下降。

而G1设计目标就是将上述两种垃圾回收器的优点融合：

支持巨大的堆空间回收，并有较高的吞吐量。
支持多CPU并行垃圾回收。
允许用户设置最大暂停时间。

** G1垃圾回收器 – 内存结构**

G1出现之前的垃圾回收器，内存结构一般是连续的，如下图：

G1的整个堆会被划分成多个大小相等的区域，称之为区Region，区域不要求是连续的。分为Eden、Survivor、Old区。
Region的大小通过堆空间大小/2048计算得到，也可以通过参数-XX:G1HeapRegionSize=32m指定(其中32m指定region大小为32M)，Region size必须是2的指数幂，取值范围从1M到32M。

** 年轻代回收（Young GC）**

年轻代回收（Young GC），回收Eden区和Survivor区中不用的对象。会导致STW，G1中可以通过参数-XX:MaxGCPauseMillis=n（默认200）设置每次垃圾回收时的最大暂停时间毫秒数，G1垃圾回收器会尽可能地保证暂停时间。

执行流程

新创建的对象会存放在Eden区。当G1判断年轻代区（即伊甸园区和幸存者区）不足（max默认60%），无法分配对象时需要回收时会执行 Young GC。
标记出Eden和Survivor区域中的存活对象
根据配置的最大暂停时间选择某些区域（和其他垃圾回收器有很大区别）将存活对象复制到一个新的Survivor区中（年龄+1），清空这些区域。
后续Young GC时与之前相同，只不过Survivor区中存活对象会被搬运到另一个Survivor区。
当某个存活对象的年龄到达阈值（默认15），将被放入老年代。

6.特殊情况：部分对象如果大小超过Region的一半，会直接放入老年代，这类老年代被称为Humongous区。比如堆内存是 4G，每个Region是2M，只要一个大对象超过了1M就被放入Humongous区，如果对象过大会横跨多个Region。

7.多次回收之后，会出现很多Old老年代区，此时老年代占整堆比达到阈值时（-XX:InitiatingHeapOccupancyPercent 默认45%）会触发混合回收MixedGC。回收所有年轻代和部分老年代的对象以及大对象区。采用复制算法来完成。

G1在进行Young GC的过程中会去记录每次垃圾回收时每个Eden区和Survivor区的平均耗时，以作为下次回收时的参考依据。这样就可以根据配置的最大暂停时间计算出本次回收时最多能回收多少个Region区域了。

比如 -XX:MaxGCPauseMillis=n（默认200），每个Region回收耗时40ms，那么这次回收最多只能回收4个Region。

** 混合回收（Mixed GC）**

混合回收分为：初始标记、并发标记、最终标记、并发清理
G1对老年代的清理会选择存活度(存活的对象数/总对象数)最低的区域来进行回收，这样可以保证回收效率最高，这也是G1（Garbage first）名称的由来。

FULL GC

G1垃圾回收器的Full GC会在以下条件下触发

从年轻代分区拷贝存活对象时，无法找到可用的空闲Region(分区)
从老年代分区转移存活对象时，无法找到可用的空闲Region(分区)
分配巨型对象时在老年代无法找到足够的连续分区

Full GC会单线程执行标记-整理算法，此时会导致用户线程的暂停。所以尽量保证应该用的堆内存有一定多余的空间。

** 优缺点**

优点：
①对比较大的堆如超过6G的堆回收时，延迟可控
②不会产生内存碎片
③并发标记采用SATB算法，效率高
缺点：JDK8之前还不够成熟
适用场景：JDK8最新版本、JDK9之后建议默认使用

GC 的调优

GC调优指的是对垃圾回收（Garbage Collection）进行调优。GC调优的主要目标是避免由垃圾回收引起程序性能下降。

GC调优的核心分成三部分：

通用JVM参数的设置。
特定垃圾回收器的JVM参数的设置。
解决由频繁的FULL GC引起的程序性能问题。

GC调优没有唯一的标准答案，如何调优与硬件、程序本身、使用情况均有关系，重点学习调优的工具和方法。

gc 的评判标准

(1). 吞吐量
吞吐量分为业务吞吐量和垃圾回收吞吐量
业务吞吐量指的在一段时间内，程序需要完成的业务数量。比如企业中对于吞吐量的要求可能会是这样的：

支持用户每天生成10000笔订单
在晚上8点到10点，支持用户查询50000条商品信息

保证高吞吐量的常规手段有两条：

优化业务执行性能，减少单次业务的执行时间
优化垃圾回收吞吐量

垃圾回收吞吐量指的是 CPU 用于执行用户代码的时间与 CPU 总执行时间的比值，即吞吐量 = 执行用户代码时间 /（执行用户代码时间 + GC时间）。吞吐量数值越高，垃圾回收的效率就越高，允许更多的CPU时间去处理用户的业务，相应的业务吞吐量也就越高。

(2) 延迟
延迟指的是从用户发起一个请求到收到响应这其中经历的时间。
延迟 = GC延迟 + 业务执行时间，所以如果GC时间过长，会影响到用户的使用。

(3) 内存使用量
内存使用量指的是Java应用占用系统内存的最大值，一般通过JVM参数调整，在满足上述两个指标的前提下，这个值越小越好。

gc 问题确认

(1) 工善利器
jstat 工具：无法精确到GC产生的时间，只能用于判断GC是否存在问题

VisualVm插件；

Prometheus + Grafana 较为专业的指标和展示产品，是企业常用的监控组合产品

（2）日志诊断

**GC日志 **
通过GC日志，可以更好的看到垃圾回收细节上的数据，同时也可以根据每款垃圾回收器的不同特点更好地发现存在的问题。

使用方法（JDK 8及以下）：-XX:+PrintGCDetails -Xloggc:文件名
使用方法（JDK 9+）：-Xlog:gc*:file=文件名

注： -verbose:gc 是将GC日志输出到控制台上，而上面是将GC日志单独输出到一个文件

GC Viewer
GCViewer是一个将GC日志转换成可视化图表的小工具，github地址：https://github.com/chewiebug/GCViewer

使用方法：java -jar gcviewer的jar包日志文件.log

GCeasy
GCViewer是将GC日志可视化，而GCeasy是业界首款使用AI机器学习技术在线进行GC分析和诊断的工具。定位内存泄漏、GC延迟高的问题，提供JVM参数优化建议，支持在线的可视化工具图表展示。官方网站：Universal JVM GC analyzer - Java Garbage collection log analysis made easy (gceasy.io)

（3）常见的gc图形
** 正常情况 **
特点：呈现锯齿状，对象创建之后内存上升，一旦发生垃圾回收之后下降到底部，并且每次下降之后的内存大小接近，存留的对象较少。

** 缓存对象过多**

特点：呈现锯齿状，对象创建之后内存上升，一旦发生垃圾回收之后下降到底部，并且每次下降之后的内存大小接近，处于比较高的位置。

问题产生原因：程序中保存了大量的缓存对象，导致GC之后无法释放，可以使用MAT或者HeapHero等工具进行分析内存占用的原因。

** 内存泄漏**

特点：呈现锯齿状，每次垃圾回收之后下降到的内存位置越来越高，最后由于垃圾回收无法释放空间导致对象无法分配产生OutOfMemory的错误。

问题产生原因：程序中保存了大量的内存泄漏对象，导致GC之后无法释放，可以使用MAT或者HeapHero等工具进行分析是哪些对象产生了内存泄漏。

** 持续的FULL GC**

特点：在某个时间点产生多次Full GC，CPU使用率同时飙高，用户请求基本无法处理。一段时间之后恢复正常。

问题产生原因：在该时间范围请求量激增，程序开始生成更多对象，同时垃圾收集无法跟上对象创建速率，导致持续地在进行FULL GC。

元空间不足导致的FULL GC

特点：堆内存的大小并不是特别大，但是持续发生FULL GC。

问题产生原因：元空间大小不足，超过了Java虚拟机设置的阈值，导致持续FULL GC回收元空间的数据。

问题修复

解决GC问题的手段中，前三种是比较推荐的手段，第四种仅在前三种无法解决时选用：

1优化基础JVM参数

参数1 ： -Xmx 和 –Xms

-Xmx参数设置的是最大堆内存，但是由于程序是运行在服务器或者容器上，计算可用内存时，要将元空间、操作系统、其它软件占用的内存排除掉。

案例：服务器内存4G，操作系统+元空间最大值+其它软件占用1.5G，-Xmx可以设置为2g。

最合理的设置方式应该是根据最大并发量估算服务器的配置，然后再根据服务器配置计算最大堆内存的值。

-Xms用来设置初始堆大小，建议将-Xms设置的和-Xmx一样大，有以下几点好处：

运行时性能更好，堆的扩容是需要向操作系统申请内存的，这样会导致程序性能短期下降。
可用性问题，如果在扩容时其他程序正在使用大量内存，很容易因为操作系统内存不足分配失败。
启动速度更快，Oracle官方文档的原话：如果初始堆太小，Java 应用程序启动会变得很慢，因为 JVM 被迫频繁执行垃圾收集，直到堆增长到更合理的大小。为了获得最佳启动性能，请将初始堆大小设置为与最大堆大小相同。

**参数2 ： -XX:MaxMetaspaceSize 和 –XX:MetaspaceSize **

-XX:MaxMetaspaceSize=值参数指的是最大元空间大小，默认值比较大，如果出现元空间内存泄漏会让操作系统可用内存不可控，建议根据测试情况设置最大值，一般设置为256m。当元空间大小超过这个值时，会抛出OutOfMemoryError。
-XX:MetaspaceSize=值参数指的是到达这个值之后会触发FULL GC（指的不是初始元空间大小），后续什么时候再触发JVM会自行计算。如果设置为和MaxMetaspaceSize一样大，就不会FULL GC，但是对象也无法回收。

参数3 ： -Xss虚拟机栈大小

如果我们不指定栈的大小，JVM 将创建一个具有默认大小的栈。大小取决于操作系统和计算机的体系结构。比如Linux x86 64位： 1MB，如果不需要用到这么大的栈内存，完全可以将此值调小节省内存空间，合理值为256k – 1m之间。

使用：-Xss256k

不建议手动设置的参数

由于JVM底层设计极为复杂，一个参数的调整也许让某个接口得益，但同样有可能影响其他更多接口。

-Xmn 年轻代的大小，默认值为整个堆的1/3，可以根据峰值流量计算最大的年轻代大小，尽量让对象只存放在年轻代，不进入老年代。但是实际的场景中，接口的响应时间、创建对象的大小、程序内部还会有一些定时任务等不确定因素都会导致这个值的大小并不能仅凭计算得出，如果设置该值要进行大量的测试。G1垃圾回收器尽量不要设置该值，G1会动态调整年轻代的大小
‐XX:SurvivorRatio 伊甸园区和幸存者区的大小比例，默认值为8。
‐XX:MaxTenuringThreshold 最大晋升阈值，年龄大于此值之后，会进入老年代。另外JVM有动态年龄判断机制：当 survior 区域的存活对象的总大小占用了 survior 区域大小的50%（可以通过参数指定），那么此时将按照这些对象的存活年龄从小到大排序，然后依次累加，当累加到对象大小超过50%，则将大于等于当前对象年龄的存活对象全部挪到老年代。

‐XX:MaxTenuringThreshold 最大晋升阈值，年龄大于此值之后，会进入老年代。另外JVM有动态年龄判断机制：当 survior 区域的存活对象的总大小占用了 survior 区域大小的50%（可以通过参数指定），那么此时将按照这些对象的存活年龄从小到大排序，然后依次累加，当累加到对象大小超过50%，则将大于等于当前对象年龄的存活对象全部挪到老年代。

其他参数

-XX:+DisableExplicitGC 禁止在代码中使用System.gc()， System.gc()可能会引起FULL GC，在代码中尽量不要使用。使用DisableExplicitGC参数可以禁止使用System.gc()方法调用。
-XX:+HeapDumpOnOutOfMemoryError 发生OutOfMemoryError错误时，自动生成hprof内存快照文件。
-XX:HeapDumpPath= 指定hprof文件的输出路径。
打印GC日志
- JDK8及之前： -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:文件路径
- JDK9及之后： -Xlog:gc*:file=文件路径

2.垃圾回收器的选择

下面是一个思路的例子：

jvm 可配置的参数有哪些？

截止目前（ 2020年3月）， JVM可配置参数已经达到1000多个，其中GC和内存配置相
关的JVM参数就有600多个。
但在绝大部分业务场景下，常用的JVM配置参数也就10来个。

# JVM启动参数不换行
2 # 设置堆内存
3 ‐Xmx4g ‐Xms4g
4 # 指定GC算法
5 ‐XX:+UseG1GC ‐XX:MaxGCPauseMillis=50
6 # 指定GC并行线程数
7 ‐XX:ParallelGCThreads=4
8 # 打印GC日志
9 ‐XX:+PrintGCDetails ‐XX:+PrintGCDateStamps
10 # 指定GC日志文件
11 ‐Xloggc:gc.log
12 # 指定Meta区的最大值
13 ‐XX:MaxMetaspaceSize=2g
14 # 设置单个线程栈的大小
15 ‐Xss1m
16 # 指定堆内存溢出时自动进行Dump
17 ‐XX:+HeapDumpOnOutOfMemoryError
18 ‐XX:HeapDumpPath=/usr/local/

其他：

# 指定默认的连接超时时间
2 ‐Dsun.net.client.defaultConnectTimeout=2000
3 ‐Dsun.net.client.defaultReadTimeout=2000
4 # 指定时区
5 ‐Duser.timezone=GMT+08
6 # 设置默认的文件编码为UTF‐8
7 ‐Dfile.encoding=UTF‐8
8 # 指定随机数熵源(Entropy Source)
9 ‐Djava.security.egd=file:/dev/./urandom

一个例子：


JAVA_OPTS="$JAVA_OPTS -server -Xms3G -Xmx3G -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/aaa/dump -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/aaa/dump/heap_trace.txt -XX:NewSize=1G -XX:MaxNewSize=1G"