一、JVM与Java体系结构

1）JVM的位置

JVM是运行在操作系统之上的，它与硬件没有直接的交互

2）字节码

JVM和Java没有必然的关系，它只与特定的二进制文件格式—Class 文件格式所关联，Class 文件中包含了 Java 虚拟机指令集（或者称为字节码、 Bytecodes）和符号表，还有一些其他辅助信息。

也就是说，只要其他编程语言的编译结果满足Class文件格式，它就能被JVM识别并加载。

3）JVM整体结构

执行引擎包含三部分：解释器，即时编译，垃圾回收器

4）Java代码执行流程

对于Java源码文件(xxx.java)，先通过Java编译器进行词法分析、语法分析等生成二进制的字节码文件(xxx.class)，之后通过JVM加载字节码文件并执行。

二、类加载子系统

1）类加载子系统的作用

类加载器子系统负责从文件系统或者网络中加载Class文件。其只负责文件的加载，至于它是否可以运行，则由Execution Engine决定。

加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串变量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

class 字节码文件位于本地硬盘上，可以理解为设计师画在纸上的模板，该模板被类装载器Class Loader加载到JVM的方法区中，成为元数据模板；之后可以通过实例化（也就是new操作）得到多个一模一样的实例，而该实例也可以通过getClass回退得到元数据模板，元数据模板也可以通过getClassloader得到类加载器

2）类加载器分类

引导类加载器（Bootstrap ClassLoader）

• 虚拟机自带，由C/C++编写实现，嵌套在JVM内部
• 出于安全考虑，引导类加载器只加载包名为java、javax、sun等开头的类
• 并不继承自java.lang.ClassLoader，没有父加载器。

扩展类加载器（Extension ClassLoader）

• Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。
• 派生于ClassLoader类，父类加载器为引导类加载器
• 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库；如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。

系统类加载器（AppClassLoader）

• java语言编写，由sun.misc.LaunchersAppClassLoader实现
• 派生于ClassLoader类，父类加载器为扩展类加载器
• 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
• 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
• 通过classLoader.getSystemclassLoader（）方法可以获取到该类加载器

用户自定义类加载器

• 在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。
• 为何要自定义：隔离加载类、修改类加载的方式、扩展加载源、防止源码泄漏
• 实现步骤：
  • 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
  • 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass（）方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadclass（）方法，而是建议把自定义的类加载逻辑写在findclass（）方法中
  • 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findclass（）方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

根加载器

根加载器只能够加载 java /lib目录下的class

public class ClassLoaderTest1 {
    public static void main(String[] args) {
        System.out.println("*********启动类加载器************");
        // 获取BootstrapClassLoader 能够加载的API的路径
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL url : urls) {
            System.out.println(url.toExternalForm());
        }

        // 从上面路径中，随意选择一个类，来看看他的类加载器是什么：得到的是null，说明是  根加载器
        ClassLoader classLoader = Provider.class.getClassLoader();
    }
}

结果

*********启动类加载器************
file:/E:/Software/JDK1.8/Java/jre/lib/resources.jar
file:/E:/Software/JDK1.8/Java/jre/lib/rt.jar
file:/E:/Software/JDK1.8/Java/jre/lib/sunrsasign.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jsse.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jce.jar
file:/E:/Software/JDK1.8/Java/jre/lib/charsets.jar
file:/E:/Software/JDK1.8/Java/jre/lib/jfr.jar
file:/E:/Software/JDK1.8/Java/jre/classes
null

3）双亲委派机制

Java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式。

🌏 工作原理

如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式

🌏 沙箱安全机制

自定义string类，但是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的string类。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

🌏 双亲委派机制的优点

• 避免类的重复加载
• 保护程序安全，防止核心API被随意篡改
  • 自定义类：java.lang.String
  • 自定义类：java.lang.ShkStart（报错：阻止创建 java.lang开头的类）

三、运行时数据区

程序计数器

虚拟机栈

本地方法接口

本地方法栈

方法区

四、垃圾回收概述

1）相关面试题

蚂蚁金服

• 你知道哪几种垃圾回收器，各自的优缺点，重点讲一下cms和G1？
• JVM GC算法有哪些，目前的JDK版本采用什么回收算法？
• G1回收器讲下回收过程GC是什么？为什么要有GC？
• GC的两种判定方法？CMS收集器与G1收集器的特点

百度

• 说一下GC算法，分代回收说下
• 垃圾收集策略和算法

天猫

• JVM GC原理，JVM怎么回收内存
• CMS特点，垃圾回收算法有哪些？各自的优缺点，他们共同的缺点是什么？

滴滴

Java的垃圾回收器都有哪些，说下g1的应用场景，平时你是如何搭配使用垃圾回收器的

京东

• 你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms和G1，
• 包括原理，流程，优缺点。垃圾回收算法的实现原理

阿里

• 讲一讲垃圾回收算法。
• 什么情况下触发垃圾回收？
• 如何选择合适的垃圾收集算法？
• JVM有哪三种垃圾回收器？

字节跳动

