JVM笔记

1. JVM

作用

JVM 本质上是一个运行在计算机上的程序，他的职责是运行Java字节码文件。实现跨平台

• 1 - 解释和运行

• 2 - 内存管理：自动为对象、方法等分配内存，自动的垃圾回收机制，回收不再使用的对象

• 3 - 即时编译

即时编译

问题：Java如果不做任何的优化，性能其实是不如C和C++的。主要原因是：多了一步解释的过程

解决：对热点代码进行优化，提升执行效率（即时编译）

          虚拟机在运行过程中如果发现某一个方法甚至是循环是热点代码（被非常高频调用），即时编译器会优化这段代码并将优化后的机器码保存在内存中，如果第二次再去执行这段代码。Java虚拟机会将机器码从内存中取出来直接调用。这样节省了一次解释的步骤，同时执行的是优化后的代码，效率较高。

JVM组成

2. 字节码文件的组成

• 基础信息：魔数、字节码文件对应的Java版本号、访问标识(public final等等)、父类和接口信息

• 常量池： 保存了字符串常量、类或接口名、字段名，主要在字节码指令中使用

• 字段： 当前类或接口声明的字段信息

• 方法： 当前类或接口声明的方法信息，核心内容为方法的字节码指令

• 属性： 类的属性，比如源码的文件名、内部类的列表等

基本信息

魔数

文件无法通过文件扩展名来确定文件类型，因为文件扩展名可以随意修改，不影响文件的内容。

软件会使用文件的头几个字节（文件头）去校验文件类型，如果不支持该类型就会出错。

Java字节码文件的文件头，用16进制表示就是0xcafebabe，称为魔数

        常见的文件格式校验方式如下：

主副版本号

主副版本号 指的是编译字节码文件时使用的 JDK版本号。

主版本号用来标识大版本号，JDK1.0-1.1使用了45.0-45.3，JDK1.2是46，之后每升级一个大版本就加1；

副版本号是当 主版本号相同 时作为区分不同版本的标识，一般只需要关心主版本号。

1.2之后大版本号计算方法就是：主版本号 – 44，比如主版本号52就是JDK8。

版本号的作用主要是判断当前 字节码的版本 和 运行时的JDK 是否兼容。如果使用较低版本的JDK去运行较高版本JDK的字节码文件，会无法使用，显示如下错误：

有两种方案：

1. 升级JDK版本（容易引发其他的兼容性问题，并且需要大量的测试）
2. 将第三方依赖的版本号降低或者更换依赖，以满足JDK版本的要求。（建议）

常量池

四种常量池

class文件常量池 主要存放两类常量：字面量和符号引用。

作用：避免相同的内容重复定义，节省空间

• 为什么要保留中间的索引？（不懂）
• 为什么要保留最后的字面量？（不懂）

字节码指令中通过编号引用到常量池的过程称之为符号引用

方法

i=i++的执行流程：

结果 i=0

• const：将常量放到栈中
• store：将常量从 栈 加到 局部变量表 中
• load：将常量从 局部变量表 加到 栈 中

栈执行运算操作

++操作直接在变量表中执行，不需要load到栈中执行

3. 类的生命周期

① 加载

类加载：将类信息加载到内存，然后 jvm 在方法区和堆上各分配一个对象（通过调用虚拟机底层方法），来保存类信息

1、类加载器根据 类的全限定名 通过不同的渠道 以二进制流的方式 获取字节码信息，程序员可以使用Java代码拓展的不同的渠道：

• 从本地磁盘上获取文件

• 运行时通过动态代理生成，比如Spring框架

• Applet技术通过网络获取字节码文件

2、类加载器在加载完类之后，Java虚拟机会将字节码中的信息保存到方法区中，方法区中生成一个 InstanceKlass对象，保存类的所有信息，里边还包含实现特定功能比如多态的信息。

3、Java虚拟机同时会在堆上生成与方法区中数据类似的 java.lang.Class对象，作用是在Java代码中去获取类的信息（反射）以及存储静态字段的数据（JDK8及之后），作为方法区数据的访问入口

 

为什么还要在堆上创建一个对象？

• 方法区中的对象是用c++编写的，不能直接操作，而堆中的对象是用 java 封装好的
• 堆中对象包含的字段少于方法区对象的，控制了开发者访问数据的范围，提高安全性

② 连接

• 验证，验证内容是否满足《Java虚拟机规范》。

• 准备，给静态变量赋初值。

• 解析，将常量池中的符号引用替换成指向内存的直接引用。

验证

验证的主要目的是 检测Java字节码文件是否遵守了《Java虚拟机规范》中的约束。这个阶段一般不需要程序员参与。主要包含如下四部分，具体详见《Java虚拟机规范》：

1、文件格式验证，比如文件是否以0xCAFEBABE开头，主次版本号是否满足当前Java虚拟机版本要求。

2、元信息验证，例如类必须有父类（super不能为空）。

3、程序执行指令的语义验证，比如方法内的指令执行中跳转到不正确的位置。

4、符号引用验证，例如是否访问了其他类中private的方法等。

准备

准备阶段为静态变量（static）分配内存并设置初值

final 修饰的基本数据类型的静态变量，准备阶段直接会将代码中的值进行赋值。

解析（静态链接）

解析阶段主要是将常量池中的符号引用替换为直接引用

符号引用就是 在字节码文件中使用编号来访问常量池中的内容。

直接引用不再使用编号，而是使用内存地址访问具体的数据。

静/动态链接：符号引用 -> 直接引用

符号引用是编译阶段

