JVM面试题

1、Java虚拟机中，数据类型可以分为哪几类？

Java虚拟机是通过某些数据类型来执行计算的，数据类型可以分为两种：基本类型和引用类型，基本类型的变量持有原始值，而引用类型的变量持有引用值。
Java语言中的所有基本类型同样也都是Java虚拟机中的基本类型。但是boolean有点特别，虽然Java虚拟机也把boolean看做基本类型，但是指令集对boolean只有很有限的支持，当编译器把Java源代码编译为字节码时，它会用int或者byte来表示boolean。在Java虚拟机中，false是由整数零来表示的，所有非零整数都表示true，涉及boolean值的操作则会使用int。另外，boolean数组是当做byte数组来访问的。
Java虚拟机还有一个只在内部使用的基本类型：returnAddress，Java程序员不能使用这个类型，这个基本类型被用来实现Java程序中的finally子句。该类型是jsr, ret以及jsr_w指令需要使用到的，它的值是JVM指令的操作码的指针。returnAddress类型不是简单意义上的数值，不属于任何一种基本类型，并且它的值是不能被运行中的程序所修改的。
Java虚拟机的引用类型被统称为“引用（reference）”，有三种引用类型：类类型、接口类型、以及数组类型，它们的值都是对动态创建对象的引用。类类型的值是对类实例的引用；数组类型的值是对数组对象的引用，在Java虚拟机中，数组是个真正的对象；而接口类型的值，则是对实现了该接口的某个类实例的引用。还有一种特殊的引用值是null，它表示该引用变量没有引用任何对象。

2、为什么不把基本类型放堆中呢？

基本类型（如int、float、boolean等）是值类型，它们的值存储在栈中，而不是堆中。在Java中，栈和堆是两种不同的内存分配方式，它们各自有不同的特点和适用场景。

栈是一种线性数据结构，它具有快速的分配和释放内存的特点。栈中存储的数据是按照后进先出（LIFO）的顺序访问的，每个栈帧都包含了局部变量、方法参数和返回值等信息。由于栈的内存分配方式是顺序的，因此栈中的数据访问速度非常快，适用于存储局部变量和方法调用过程中的临时数据。

堆是一种动态数据结构，它的内存分配方式是不规则的，由垃圾回收器负责管理。堆中存储的数据是按照任意顺序访问的，每个对象都有一个唯一的地址，可以通过引用来访问。由于堆的内存分配方式是不规则的，因此堆中的数据访问速度相对较慢，但是可以存储任意大小的数据，适用于存储动态生成的对象和数据结构。

将基本类型存储在堆中，会增加内存分配和访问的开销，并且会使程序的性能降低。因此，为了提高程序的性能和效率，Java将基本类型存储在栈中，而将对象和数据结构存储在堆中。

3、JVM 由哪些部分组成？

JVM 的结构基本上由 4 部分组成：

类加载器，在 JVM 启动时或者类运行时将需要的 class 加载到 JVM 中
执行引擎，执行引擎的任务是负责执行 class 文件中包含的字节码指令，相当于实际机器上的 CPU
内存区，将内存划分成若干个区以模拟实际机器上的存储、记录和调度功能模块，如实际机器上的各种功能的寄存器或者 PC 指针的记录器等
本地方法调用，调用 C 或 C++ 实现的本地方法的代码返回结果

4、类加载器是有了解吗？

顾名思义，类加载器（class loader）用来加载 Java 类到 Java 虚拟机中。一般来说，Java 虚拟机使用 Java 类的方式如下：Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成 Java 字节代码（.class 文件）。

类加载器负责读取 Java 字节代码，并转换成 java.lang.Class类的一个实例。每个这样的实例用来表示一个 Java 类。通过此实例的 newInstance()方法就可以创建出该类的一个对象。实际的情况可能更加复杂，比如 Java 字节代码可能是通过工具动态生成的，也可能是通过网络下载的。

5、Java 虚拟机是如何判定两个 Java 类是相同的？

Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。比如一个 Java 类 com.example.Sample，编译之后生成了字节代码文件 Sample.class。两个不同的类加载器 ClassLoaderA和 ClassLoaderB分别读取了这个 Sample.class文件，并定义出两个 java.lang.Class类的实例来表示这个类。这两个实例是不相同的。对于 Java 虚拟机来说，它们是不同的类。试图对这两个类的对象进行相互赋值，会抛出运行时异常 ClassCastException。

6、Java类加载过程（生命周期）

加载、Loading(装载)阶段

加载是类加载的第一个过程，在这个阶段，将完成一下三件事情：

通过一个类的全限定名获取该类的二进制流
将该二进制流中的静态存储结构转化为方法去运行时数据结构。
在内存中生成该类的 Class 对象，作为该类的数据访问入口

验证

验证的目的是为了确保 Class 文件的字节流中的信息不回危害到虚拟机.在该阶段主要完成以下四钟验证

文件格式验证：验证字节流是否符合 Class 文件的规范，如主次版本号是否在当前虚拟机范围内，常量池中的常量是否有不被支持的类型
元数据验证:对字节码描述的信息进行语义分析，如这个类是否有父类，是否集成了不被继承的类等。
字节码验证：是整个验证过程中最复杂的一个阶段，通过验证数据流和控制流的分析，确定程序语义是否正确，主要针对方法体的验证。如：方法中的类型转换是否正确，跳转指令是否正确等
符号引用验证：这个动作在后面的解析过程中发生，主要是为了确保解析动作能正确执行

准备
简言之，为类的静态变量分配内存，并将其初始化为默认值。
在这个阶段，虚拟机就会为这个类分配相应的内存空间，并设置默认初始值。Java虚拟机为各类型变量默认的初始值如表所示。

java

public static int value=123;//在准备阶段 value 初始值为 0 。在初始化阶段才会变为 123 。

解析

该阶段主要完成符号引用到直接引用的转换动作。解析动作并不一定在初始化动作完成之前，也有可能在初始化之后。

初始化