• 常见的垃圾回收器算法有哪些，各有什么优劣？
• System.gc（）和Runtime.gc（）会做什么事情？
• Java GC机制？GC Roots有哪些？
• Java对象的回收方式，回收算法。
• CMS和G1了解么，CMS解决什么问题，说一下回收的过程。
• CMS回收停顿了几次，为什么要停顿两次?

2）概述

垃圾是指在运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾。

如果不及时对内存中的垃圾进行清理，那么，这些垃圾对象所占的内存空间会一直保留到应用程序的结束，被保留的空间无法被其它对象使用，甚至可能导致内存溢出。

在早期的C/C++时代，垃圾回收基本上是手工进行的。开发人员可以使用new关键字进行内存申请，并使用delete关键字进行内存释放

这种方式可以灵活控制内存释放的时间，但是会给开发人员带来频繁申请和释放内存的管理负担。倘若有一处内存区间由于程序员编码的问题忘记被回收，那么就会产生内存泄漏，垃圾对象永远无法被清除，随着系统运行时间的不断增长，垃圾对象所耗内存可能持续上升，直到出现内存溢出并造成应用程序崩溃

Java的垃圾回收GC主要关注于方法区和堆中的垃圾收集。其中，Java堆是垃圾收集器的工作重点。

从次数上讲：

• 频繁收集Young区
• 较少收集Old区
• 基本不收集Perm区（元空间）

五、垃圾回收相关算法

1）标记阶段

在堆中存放着几乎所有的Java对象实例，在GC执行垃圾回收之前，首先要区分出哪些是需要被清除的死亡对象。当一个对象已经不再被任何的存活对象继续引用时，其被宣判死亡。（老寻梦环游记了…）判断对象是否存活，一般有引用计数算法和可达性分析算法两种方式：

⚡ 引用计数算法（Reference Counting）

• 原理：为每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况。对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1；当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。
• 优点：实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性
• 缺点：它需要单独的字段存储计数器，这样的做法增加了存储空间的开销；每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销；引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在Java的垃圾回收器中没有使用这类算法。
• Python在使用引用计数算法，其在处理循环引用时，用两种方案：在合适的时机，手动解除引用关系；采用Python的弱引用库weakref

⚡ 可达性分析算法

• 可达性分析算法，也称为根搜索算法、追踪性垃圾收集。其有效解决了引用计数算法中的循环引用问题，防止内存泄漏
• 原理：以根对象集合（GC Root Set）为起始点，向下搜索被根对象集合直接或间接连接到的对象被标记为存活对象，无法建立连接的对象被标记为可回收对象。参考官场的裙带关系

• Java语言中，GC Roots是一组活跃的引用，其主要包含以下几类元素：
  • 虚拟机栈中引用的对象，比如：各个线程被调用的方法中使用到的参数、局部变量等。
  • 本地方法栈内JNI（通常说的本地方法）引用的对象
  • 方法区中类静态属性引用的对象，比如：Java类的引用类型静态变量；常量引用的对象，比如：字符串常量池（StringTable）里的引用
  • 所有被同步锁synchronized持有的对象
  • Java虚拟机内部的引用：基本数据类型对应的Class对象，一些常驻的异常对象（如：NullPointerException、OutofMemoryError），系统类加载器，反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
  • 除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。比如：分代收集和局部回收（PartialGC）。
    • 如果只针对Java堆中的某一块区域进行垃圾回收（比如：典型的只针对新生代），必须考虑到内存区域是虚拟机自己的实现细节，更不是孤立封闭的，这个区域的对象完全有可能被其他区域的对象所引用，这时候就需要一并将关联的区域对象也加入GC Roots集合中去考虑，才能保证可达性分析的准确性。
  • 由于Root采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个Root。
• 当使用可达性分析算法 来判断内存是否可回收时，分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。这点也是导致GC进行时必须“Stop The World”的一个重要原因。即使是号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。

2）对象的finalization机制

3）清除阶段

当成功区分出内存中存活对象和死亡对象后，GC接下来的任务是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存。目前在JVM中比较常见的几种垃圾收集算法：

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

• J.McCarthy 1960年提出，并用于Lisp语言
• 执行过程：当堆中的有效内存空间（available memory）被耗尽时，就会停止整个程序（stop the world），然后进行两项标记和清除工作：
  • 标记：Collector从引用根节点开始遍历，标记所有被引用的对象。是可达对象，而不是不可达对象！一般是在对象的Header中记录为可达对象。
  • 清除：Collector对堆内存从头到尾进行线性遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收（把需要清除的对象地址保存在空闲地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放并覆盖原有地址内容）。
• 缺点：标记时从根节点开始遍历，清除时对堆内存进行遍历，相当于两次O(N)，效率不高；在进行GC时，需要停止整个应用程序，用户体验较差；清理后的空闲内存并不连续，会产生内存碎片，需要维护一个空闲列表来分配这些内存。

⚡ 复制算法（Copying）

• M.L.Minsky 1963年提出，改进了标记清除算法的低效率问题

• 原理：将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收