符号引用就是该引用指向的只是一个符号（编号），直接引用就是该引用指向的是一个实际内存地址

静态链接发生在类加载的连接阶段中的解析阶段，动态链接发生在程序运行期间。

类加载时会对类中静态方法或者私有方法中的引用类型的变量进行静态链接。在程序运行期间会对执行到方法的内部的引用类型的变量进行动态链接。

③ 初始化 

执行静态代码块中的代码，并为静态变量赋值。会执行字节码文件中clinit（class init，类初始化）方法的字节码指令

如下代码编译成字节码文件之后，会生成三个方法：

• init方法，会在对象初始化时执行（构造方法）

• main方法，主方法

• clinit方法，类的初始化阶段执行

public class Demo1 {
    public static int value = 1;
    static {
        value = 2;
    }
   
    public static void main(String[] args) {}
}

类的初始化时机

1. 访问一个类的静态变量或者静态方法，注意：如果 变量是final修饰的 并且 等号右边是常量则不会触发初始化。
2. 调用Class.forName(String className)。
3. new一个该类的对象时。
4. 执行Main方法的当前类。

添加 -XX:+TraceClassLoading 参数可以打印出加载并初始化的类

putstatic：将操作数栈上的数弹出来，并放入堆中静态变量的位置

ldc：从常量池中将字符串加载到操作数栈

clinit不会执行的情况

如下几种情况是不会进行初始化指令执行的：

1. 无 静态代码块 且 无 静态变量赋值语句。
2. 有静态变量的声明，但是没有赋值语句。public static int a;
3. 静态变量的定义使用final关键字，这类变量会在准备阶段直接进行初始化。

继承的初始化

1. 直接访问父类的静态变量，不会触发子类的初始化。
2. 子类的初始化clinit调用之前，会先调用父类的clinit初始化方法

数组的初始化

数组的创建不会导致数组中元素的类进行初始化（Person[] arr = new Person[10];）

其它

final修饰的变量如果赋值的内容需要执行指令才能得出结果，会执行clinit方法进行初始化。

public static final int a = Integer.valueOf(1);

4. 类加载器

① 概述 

类加载器负责 获取在类加载过程中的字节码并加载到内存 这一部分。通过加载字节码数据放入内存转换成byte[]，接下来调用虚拟机底层方法将byte[] 转换成方法区和堆中的数据  

类加载器（ClassLoader）是Java虚拟机提供给应用程序 去实现 获取 类和接口 字节码数据 的技术，只参与 加载过程 中的 字节码获取并加载到内存 这一部分。

类加载器会通过 二进制流 的方式获取到字节码文件的内容，接下来将获取到的数据交给Java虚拟机，虚拟机会在方法区和堆上生成对应的对象保存字节码信息。

② 分类

类加载器分为两类，一类是Java代码中实现的，一类是Java虚拟机底层源码实现的。

• 虚拟机底层实现：源代码位于Java虚拟机的源码中，实现语言与虚拟机底层语言一致，比如Hotspot使用C++。主要目的是保证Java程序运行中基础类被正确地加载，比如java.lang.String，Java虚拟机需要确保其可靠性。

• JDK中默认提供或者自定义：JDK中默认提供了多种处理不同渠道的类加载器，程序员也可以自己根据需求定制，使用Java语言。所有Java中实现的类加载器都需要继承ClassLoader这个抽象类。

JDK1.8及之前

启动类加载器

• 启动类加载器（Bootstrap ClassLoader）是由Hotspot虚拟机提供的、使用C++编写的类加载器。

• 默认加载 Java安装目录/jre/lib 下的类文件，比如rt.jar，tools.jar，resources.jar等。

/**
 * 启动程序类加载器案例
 */
public class BootstrapClassLoaderDemo {
    public static void main(String[] args) throws IOException {
        ClassLoader classLoader = String.class.getClassLoader();//获取类加载器
        System.out.println(classLoader);// 输出为null
        System.in.read();
    }
}

这是因为启动类加载器在JDK8中是由C++语言来编写的，在Java代码中去获取既不适合也不安全，所以才返回null

如果用户想扩展一些比较基础的 jar包，让启动类加载器加载，有两种途径：

• 放入jre/lib下进行扩展。不推荐，尽可能不要去更改JDK安装目录中的内容，会出现即时放进去由于文件名不匹配的问题也不会正常地被加载。

• 使用参数进行扩展。推荐，使用 -Xbootclasspath/a:jar包目录/jar包名 进行扩展，参数中的/a代表新增。

扩展和应用程序类加载器

• 扩展类加载器 和 应用程序类加载器 都是JDK中提供的、使用Java编写的类加载器。

• 它们的源码都位于sun.misc.Launcher中，是一个静态内部类。继承自URLClassLoader。具备 通过目录或者指定jar包 将字节码文件加载到内存 的能力。

扩展类加载器（Extension Class Loader）

        默认加载 Java安装目录/jre/lib/ext 下的类文件。

        通过扩展类加载器去加载用户jar包：

• 放入 /jre/lib/ext 下进行扩展。不推荐，尽可能不要去更改JDK安装目录中的内容。

• 使用参数进行扩展使用参数进行扩展。推荐，使用 -Djava.ext.dirs=jar包目录 进行扩展,这种方式会覆盖掉原始目录，可以用;(windows):(macos/linux)追加上原始目录

应用程序类加载器 

        加载classpath下的类文件，默认加载的是 项目中的类 以及 通过maven引入的第三方jar包中的类。

③ 双亲委派机制

解决 类由哪个类加载器来加载 的核心问题