初始化阶段，简言之，为类的静态变量赋予正确的初始值。(显式初始化)

具体描述

类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码。（即： 到了初始化阶段，才真正开始执行类中定义的 Java 程序代码。）

初始化阶段的重要工作是执行类的初始化方法:<clinit>()方法。

该方法仅能由Java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是由字节码指令所组成。
它是由类静态成员的赋值语句以及static语句块合并产生的。

<clinit>():只有在给类中的static的变量显示赋值或在静态代码中赋值了。才会生成此方法。
<init>():一定会出现在Class的method表中。

使用
任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类型成功经历过这3个步骤之后，便“万事俱备，只欠东风”，就等着开发者使用了。
开发人员可以在程序中访问和调用它的静态类成员信息（比如：静态字段、静态方法），或者使用new关键字为其创建对象实例。
卸载

在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。

一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。

7、Class的forName("Java.lang.String")和Class的getClassLoader()的loadClass("Java.lang.String")有什么区别？

使用 loadClass() 方法获得的 Class 对象只完成了类加载过程中的第一步：加载，后续的操作均未进行。
使用 Class.forName() 方法获得 Class 对象是已经执行完初始化的了

Class的forName("Java.lang.String")和Class的getClassLoader().loadClass("Java.lang.String")都是用于获取Java.lang.String类的Class对象的方法，但是它们有一些区别。

Class.forName("Java.lang.String")方法会触发类的静态初始化，而ClassLoader.loadClass("Java.lang.String")方法不会触发类的静态初始化。静态初始化是指在类加载时执行的static块，如果一个类没有被加载过，则在调用Class.forName("Java.lang.String")方法时会进行类的加载和静态初始化，如果一个类已经被加载过，则只进行静态初始化；而ClassLoader.loadClass("Java.lang.String")方法只进行类的加载，不进行静态初始化，所以在调用该方法后需要手动调用类的静态方法或者使用类的实例触发静态初始化。
Class.forName("Java.lang.String")方法默认使用当前线程的ClassLoader进行类的加载，而ClassLoader.loadClass("Java.lang.String")方法需要显式指定ClassLoader进行类的加载。如果需要使用自定义的ClassLoader进行类的加载，则可以使用ClassLoader.loadClass("Java.lang.String")方法。
Class.forName("Java.lang.String")方法可以加载并返回指定类的Class对象，如果指定的类不存在，则会抛出ClassNotFoundException异常。而ClassLoader.loadClass("Java.lang.String")方法只进行类的加载，返回的是一个Class对象的引用，需要手动进行类型转换。

综上所述，Class.forName("Java.lang.String")方法触发类的静态初始化，使用当前线程的ClassLoader进行类的加载，可以加载并返回指定类的Class对象；而ClassLoader.loadClass("Java.lang.String")方法只进行类的加载，需要显式指定ClassLoader进行类的加载，不会触发类的静态初始化，返回的是一个Class对象的引用，需要手动进行类型转换。

8、双亲委派机制

规定了类加载的顺序是：引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)接口中体现。该接口的逻辑如下：

(1)先在当前加载器的缓存中查找有无目标类，如果有，直接返回。

(2)判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name, false)接口进行加载。

(3)反之，如果当前加载器的父类加载器为空，则调用findBootstrapClassOrNull(name)接口，让引导类加载器进行加载。

(4)如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类。

双亲委派的模型就隐藏在这第2和第3步中。

9、双亲委派机制的优势与劣势

1.双亲委派机制优势

避免类的重复加载，确保一个类的全局唯一性

Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关系可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。

保护程序安全，防止核心API被随意篡改

2.双亲委托模式的弊端

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

3.结论：

由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。

比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

10、破坏双亲委派机制

1、破坏双亲委派机制1

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。

在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。

第一次破坏双亲委派机制：

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远古”时代。

由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

2、破坏双亲委派机制2

第二次破坏双亲委派机制：线程上下文类加载器

双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？

这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？（SPI:在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI）

为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器

有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。

默认上下文加载器就是应用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用类加载器中的类。

3、破坏双亲委派机制3

第三次破坏双亲委派机制：

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如：**代码热替换（Hot Swap）、模块热部署（Hot Deployment）**等

IBM公司主导的JSR-291（即OSGi R4.2）实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。

当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

1）*将以java.开头的类，委派给父类加载器加载。

2）否则，将委派列表名单内的类，委派给父类加载器加载。

3）否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。

4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。

5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。

6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。

7）否则，类查找失败。

说明：只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的

11、什么是tomcat类加载机制？

Tomcat8 和 Tomcat6比较大的区别是：

Tomcat8可以通过配置<Loader delegate="true"/>表示遵循双亲委派机制。

Tomcat 如何实现自己独特的类加载机制？

所以，Tomcat 是怎么实现的呢？牛逼的Tomcat团队已经设计好了。我们看看他们的设计图：

当应用需要到某个类时，则会按照下面的顺序进行类加载：

1 使用bootstrap引导类加载器加载

2 使用system系统类加载器加载

3 使用应用类加载器在WEB-INF/classes中加载

4 使用应用类加载器在WEB-INF/lib中加载

5 使用common类加载器在CATALINA_HOME/lib中加载

好了，至此，我们已经知道了tomcat为什么要这么设计，以及是如何设计的，那么，tomcat 违背了java 推荐的双亲委派模型了吗？答案是：违背了。我们前面说过：双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。

很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