• 优点：没有标记和清除过程，实现简单，运行高效；复制过去以后保证空间的连续性，不会出现“碎片”问题。
• 缺点：需要两倍内存空间；对于G1这种分拆成大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，内存占用、时间开销都较大
• 适用于垃圾对象很多，存活对象很少的场景；例如：Young区的Survivor 0区 和Survivor 1区

⚡ 标记-压缩算法（Mark-Compact）

• 复制算法适用于存活对象少、垃圾对象多的新生代，不适合有大量存活对象的老年代；标记-清除算法可以应用于老年代，但是会产生大量内存碎片
• 1970年前后，G.L.Steele等人提出标记压缩算法
• 执行过程：第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象；第二阶段将所有的存活对象压缩到内存一端，按顺序排放；之后，清理边界外所有空间。
• 标记-压缩算法相当于在标记-清除算法执行完成后，再进行一次内存碎片整理。两者的主要区别在于是否需要移动，移动时需要调整对象引用的地址，双刃剑。
• 优点：消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可；消除了复制算法当中，内存减半的高额代价。
• 缺点：从效率上来说，标记-整理算法要低于复制算法；移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址；移动过程中，需要全程暂停用户应用程序。即：STW

⚡ 三种算法的比较

	标记-清除算法	标记-整理算法	复制算法
速度	中等	最慢	最快
空间开销	少（但会堆积碎片）	少（不堆积碎片）	通常需要活对象的两倍大小（不堆积碎片）
移动对象	否	是	是

没有最好的，只有最合适的！具体问题、具体分析的算法应运而生。

⚡ 分代算法（Generational Collecting）

分代思想被现有的虚拟机广泛应用，几乎所有的垃圾回收器都是采用分代收集算法进行垃圾回收的。

• 年轻代（Young Gen）
  • 区域相对老年代较小，对象生命周期短、存活率低，回收频繁。
  • 这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。
• 老年代（Tenured Gen）
  • 区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。
  • 这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记-清除或者是标记-清除与标记-整理的混合实现。
    • Mark标记阶段的开销与存活对象的数量成正比。
    • Sweep清除阶段的开销与所管理区域的大小成正相关。
    • Compact压缩阶段的开销与存活对象的数据成正比。

以HotSpot中的CMS回收器为例，CMS是基于Mark-Sweep实现，对于对象的回收效率很高；对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器作为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。

⚡ 增量收集算法

上述现有的算法，在垃圾回收过程中，应用软件将处于一种Stop the World的状态。在Stop the World状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成；

如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集（Incremental Collecting）算法的诞生。

• 基本思想：让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。
• 增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作
• 优缺点：系统停顿时间大量减少，但由于线程切换和上下文转换的消耗，垃圾回收的总体成本上升，造成系统吞吐量的下降。

⚡ 分区算法

一般来说，在相同条件下，堆空间越大，一次GC时所需要的时间就越长，有关GC产生的停顿也越长。

为了更好地控制GC产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC所产生的停顿。

六、垃圾回收相关概念

1）System.gc()的理解

在默认情况下，通过System.gc()者Runtime.getRuntime().gc() 的调用，会显式触发Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。但System.gc()调用时，对垃圾收集器的调用不能确保立即生效。

JVM实现者可以通过System.gc() 调用来决定JVM的GC行为。而一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦。

2）内存溢出与泄漏

⚡ 内存溢出（Out of memory）

• 没有空闲内存，且垃圾回收器也无法提供更多内存

  • Java虚拟机的堆内存设置不够。
  • 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）

• 在抛出OOM之前，通常垃圾收集器都会被触发，尽其可能地清理出空间；但当分配一个超大对象，比如超过数组超过堆的最大值时，JVM可以判断出垃圾收集并不能解决这个问题，此时会直接抛出OOM，不再执行垃圾收集

⚡ 内存泄漏

• 某些对象不会被程序用到，但是也GC由无法回收，即内存泄漏，也称为存储泄漏
• 有时候对象的生命周期变的很长甚至导致OOM，也可以成为宽泛意义上的内存泄漏
• 内存泄漏时，程序不会立刻崩溃，但是内存可能会被逐渐蚕食，最终出现OutofMemory异常，导致程序崩溃。

• 引用计数算法的循环引用会引发内存泄漏问题，但Java的回收机制中并没有采用该算法！！
• 举个栗子：
  • 单例模式：单例的生命周期和应用程序一样长，所以在单例程序中，若持有对外部对象的引用，那么这个外部对象在不再使用后，无法被GC及时回收，会导致内存泄漏。
  • 一些提供close()方法的资源未关闭导致内存泄漏：数据库连接 dataSourse.getConnection()，网络连接socket和io连接必须及时手动close，否则不能被及时回收。

3）Stop the world

• GC事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STW。

• 可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿。为什么需要停顿所有 Java 执行线程？

  • 分析工作必须在一个能确保一致性的快照中进行
  • 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上，保护现场。如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证

• 被STW中断的应用程序线程会在完成GC之后恢复，频繁中断令用户体验差，需要减少STW的发生。

• STW事件和采用哪款GC无关，所有的GC都有这个事件。
• STW是JVM在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。
• system.gc会触发STW事件

4）垃圾回收的并行与并发