当一个类加载器接收到加载类的任务时，会自底向上查找是否加载过，再由顶向下进行加载

作用

流程

每个类加载器都有一个父类加载器。父类加载器的关系如下，启动类加载器没有父类加载器：

自底向上：

        在类加载的过程中，每个类加载器都会先检查是否已经加载了该类，如果已经加载则 直接返回，否则会将加载请求 委派给父类加载器

自顶向下：

        发现所有类加载器都没有加载过，类加载器就会自顶向下尝试加载。如果发现这个类在它的加载目录中，则加载，否则向下 传递给子类加载器

如何指定加载类的类加载器？

1. 使用 Class.forName 方法，使用当前类的类加载器去加载指定的类。
2. 获取到类加载器，通过类加载器的 loadClass 方法指定某个类加载器加载。

面试：类的双亲委派机制？

• 当一个类加载器去加载某个类的时候，会自底向上查找是否加载过，如果加载过就直接返回，如果一直到最顶层的类加载器都没有加载，再由顶向下进行加载

• 应用程序类加载器的父类加载器是扩展类加载器，扩展类加载器的父类加载器是启动类加载器

• 双亲委派机制的好处有两点：第一是避免恶意代码替换JDK中的核心类库，比如java.lang.String，确保核心类库的完整性和安全性。第二是避免一个类重复地被加载。

④ 打破双亲委派

打破双亲委派机制历史上有三种方式，但本质上只有第一种算是真正的打破了双亲委派机制：

• 自定义类加载器 并且 重写loadClass方法。Tomcat通过这种方式实现应用之间类隔离。

• 线程上下文类加载器。利用上下文类加载器加载类，比如JDBC和JNDI等。

• Osgi框架的类加载器。历史上Osgi框架实现了一套新的类加载器机制，允许同级之间委托进行类的加载，目前很少使用。

自定义类加载器

为什么需要自定义类加载器？

        用户可以自定义类加载器来进行拓展，以满足自己的特殊需求。就比如说，我们可以对 Java 类的字节码（ .class 文件）进行加密，加载时再利用自定义的类加载器对其解密。

        比如：一个Tomcat程序中是可以运行多个Web应用的，如果这两个应用中出现了相同限定名的类，比如Servlet类，Tomcat要保证这两个类都能加载并且它们应该是不同的类。如果不打破双亲委派机制，当应用类加载器加载Web应用1中的MyServlet之后，Web应用2中相同限定名的MyServlet类就无法被加载了。

        在同一个Java虚拟机中，只有 相同类加载器+相同的类限定名 才会被认为是同一个类。

        Tomcat使用了自定义类加载器，每一个应用会有一个独立的类加载器加载对应的类，从而实现了应用之间类的隔离

   ->  

        ClassLoader中包含了4个核心方法：

public Class<?> loadClass(String name)
类加载的入口，提供了双亲委派机制。内部会调用findClass   重要

protected Class<?> findClass(String name)
由类加载器子类实现,获取二进制数据调用defineClass ，比如URLClassLoader会根据文件路径去获取类文件中的二进制数据。重要

protected final Class<?> defineClass(String name, byte[] b, int off, int len)
做一些类名的校验，然后调用虚拟机底层的方法将字节码信息加载到虚拟机内存中

protected final void resolveClass(Class<?> c)
执行类生命周期中的连接阶段

        loadClass：

提供双亲委派机制，会向上查找类，如果没找到则调用findClass

        findClass：

获取类的字节码，可以从指定位置获取类的字节码数据。由类加载器子类实现。

** 如果不想打破双亲委派，只想从指定位置（比如数据库）获取类的字节码数据，则只需要重写findClass方法即可

        defineClass：

调用虚拟机底层方法，将字节码信息加载到内存，在堆和方法区分配对象（类的加载阶段）

        resolveClass：

连接阶段

        双亲委派机制的核心代码就位于loadClass方法中

     默认情况下 自定义类加载器的父类加载器 是 应用程序类加载器

线程上下文类加载器

线程上下文类加载器的原理是 将一个 类加载器 保存在线程私有数据里，跟线程绑定，然后在需要的时候取出来使用

JDBC案例：

JDBC中使用了DriverManager来管理项目中引入的不同数据库的驱动，比如mysql驱动

DriverManager类 位于rt.jar包中，由 启动类加载器 加载。

依赖中的 mysql驱动 对应的类，由 应用程序类加载器 来加载。

DriverManager 怎么知道jar包中要加载的驱动在哪儿？

        使用SPI机制

1. 在这个位置下存放了一个文件，文件名是接口名（java.sql.Driver），文件里包含了实现类的类名（com.mysql.cj.jdbc.Driver）。这样SPI机制就可以找到实现类了        
2. 在初始化Driver时，调用 ServiceLoader.load 方法，去加载所有jar包中Driver接口的实现类
3. 获取应用程序类加载器：

        利用线程上下文类加载器（线程创建完成后，线程上下文类加载器 就是 应用程序类加载器）去加载类并创建对象

        

总结：

⑤ JDK9之后的类加载器

由于JDK9引入了 module 的概念，类加载器在设计上发生了很多变化。

1. 启动类加载器

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

2. 扩展类加载器 被替换成了 平台类加载器（Platform Class Loader）。

• 平台类加载器遵循 模块化 方式加载字节码文件，所以继承关系从URLClassLoader变成了BuiltinClassLoader，BuiltinClassLoader实现了从模块中加载字节码文件
• 平台类加载器的存在更多的是为了与老版本的设计方案兼容，自身没有特殊的逻辑。