1、既然 Tomcat 不遵循双亲委派机制，那么如果我自己定义一个恶意的HashMap，会不会有风险呢？(阿里面试问题)
答：显然不会有风险，如果有，Tomcat都运行这么多年了，那能不改进吗？
tomcat不遵循双亲委派机制，只是自定义的classLoader顺序不同，但顶层还是相同的，还是要去顶层请求classloader。
2、我们思考一下：Tomcat是个web容器，那么它要解决什么问题？
一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机，这是扯淡的。
web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？所以，web容器需要支持 jsp 修改后不用重启。
3、Tomcat 如果使用默认的类加载机制行不行？
答案是不行的。为什么？我们看:
第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的累加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。
第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。
第三个问题和第一个问题一样。
我们再看第四个问题，我们想我们要怎么实现jsp文件的热替换，jsp 文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。
4、如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类，该怎么办？
看了前面的关于破坏双亲委派模型的内容，我们心里有数了，我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作。
5、为什么java文件放在Eclipse/IDEA中的src文件夹下会优先jar包中的class?
tomcat类加载机制的理解，就不难明白。因为Eclipse/IDEA中的src文件夹中的文件java以及webContent中的JSP都会在tomcat启动时，被编译成class文件放在 WEB-INF/class 中。
而Eclipse/IDEA外部引用的jar包，则相当于放在 WEB-INF/lib 中。
因此肯定是 java文件或者JSP文件编译出的class优先加载。

12、JVM 内存结构

执行 javac 命令编译源代码为字节码
执行 java 命令
1. 创建 JVM，调用类加载子系统加载 class，将类的信息存入方法区
2. 创建 main 线程，使用的内存区域是 JVM 虚拟机栈，开始执行 main 方法代码
3. 如果遇到了未见过的类，会继续触发类加载过程，同样会存入方法区
4. 需要创建对象，会使用堆内存来存储对象
5. 不再使用的对象，会由垃圾回收器在内存不足时回收其内存
6. 调用方法时，方法内的局部变量、方法参数所使用的是 JVM 虚拟机栈中的栈帧内存
7. 调用方法时，先要到方法区获得到该方法的字节码指令，由解释器将字节码指令解释为机器码执行
8. 调用方法时，会将要执行的指令行号读到程序计数器，这样当发生了线程切换，恢复时就可以从中断的位置继续
9. 对于非 java 实现的方法调用，使用内存称为本地方法栈（见说明）
10. 对于热点方法调用，或者频繁的循环代码，由 JIT 即时编译器将这些代码编译成机器码缓存，提高执行性能

说明

加粗字体代表了 JVM 虚拟机组件
对于 Oracle 的 Hotspot 虚拟机实现，不区分虚拟机栈和本地方法栈

会发生内存溢出的区域

不会出现内存溢出的区域 – 程序计数器
出现 OutOfMemoryError 的情况
- 堆内存耗尽 – 对象越来越多，又一直在使用，不能被垃圾回收
- 方法区内存耗尽 – 加载的类越来越多，很多框架都会在运行期间动态产生新的类
- 虚拟机栈累积 – 每个线程最多会占用 1 M 内存，线程个数越来越多，而又长时间运行不销毁时
出现 StackOverflowError 的区域
- JVM 虚拟机栈，原因有方法递归调用未正确结束、反序列化 json 时循环引用

方法区、永久代、元空间

方法区是 JVM 规范中定义的一块内存区域，用来存储类元数据、方法字节码、即时编译器需要的信息等
永久代是 Hotspot 虚拟机对 JVM 规范的实现（1.8 之前）
元空间是 Hotspot 虚拟机对 JVM 规范的另一种实现（1.8 以后），使用本地内存作为这些信息的存储空间

从这张图学到三点

当第一次用到某个类是，由类加载器将 class 文件的类元信息读入，并存储于元空间
X，Y 的类元信息是存储于元空间中，无法直接访问
可以用 X.class，Y.class 间接访问类元信息，它们俩属于 java 对象，我们的代码中可以使用

从这张图可以学到

堆内存中：当一个类加载器对象，这个类加载器对象加载的所有类对象，这些类对象对应的所有实例对象都没人引用时，GC 时就会对它们占用的对内存进行释放
元空间中：内存释放以类加载器为单位，当堆中类加载器内存释放时，对应的元空间中的类元信息也会释放

13、内存模型以及分区

JVM 分为堆区和栈区，还有方法区(元空间)，初始化的对象放在堆里面，引用放在栈里面，class 类信息常量池（static 常量和 static 变量）等放在方法区

方法区：主要是存储类信息，常量池（static 常量和 static 变量），编译后的代码（字节码）等数据
堆：初始化的对象，成员变量（那种非 static 的变量），所有的对象实例和数组都要在堆上分配
栈：栈的结构是栈帧组成的，调用一个方法就压入一帧，帧上面存储局部变量表，操作数栈，方法出口等信息，局部变量表存放的是 8 大基础类型加上一个应用类型，所以还是一个指向地址的指针
本地方法栈：主要为 Native 方法服务
程序计数器：记录当前线程执行的行号

14、栈和堆的区别

栈和堆都会有OOM，但是栈不会有GC
栈的效率更高
内存大小（堆的空间大）；数据结构（栈，先进先出、堆，数组、链表、树等等）
栈管运行；堆管存储。

15、什么情况下会发生栈内存溢出

局部数组过大。当函数内部的数组过大时，有可能导致堆栈溢出。
递归调用层次太多。递归函数在运行时会执行压栈操作，当压栈次数太多时，也会导致堆栈溢出。

16、如何设置栈大小

-Xss size (即：-XX:ThreadStackSize)

一般默认为512k-1024k，取决于操作系统。

jdk5.0之前，默认栈大小:256k jdk5.0之后，默认栈大小: 1024k( linux \mac\windows )

设置的栈空间值过大，会导致系统可以用于创建线程的数量减少。一般一个进程中通常有3000-5000个线程。

17、方法和栈帧的关系？

每个线程都有自己的栈，栈中的数据都是以**栈帧（Stack Frame）**的格式存在。

在这个线程上正在执行的每个方法都各自对应一个栈帧（Stack Frame）。
栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息。

在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧(栈顶栈帧)是有效的，这个栈帧被称为当前栈帧(Current Frame) ，与当前栈帧相对应的方法就是当前方法(Current Method) ，定义这个方法的类就是当前类(Current Class) 。如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前帧。 执行引擎运行的所有字节码指令只针对当前栈帧进行操作。

18、栈桢内部结构

每个栈帧中存储着：