⚡ 并发（Concurrent）

• 多个事情，在同一时间段内同时发生
• 并发的多个任务之间是互相抢占资源的。

⚡ 并行（Parallel）

• 多个事情，在同一时间点上同时发生。
• 并行的多个任务之间不互相抢占资源。
• 只有在多CPU或者一个CPU多核的情况中，才会发生并行。否则，看似同时发生的事情，其实都是并发执行的。
  • 比如打篮球，虽然可能五六个人都在球场上打球，但同一时间点球只在一个人手上，因此可以看做是并发的，而不是并行的
• 决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU多个核也可以并行

并发示例图	并行示例图

⚡ 垃圾回收

• 串行：单线程地执行垃圾回收，比如内存不够需要清理垃圾时，先暂停程序，再启动JVM垃圾回收器进行垃圾回收，回收完之后启动用户程序线程

• 并行：多条垃圾回收线程并行工作，用户线程此时处于等待状态

• 并发：用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），垃圾回收线程在执行时不会停顿用户程序的运行。

  • 比如用户程序在继续运行，而垃圾收集程序线程运行于另一个CPU上；
  • 典型垃圾回收器：CMS、G1

  | 串行和并行示例 | 并发示例 |
  | :—————————————————————————————: | :—————————————————————————————: |
  | | |

5）安全点与安全区域

⚡ 安全点（Safepoint）

• 程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些程序可以安全暂停的位置被称为“安全点”。

• Safe Point的选择很重要，如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令执行时间都非常短暂，通常会根据“是否具有让程序长时间执行的特征”为标准。如：选择一些执行时间较长的指令作为Safepoint，如方法调用、循环跳转和异常跳转等。

• 如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢？

  • 抢先式中断：首先中断所有进程，如何还有线程不再安全点，就恢复线程，让进程跑到安全点。。已被所有的虚拟机弃用
  • 主动式中断：设置一个中断标志，各个线程运行到SafePoint的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。（有轮询的机制）

⚡ 安全区域（Safe Region）

• 安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？例如线程处于Sleep状态或Blocked 状态，这时候线程无法响应JVM的中断请求，“走”到安全点去中断挂起，JVM也不太可能等待线程被唤醒。

• 安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。

• 执行流程：

  • 当线程运行到Safe Region的代码时，首先标识已经进入了Safe Region，如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程；
  • 当线程即将离开Safe Region时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开Safe Region的信号为止。

6）引用

我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存中；如果内存空间在进行垃圾收集后还是很紧张，则可以抛弃这些对象。

强软弱虚这4种引用强度依次逐渐减弱。除强引用外，其他3种引用均可以在java.lang.ref包中找到。Reference四个子类中只有终结器引用是包内可见，其他3种引用类型均为public，可以在应用程序中直接使用。

偏门但又高频的面试题：四种引用的区别，具体使用场景又是什么

🌏 强引用（Strong Reference）

• 最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“object obj=new Object()”这种引用关系。
• 死不回收：无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。
• 强引用是造成Java内存泄漏的主要原因之一。
  • 通过obj=null来销毁强引用

🌏 软引用（Soft Reference）

• 内存不足即回收：只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。第一次回收是清理不可触及的对象。
• 软引用通常用来实现内存敏感的缓存。比如：高速缓存就有用到软引用。如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。比如Mybatis里面就有
  • MyBatis分为一级缓存和二级缓存，一级缓存默认开启，作用域为session，当session flush或者close时，该session中的所有Cache被清空；二级缓存须通过</cache>手动开启，作用域为Namespace，也就是说如果你用两个不同的sqlsession去执行相同查询条件的查询，第二次查询时不再发送SQL语句，而是直接从缓存中取出数据。

🌏 弱引用（Weak Reference）

• 发现即回收：在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。
• 由于垃圾回收器的线程通常优先级很低，因此，并不一定能很快地发现持有弱引用的对象。在这种情况下，弱引用对象可以存在较长的时间。
• 软引用、弱引用都非常适合来保存那些可有可无的缓存数据。如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。

🌏 虚引用（Phantom Reference）

• 一个对象是否有虚引用的存在，完全不会决定对象的生命周期。
• 对象回收跟踪：如果一个对象仅持有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收。但是，当这个对象被回收时，会产生一个系统通知。可以将一些资源释放操作放置在虚引用中执行和记录。
• 虚引用无法单独使用，无法通过get()方法取得对象。必须和引用队列一起使用：虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况。
• 案例：
  • 第一次尝试获取虚引用的值，发现无法获取，这是因为虚引用是无法直接获取对象的值，然后进行第一次GC，因为会调用finalize方法，将对象复活了，所以对象没有被回收
  • 但是调用第二次GC操作的时候，因为finalize方法只能执行一次，所以就触发了GC操作，将对象回收了，同时将会触发第二个操作就是将待回收的对象存入到引用队列中。

🌏 终结器引用

• 用于实现对象的finalize() 方法
• 无需手动编码，其内部配合引用队列使用
• 在GC时，终结器引用入队。由Finalizer线程通过终结器引用找到被引用对象调用它的finalize()方法，第二次GC时才回收被引用的对象