5. 运行时数据区域

Java虚拟机在运行Java程序过程中管理的内存区域，称之为运行时数据区。

① 程序计数器

程序计数器（Program Counter Register）也叫PC寄存器，每个线程会通过程序计数器记录当前要执行的的字节码指令的地址。

• 控制解释器解释执行字节码指令的顺序
• 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而使线程切换后能恢复到正确的执行位置

程序计数器会出现内存溢出吗？

每个线程只存储一个固定长度的内存地址，所以程序计数器是不会发生内存溢出的。程序员无需对程序计数器做任何处理。 

② 虚拟机栈

概述 

        Java虚拟机栈（Stack）采用 栈 的数据结构来管理方法调用中的基本数据，先进后出，每一个方法的调用使用一个栈帧（Stack Frame）来保存 

        Java虚拟机栈随着线程的创建而创建，而回收则会在线程的销毁时进行

        栈帧中主要包含：

• 局部变量表，局部变量表的作用是 在运行过程中 存放所有的局部变量

• 操作数栈，操作数栈是栈帧中虚拟机在执行指令过程中用来存放临时数据的一块区域

• 帧数据，帧数据主要包含动态链接、方法出口、异常表的引用

局部变量表

• 局部变量表的作用：在方法执行过程中存放所有的局部变量。
• 局部变量表分为两种：一种是字节码文件中的，另外一种是栈帧中的，也就是保存在内存中。栈帧中的局部变量表是根据字节码文件中的内容生成的。
• 局部变量表保存的内容有：实例方法的this对象，方法的参数，方法体中声明的局部变量。

字节码文件中的局部变量表：控制变量能访问的指令范围

栈帧中的局部变量表：栈帧中的局部变量表是一个数组，数组中每一个位置称之为槽(slot) ，long和double类型占用两个槽，其他类型占用一个槽。

非静态方法：运行时会在内存中存放实例对象的地址，实例方法中的序号为0的位置存放的是this，指的是当前调用方法的对象。

方法参数：也会保存在局部变量表中，其顺序与方法中参数定义的顺序一致。

为了节省空间，局部变量表中的槽是可以复用的，一旦某个局部变量不再生效，当前槽就可以再次被使用。

操作数栈

操作数栈是 栈帧中虚拟机在执行指令过程中用来 存放中间数据 的一块区域。他是一种栈式的数据结构，如果一条指令将一个值压入操作数栈，则后面的指令可以弹出并使用该值。

在编译期就可以确定操作数栈的最大深度，从而在执行时正确的分配内存大小。

帧数据

帧数据主要包含动态链接、方法出口、异常表的引用。

动态链接：

当前类的字节码指令引用了其他类的属性或者方法时，需要将 符号引用（编号）转换成对应的 运行时常量池 中的内存地址。动态链接就保存了编号到运行时常量池的内存地址的映射关系。

方法出口

方法出口指的是方法在正确或者异常结束时，当前栈帧（sleep）会被弹出，同时程序计数器应该指向上一个栈帧中（study）下一条指令的地址。所以在当前栈帧中，需要存储此方法出口的地址。

异常表

异常表存放的是代码中异常的处理信息，包含了异常捕获的生效范围以及异常发生后跳转到的字节码指令位置。

astore 会将 捕获到的异常对象的引用 存放到 局部变量表 的1号位置

内存溢出

Java虚拟机栈如果栈帧过多，占用内存超过栈内存可以分配的最大大小就会出现内存溢出。Java虚拟机栈内存溢出时会出现 StackOverflowError 的错误。

如果不指定栈的大小，JVM 将创建一个具有 默认大小 的栈，取决于操作系统和计算机的体系结构

要修改Java虚拟机栈的大小，可以使用虚拟机参数 -Xss ：

• 语法：-Xss栈大小

• 单位：字节（默认，必须是 1024 的倍数）、k或者K(KB)、m或者M(MB)、g或者G(GB)

• -Xss1024K

1、与-Xss类似，也可以使用 -XX:ThreadStackSize 调整标志来配置堆栈大小。

格式为： -XX:ThreadStackSize=1024

2、HotSpot JVM对栈大小的 最大值 和 最小值 有要求：

      比如测试如下参数，会直接报错：-Xss1k

      Windows（64位）下的JDK8测试最小值为180k，最大值为1024m。

3、局部变量过多、操作数栈深度过大也会影响栈内存的大小。

③本地方法栈

Java虚拟机栈存储了Java方法调用时的栈帧，而本地方法栈存储的是 native本地方法 的栈帧。

在Hotspot虚拟机中，Java虚拟机栈和本地方法栈实现上使用了同一个栈空间。本地方法栈会在栈内存上生成一个栈帧，临时保存方法的参数同时方便出现异常时也把本地方法的栈信息打印出来。

④ 堆内存

• 一般Java程序中 堆内存 是空间最大的一块内存区域。
• 创建出来的对象都存在于堆上。栈上的局部变量表中，可以存放堆上对象的引用。
• 静态变量也可以存放堆对象的引用，通过静态变量就可以实现对象在线程之间共享。

堆用来存放几乎所有的对象实例

几乎：如果没有逃逸，那么会在栈上分配内存

堆内存大小是有上限的，达到上限之后，就会抛出OutOfMemory错误

堆空间有三个需要关注的值，used、total、max。

used 指的是当前已使用的堆内存，total 是java虚拟机已经分配的可用堆内存，max 是java虚拟机可以分配的最大堆内存。

随着堆中的对象增多，当total可以使用的内存即将不足时，java虚拟机会继续分配内存给堆