局部变量表（Local Variables）
操作数栈（Operand Stack）（或表达式栈）
动态链接(Dynamic Linking) （或指向运行时常量池的方法引用）
方法返回地址（Return Address）（或方法正常退出或者异常退出的定义）
一些附加信息

19、局部变量表

局部变量表也被称之为局部变量数组或本地变量表
定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括各类基本数据类型(8种)、对象引用（reference），以及returnAddress类型。
局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的Code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。
方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。
局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

20、操作数栈

我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。
每一个独立的栈帧中除了包含局部变量表以外，还包含一个后进先出（Last-In-First-Out）的操作数栈，也可以称之为表达式栈（Expression Stack）。
操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的。
每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的Code属性中，为max_stack的值。
栈中的任何一个元素都是可以任意的Java数据类型。
- 32bit的类型占用一个栈单位深度
- 64bit的类型占用两个栈单位深度
操作数栈，在方法执行过程中，根据字节码指令，并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈（push）和出栈（pop）操作，往栈中写入数据或提取数据来完成一次数据访问。
某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。比如：执行复制、交换、求和等操作
如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。

21、栈溢出的情况

栈溢出:StackOverflowError;

举个简单的例子:在main方法中调用main方法,就会不断压栈执行,直到栈溢出;

栈的大小可以是固定大小的,也可以是动态变化（动态扩展）的。

如果是固定的,可以通过-Xss设置栈的大小;

如果是动态变化的,当栈大小到达了整个内存空间不足了,就是抛出OutOfMemory异常(java.lang.OutOfMemoryError)

误用线程池导致的内存溢出

java

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