Java不同版本的新特性：

1.语法层面：Lambda表达式、switch、自动装箱和拆箱、enum等等

2.API层面：Stream API、新的日期时间、Optional、String、集合框架

3.底层优化：JVM优化、GC方面的变化、元空间、静态域、字符串常量池等等

七、垃圾回收器

1）GC分类

• 按垃圾回收线程数：串行垃圾回收器和并行垃圾回收器
• 按工作模式：独占式垃圾回收器（STW）和并发式垃圾回收器
• 按碎片处理方式：压缩式垃圾回收器（整理内存碎片，通过指针碰撞分配对象空间）和非压缩式垃圾回收器（不整理内存碎片，通过空闲列表分配对象空间）
• 按工作的内存空间：年轻代垃圾回收器和年轻代垃圾回收器

2）GC的性能指标

• 吞吐量：运行用户代码的时间占总运行时间的比例

  • 总运行时间s = 程序的运行时间a + 内存回收的时间b
  • 吞吐量throughput = a/s；
  • 吞吐量优先，意味着在单位时间内，STW的时间最短

• 暂停时间：是指一个时间段内应用程序线程暂停（STW），让GC线程执行的状态

  • GC期间100毫秒的暂停时间意味着在这100毫秒期间内没有应用程序线程是活动的
  • 暂停时间优先，意味着尽可能让单次STW的时间最短
  • 交互式应用程序，低暂停时间（低延迟）的用户体验更好。

  吞吐量和暂停时间相互矛盾，吞吐量大了，每次暂停时间较长，暂停时间短了，垃圾收集的频率增大，吞吐量也随之减小了。目前的标准是，在可控的暂停时间下，尽可能地提高吞吐量

• 内存占用：Java堆区所占的内存大小。

• 垃圾收集开销：垃圾收集所用时间与总运行时间的比例。

• 收集频率：相对于应用程序的执行，收集操作发生的频率。

• 快速：一个对象从诞生到被回收所经历的时间。

3）7种经典垃圾回收器

串行回收器：Serial、Serial old

并行回收器：ParNew、Parallel Scavenge、Parallel old

并发回收器：CMS、G1

新生代：Serial、ParNew、Parallel Scavenge

老年代：CMS、Serial Old、Parallel Old

全功能：G1

如何当前版本查看默认的垃圾回收器：

• -XX:+PrintCommandLineFlags：查看命令行相关参数（包含使用的垃圾收集器）
• 使用命令行指令：jinfo -flag 相关垃圾回收器参数（如UseG1GC） 进程ID

4）Serial串行回收器

Serial GC（年轻代）：复制算法、串行回收、”Stop-the-World”机制

Serial Old GC（老年代）：标记-压缩算法、串行回收和”Stop the World”机制

• Server模式下，与新生代的Parallel Scavenge配合使用，同时也作为老年代CMS收集器的后备垃圾收集方案

• 单线程：它只会使用一个CPU或一条收集线程去完成垃圾收集工作，省去了切换线程的开销；此外，在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束（STW）

对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。运行在Client模式下的虚拟机是个不错的选择。

在HotSpot虚拟机中，可通过-XX:+UseSerialGC指定年轻代和老年代都使用串行收集器

• 新生代Serial GC，老年代Serial Old GC

现在的设备基本已经没有单核的了，这个垃圾回收器也在弃用的边缘了…

JavaWeb中交互较多，但串行时会暂停程序，用户体验很差，因此JavaWeb程序中也是不会采用串行垃圾回收器的…

5）ParNew —— 并行回收

Parallel New，并行回收垃圾，只能处理新生代；和Serial GC一样，也都是复制算法、Stop the World机制，区别仅为是否并行。

• ParaNew是很多JVM运行在Server模式下新生代 的默认垃圾回收器

• 新生代：回收次数频繁，使用并行方式高效
• 老年代：回收次数少，使用串行方式节省资源（避免切换线程）

适用范围：

• 多GPU下，ParaNew比Serial高效
• 单CPU下，还是Serial好一些，避免了多线程交互中的一些额外开销

参数配置：

• 可通过-XX:+UseParNewGC指定使用ParNew收集器执行内存回收任务。它表示年轻代使用并行收集器，不影响老年代
• 可通过-XX:ParallelGCThreads限制线程数量，默认开启和CPU相同线程数

6）Parallel Scavenge —— 吞吐量优先

并行回收垃圾、复制算法、Stop the world机制

区别ParaNew：

• Parallel Scavenge收集器的目标：达到一个可控制的吞吐量
• 自适应调节策略

高吞吐量可以高效率利用CPU时间，尽快完成程序的运算任务，主要适用于后台运算而不需要太多交互任务。因此，常见在服务器环境中使用。例如，执行批量处理、订单处理、工资支付、科学计算的应用程序。

• 新生代：复制算法、STW，Parallel
• 老年代：标记-压缩算法、STW，Parallel Old

JDK8中，默认的垃圾回收器为Parallel（也会自动激活Parallel Old）

JKD9中，默认为G1.

参数配置：