当used达到了total的大小，Java虚拟机会向操作系统申请更大的内存。

但是这个申请过程不是无限的，total最多只能与max相等。

要修改堆的大小，可以使用虚拟机参数-Xmx（max最大值）和 -Xms (初始的total)。

• 语法：-Xmx值 -Xms值
• 单位：字节（默认，必须是 1024 的倍数）、k或者K(KB)、m或者M(MB)、g或者G(GB)
• 限制：Xmx必须大于 2 MB，Xms必须大于1MB

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

⑤ 方法区

方法区是存放基础信息的位置，线程共享，是一个逻辑区域（表现为永久代和元空间），主要包含：

• 类的元信息，保存了所有类的基本信息

• 运行时常量池，保存了字节码文件中的常量池内容，只保存了引用

类的元信息

方法区是用来存储每个 类的基本信息（元信息），一般称之为InstanceKlass对象。在类的加载阶段完成。其中就包含了类的字段、方法等字节码文件中的内容，同时还保存了运行过程中需要使用的虚方法表（实现多态的基础）等信息。

真正的JVM在底层实现上，会把常量池和方法抽出来，单独分配一块区域存放，InstanceKlass对象仅仅保存他们的引用

运行时常量池

• 运行时常量池中存放的是字节码中的常量池内容。
• 字节码文件中通过编号查表的方式找到常量，这种常量池称为静态常量池。
• 当常量池加载到内存中之后，可以通过 内存地址 快速的定位到常量池中的内容，这种常量池称为运行时常量池。

方法区的实现

• 每款Java虚拟机在实现上都各不相同。Hotspot设计如下：
• JDK7及之前的版本将方法区存放在 堆区域中的永久代空间，堆的大小由虚拟机参数               -XX:MaxPermSize=值 来控制。
• JDK8及之后的版本将方法区存放在 元空间 中，元空间位于操作系统维护的直接内存中，默认情况下只要不超过操作系统承受的上限，可以一直分配。（独立于JVM外）。可以使用           -XX:MaxMetaspaceSize=值 将元空间最大大小进行限制。

⑥ 字符串常量池

字符串常量池存储在代码中定义的常量字符串内容

字符串拼接

字符串变量拼接 底层使用了 StringBuilder 的append和toString

字符串常量拼接 直接在 字符串常量池 中获取

intern

String.intern()方法是可以手动将字符串放入字符串常量池中，分别在JDK6 JDK8下执行代码，JDK6 中结果是false false ，JDK8中是true false

public class Demo4 {
    public static void main(String[] args) {
        String s1 = new StringBuilder().append("think").append("123").toString();
        System.out.println(s1.intern() == s1); // 6 false  8 true

        String s2 = new StringBuilder().append("ja").append("va").toString();
        System.out.println(s2.intern() == s2); // false
    }
}

JDK6 

JDK7及之后

JVM加载时会使用到java字符串，所以先保存在了字符串常量池中

JDK7及之后 字符串常量池位于堆中，所以intern直接保存堆上对象的引用，而不是保存内容，节省空间

静态变量存放在哪

• JDK6及之前的版本中，静态变量是存放在方法区中的，也就是永久代。

• JDK7及之后的版本中，静态变量是存放在堆中的Class对象中，脱离了永久代。

直接内存

直接内存（Direct Memory）不在《Java虚拟机规范》中存在，所以不属于Java运行时的内存区域

在 JDK 1.4 中引入了 NIO 机制，使用了直接内存，主要为了解决以下两个问题:

1、Java堆中的对象如果不再使用要回收，回收时会影响对象的创建和使用。

2、IO操作比如读文件，需要先把文件读入内存（缓冲区）再把数据复制到Java堆中。

     现在直接放入直接内存即可，同时Java堆上维护直接内存的引用，减少了数据复制的开销。写文件也是类似的思路。

传统方式

使用直接内存

        如果需要手动调整直接内存的大小，可以使用 XX:MaxDirectMemorySize=大小

        单位k或K表示千字节，m或M表示兆字节，g或G表示千兆字节。

        默认不设置该参数情况下，JVM 自动选择 最大分配的大小。

6. 垃圾回收器GC

概述

内存泄漏指的是不再使用的对象在系统中未被回收，内存泄漏的积累可能会导致内存溢出。

• 自动垃圾回收：自动根据对象是否使用由虚拟机来回收对象

  • 优点：降低程序员实现难度、降低对象回收bug的可能性

  • 缺点：程序员无法控制内存回收的及时性

• 手动垃圾回收：由程序员编程实现对象的删除

  • 优点：回收及时性高，由程序员把控回收的时机

  • 缺点：编写不当容易出现悬空指针、重复释放、内存泄漏等问题

垃圾回收器需要负责对哪些部分的内存进行回收？

线程不共享的部分，都是伴随着线程的创建而创建，线程的销毁而销毁。方法的栈帧在执行完方法之后就会自动弹出栈并释放掉对应的内存。所以这一部分不需要垃圾回收器负责回收

① 方法区的回收

方法区中能回收的内容主要就是不再使用的类

判定一个类可以被卸载。需要同时满足下面三个条件：

1. 此类所有实例对象都已经被回收，在堆中不存在任何该类的实例对象以及子类对象。
2. 加载该类的 类加载器 已经被回收。
3. 该类对应的 java.lang.Class 对象 没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

如果需要手动触发垃圾回收，可以调用System.gc()方法。

语法： System.gc()

注意事项：