// -Xmx64m
// 模拟短信发送超时，但这时仍有大量的任务进入队列
public class TestOomThreadPool {
    public static void main(String[] args) {
        ExecutorService executor = Executors.newFixedThreadPool(2);
        LoggerUtils.get().debug("begin...");
        while (true) {
            executor.submit(()->{
                try {
                    LoggerUtils.get().debug("send sms...");
                    TimeUnit.SECONDS.sleep(30);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        }
    }
}

查询数据量太大导致的内存溢出

java

import org.openjdk.jol.info.ClassLayout;

import java.nio.charset.StandardCharsets;

// 演示对象的内存估算
public class TestOomTooManyObject {
    public static void main(String[] args) {
        // 对象本身内存
        long a = ClassLayout.parseInstance(new Product()).instanceSize();
        System.out.println(a);
        // 一个字符串占用内存
        String name = "联想小新Air14轻薄本 英特尔酷睿i5 14英寸全面屏学生笔记本电脑(i5-1135G7 16G 512G MX450独显 高色域)银";
        long b = ClassLayout.parseInstance(name).instanceSize();
        System.out.println(b);
        String desc = "【全金属全面屏】学生商务办公，全新11代处理器，MX450独显，100%sRGB高色域，指纹识别，快充（更多好货）";
        long c = ClassLayout.parseInstance(desc).instanceSize();
        System.out.println(c);
        // byte对象本身还占用16个字节
        System.out.println(16 + name.getBytes(StandardCharsets.UTF_8).length);
        System.out.println(16 + desc.getBytes(StandardCharsets.UTF_8).length);
        // 一个对象估算的内存
        long avg = a + b + c + 16 + name.getBytes(StandardCharsets.UTF_8).length + 16 + desc.getBytes(StandardCharsets.UTF_8).length;
        System.out.println(avg);
        // ArrayList 24, Object[] 16 共 40
        System.out.println((1_000_000 * avg + 40) / 1024 / 1024 + "Mb");
    }

    static public class Product {
        private int id;
        private String name;
        private int price;
        private String desc;

        public int getId() {
            return id;
        }

        public void setId(int id) {
            this.id = id;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }

        public int getPrice() {
            return price;
        }

        public void setPrice(int price) {
            this.price = price;
        }

        public String getDesc() {
            return desc;
        }

        public void setDesc(String desc) {
            this.desc = desc;
        }
    }
}

动态生成类导致的内存溢出

java

import groovy.lang.GroovyShell;

import java.io.FileReader;
import java.io.IOException;
import java.util.concurrent.atomic.AtomicInteger;

// -XX:MaxMetaspaceSize=24m
// 模拟不断生成类, 但类无法卸载的情况
public class TestOomTooManyClass {

//    static GroovyShell shell = new GroovyShell();

    public static void main(String[] args) {
        AtomicInteger c = new AtomicInteger();
        while (true) {
            try (FileReader reader = new FileReader("script")) {
                GroovyShell shell = new GroovyShell();
                shell.evaluate(reader);
                System.out.println(c.incrementAndGet());
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}

22、调整栈大小,就能保证不出现溢出吗?

不能。因为调整栈大小,只会减少出现溢出的可能,栈大小不是可以无限扩大的,所以不能保证不出现溢出

23、分配的栈内存越大越好吗?

不是,因为增加栈大小，会造成每个线程的栈都变的很大,使得一定的栈空间下,能创建的线程数量会变小

24、垃圾回收是否会涉及到虚拟机栈?

不会;垃圾回收只会涉及到方法区和堆中,方法区和堆也会存在溢出的可能;

程序计数器,只记录运行下一行的地址,不存在溢出和垃圾回收;

虚拟机栈和本地方法栈,都是只涉及压栈和出栈,可能存在栈溢出,不存在垃圾回收。

25、对象都分配在堆上？

《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated ) 数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。
我要说的是：“几乎”所有的对象实例都在这里分配内存。——从实际使用角度看的。

26、堆里面的分区：Eden，survival （from+ to），老年代，各自的特点。

堆里面分为新生代和老生代（java8 取消了永久代，采用了 Metaspace），新生代包含 Eden+Survivor 区，survivor 区里面分为 from 和 to 区，内存回收时，如果用的是复制算法，从 from 复制到 to，当经过一次或者多次 GC 之后，存活下来的对象会被移动到老年区，当 JVM 内存不够用的时候，会触发 Full GC，清理 JVM 老年区当新生区满了之后会触发 YGC,先把存活的对象放到其中一个 Survice区，然后进行垃圾清理。因为如果仅仅清理需要删除的对象，这样会导致内存碎片，因此一般会把 Eden 进行完全的清理，然后整理内存。那么下次 GC 的时候，就会使用下一个 Survive，这样循环使用。如果有特别大的对象，新生代放不下，就会使用老年代的担保，直接放到老年代里面。因为 JVM 认为，一般大对象的存活时间一般比较久远。

存储在JVM中的Java对象可以被划分为两类：
- 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
- 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致。
Java堆区进一步细分的话，可以划分为年轻代（YoungGen）和老年代（OldGen）
其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫做from区、to区）。

几乎所有的Java对象都是在Eden区被new出来的。
绝大部分的Java对象的销毁都在新生代进行了。
- IBM 公司的专门研究表明，新生代中 80% 的对象都是“朝生夕死”的。

27、如何设置堆内存大小？

Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项”-Xmx”和”-Xms”来进行设置。
- “-Xms”用于表示堆区的起始内存，等价于-XX:InitialHeapSize
- “-Xmx”则用于表示堆区的最大内存，等价于-XX:MaxHeapSize
一旦堆区中的内存大小超过“-Xmx”所指定的最大内存时，将会抛出OutOfMemoryError:heap异常。
通常会将 -Xms 和 -Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。
- heap默认最大值计算方式：如果物理内存少于192M,那么heap最大值为物理内存的一半。如果物理内存大于等于1G，那么heap的最大值为物理内存的1/4。
- heap默认最小值计算方式：最少不得少于8M，如果物理内存大于等于1G，那么默认值为物理内存的1/64，即1024/64=16M。最小堆内存在jvm启动的时候就会被初始化。

28、初始堆大小和最大堆大小一样，问这样有什么好处？

通常会将 -Xms 和 -Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。

29、JVM中最大堆大小有没有限制

在Oracle Solaris 7和Oracle Solaris 8 SPARC平台上，这个值的上限大约是4000 MB减去开销。在Oracle Solaris 2.6和x86平台上，上限大约是2000 MB减去开销。在Linux平台上，上限大约是2000 MB减去开销。

另：对于32位操作系统，如果物理内存等于4G，那么堆内存可以达到1G。对于64位操作系统，如果物理内存为128G，那么heap最多可以达到32G。

30、如何设置新生代与老年代比例

下面这参数开发中一般不会调：

配置新生代与老年代在堆结构的占比。
- 默认**-XX:NewRatio=2**，表示新生代占1，老年代占2，新生代占整个堆的1/3
- 可以修改-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5
可以使用选项”-Xmn”设置新生代最大内存大小
- 这个参数一般使用默认值就可以了。

31、如何设置Eden、幸存者区比例

在HotSpot中，Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1（要显式配置）
当然开发人员可以通过选项“-XX:SurvivorRatio”调整这个空间比例。比如-XX:SurvivorRatio=8

32、对象分配过程

1.new的对象先放伊甸园区。此区有大小限制。

2.当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC/YGC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区

3.然后将伊甸园中的剩余对象移动到幸存者0区。

4.如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。

5.如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。

6.啥时候能去养老区呢？可以设置次数。默认是15次。

可以设置参数：-XX:MaxTenuringThreshold=<N> 设置对象晋升老年代的年龄阈值。

7.在养老区，相对悠闲。当养老区内存不足时，再次触发GC：Major GC，进行养老区的内存清理。

8.若养老区执行了Major GC之后发现依然无法进行对象的保存，就会产生OOM异常

33、内存分配原则

优先分配到Eden
大对象直接分配到老年代
- 尽量避免程序中出现过多的大对象
长期存活的对象分配到老年代
动态对象年龄判断
- 如果Survivor 区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。
空间分配担保
- -XX:HandlePromotionFailure

34、解释MinorGC、MajorGC、FullGC

JVM在进行GC时，并非每次都对上面三个内存(新生代、老年代；方法区)区域一起回收的，大部分时候回收的都是指新生代。

针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大种类型：

一种是部分收集（Partial GC）
一种是整堆收集（Full GC）
部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：
- 新生代收集（Minor GC / Young GC）：只是新生代（Eden\S0,S1）的垃圾收集
- 老年代收集（Major GC / Old GC）：只是老年代的垃圾收集。
- 目前，只有CMS GC会有单独收集老年代的行为。
- 注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。
混合收集（Mixed GC)：收集整个新生代以及部分老年代的垃圾收集。
- 目前，只有G1 GC会有这种行为
整堆收集（Full GC)：收集整个java堆和方法区的垃圾收集。

35、GC 的两种判定方法

引用计数法：指的是如果某个地方引用了这个对象就+1，如果失效了就-1，当为 0 就会回收但是 JVM 没有用这种方式，因为无法判定相互循环引用（A 引用 B,B 引用 A）的情况
引用链法：通过一种 GC ROOT 的对象（方法区中静态变量引用的对象等-static 变量）来判断，如果有一条链能够到达 GC ROOT 就说明，不能到达 GC ROOT 就说明可以回收

36、java 中垃圾收集的方法有哪些?

标记-清除

这是垃圾收集算法中最基础的，根据名字就可以知道，它的思想就是标记哪些要被回收的对象，然后统一回收。这种方法很简单，但是会有两个主要问题：1.效率不高，标记和清除的效率都很低；2.会产生大量不连续的内存碎片，导致以后程序在分配较大的对象时，由于没有充足的连续内存而提前触发一次 GC 动作。

复制算法

为了解决效率问题，复制算法将可用内存按容量划分为相等的两部分，然后每次只使用其中的一块，当一块内存用完时，就将还存活的对象复制到第二块内存上，然后一次性清楚完第一块内存，再将第二块上的对象复制到第一块。但是这种方式，内存的代价太高，每次基本上都要浪费一般的内存。于是将该算法进行了改进，内存区域不再是按照 1：1 去划分，而是将内存划分为8:1:1 三部分，较大那份内存交 Eden 区，其余是两块较小的内存区叫 Survior 区。每次都会优先使用 Eden 区，若 Eden 区满，就将对象复制到第二块内存区上，然后清除 Eden 区，如果此时存活的对象太多，以至于 Survivor 不够时，会将这些对象通过分配担保机制复制到老年代中。(java 堆又分为新生代和老年代)

标记-整理

该算法主要是为了解决标记-清除，产生大量内存碎片的问题；当对象存活率较高时，也解决了复制算法的效率问题。它的不同之处就是在清除对象的时候现将可回收对象移动到一端，然后清除掉端边界以外的对象，这样就不会产生内存碎片了。

分代收集

现在的虚拟机垃圾收集大多采用这种方式，它根据对象的生存周期，将堆分为新生代和老年代。在新生代中，由于对象生存期短，每次回收都会有大量对象死去，那么这时就采用复制算法。老年代里的对象存活率较高，没有额外的空间进行分配担保，所以可以使用标记-整理 或者 标记-清除。

37、JVM 内存参数

堆内存，按大小设置

解释：

-Xms 最小堆内存（包括新生代和老年代）
-Xmx 最大堆内存（包括新生代和老年代）
通常建议将 -Xms 与 -Xmx 设置为大小相等，即不需要保留内存，不需要从小到大增长，这样性能较好
-XX:NewSize 与 -XX:MaxNewSize 设置新生代的最小与最大值，但一般不建议设置，由 JVM 自己控制
-Xmn 设置新生代大小，相当于同时设置了 -XX:NewSize 与 -XX:MaxNewSize 并且取值相等
保留是指，一开始不会占用那么多内存，随着使用内存越来越多，会逐步使用这部分保留内存。下同

堆内存，按比例设置

解释：

-XX:NewRatio=2:1 表示老年代占两份，新生代占一份
-XX:SurvivorRatio=4:1 表示新生代分成六份，伊甸园占四份，from 和 to 各占一份

元空间内存设置

解释：

class space 存储类的基本信息，最大值受 -XX:CompressedClassSpaceSize 控制
non-class space 存储除类的基本信息以外的其它信息（如方法字节码、注解等）
class space 和 non-class space 总大小受 -XX:MaxMetaspaceSize 控制

注意：

这里 -XX:CompressedClassSpaceSize 这段空间还与是否开启了指针压缩有关，这里暂不深入展开，可以简单认为指针压缩默认开启

代码缓存内存设置

解释：

如果 -XX:ReservedCodeCacheSize < 240m，所有优化机器代码不加区分存在一起
否则，分成三个区域（图中笔误 mthod 拼写错误，少一个 e）
- non-nmethods - JVM 自己用的代码
- profiled nmethods - 部分优化的机器码
- non-profiled nmethods - 完全优化的机器码

线程内存设置

官方参考文档
https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE

38、JVM 垃圾回收

三种垃圾回收算法

标记清除法

解释：

找到 GC Root 对象，即那些一定不会被回收的对象，如正执行方法内局部变量引用的对象、静态变量引用的对象
标记阶段：沿着 GC Root 对象的引用链找，直接或间接引用到的对象加上标记
清除阶段：释放未加标记的对象占用的内存

要点：

标记速度与存活对象线性关系
清除速度与内存大小线性关系
缺点是会产生内存碎片

标记整理法

解释：

前面的标记阶段、清理阶段与标记清除法类似
多了一步整理的动作，将存活对象向一端移动，可以避免内存碎片产生

特点：

标记速度与存活对象线性关系
清除与整理速度与内存大小成线性关系
缺点是性能上较慢

标记复制法

解释：

将整个内存分成两个大小相等的区域，from 和 to，其中 to 总是处于空闲，from 存储新创建的对象
标记阶段与前面的算法类似
在找出存活对象后，会将它们从 from 复制到 to 区域，复制的过程中自然完成了碎片整理
复制完成后，交换 from 和 to 的位置即可

特点：

标记与复制速度与存活对象成线性关系
缺点是会占用成倍的空间

GC 与分代回收算法

GC 的目的在于实现无用对象内存自动释放，减少内存碎片、加快分配速度

GC 要点：

回收区域是堆内存，不包括虚拟机栈
判断无用对象，使用可达性分析算法，三色标记法标记存活对象，回收未标记对象
GC 具体的实现称为垃圾回收器
GC 大都采用了分代回收思想
- 理论依据是大部分对象朝生夕灭，用完立刻就可以回收，另有少部分对象会长时间存活，每次很难回收
- 根据这两类对象的特性将回收区域分为新生代和老年代，新生代采用标记复制法、老年代一般采用标记整理法
根据 GC 的规模可以分成 Minor GC，Mixed GC，Full GC

分代回收

伊甸园 eden，最初对象都分配到这里，与幸存区 survivor（分成 from 和 to）合称新生代，

当伊甸园内存不足，标记伊甸园与 from（现阶段没有）的存活对象

将存活对象采用复制算法复制到 to 中，复制完毕后，伊甸园和 from 内存都得到释放

将 from 和 to 交换位置

经过一段时间后伊甸园的内存又出现不足

标记伊甸园与 from（现阶段没有）的存活对象

将存活对象采用复制算法复制到 to 中

复制完毕后，伊甸园和 from 内存都得到释放

将 from 和 to 交换位置

老年代 old，当幸存区对象熬过几次回收（最多15次），晋升到老年代（幸存区内存不足或大对象会导致提前晋升）

GC 规模

Minor GC 发生在新生代的垃圾回收，暂停时间短
Mixed GC 新生代 + 老年代部分区域的垃圾回收，G1 收集器特有
Full GC 新生代 + 老年代完整垃圾回收，暂停时间长，应尽力避免

三色标记

即用三种颜色记录对象的标记状态

黑色 – 已标记
灰色 – 标记中
白色 – 还未标记

起始的三个对象还未处理完成，用灰色表示

该对象的引用已经处理完成，用黑色表示，黑色引用的对象变为灰色

依次类推

沿着引用链都标记了一遍

最后为标记的白色对象，即为垃圾

并发漏标问题

比较先进的垃圾回收器都支持并发标记，即在标记过程中，用户线程仍然能工作。但这样带来一个新的问题，如果用户线程修改了对象引用，那么就存在漏标问题。例如：

如图所示标记工作尚未完成

用户线程同时在工作，断开了第一层 3、4 两个对象之间的引用，这时对于正在处理 3 号对象的垃圾回收线程来讲，它会将 4 号对象当做是白色垃圾

但如果其他用户线程又建立了 2、4 两个对象的引用，这时因为 2 号对象是黑色已处理对象了，因此垃圾回收线程不会察觉到这个引用关系的变化，从而产生了漏标

如果用户线程让黑色对象引用了一个新增对象，一样会存在漏标问题

因此对于并发标记而言，必须解决漏标问题，也就是要记录标记过程中的变化。有两种解决方法：

Incremental Update 增量更新法，CMS 垃圾回收器采用
- 思路是拦截每次赋值动作，只要赋值发生，被赋值的对象就会被记录下来，在重新标记阶段再确认一遍
Snapshot At The Beginning，SATB 原始快照法，G1 垃圾回收器采用
- 思路也是拦截每次赋值动作，不过记录的对象不同，也需要在重新标记阶段对这些对象二次处理
- 新加对象会被记录
- 被删除引用关系的对象也被记录

垃圾回收器 - Parallel GC

eden 内存不足发生 Minor GC，采用标记复制算法，需要暂停用户线程
old 内存不足发生 Full GC，采用标记整理算法，需要暂停用户线程
注重吞吐量

垃圾回收器 - ConcurrentMarkSweep GC

它是工作在 old 老年代，支持并发标记的一款回收器，采用并发清除算法
- 并发标记时不需暂停用户线程
- 重新标记时仍需暂停用户线程
如果并发失败（即回收速度赶不上创建新对象速度），会触发 Full GC
注重响应时间

垃圾回收器 - G1 GC

响应时间与吞吐量兼顾
划分成多个区域，每个区域都可以充当 eden，survivor，old， humongous，其中 humongous 专为大对象准备
分成三个阶段：新生代回收、并发标记、混合收集
如果并发失败（即回收速度赶不上创建新对象速度），会触发 Full GC

G1 回收阶段 - 新生代回收

初始时，所有区域都处于空闲状态

创建了一些对象，挑出一些空闲区域作为伊甸园区存储这些对象

当伊甸园需要垃圾回收时，挑出一个空闲区域作为幸存区，用复制算法复制存活对象，需要暂停用户线程

复制完成，将之前的伊甸园内存释放

随着时间流逝，伊甸园的内存又有不足

将伊甸园以及之前幸存区中的存活对象，采用复制算法，复制到新的幸存区，其中较老对象晋升至老年代

释放伊甸园以及之前幸存区的内存

G1 回收阶段 - 并发标记与混合收集

当老年代占用内存超过阈值后，触发并发标记，这时无需暂停用户线程

并发标记之后，会有重新标记阶段解决漏标问题，此时需要暂停用户线程。这些都完成后就知道了老年代有哪些存活对象，随后进入混合收集阶段。此时不会对所有老年代区域进行回收，而是根据暂停时间目标优先回收价值高（存活对象少）的区域（这也是 Gabage First 名称的由来）。

混合收集阶段中，参与复制的有 eden、survivor、old，下图显示了伊甸园和幸存区的存活对象复制

下图显示了老年代和幸存区晋升的存活对象的复制

复制完成，内存得到释放。进入下一轮的新生代回收、并发标记、混合收集

39、四种引用

强引用

普通变量赋值即为强引用，如 A a = new A();
通过 GC Root 的引用链，如果强引用不到该对象，该对象才能被回收

软引用（SoftReference）

例如：SoftReference a = new SoftReference(new A());
如果仅有软引用该对象时，首次垃圾回收不会回收该对象，如果内存仍不足，再次回收时才会释放对象
软引用自身需要配合引用队列来释放
典型例子是反射数据

弱引用（WeakReference）

例如：WeakReference a = new WeakReference(new A());
如果仅有弱引用引用该对象时，只要发生垃圾回收，就会释放该对象
弱引用自身需要配合引用队列来释放
典型例子是 ThreadLocalMap 中的 Entry 对象

虚引用（PhantomReference）

例如： PhantomReference a = new PhantomReference(new A(), referenceQueue);
必须配合引用队列一起使用，当虚引用所引用的对象被回收时，由 Reference Handler 线程将虚引用对象入队，这样就可以知道哪些对象被回收，从而对它们关联的资源做进一步处理
典型例子是 Cleaner 释放 DirectByteBuffer 关联的直接内存

40、finalize

它是 Object 中的一个方法，如果子类重写它，垃圾回收时此方法会被调用，可以在其中进行资源释放和清理工作
将资源释放和清理放在 finalize 方法中非常不好，非常影响性能，严重时甚至会引起 OOM，从 Java9 开始就被标注为 @Deprecated，不建议被使用了

finalize 原理

对 finalize 方法进行处理的核心逻辑位于 java.lang.ref.Finalizer 类中，它包含了名为 unfinalized 的静态变量（双向链表结构），Finalizer 也可被视为另一种引用对象（地位与软、弱、虚相当，只是不对外，无法直接使用）
当重写了 finalize 方法的对象，在构造方法调用之时，JVM 都会将其包装成一个 Finalizer 对象，并加入 unfinalized 链表中

Finalizer 类中还有另一个重要的静态变量，即 ReferenceQueue 引用队列，刚开始它是空的。当狗对象可以被当作垃圾回收时，就会把这些狗对象对应的 Finalizer 对象加入此引用队列
但此时 Dog 对象还没法被立刻回收，因为 unfinalized -> Finalizer 这一引用链还在引用它嘛，为的是【先别着急回收啊，等我调完 finalize 方法，再回收】
FinalizerThread 线程会从 ReferenceQueue 中逐一取出每个 Finalizer 对象，把它们从链表断开并真正调用 finallize 方法

由于整个 Finalizer 对象已经从 unfinalized 链表中断开，这样没谁能引用到它和狗对象，所以下次 gc 时就被回收了

finalize 缺点

无法保证资源释放：FinalizerThread 是守护线程，代码很有可能没来得及执行完，线程就结束了
无法判断是否发生错误：执行 finalize 方法时，会吞掉任意异常（Throwable）
内存释放不及时：重写了 finalize 方法的对象在第一次被 gc 时，并不能及时释放它占用的内存，因为要等着 FinalizerThread 调用完 finalize，把它从 unfinalized 队列移除后，第二次 gc 时才能真正释放内存
有的文章提到【Finalizer 线程会和我们的主线程进行竞争，不过由于它的优先级较低，获取到的CPU时间较少，因此它永远也赶不上主线程的步伐】这个显然是错误的，FinalizerThread 的优先级较普通线程更高，原因应该是 finalize 串行执行慢等原因综合导致

代码说明

java

import java.io.IOException;

public class TestFinalize {
    static class Dog {
        private String name;

        public Dog(String name) {
            this.name = name;
        }

        @Override
        protected void finalize() throws Throwable {
            LoggerUtils.get().debug("{}被干掉了?", this.name);
            int i = 1 / 0;
        }
    }

    public static void main(String[] args) throws IOException {
        new Dog("大傻");
        new Dog("二哈");
        new Dog("三笨");
        System.gc();
        System.in.read();
    }
    /*
    第一，从表面上我们能看出来 finalize 方法的调用次序并不能保证
    第二，日志中的 Finalizer 表示输出日志的线程名称，从这我们看出是这个叫做 Finalizer 的线程调用的 finalize 方法
    第三，你不能注释掉 `System.in.read()`，否则会发现（绝大概率）并不会有任何输出结果了，从这我们看出 finalize 中的代码并不能保证被执行
    第四，如果将 finalize 中的代码出现异常，会发现根本没有异常输出
    第五，还有个疑问，垃圾回收时就会立刻调用  finalize 方法吗？
     */
}

JVM面试题 ​

1、Java虚拟机中，数据类型可以分为哪几类？ ​

2、为什么不把基本类型放堆中呢？ ​

3、JVM 由哪些部分组成？ ​

4、类加载器是有了解吗？ ​

5、Java 虚拟机是如何判定两个 Java 类是相同的？ ​

6、Java类加载过程（生命周期） ​

7、Class的forName("Java.lang.String")和Class的getClassLoader()的loadClass("Java.lang.String")有什么区别？ ​

8、双亲委派机制 ​

9、双亲委派机制的优势与劣势 ​

10、破坏双亲委派机制 ​

1、破坏双亲委派机制1 ​

2、破坏双亲委派机制2 ​

3、破坏双亲委派机制3 ​

11、什么是tomcat类加载机制？ ​

12、JVM 内存结构 ​

13、内存模型以及分区 ​

14、栈和堆的区别 ​

15、什么情况下会发生栈内存溢出 ​

16、如何设置栈大小 ​

17、方法和栈帧的关系？ ​

18、栈桢内部结构 ​

19、局部变量表 ​

20、操作数栈 ​

21、栈溢出的情况 ​

22、调整栈大小,就能保证不出现溢出吗? ​

23、分配的栈内存越大越好吗? ​

24、垃圾回收是否会涉及到虚拟机栈? ​

25、对象都分配在堆上？ ​

26、堆里面的分区：Eden，survival （from+ to），老年代，各自的特点。 ​

27、如何设置堆内存大小？ ​

28、初始堆大小和最大堆大小一样，问这样有什么好处？ ​

29、JVM中最大堆大小有没有限制 ​

30、如何设置新生代与老年代比例 ​

31、如何设置Eden、幸存者区比例 ​

32、对象分配过程 ​

33、内存分配原则 ​

34、解释MinorGC、MajorGC、FullGC ​

35、GC 的两种判定方法 ​

36、java 中垃圾收集的方法有哪些? ​

37、JVM 内存参数 ​

38、JVM 垃圾回收 ​

39、四种引用 ​

40、finalize ​

JVM面试题

1、Java虚拟机中，数据类型可以分为哪几类？

2、为什么不把基本类型放堆中呢？

3、JVM 由哪些部分组成？

4、类加载器是有了解吗？

5、Java 虚拟机是如何判定两个 Java 类是相同的？

6、Java类加载过程（生命周期）

7、Class的forName("Java.lang.String")和Class的getClassLoader()的loadClass("Java.lang.String")有什么区别？

8、双亲委派机制

9、双亲委派机制的优势与劣势

10、破坏双亲委派机制

1、破坏双亲委派机制1

2、破坏双亲委派机制2

3、破坏双亲委派机制3

11、什么是tomcat类加载机制？

12、JVM 内存结构

13、内存模型以及分区

14、栈和堆的区别

15、什么情况下会发生栈内存溢出

16、如何设置栈大小

17、方法和栈帧的关系？

18、栈桢内部结构

19、局部变量表

20、操作数栈

21、栈溢出的情况

22、调整栈大小,就能保证不出现溢出吗?

23、分配的栈内存越大越好吗?

24、垃圾回收是否会涉及到虚拟机栈?

25、对象都分配在堆上？

26、堆里面的分区：Eden，survival （from+ to），老年代，各自的特点。

27、如何设置堆内存大小？

28、初始堆大小和最大堆大小一样，问这样有什么好处？

29、JVM中最大堆大小有没有限制

30、如何设置新生代与老年代比例

31、如何设置Eden、幸存者区比例

32、对象分配过程

33、内存分配原则

34、解释MinorGC、MajorGC、FullGC

35、GC 的两种判定方法

36、java 中垃圾收集的方法有哪些?

37、JVM 内存参数

38、JVM 垃圾回收

39、四种引用

40、finalize