• 可通过-XX:+UseParallelGC 指定年轻代使用Parallel GC，但也会激活Parallel Old GC
• 可通过-XX:+UseParallelOldGC指定老年代使用并行回收收集器，但也会激活Parallel GC
• 可通过-XX:ParallelGCThreads：设置年轻代并行收集器的『线程数』
  • 默认情况下，当CPU数量小于8个，ParallelGCThreads的值等于CPU数量
  • 当CPU数量大于8个，ParallelGCThreads的值等于3+[5*CPU_Count]/8]
• 可通过-XX:MaxGCPauseMillis：设置垃圾收集器『最大停顿时间』（即STW的时间）单位：毫秒
• 可通过-XX:GCTimeRatio：垃圾收集时间占总时间的『比例』，用于衡量吞吐量的大小
• 可通过-XX:+UseAdaptiveSizePolicy：设置Parallel Scavenge收集器具有『自适应调节策略』
  • 在这种模式下，年轻代的大小、Eden和Survivor的比例、晋升老年代的对象年龄等参数会被自动调整，来达到在堆大小、吞吐量和停顿时间之间的平衡点。
  • 在手动调优比较困难的场合，可以直接使用这种自适应方式，仅指定虚拟机的最大堆、目标的吞吐量（GCTimeRatio）和停顿时间（MaxGCPauseMillis），让虚拟机自己完成调优工作

7）CMS —— 低延迟

⚡ 概述

Concurrent-Mark-Sweep，第一次实现了让垃圾收集线程和用户线程同时工作，HotSpot虚拟机中第一款真正意义上的并发收集器。

匹配的清除器有：ParNew和Serial GC，无法和Parallel Scavenge匹配使用；

标记清除算法

⚡ 工作原理

• 初始标记（Initial-Mark）阶段：STW。程序中所有的工作线程都将会因为“Stop-the-World”机制而出现短暂的暂停，这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小，所以这里的速度非常快。
• 并发标记（Concurrent-Mark）阶段：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
• 重新标记（Remark）阶段：STW。由于在并发标记阶段中，程序的工作线程会和垃圾收集线程同时运行或者交叉运行，因此为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，并且也会导致“Stop-the-World”的发生，但也远比并发标记阶段的时间短
• 并发清除（Concurrent-Sweep）阶段：此阶段清理删除掉标记阶段判断的已经死亡的对象，释放内存空间。由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的

• 由于在垃圾收集阶段用户线程没有中断，所以在CMS回收过程中，还应该确保 应用程序用户线程 有足够的内存可用 —> 堆内存使用率达到某一阈值时，便开始进行垃圾回收
• CMS运行期间预留的内存无法满足程序需求：出现“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial old收集器来重新进行老年代的垃圾收集，这样停顿时间更长
• 由于清除阶段是并发进行的，用compact整理内存，需要移动对象，这时是需要STW的，这就违背了并发的规则。因此，无法采用并发整理算法

⚡ 优缺点

• 并发、低延迟：CMS中最耗时的并发标记、并发清除阶段都不需要暂停工作，所以整体的回收是低停顿的
• 产生内存碎片：CMS采用标记-清除算法，不可避免地将会产生一些内存碎片；此时，无法使用指针碰撞（Bump the pointer）来分配对象，只能再维护一个空闲列表（free list）来分配内存。此外，无法分配大对象，只能提前触发Full GC。
• 对CPU资源敏感：并发阶段占用了一部分线程而导致应用程序变慢，总吞吐量降低
• 无法处理浮动垃圾：在CMS的并发标记和并发清理阶段，用户线程和垃圾收集线程是同时运行的，而程序的运行自然伴随着垃圾对象的产生，但这一部分垃圾已经无法再本次CMS收集中处理掉了，只能留待下一次垃圾收集时才可以处理掉

⚡ 参数设置

• -XX:+UseConcMarkSweepGC：手动指定使用CMS收集器执行内存回收任务。
  • 开启该参数后会自动将-XX:+UseParNewGC打开。即：ParNew（Young区）+CMS（Old区）+Serial Old（Old区备选方案）的组合。
• -XX:CMSInitiatingOccupanyFraction：设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收。
  • JDK5及以前版本的默认值为68，即当老年代的空间使用率达到68%时，会执行一次CMS回收。JDK6及以上版本默认值为92%
  • 如果内存增长缓慢，则可以设置一个稍大的值，大的阀值可以有效降低CMS的触发频率，减少老年代回收的次数可以较为明显地改善应用程序性能；反之，如果应用程序内存使用率增长很快，则应该降低这个阈值，以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低Full GC的执行次数。
• -XX:+UseCMSCompactAtFullCollection：用于指定在执行完Full GC后对内存空间进行压缩整理，以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行，所带来的问题就是停顿时间变得更长了。
• -XX:CMSFullGCsBeforeCompaction：设置执行多少次Full GC后对内存空间进行压缩整理
• -XX:ParallelCMSThreads：设置CMS的线程数

如何选择垃圾回收器？

（1）最小化地使用内存和并行开销：Serial GC

（2）最大化应用程序的吞吐量：Parallel Scavenge GC