调用System.gc()方法并不一定会立即回收垃圾，仅仅是向Java虚拟机发送一个垃圾回收的请求，具体是否需要执行垃圾回收Java虚拟机会自行判断。

 ② 堆回收时机

判断对象是否可以回收，主要有两种方式：引用计数法和可达性分析法。

引用计数法

引用计数法会为每个对象维护一个引用计数器，当对象被引用时加1，取消引用时减1。

引用计数法的优点是实现简单，但是它也存在缺点，主要有两点：

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

可达性分析法

Java使用的是可达性分析算法来判断对象是否可以被回收

可达性分析将对象分为两类：垃圾回收的根对象（GC Root）和普通对象，对象与对象之间存在引用关系

如果当一个对象到 GC Roots 没有任何引用链相连的话，对象就需要被回收

GC Root对象：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象

• 类静态属性引用的对象：类的静态变量引用的对象，例如静态变量、常量等。

• 方法区中的常量引用的对象：在类的常量池中定义的常量引用的对象，例如字符串常量、基本类型的常量等。

• 本地方法栈中JNI（Java Native Interface）引用的对象：JNI是Java调用本地方法的接口，本地方法可能引用Java堆中的对象。

③ 常见的引用对象

软引用

概述

• 软引用相对于强引用是一种比较弱的引用关系
• 如果一个对象只有软引用关联到它，当程序内存不足时，就会将软引用中的数据进行回收。
• 在JDK 1.2版之后提供了SoftReference类来实现软引用，软引用常用于缓存中。

好处：如果对象A是一个缓存，平时会保存在内存中，如果想访问数据可以快速访问。但是如果内存不够用了，我们就可以将这部分缓存清理掉释放内存。即便缓存没了，也可以从数据库等地方获取数据，不会影响到业务正常运行，这样可以减少内存溢出产生的可能性。

软引用对象本身，也需要被强引用，否则软引用对象也会被回收掉

软引用的执行过程

1.将对象使用软引用包装起来，new SoftReference<对象类型>(对象)

2.内存不足时，虚拟机尝试进行垃圾回收

3.如果垃圾回收仍不能解决内存不足的问题，回收软引用中的对象

4.如果依然内存不足，抛出OutOfMemory异常

软引用对象本身回收

如果软引用对象里边包含的数据已经被回收了，那么软引用对象本身其实也可以被回收了

SoftReference提供了一套队列机制：

1、软引用创建时，通过构造器传入引用队列

2、在软引用中包含的对象被回收时，该软引用对象会被放入引用队列

3、通过代码遍历引用队列，将SoftReference的强引用删除

为什么软引用对象不直接=null而是要放到队列？

因为软引用中的对象不是立即被回收的，而是在内存不足时回收，因此不能在其使用完毕后立刻回收掉其外部的软引用对象

弱引用

弱引用的整体机制和软引用基本一致，区别在于弱引用包含的对象在垃圾回收时，不管内存够不够都会直接被回收。在JDK 1.2版之后提供了WeakReference类来实现弱引用，弱引用主要在ThreadLocal中使用。

弱引用对象本身也可以使用引用队列进行回收。

虚引用

• 虚引用也叫幽灵引用/幻影引用，不能通过虚引用对象获取到包含的对象。
• 虚引用唯一的用途是当对象被垃圾回收器回收时可以接收到对应的通知。
• Java中使用PhantomReference实现了虚引用，直接内存中为了及时知道直接内存对象不再使用，从而回收内存，使用了虚引用来实现。

任何时候都可能被回收，相当于没有引用一样。不对生存造成任何影响，用于跟踪GC的回收通知

虚引用：该对象在回收前和回收后都 无法通过虚引用获取到，在该对象被回收掉时会将对象部分信息存储到虚引用回收队列中，仅仅是拿到一个对象被回收掉的通知

弱引用：在该对象被回收前 可以通过弱引用获取到，回收后无法获取到这个对象，在该对象被回收掉时会将对象部分信息存储到弱引用回收队列中，可以拿到一个对象被回收掉的通知

终结器引用

终结器引用指的是在对象需要被回收时，终结器引用会关联对象并放置在Finalizer类中的引用队列中，在稍后由一条由FinalizerThread线程从队列中获取对象，然后执行对象的 finalize方法，在对象第二次被回收时，该对象才真正的被回收。在这个过程中可以在finalize方法中再将自身对象使用强引用关联上，但是不建议这样做。

④ 垃圾回收算法

垃圾回收算法的评价标准

Java垃圾回收过程会通过单独的GC线程来完成，但是不管使用哪一种GC算法，都会有部分阶段需要停止所有的用户线程。这个过程被称之为Stop The World简称STW，如果STW时间过长则会影响用户的使用。

所以判断GC算法是否优秀，可以从三个方面来考虑：

1.吞吐量

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

2.最大暂停时间

最大暂停时间指的是所有在垃圾回收过程中的STW时间最大值。比如如下的图中，黄色部分的STW就是最大暂停时间，显而易见上面的图比下面的图拥有更少的最大暂停时间。最大暂停时间越短，用户使用系统时受到的影响就越短。

3.堆使用效率

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

上述三种评价标准：堆使用效率、吞吐量，以及最大暂停时间不可兼得

一般来说，堆内存越大，最大暂停时间就越长。想要减少最大暂停时间，就会降低吞吐量。

标记清除算法

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

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

优点：

实现简单，只需要在第一阶段给每个对象维护标志位，第二阶段删除对象即可。

缺点：

1.碎片化问题

        由于内存是连续的，所以在对象被删除之后，内存中会出现很多细小的可用内存单元。如果我们需要的是一个比较大的空间，很有可能这些内存单元的大小过小无法进行分配。

        如下图，红色部分已经被清理掉了，总共回收了9个字节，但是每个都是一个小碎片，无法为5个字节的对象分配空间。

2.分配速度慢

        由于内存碎片的存在，我们需要用一个空闲链表来维护，哪些空间可以分配对象，很有可能需要遍历这个链表到最后，才能发现这块空间足够我们去创建一个对象。

        如下图，遍历到最后才发现有足够的空间分配3个字节的对象了。如果链表很长，遍历也会花费较长的时间

复制算法

复制算法的核心思想：

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

优点：

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

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

缺点：        

        可用内存变小：内存使用效率低，每次只能让一半的内存空间来为创建对象使用。

标记整理算法

也叫标记压缩算法

核心思想分为两个阶段：

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

优点：

• 内存使用效率高，整个堆内存都可以使用，不会像复制算法只能使用半个堆内存

• 不会发生碎片化，在整理阶段可以将对象往内存的一侧进行移动，剩下的空间都是可以分配对象的有效空间

缺点：

        整理阶段的效率不高，整理算法有很多种，比如Lisp2整理算法需要对整个堆中的对象搜索3次，整体性能不佳。可以通过Two-Finger、表格算法、ImmixGC等高效的整理算法优化此阶段的性能。

分代垃圾回收算法

新生代-复制算法：

每次垃圾收集都能发现大批对象已死, 只有少量存活. 因此选用复制算法, 只需要付出少量 存活对象的复制成本就可以完成收集

老年代-标记整理算法：

因为对象存活率高、没有额外空间对它进行分配担保, 就必须采用“标记—清理”或“标记—整理”算法来进行回收, 不必进行内存复制, 且直接腾出空闲内存

分代垃圾回收将整个内存区域划分为年轻代和老年代：

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

2、随着对象在Eden区越来越多，如果Eden区满，新创建的对象已经无法放入，就会触发年轻代的GC，称为Minor GC或者Young GC（复制算法）

Minor GC会把需要eden中和From需要回收的对象回收，把没有回收的对象放入To区

3、接下来，S0会变成To区，S1变成From区。当eden区满时再往里放入对象，依然会发生Minor GC

此时会回收eden区和S1(from)中的对象，并把eden和from区中剩余的对象放入S0。

注意：每次Minor GC中都会为对象记录他的年龄，初始值为0，每次GC完加1。

4、如果Minor GC后对象的年龄达到阈值（最大15，默认值和垃圾回收器有关），对象就会被晋升至老年代（如果年轻代放不下了，那么不到阈值的对象也可能被放到老年代）

5、当老年代中空间不足，无法放入新的对象时，先尝试minor gc。如果还是不足，就会触发Full GC，Full GC会对整个堆进行垃圾回收。

如果Full GC依然无法回收掉老年代的对象，那么当对象继续放入老年代时，就会抛出Out Of Memory异常

⑤ 垃圾回收器

堆内存中对象的特性：

• 系统中的大部分对象，都是创建出来之后很快就不再使用可以被回收，比如用户获取订单数据，订单数据返回给用户之后就可以释放了。

• 老年代中会存放长期存活的对象，比如Spring的大部分bean对象，在程序启动之后就不会被回收了。

• 在虚拟机的默认设置中，新生代大小要 远小于 老年代的大小。

分代GC算法将堆分成年轻代和老年代主要原因有：

1、可以通过调整年轻代和老年代的比例来适应不同类型的应用程序，提高内存的利用率和性能。

2、新生代和老年代使用不同的垃圾回收算法，新生代一般选择复制算法，老年代可以选择标记-清除和标记-整理算法，由程序员来选择灵活度较高。

3、分代的设计中允许只回收新生代（minor gc），如果能满足对象分配的要求就不需要对整个堆进行回收(full gc)，STW时间就会减少。

垃圾回收器

年轻代-Serial

Serial是一种 单线程串行 回收年轻代的垃圾回收器。

回收年代和算法：

年轻代、复制算法

优点

单CPU处理器下吞吐量非常出色

缺点

多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待

适用场景

Java编写的客户端程序或者硬件配置有限的场景

老年代-SerialOld

SerialOld是Serial垃圾回收器的老年代版本，采用单线程串行回收

-XX:+UseSerialGC 新生代、老年代都使用串行回收器。

回收年代和算法：

老年代、标记-整理算法

优点

单CPU处理器下吞吐量非常出色

缺点

多CPU下吞吐量不如其他垃圾回收器，堆如果偏大会让用户线程处于长时间的等待

适用场景

与Serial垃圾回收器搭配使用，或者在CMS特殊情况下使用

年轻代-ParNew

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

-XX:+UseParNewGC 新生代使用ParNew回收器， 老年代使用串行回收器

回收年代和算法：

年轻代、复制算法

优点

多CPU处理器下停顿时间较短

缺点

吞吐量和停顿时间不如G1，所以在JDK9之后不建议使用

适用场景

JDK8及之前的版本中，与CMS老年代垃圾回收器搭配使用

老年代- CMS

CMS(Concurrent Mark Sweep)垃圾回收器关注的是系统的暂停时间，允许用户线程和垃圾回收线程在某些步骤中同时执行，减少了用户线程的等待时间。

参数：XX:+UseConcMarkSweepGC

CMS执行步骤：

1. 初始标记，用极短的时间标记出GC Roots能直接关联到的对象。

2. 并发标记，标记所有的对象，用户线程不需要暂停。