（3）最小化GC的中断或停顿时间：CMS GC

JDK9之后，CMS被废弃deprecated

JDK14之后，直接删除了CMS

8）G1 —— 区域化分代式

Garbage-First，复制算法、并行并发兼具、面向服务器，在延迟可控的情况下获得尽可能高的吞吐量

⚡ 概述

• G1是一个并行回收器，它把Java堆内存分割为很多不相关的区域（Region）（物理上不连续的）。使用不同的Region来表示Eden、幸存者0区，幸存者1区，老年代等。

• G1有计划地避免在整个Java堆中进行全区域的垃圾收集，其跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。

• 由于该回收器的侧重点在于回收垃圾最大量的区间（Region），所以我们将该回收器称为：垃圾优先（Garbage First）

• G1是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器，以极高概率满足GC停顿时间的同时，还兼具高吞吐量的性能特征。

• JDK9之后的默认垃圾回收器，且JDK9之后废弃了CMS。在JDK8中，可通过-XX:+UseG1GC启用

⚡ 优势

• 支持并行与并发
  • 并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时用户线程STW
  • 并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况
• 分代收集
  • 区分年轻代和老年代，年轻代依然有Eden区和Survivor区；但从堆的结构上看，它不要求整个Eden区、年轻代或者老年代都是物理连续的，也不再坚持固定大小和固定数量。
  • 堆空间物理上被分为了若干个区域Region，但这些区域中包含了逻辑上的年轻代和老年代

• 可预测的停顿时间模型（软实时）
  • 可以让使用者明确设定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
  • G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能得到较好的控制。

⚡ 缺点

• 用户程序运行过程中，G1无论是为了垃圾收集产生的内存占用（Footprint）还是程序运行时的额外执行负载（overload）都要比CMS要高。
• 从经验上来说，在小内存应用上CMS的表现大概率会优于G1，而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。

⚡ 参数配置

• -XX:+UseG1GC：手动指定使用G1垃圾收集器执行内存回收任务
• -XX:G1HeapRegionSize：设置每个Region的大小
  • 值是2的幂，范围是1MB到32MB之间，目标是根据最小的Java堆大小划分出约2048个区域。
  • 默认是堆内存的1/2000
• -XX:MaxGCPauseMillis：设置期望达到的最大GC停顿时间指标，默认值：200ms
• -XX:+ParallelGCThread：设置并行垃圾回收线程数。最多设置为8
• -XX:ConcGCThreads：设置并发标记的线程数。一般将n设置为并行垃圾回收线程数的1/4左右
• -XX:InitiatingHeapOccupancyPercent：设置触发并发GC周期的Java堆占用率阈值
  • 超过此值，触发GC。默认值为45

⚡ G1的适用场景

• 面向服务端应用，针对具有大内存、多处理器的机器。（在普通大小的堆里，表现并没有那么惊喜）
• 要低GC延迟，并具有大堆的应用程序提供解决方案
  • 比如：在堆大小约6GB或更大时，可预测的暂停时间可以低于0.5秒；（G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次GC停顿时间不会过长）
• 以下场景，采用G1替换掉CMS收集器，可以收获更好的效果：
  • 超过50%的Java堆被活动数据占用
  • 对象分配频率或年代提升频率变化很大
  • GC停顿时间过长（长于0.5至1秒）

⚡ 分区：化整为零

• 使用G1收集器时，它将整个Java堆划分成约2048个大小相同的独立Region块，每个Region块大小根据堆空间的实际大小而定，整体被控制在1MB到32MB之间，且为2的N次幂，即1MB，2MB，4MB，8MB，16MB，32MB。
• 可以通过-XX:G1HeapRegionSize设定。所有的Region大小相同，且在JVM生命周期内不会被改变。
• 虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region的集合。通过Region的动态分配方式实现逻辑上的连续。
• G1垃圾收集器还增加了一种新的内存区域，叫做Humongous内存区域，如图中的H块。主要用于存储大对象，如果超过0.5个Region，就放到H。
  • 对于堆中的大对象，默认直接会被分配到老年代，但是如果它是一个短期存在的大对象就会对垃圾收集器造成负面影响。

• 每个Region都是通过指针碰撞来分配空间；每个Region都有TLAB，提高对象分配的效率

⚡ G1垃圾回收过程

① 年轻代GC

JVM启动时，G1先准备好Eden区，程序在运行过程中不断创建对象到Eden区，当Eden空间耗尽时，G1会启动一次年轻代垃圾回收过程。

年轻代垃圾回收时，首先停止应用程序的执行（stop-The-Wor1d），然后G1创建回收集（Collection Set，需要被回收的内存分段的集合，年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段）。