3. 重新标记，由于并发标记阶段有些对象会发生了变化，存在错标、漏标等情况，需要重新标记。

4. 并发清理，清理死亡的对象，用户线程不需要暂停。

回收年代和算法：

老年代、标记清除算法

优点

系统由于垃圾回收出现的停顿时间较短，用户体验好

缺点

1. CMS使用了标记-清除算法，在垃圾收集结束之后会出现大量的内存碎片，CMS会在Full GC时进行碎片的整理。这样会导致用户线程暂停，可以使用-XX:CMSFullGCsBeforeCompaction=N 参数（默认0）调整N次Full GC之后再整理。
2. CMS的并发能力比较依赖于CPU资源，并发回收时垃圾收集线程可能会抢占用户线程的资源，导致用户程序性能下降。
3. 无法处理在并发清理过程中产生的“浮动垃圾”，不能做到完全的垃圾回收。
4. 如果老年代内存不足无法分配对象，CMS就会退化成Serial Old单线程回收老年代。

适用场景

大型的互联网系统中用户请求数据量大、频率高的场景，比如订单接口、商品接口等

年轻代-Parallel Scavenge

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

回收年代和算法：

年轻代、复制算法

优点

吞吐量高，而且手动可控。为了提高吞吐量，虚拟机会动态调整堆的参数

缺点

不能保证单次的停顿时间

适用场景 

后台任务，不需要与用户交互，且容易产生大量的对象。比如：大数据的处理，大文件导出

常用参数：

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

• 最大暂停时间，-XX:MaxGCPauseMillis=n 设置每次垃圾回收时的最大停顿毫秒数

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

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

老年代-Parallel Old

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

参数： -XX:+UseParallelGC 或

-XX:+UseParallelOldGC可以使用Parallel Scavenge + Parallel Old这种组合。

回收年代和算法：

老年代、标记-整理算法

优点

并发收集，在多核CPU下效率较高

缺点

暂停时间会比较长

适用场景

与Parallel Scavenge配套使用

G1垃圾回收器

JDK9之后默认的垃圾回收器是G1（Garbage First）垃圾回收器。Parallel Scavenge关注吞吐量，允许用户设置最大暂停时间 ，但是会减少年轻代可用空间的大小。CMS关注暂停时间，但是吞吐量方面会下降。

优点

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

1.支持巨大的堆空间回收，并有较高的吞吐量。

2.支持多CPU并行垃圾回收。

3.允许用户设置最大暂停时间。

关于吞吐量和暂停时间：吞吐量与暂停时间

JDK9之后强烈建议使用G1垃圾回收器。

结构

G1出现之前的垃圾回收器，年轻代和老年代一般是连续的，如下图：

G1的整个堆会被划分成多个大小相等的区域，称之为区Region，区域不要求是连续的。分为Eden、Survivor、Old区。

通过引入 Region 的概念，从而将原来的一整块内存空间划分成多个的小空间，使得每个小空间可以单独进行垃圾回收

Region的大小通过堆空间大小/2048计算得到，也可以通过参数-XX:G1HeapRegionSize=32m指定(其中32m指定region大小为32M)，Region size必须是2的指数幂，取值范围从1M到32M。

方式

1、年轻代回收（Young GC）

2、混合回收（Mixed GC）

年轻代回收

Young GC，回收 Eden区和Survivor区 中不用的对象。会导致STW。

G1中可以通过参数 -XX:MaxGCPauseMillis=n（默认200） 设置每次垃圾回收时的最大暂停时间毫秒数，G1垃圾回收器会尽可能地保证暂停时间。

1、新创建的对象会存放在Eden区。当G1判断年轻代区不足（max默认60%），无法分配对象时需要回收时会执行Young GC。

2、标记出 Eden 和 Survivor 区域中的存活对象，

3、根据配置的最大暂停时间选择某些区域将存活对象复制到一个新的Survivor区中（年龄+1），清空这些区域。

        

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

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

4、后续Young GC时与之前相同，只不过Survivor区中存活对象会被搬运到另一个Survivor区。

5、当某个存活对象的年龄到达阈值（默认15），将被放入老年代。

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

7、多次回收之后，会出现很多Old老年代区，此时总堆占有率达到阈值时

（-XX:InitiatingHeapOccupancyPercent默认45%）会触发混合回收MixedGC。回收所有年轻代和部分老年代的对象以及大对象区。采用复制算法来完成。

混合回收

混合回收分为：初始标记（initial mark）、并发标记（concurrent mark）、最终标记（remark或者Finalize Marking）、并发清理（cleanup）

最终标记阶段跟CMS不同

G1对老年代的清理会选择 存活度最低（区域内存活对象最少） 的区域来进行回收，这样可以保证回收效率最高，这也是G1（Garbage first）名称的由来。最后清理阶段使用复制算法，不会产生内存碎片。

注意：如果清理过程中发现没有足够的空Region存放转移的对象，会出现Full GC。单线程执行标记-整理算法，此时会导致用户线程的暂停。所以尽量保证应该用的堆内存有一定多余的空间。

G1 – Garbage First 垃圾回收器

参数1： -XX:+UseG1GC 打开G1的开关，JDK9之后默认不需要打开

参数2：-XX:MaxGCPauseMillis=毫秒值 最大暂停的时

回收年代和算法：

年轻代+老年代、复制算法

优点

• 对比较大的堆如超过6G的堆回收时，延迟可控
• 不会产生内存碎片
• 并发标记的SATB算法效率高

缺点

JDK8之前还不够成熟

适用场景

JDK8最新版本、JDK9之后建议默认使用