• 扫描根：根是指static变量指向的对象，正在执行的方法调用链条上的局部变量等。根引用连同RSet记录的外部引用作为扫描存活对象的入口。
• 更新RSet：处理dirty card queue中的card，更新RSet。此阶段完成后，RSet可以准确的反映老年代对所在的内存分段中对象的引用。
• 处理RSet：识别被老年代对象指向的Eden中的对象，这些被指向的Eden中的对象被认为是存活的对象
• 复制对象：此阶段，对象树被遍历，Eden区内存段中存活的对象会被复制到Survivor区中空的内存分段，Survivor区内存段中存活的对象如果年龄未达阈值，年龄会加1，达到阀值会被会被复制到o1d区中空的内存分段。如果Survivor空间不够，Eden空间的部分数据会直接晋升到老年代空间。
• 处理引用：处理Soft，Weak，Phantom，Final，JNI Weak 等引用。最终Eden空间的数据为空，GC停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少碎片。

② 老年代并发标记过程

• 初始标记阶段：标记从根节点直接可达的对象。这个阶段是sTw的，并且会触发一次年轻代GC。
• 根区域扫描（Root Region Scanning）：G1 Gc扫描survivor区直接可达的老年代区域对象，并标记被引用的对象。这一过程必须在youngGC之前完成。
• 并发标记（Concurrent Marking）：在整个堆中进行并发标记（和应用程序并发执行），此过程可能被youngGC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。同时，并发标记过程中，会计算每个区域的对象活性（区域中存活对象的比例）。
• 再次标记（Remark）：由于应用程序持续进行，需要修正上一次的标记结果。是STW的。G1中采用了比CMS更快的初始快照算法：snapshot-at-the-beginning（SATB）。
• 独占清理（cleanup，STW）：计算各个区域的存活对象和GC回收比例，并进行排序，识别可以混合回收的区域。为下阶段做铺垫。是sTw的。这个阶段并不会实际上去做垃圾的收集
• 并发清理阶段：识别并清理完全空闲的区域。

③ 混合回收

当越来越多的对象晋升到老年代o1d region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即Mixed GC，该算法并不是一个old GC，除了回收整个Young Region，还会回收一部分的old Region。这里需要注意：是一部分老年代，而不是全部老年代。可以选择哪些o1d Region进行收集，从而可以对垃圾回收的耗时时间进行控制。也要注意的是Mixed GC并不是Full GC。

• 并发标记结束以后，老年代中百分百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算了出来。

• 混合回收的回收集（Collection Set）包括八分之一的老年代内存分段，Eden区内存分段，Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是回收集多了老年代的内存分段。具体过程请参考上面的年轻代回收过程。

• 由于老年代中的内存分段默认分8次回收，G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的，越会被先回收。并且有一个阈值会决定内存分段是否被回收，XX:G1MixedGCLiveThresholdPercent，默认为65%，意思是垃圾占内存分段比例要达到65%才会被回收。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间。

• 混合回收并不一定要进行8次。有一个阈值-XX:G1HeapWastePercent，默认值为1e%，意思是允许整个堆内存中有10%的空间被浪费，意味着如果发现可以回收的垃圾占堆内存的比例低于1e%，则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少。

④ Full GC

G1的初衷就是要避免Fu11GC的出现。但是如果上述方式不能正常工作，G1会停止应用程序的执行（stop-The-world），使用单线程的内存回收算法进行垃圾回收，性能会非常差，应用程序停顿时间会很长。

要避免Fu11GC的发生，一旦发生需要进行调整。什么时候会发生Ful1GC呢？比如堆内存太小，当G1在复制存活对象的时候没有空的内存分段可用，则会回退到ful1gc，这种情况可以通过增大内存解决。 导致61Fu11GC的原因可能有两个：

• EVacuation的时候没有足够的to-space来存放晋升的对象；
• 并发处理过程完成之前空间耗尽。

⑤ 可优化的点

• 年轻代大小：避免使用-Xmn或-XX:NewRatio等相关选项显式设置年轻代大小
• 暂停时间目标暂停时间目标不要太过严苛：G1的吞吐量目标是90%的应用程序时间和10%的垃圾回收时间，目标太过严苛表示你愿意承受更多的垃圾回收开销，而这些会直接影响到吞吐量。

9）垃圾回收器的总结

GC发展阶段：Seria l=> Parallel（并行）=> CMS（并发）=> G1 => ZGC

同厂商、不同版本的虚拟机实现差距比较大。HotSpot虚拟机在JDK7/8后所有收集器及组合如下图

🔎 新生代垃圾回收器和老年代垃圾回收器都有哪些？有什么区别？

🔎 怎样选择垃圾回收器：

• 优先调整堆的大小让JVM自适应完成。
• 如果内存小于100M，使用串行收集器
• 如果是单核、单机程序，并且没有停顿时间的要求，串行收集器
• 如果是多CPU、需要高吞吐量、允许停顿时间超过1秒，选择并行或者JVM自己选择
• 如果是多CPU、追求低停顿时间，需快速响应（比如延迟不能超过1秒，如互联网应用），使用并发收集器
• 官方推荐G1，性能高。现在互联网的项目，基本都是使用G1。

最后需要明确一个观点：

• 没有最好的收集器，更没有万能的收集
• 调优永远是针对特定场景、特定需求，不存在一劳永逸的收集器

🔎 垃圾收集的算法有哪些？如何判断一个对象是否可以回收？垃圾收集器工作的基本流程；垃圾回收器各种常用参数