JVM杂记

于 2021-04-17 20:56:47 发布
阅读量441 收藏
点赞数
分类专栏： Study合集 文章标签： jvm
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/A13777852949/article/details/115801339
版权

JVM概述

  • 整体结构

整体结构

  • Java代码执行流程

代码执行流程

JVM生命周期

虚拟机的启动

  • Java虚拟机的启动是通过引导类加载器(bootstrap class loader)创建一个初始类(initial class)来完成的，这个类是由虚拟机的具体实现指定的。
虚拟机的执行
  • 一个运行中的Java虚拟机有一个清晰的任务：执行Java程序
  • 程序开始执行它才运行，程序结束它就停止
  • 执行一个所谓的Java程序时，真正执行的是一个叫做Java虚拟机的进程

虚拟机的退出

有如下几种情况：

  • 程序正常执行结束
  • 程序在执行过程中遇到异常或错误而异常终止
  • 由于操作系统出现错误而导致Java虚拟机进程终止
  • 某线程调用Runtime类或System类的exit方法，或Runtime类的halt方法，并且Java安全管理器也允许这次exit或halt操作
  • 除此之外，JNI(Java Native Interface)规范描述了用JNI Invocation API来加载或卸载Java虚拟机时，Java虚拟机的退出情况

JVM发展历程

  • Sun 的 Sun Classic VM

    • 1996年，Sun公司发布，JDK1.4时完全被淘汰
    • 世界上第一款商业Java虚拟机，只提供解释器

  • Sun 的 Exact VM

    • jdk1.2时，由Sun公司提供。
    • Exact Memory Management：准确式内存管理。也可以叫Non-Conservative/Accurate Memory Management
    • 具备线代高性能虚拟机的雏形：热点探测、编译器与解释器混合工作模式
    • 只在Solaris平台短暂使用

  • Sun 的 HotSpot VM

    • 最初由一家名为"Longview Technologies"的小公司设计；1997年，此公司被Sun公司收购；2009年，Sun公司被Oracle公司收购。JDK1.3时，HotSpot VM成为默认虚拟机
    • Oracle JDK 和 OpenJDK的默认虚拟机
    • 名称中的HotSpot指的就是它的热点代码探测技术
      • 通过计数器找到最具编译价值的代码，触发即使编译或栈上替换
      • 通过编译器与解释器协同工作，在最优化程序响应时间与最佳执行性能中取得平衡

  • BEA 的 JRockit

    • 它可以不太关注程序启动速度，因此JRockit内部不包含解释器实现，全部代码都靠即时编译器编译后执行
    • 大量行业基准测试显示，JRockit JVM是世界上最快的JVM
    • 2008年，BEA被Oracle收购
    • Oracle表达了整合优秀虚拟机的工作，大致在JDK 8中完成。整合的方式是在HotSpot的基础上，移植JRockit的优秀特征

  • IBM 的 J9

    • 全称：IBM Technology for Java Virtual Machine，简称IT4J，内部代号J9
    • 广泛用于IBM的各种Java产品。目前，有影响力的三大商业虚拟机之一，也号称是世界上最快的Java虚拟机
    • 2017左右，IBM发布了开源J9 VM，命名为OpenJ9，交给Eclipse基金会管理，也称为Eclipse OpenJ9

  • KVM和CDC/CLDC HotSpot

    • Oracle在Java ME产品线上的两款虚拟机：CDC/CLDC HotSpot Implementation VM
    • KVM(Kilobyte)是CLDC-HI早期产品

  • Azul VM

    • 前面三大"高性能Java虚拟机"使用在通用硬件平台上。这里的Azul VM和BEA Liquid VM是与特定硬件平台绑定、软硬件配合的专有虚拟机，高性能java虚拟机中的战斗机！！！
    • Azul VM是Azul Systems公司在HotSpot基础上进行大量改进，运行于Azul Systems公司的专有硬件Vega系统上的Java虚拟机

  • Liquid VM

    • 高性能Java虚拟机中的战斗机。BEA公司开发的，直接运行在自家Hypervisor系统上
    • Liquid VM即是现在的JRockit VE(Virtual Edition)。随着JRockit虚拟机终止开发，Liquid VM项目也停止了

  • Apache harmony

    • Apache也曾经推出过与JDK1.5和JDK1.6兼容的Java运行平台Apache Harmony
    • 它是IBM和Intel联合开发的开源JVM，受到同样开源的OpenJDK的压制，Sun公司坚决不让Harmony获得JCP认证，最终于2011年退役，IBM转而参与OpenJDK

  • Microsoft JVM

    • 微软为了在IE3浏览器中支持Java Applets，开发了Microisoft JVM
    • 只能在windows平台下运行，但却是当下Windows下性能最好的Java VM
    • 1997年，Sun公司以侵犯商标、不正当竞争罪名指控微软成功，赔了Sun很多钱。
    • 微软在WindowsXP SP3中抹掉了其VM。现在Windows上安装的JDK都是HotSpot

  • Taobao JVM

    • 由AliJVM团队开发。
    • 基于OpenJDK HotSpot VM发布的国内第一个优化、深度定制且开源的高性能服务器版Java虚拟机
    • taobao vm应用在阿里产品上性能高，硬件严重依赖intel的CPU，损失了兼容性，但提高了性能
      • 目前已经在淘宝、天猫上线，把Oracle官方JVM版本全部替换了

  • Dalvik VM

    • 谷歌开发的，应用于Android系统，并在Android2.2中提供了JIT，发展迅猛。
    • Dalvik VM只能称作虚拟机，而不能称作"Java虚拟机"，它没有遵循Java虚拟机规范
    • 不能直接执行Java的Class文件。基于寄存器架构，不是JVM的栈架构
    • 执行的是编译以后的dex(Dalvik Executable)文件。执行效率比较高
      • 它执行的dex(Dalvik Executable)文件可以通过Class文件转化而来，使用Java语法编写应用程序，可以直接使用大部分的Java API等
    • Android5.0使用支持提前编译(Ahead Of Time Compilation,AOPT)的ART VM替换Dalvik VM

  • Graal VM

    • 2018年4月，Oracle Labs公开了Graal VM，号称"Run Programs Anywhere"
    • Graal VM在HotSpot VM基础上增强而成的跨语言全栈虚拟机，可以作为"任何语言"的运行平台使用。包括：Java、Scala、Groovy、Kotlin；C、C++、JavaScript、Ruby、Python、R等
    • 支持不同语言中混用对方的接口和对象，支持这些语言使用已经编写好的本地库文件
    • 如果有一天HotSpot被取代，那么Graal VM希望最大。

类加载子系统

类加载过程

类加载过程

类加载过程

加载

  • 通过一个类的全限定名获取定义此类的二进制字节流
  • 将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构
  • 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

链接

  • 验证(Verify):

    • 目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全
    • 主要包含四种验证：文件格式验证，元数据验证，字节码验证，符号引用验证。

  • 准备(Prepare)

    • 为类变量分配内存并设置该类变量的默认初始值，即零值
    • 这里不包含final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化
    • 这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量会随着对象一起分配到Java堆中

  • 解析(Resolve)

    • 将常量池内的符号引用转换为直接引用的过程
    • 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
    • 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《Java虚拟机》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄
    • 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型的那个。对应常量池中的CONSTANT_CLASS_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等

初始化

  • 初始化阶段就是执行类构造器方法<clinit>()的过程
  • 此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并起来
    • 即类中的显示初始化static的属性赋值和static静态代码块组成了<clinit()>()方法；若类中都没有这两种之一的代码，则JVM中没有此方法执行。
  • 构造器方法中指令按语句在源文件中出现的顺序执行
  • <clinit>()不同于类的构造器。（关联：构造器是虚拟机视角下的<init>()）
  • 若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕
  • 虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

针对上述第三条执行顺序的代码演示

/**
 * 这样写竟然也行？？？原因是因为static{}初始化number已经初始化为0
 * 此后再进行，先用20覆盖0，再用10覆盖20，最后输出结果为10
 */
public class Test2 {

    static {
        number = 20;
    }

    private static int number = 10;

    public static void main(String[] args) {
        System.out.println(Test2.number);
    }
}

类加载器的分类

  • JVM支持两种类型的类加载器
    • 引导类加载器(Bootstrap ClassLoader)
    • 自定义类加载器(User-Defined ClassLoader)
  • 从概念上讲，自定义类加载器一般指的是程序中由开发人员自定义的一类 类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生与抽象类ClassLoader的类加载器都划分为自定义类加载器
  • 无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个。其中只有引导类加载器(Bootstrap ClassLoader)非Java语言实现的，其它都是Java语言编写

类加载器分类

引导类加载器(Bootstrap ClassLoader)

  • 也叫作启动类加载器，这个类加载器使用C/C++语言实现的，嵌套在JVM内部。

  • 它用来加载Java的核心库(JAVA_HOME/jre/lib/rt.jar、resource.jar或sun.boot.class.path路径下的内容)，用于提供JVM自身需要的类

  • 并不继承自java.lang.ClassLoader，没有父加载器。加载扩展类和应用程序类加载器，并指定为它们的父类加载器

  • 处于安全考虑，BootStrap启动类加载器只加载包名为java、javax、sun等开头的类

扩展类加载器(Extension ClassLoader)

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

应用程序类加载器(AppClassLoader)

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

用户自定义类加载器

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

ClassLoader

public abstract class ClassLoader
extends Object
  • ClassLoader是一个抽象类，类加载器是负责加载类的对象。每个类对象包含reference来定义它的ClassLoader。
  • 获取类加载器的方法
    • 获取当前类的ClassLoader：class.getClassLoader()
    • 获取当前线程的上下文的ClassLoader：Thread.currentThread().getContextClassLoader()
    • 获取系统的ClassLoader：ClassLoader.getSystemClassLoader()
    • 获取调用者的ClassLoader：DriverManager.getCallerClassLoader()
package com.reflect.jvm;

import java.sql.DriverManager;

/**
 * @author: reflect0714
 * @date: 2/4/2021 - 12:49 PM
 * @project: JavaSEDemo
 * @since: JDK1.8
 * @description: 获取ClassLoader的测试
 */
public class ClassLoaderDemo {
    public static void main(String[] args) {
        // - 获取当前类的ClassLoader：class.getClassLoader()
        try {
            ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
            System.out.println(classLoader);

            // - 获取当前线程的上下文的ClassLoader：Thread.currentThread().getContextClassLoader()
            ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
            System.out.println(contextClassLoader);

            // - 获取系统的ClassLoader：ClassLoader.getSystemClassLoader()
            ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
            ClassLoader parent = systemClassLoader.getParent();
            System.out.println(systemClassLoader);
            System.out.println(parent);

        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

// 结果
null
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@5e481248

双亲委派机制

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

工作原理

双亲委派机制工作原理

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

优点

  • 避免类的重复加载
  • 保护程序安全，防止核心API被随意篡改
    • 自定义类：java.lang.String 出现找不到main方法错误
    • 自定义类：java.lang.Reflect java.lang.SecurityException: Prohibited package name: java.lang

沙箱安全机制

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

其他

  • 在JVM中表示两个Class对象是否为同一个类存在两个必要条件：
    • 类的完整类名必须一致，包括包名
    • 加载这个类的ClassLoader(值ClassLoader实例对象)必须相同
  • 换句话说，在JVM中，即使这两个类对象(Class对象)来源于同一个Class文件，被同一个虚拟机加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的。

对类加载器的引用

JVM必须知道一个类型是由引导类加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的。

类的主动使用和被动使用

Java程序对类的使用方式分为：主动使用和被动使用。

  • 主动使用，又分为七种情况
    • 创建类的实例
    • 访问某个类的接口的静态变量，或者对该静态变量赋值
    • 调用类的静态方法
    • 反射(比如：Class.forName(“com.reflect.Test”))
    • 初始化一个类的子类
    • Java虚拟机启动时被标明为启动类的类
    • JDK7开始提供的动态语言支持：
      • java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化
  • 除了以上七种情况，其它使用Java类的方式都被看作是对类的被动使用，都不会导致类的初始化。

Java内存区域

Java内存区域

  • 灰色的为线程私有，红色的为多个线程共享

    • 每个线程独立的：程序计数器、栈、本地方法栈
    • 线程之间共享的：堆、堆外内存（永久代或元空间、代码缓存）

  • 每个Java应用程序都有一个Runtime类的实例，即单例的，对应着上图的运行时数据区

  • 运行的主要后台系统线程在HotSpot JVM中主要有以下几个

    • 虚拟机线程：这种线程的操作时xuyaoJVM达到安全点才会出现。这种线程的执行类型包括STW的垃圾收集，线程栈收集，线程挂起以及偏向锁撤销。
    • 周期任务线程：这种线程是时间周期事件的体现（比如中断），它们一般用于周期性操作的调度执行
    • GC线程：这种线程对JVM里不同种类的垃圾收集行为提供了支持
    • 编译线程：这种线程在运行时会将字节码编译成本地代码
    • 信号调度线程：这种线程接收信号并发送给JVM，在它内部通过调用适当的方法进行处理

程序计数器（PC Register）

  • 也叫作PC计数器、PC寄存器。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟。

  • 作用：PC寄存器用来存储指向下一条指令的地址，也即将要执行的指令代码。由执行引擎读取下一条指令。

  • 它是一块很小的内存空间，几乎可以忽略不计，也是运行速度最快的存储区域。

  • 在JVM规范中，每个线程都有自己的程序计数器，是线程私有的，生命周期与线程的生命周期保持一致。

  • 任何时间一个线程都只有一个方法在执行，也就是当前方法。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址；或者如果是在执行native方法，则是未指定值（undefined）

  • 它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

  • 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。

  • 它是唯一 一个在Java虚拟机规范中没有规定任何 OutOfMemoryError情况的区域。

两个常见问题

  • 使用PC寄存器存储字节码指令地址有什么用？为什么使用PC寄存器记录当前线程的执行地址呢？
    • 因为CPU需要不停的切换各个线程，这时候切换回来以后，就得知道接着从哪开始继续执行。JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令。
  • PC寄存器为什么会被设为线程私有？
    • 我们都知道所谓的多线程在一个特定的时间段内只会执行其中某一个线程的方法，CPU会不停地做仼务切换，这样必然导致经常中断或恢复，如何保证分毫无差呢？为了能够准确地记录各个线程正在执行的当前字节码指令地址，最好的办法自然是为每一个线程都分配一个pc寄存器，这样一来各个线程之间便可以进行独立计算，从而不会出现相互干扰的情况。
    • 由于CPU时间片轮限制，众多线程在并发执行过程中，任何一个确定的时刻，一个处理器或者多核处理器中的一个内核，只会执行某个线程中的一条指令。
    • 这样必然导致经常中断或恢复，如何保证分毫无差呢？每个线程在创建后，都会产生自己的程序计数器和栈帧，程序计数器在各个线程之间互不影响。
  • CPU时间片
    • CPU时间片即CPU分配给各个程序的时间，每个线程被分配一个时间段，称作它的时间片。
    • 在宏观上：我们可以同时打开多个应用程序，每个程序并行不悖，同时运行
    • 但在微观上：由于只有一个CPU，一次只能处理程序要求的一部分，如何处理公平，一种方法就是引入时间片，每个程序轮流执行。

虚拟机栈

  • 栈是运行时的单位，而堆是存储的单位。

    • 即：栈解决程序的运行问题，即程序如何执行，或者说如何处理数据。
    • 堆解决的是数据存储的问题，即数据怎么放、放在哪儿。

  • Java虚拟机栈是什么？

    • Java虚拟机栈（Java Virtual Machine Stack），早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧
      （ Stack frame）——栈帧对应着一次次的Java方法调用。
    • 是线程私有的，生命周期和线程一致
    • 作用：主管Java程序的运行，它保存方法的局部变量（8种基本数据类型和对象的引用地址）、部分结果，并参与方法的调用和返回。

  • 特点

    • 栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器。
    • JVM直接对Java栈的操作只有两个：
      • 每个方法执行，伴随着进栈（入栈、压栈）
      • 执行结束后的出栈工作
    • 对于栈来说不存在垃圾回收问题

  • 栈中可能出现的异常

    • 如果使用固定大小的Java虚拟机栈，那么每个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量，JVM将会抛出StackOverflowError异常
    • 如果Java虚拟机栈可以动态扩展，并且在尝试扩展的时候无法中请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，JVM将会抛出一个OutOfMemoryError异常。

  • 设置栈内存大小：使用参数-Xss设置线程的最大栈空间。

栈帧

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

栈运行原理

  • JVM直接对Java栈的操作只有两个，就是对栈帧的压栈和出栈，遵循“先进后出”/“后进先出”原则。

  • 在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为当前栈帧
    （Current Frame），与当前栈帧相对应的方法就是当前方法（Current Method），定义这个方法的类就是当前类（Current Class）。

  • 执行引擎运行的所有字节码指令只针对当前栈帧进行操作

  • 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，成为新的当前栈帧。

  • 不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧之中引用另外一个线程的栈帧。

  • 如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着，虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧。

  • Java方法有两种返回函数的方式，一种是正常的函数返回，使用 return指令；另外一种是抛出异常。不管使用哪种方式，都会导致栈帧被弹出。

栈帧的内部结构

每个栈帧中存储着：

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

  • 局部变量表也被称之为局部变量数组或本地变量表

  • 定义为一个数字数组，主要用于存储方法参数和定义在方法体内的局部变量，这些数据类型包括8种基本数据类型、对象引用（ reference），以及returnAddress类型。

  • 由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题

  • 局部变量表所需的容量大小是在编译期确定下来的，并保存在方法的Code属性的msximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。

  • 方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少。

  • 局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁。

Slot

  • 参数值的存放总是在局部变量数组的 index0开始，到数组长度-1的索引结束。

  • 局部变量表最基本的存储单元是Slot（变量槽）

  • 局部变量表中存放编译期可知的各种基本数据类型（8种），引用类型（ reference），returnAddress类型的变量。

  • 在局部变量表里，32位以内的类型只占用一个slot（包括returnAddress类型），64位的类型（long和 double）占用两个slot。

    • byte、 short、char在存储前被转换为int，boolean也被转换为int，0表示false，非0表示true。
    • long和 double则占据两个Slot

  • JVM会为局部变量表中的每一个slot都分配一个访问索引，通过这个素引即可成功访问到局部变量表中指定的局部变量值

  • 当一个实例方法被调用的时候，它的方法参数和方法体内部定义的局部变量将会按照顺序被复制到局部变量表中的每一个slot

  • 如果需要访问局部变量表中一个64bit的局部变量值时，只需要使用前一个索引即可。（比如：访问long或double类型变量）

  • 如果当前帧是由构造方法或者实例方法创建的，那么该对象引用this将会存放在index为0的slot处，其余的参数按照参数表顺序继续排列。

Slot的重复利用

  • 栈帧中的局部变量表中的槽位是可以重用的，如果一个局部变量过了其作用域，那么在其作用域之后申明的新的局部变量就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。
静态变量与局部变量的对比
  • 参数表分配完毕之后，再根据方法体内定义的变量的顺序和作用域分配。
  • 我们知道类变量表有两次初始化的机会，第一次是在“准备阶段”，执行系统初始化，对类变量设置零值，另一次则是在“初始化”阶段，赋予程序员在代码中定义的初始值。
  • 和类变量初始化不同的是，局部变量表不存在系统初始化的过程，这意味着一旦定义了局部变量则必须人为的初始化，否则无法使用。

成员变量：在使用前，都经历过默认初始化赋值

​ 类变量：linking的prepare阶段：给类变量默认赋值 — > initial阶段：给类变量显示赋值，即静态代码块赋值

​ 实例变量：随着对象的创建，会在堆空间中分配实例变量空间，并进行默认赋值

局部变量：在使用前，必须进行显式赋值！否则编译不通过。

  • 在栈帧中，与性能调优关系最为密切的部分就是前面提到的局部变量表。在方法执行时，虚拟机使用局部变量表完成方法的传递。
  • 局部变量表中的变量也是重要的垃圾回收根节点，只要被局部变量表中直接或间接引用的对象都不会被回收。
操作数栈（Operand Stack）

  • 每一个独立的栈帧中除了包含局部变量表以外，还包含一个后进先出（Last-In- First-Out）的操作数栈，也可以称之为表达式栈（ Expression Stack）

  • 操作数栈，在方法执行过程中，根据字节码指令，往栈中写入数据或提取数据，即入栈（push）/出栈（pop）

    • 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈
    • 比如：执行复制、交换、求和等操作

  • 如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令。

  • 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译器期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。

  • 另外，我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈。

  • 操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间。

  • 操作数栈就是JVM执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，这个方法的操作数栈是空的。

  • 每一个操作散栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译就定义好了，保存在方法的Code属性中，为 max_stack的值

  • 栈中的任何一个元素都是可以任意的Java数据类型。

    • 32bit的类型占用一个栈单位深度
    • 64bit的类型占用两个栈单位深度

  • 操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈（push）和出栈（pop）操作来完成一次数据访问。

栈顶缓存技术（Top-of-Stack Cashing）

  • 前而提过，基于栈式架构的虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然需要使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派（ instruction dispatch）次数和内存读/写次数。
  • 由于操作数是存储在内存中的，因此频繁地执行内存读/写操作必然会影响执行速度。为了解决这个问题， Hotspot JVM的设计者们提出了栈顶缓存（ToS,Top-of- Stack Cashing）技术，将栈顶元素全部缓存在物理CPU的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率。
动态链接（Dynamic Linking）

方法返回地址、动态链接、一些附加信息也被称为帧数据区。

  • 动态链接也叫作指向运行时常量池的方法引用。

  • 每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了攴持当前方法的代码能够实现动态链接
    （ Dynamic Linking）。比如：invokedynamic指令

  • 在Java源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在class文件的常量池里。
    比如：描述一个方法调用了另外的其他方法时，就是通过常量池中指向方法的符号引用来表示的，那么动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用。

  • 为什么需要常量池呢？

    • 常量池的作用，就是为了提供一些符号和常量，便于指令的识别。
方法的调用

  • 在JVM中，将符号引用转换为调用方法的直接引用与方法的绑定机制相关。
    静态链接：

    • 当一个字节码文件被裝载进JVM内部时，如果被调用的目标方法在编译期可知且运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接。

    动态链接：

    • 如果被调用的方法在编译期无法被确定下来，也就是说，只能够在程序运行期将调用方法的符号引用转换为直接引用，由于这种引用转换过程具备动态性，因此也就被称之为动态链接。

  • 对应的方法的绑定机制为：早期绑定（Early Binding）和晚期绑定（Late Binding）。绑定是一个字段、方法或者类在符号引用被替换为直接引用的过程，这仅仅发生一次。
    早期绑定：

    • 早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用。

    晚期绑定：

    • 如果被调用的方法在编译期无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式也就被称之为晚期绑定。

  • Java中任何一个普通的方法其实都具备虚函数的特征，它们相当于c++语言中的虚函数（C++中则需要使用关键字 virtual来显式定义）。如果在Java程序中不希望某个方法拥有虛函数的特征时，则可以使用关键字final来标记这个方法。

虚方法与非虚方法

非虚方法：

  • 如果方法在编译期就确定了具体的调用版木，这个版本在运行时是不可变的。这样的方法称为非虚方法。
  • 静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法。
  • 其他方法称为虚方法

虚拟机中提供了以下几条方法调用指令

  • 普通调用指令

    • invokestatic：调用静态方法，解析阶段确定唯一方法版本

    • invokespecial：调用<init>方法、私有及父类方法，解析阶段确定唯一方法版本

    • invokevirtual：调用所有虚方法

    • invokeinterface：调用接口方法

  • 动态调用指令

    • invokedynamic：动态解析出需要调用的方法，然后执行

前四条指令固化在虚拟机内部，方法的调用执行不可人为干预，而 invokedynamic指令则支持由用户确定方法版本。其中 invokestatic指令和 invokespecial指令调用的方法称为非虚方法，其余的（final修饰的除外）称为虚方法。

关于invokedynamic指令
  • JVM字节码指令集一直比较稳定，一直到Java7中才增加invokedynamic指令，这是Java为了实现【动态类型语言】支持而做的一种改进。
  • 但是在Java7中并没有提供直接生成 invokedynamic指令的方法，需要借助ASM这种底层字节码工具来产生 invokedynamic指令。直到Java8的 Lambda表达式的出现， invokedynamic指令的生成，在Java中才有了直接的生成方式。
  • Java7中增加的动态语言类型支持的本质是对Java虚拟机规范的修改，而不是对Java语言规则的修改，这一块相对来讲比较复杂，增加了虚拟机中的方法调用，最直接的受益者就是运行在Java平台的动态语言的编译器。

动态类型语言和静态类型语言

  • 动态类型语言和静态类型语言两者的区别就在于对类型的检查是在编译期还是在运行期，满足前者就是静态类型语言，反之是动态类型语言。
  • 说的再直白一点就是，静态类型语言是判断变量自身的类型信息；动态类型语言是判断变量值的类型信息，变量没有类型信息，变量值才有类型信息这是动态语言的一个重要特征。
方法重写的本质

Java语言中方法重写的本质：

  • 1.找到操作数栈顶的第一个元素所执行的对象的实际类型，记作C
  • 2.如果在类型C中找到与常量中的描述符合简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回java.lang.IllegalAccessError异常。
  • 3.否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程。
  • 4.如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。

IlegalAccessError介绍：

  • 程序试图访问或修改一个属性或调用一个方法，这个属性或方法，你没有权限访问。一般的，这个会引起编译器异常。这个错误如果发生在运行时，就说明一个类发生了不兼容的改变。
虚方法表
  • 在面向对象的编程中，会很频繁的使用到动态分派，如果在每次动态分派的过程中都要重新在类的方法元数据中搜索合适的目标的话就可能影响到执行效率。因此，为了提高性能，JVM采用在类的方法区建立一个虚方法表**（virtual method table）（非虚方法不会出现在表中）来实现。使用索引表来代替查找**。
  • 每个类中都有一个虚方法表，表中存放着各个方法的实际入口。
  • 那么虚方法表什么时候被创建？
    • 虚方法表会在类加载的链接阶段被创建并开始初始化，类的变量初始值准备完成之后，JW会把该类的方法表也初始化完毕
方法返回地址（Return Address）

  • 存放调用该方法的pc寄存器的值

  • 一个方法的结束，有两种方式：

    • 正常执行完成
    • 出现未处理的异常，非正常退出

  • 无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。方法正常退出时，调用者的pc计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。而通过异常退出的，返回地址是要通过异常表来确定，栈帧中一般不会保存这部分信息

  • 本质上，方法的退出就是当前栈帧出栈的过程。此时，需要恢复上层方法的局部变量表、操作数栈、将返回值压入调用者栈帧的操作数栈、设置PC寄存器值等，让调用者方法继续执行下去。

  • 正常完成出口和异常完成出口的区别在于：通过异常完成出口退出的不会给它的上层调用者产生任何的返回值。

  • 当一个方法开始执行后，只有两种方式可以退出这个方法：

    • 执行引擎遇到任意一个方法返回的字节码指令（ return），会有返回值传递给上层的方法调用者，简称正常完成出口
      • 一个方法在正常调用完成之后究竟需要使用哪一个返回指令还需要根据方法返回值的实际数据类型而定
      • 在字节码指令中，返回指令包含 ireturn（当返回值是 boolean、byte、char、 short和int类型时使用）、lreturn、 freturn、dreturn以及 areturn，另外还有一个return指令供声明为void的方法、实例初始化方法、类和接口的初始化方法使用。
    • 在方法执行的过程中遇到了异常（ Exception），并且这个异常没有在方法内进行处理，也就是只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出。简称异常完成出口。
      • 方法执行过程中抛出异常时的异常处理，存储在一个异常处理表，方便在发生异常的时候找到处理异常的代码。
一些附加信息
  • 栈帧中还允许携带与Java虚拟机实现相关的一些附加信息。例如，对程序调试提供支持的信息。

相关面试题

  • 举例栈溢出的情况？
    • 这里指的是StackOverflowError
    • 通过-Xss设置栈的大小，当栈已满则出现溢出StackOverFlowError
    • 通过自动扩容栈时，无法继续扩容，则出现OutOfMemoryError
  • 调整栈大小，就能保证不出现溢出吗？
    • 不能！调整栈的大小只能让StackOverFlow出现的时间变晚，不能确保一定不溢出
  • 分配的栈内存越大越好吗？
    • 不是！
  • 垃圾回收是否会涉及到虚拟机栈？
    • 不会！
    • 程序计数器不存在Error，也不存在GC
    • 虚拟机栈存在Error，不存在GC
    • 本地方法栈不存在Error，也不存在GC
    • 堆既存在Error，也存在GC
    • 方法区既存在Error，也存在GC
  • 方法中定义的局部变量是否线程安全？
    • 具体问题具体分析
    • 如果方法中定义的局部变量在方法内消亡的，就是线程安全
    • 如果返回出去或者接收外界的数据，则是线程不安全的

本地方法接口

  • 什么是本地方法？

    • 简单地讲，一个Native Method就是一个Java调用非Java代码的接口。一个Native Method是这样一个Java方法：该方法的实现由非Java语言实现，比如C。这个特征并非Java所特有，很多其它的编程语言都有这一机制，比如在C++中可以用 extern "C"告知C++编译器去调用一个C的函数。
    • “A native method is a Java method whose implementation is provided by non-java code.”
    • 在定义一个native method时，并不提供实现体（有些像定义一个Java interface），因为其实现体是由非java语言在外面实现的。
    • 本地接的作用是融合不同的编程语言为Java所用，它的初衷是融合c/c++程序

  • 标识符native可以与所有其它的Java标识符连用，但是 abstract除外。

  • 为什么要使用Native Method？

    • Java使用起来非常方便，然而有些层次的任务用Java实现起来不容易，或者我们对程序的效率很在意时，问题就来了。

      与Java环境外交互：

      • **有时Java应用需要与Java外面的环境交互，这是本地方法存在的主要原因。**你可以想想Java需要与一些底层系统，如操作系统或某些硬件交换信息时的凊况。本地方法正是这样一种交流机制：它为我们提供了一个非常简洁的接口，而且我们无需去了解Java应用之外的繁琐的细节。

    • 与操作系统交互

      • JVM支持着Java语言本身和运行时库，它是Java程序赖以生存的平台，它由一个解释器（解释字节码）和一些连接到本地代码的库组成。然而不管怎样，它毕竟不是一个完整的系统，它经常依赖于一些底层系统的支持。这些底层系统常常是强大的操作系统。通过使用本地方法，我们得以用Java实现了jre的与底层系统的交互，甚至JvM的一些部分就是用c写的。还有，如果我们要使用一些Java语言本身没有提供封装的操作系统的特性时，我们也需要使用本地方法

    • Sun’s Java

      • Sun的解释器是用C实现的，这使得它能像一些普通的C一样与外部交互。jre大部分是用Java实现的，它也通过一些本地方法与外界交互。例如：类java.lang.Thread的 setPriority（方法是用Java实现的，但是它实现调用的是该类里的本地方法setPriority0( )。这个本地方法是用C实现的，并被植入JVM内部，在 Windows95的平台上，这个本地方法最终将调用Win32 Setpriority( ) API。这是一个本地方法的具体实现由JWM直接提供，更多的情况是本地方法由外部的动态链接库（external dynamic link library）提供，然后被JVM调用。

  • 现状

    • 目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用 Socket通信，也可以使用 Web service等等，不多做介绍。

本地方法栈

  • Java虚拟机找用于管理Java方法的调用，而本地方法栈用于管理本地方法的调用。

  • 本地方法栈，也是线程私有的

  • 允许被实现成固定或者是可动态扩展的内存大小。（在内存溢出方面是相同的）

    • 如果线程请求分配的栈容量超过本地方法栈允许的最大容量，Java虚拟机将会抛出一个StackOverFlowError异常。
    • 如果本地方法栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的本地方法栈，那么Java虚拟机将会抛出一个OutOfMemoryError异常。

  • 本地方法是使用C语言实现的。

  • 它的具体做法是 Native Method Stack中登记native方法，在Execution Engine执行时加载本地方法库。

  • 当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限。

    • 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区。
    • 它甚至可以直接使用本地处理器中的寄存器
    • 直接从本地内存的堆中分配任意数量的内存。

  • 并不是所有的JVM都支持本地方法。因为Java虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果JVM产品不打算支持 native方法，也可以无需实现本地方法栈。

  • 在 HotSpot JVM中，直接将本地方法栈和虚拟机栈合二为一。

堆

  • 一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。

  • Java堆区在JVM启动的时候即被创建，其空间大小也就确定了。是JVM管理的最大一块内存空间。

    • 堆内存的大小是可以调节的。

  • 《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。

  • 所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区（Thread Local Allocation Buffer, TLAB）

  • 《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated）

    • 准确来说的是：“几乎”所有的对象实例都在这里分配内存。一从实际使用角度看的。

  • 数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。

  • 在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除。

  • 堆，是GC（Garbage Collection，垃圾收集器）执行垃圾回收的重点区域。

内存细分

  • 现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为：
    • Java7及之前堆内存逻辑上分为三部分：新生区+养老区+永久区
      • Young Generation Space：新生区 Young/New
        • 又被划分为Eden区和 Survivor区
      • Tenure generation Space：养老区 Old/Tenure
      • Permanent Space：永久区 Perm
    • Java8及之后堆内存逻辑上分为三部分：新生区+养老区+元空间
      • Young Generation Space：新生区 Young/New
        • 又被划分为Eden区和 Survivor区
      • Tenure generation Space：养老区 Old/Tenure
      • Meta Space：元空间 Meta
    • 新生区 = 新生代 = 年轻代
    • 养老区 = 老年区 = 老年代
    • 永久区 = 永久代

堆空间大小设置

  • Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，以通过选项”-Xmx和”-Xms"来进行设置
    • "-Xms"用于表示堆区的起始内存，等价于-XX:InitialHeapSize
    • "-Xmx"用于表示堆区的最大内存，等价于-XX:MaxHeapsize
  • 一旦堆区中的内存大小超过“-Xmx"所指定的最大内存时，将会抛出OutofMemoryError异常。
  • 通常会将-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能
  • 默认情况下
    • 初始内存大小：物理电脑内存大小 / 64
    • 最大内存大小：物理电脑内存大小 / 4

年轻代与老年代

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

堆分代

  • 配置新生代与老年代在堆结构的占比

    • 默认-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3
    • 可以修改-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5

  • 在 HotSpot中，Eden空间和另外两个Survivor空间缺省所占的比例是8:1:1

  • 也可以通过选项“-XX:SurvivoRatio”调整这个空间比例。比如-XX:SurvivorRatio=8

  • 几乎所有的Java对象都是在Eden区被new出来的

  • 绝大部分的Java对象的销毁都在新生代进行了

    • IBM公司的专门研究表明，新生代中80%的对象都是“朝生夕死”的。

  • 可以使用选项"-Xmn"设置新生代最大内存大小

    • 这个参数一般使用默认值就可以了

对象分配过程

为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。

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

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

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

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

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

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

    • 可以设置参数：-XX:MaxTenuringThresho1d=<N>进行设置

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

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

总结：

  • 针对幸存者s0,s1区的总结：复制之后有交换，谁空谁是to
  • 关于垃圾回收：频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集

Minor GC、Major GC、Full GC

  • 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）：收集整个新生代以及部分老年代的垃圾收集。
        • 目前，只有G1GC会有这种行为
    • 整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集

  • 年轻代GC（Minor GC）触发机制：

    • 当年轻代空间不足时，就会触发 Minor GC，这里的年轻代满指的是Eden代满， Survivor满不会引发GC。（每次 Minor GC会清理年轻代的内存。）
    • 因为Java对象大多都具备朝生夕灭的特性，所以 Minor GC非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。
    • Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行

  • 老年代GC（ Major GC/Full GC）触发机制

    • 指发生在老年代的GC，对象从老年代消失时，我们说“Major GC"或"Full GC"发生了。
    • 出现了 Major GC，经常会伴随至少一次的 Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行 Major GC的策略选择过程）
      • 也就是在老年代空间不足时，会先尝试触发 Minor GC。如果之后空间还不足，则触发 Mayor GC
    • Major GC的速度一般会比 Minor GC慢1倍以上，STW的时间更长。
    • 如果 Major GC后，内存还不足，就报OOM了。
    • Major GC的速度一般会比 Minor GC慢10倍以上。

  • Full GC触发机制：（后面细讲）
    触发Full GC执行的情况有如下五种
    （1）调用 System.gc()时，系统建议执行Full GC，但是不必然执行
    （2）老年代空间不足
    （3）方法区空间不足
    （4）通过 Minor GC后进入老年代的平均大小大于老年代的可用内存
    （5）由Eden区、 survivor space0（ From Space）区向 survivor space1（To Space）区复制时，对象大小大于 To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小

  • 说明：full gc是开发或调优中尽量要避免的。这样暂时时间会短一些

堆空间分代思想

  • 为什么需要把Java堆分代？不分代就不能正常工作了吗？
    • 经研究，不同对象的生命周期不同。70%-99%的对象是临时对象
      • 新生代：有Eden、两块大小相同的Survivor（又称为from/to，s0/s1）构成， to总为空。
      • 老年代：存放新生代中经历多次GC仍然存活的对象
    • 其实不分代完全可以，分代的唯一理由就是优化GC性能。如果没有分代，那所有的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用这样就会对堆的所有区域进行扫描。而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来

内存分配策略

  • 或称为对象提升（Promotion）规则

  • 如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1.对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，其实每个JVM、每个GC都有所不同）时，就会被晋升到老年代

  • 对象晋升老年代的年龄阈值，可以通过选项-Xx:MaxTenuringThreshold来设置

  • 针对不同年龄段的对象分配原则如下所示：

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

为对象分配内存：TLAB

  • 为什么有TLAB（Thread Local Allocation Buffer）？

    • 堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据
    • 由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的
    • 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度

  • 什么是TLAB？

    • 从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内。
    • 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略
    • 据所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计

  • TLAB再说明

    • 尽管不是所有的对象实例都能够在TLAB中成功分配内存，但JVM确实是将TLAB作为内存分配的首选
    • 可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间
    • 默认情况下，TLAB空间的内存非常小，仅占有整个Eden空间的1%，当然可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB空间所占用Eden空间的百分比大小。
    • 一旦对象在TLAB空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存

  • 对象分配过程：TLAB

    • TLAB

堆空间常用参数

  • -XX:+PrintFlagsInitial：查看所有的参数的默认初始值
  • -XX:+PrintFlagsFinal：査看所有的参数的最终值（可能会存在修改不再是初始值）
  • -Xms：初始堆空间内存（默认为物理内存的1/64）
  • -Xmx：最大堆空间内存（默认为物理内存的1/4）
  • -Xmn：设置新生代的大小。（初始值及最大值）
  • -XX:NewRatio：配置新生代与老年代在堆结构的占比
  • -XX:SurvivorRatio：设置新生代中Eden和S0/S1空间的比例
  • -XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄
  • -XX:+PrintGCDetails：输出详细的GC处理日志
    • 打印gc简要信息：① -XX+ PrintGC② -verbose:gc
  • -XX:HandlePromotionFailure：是否设置空间分配担保

解释说明

  • 在发生 Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。
    • 如果大于，则此次 Minor GC是安全的
    • 如果小于，则虚拟机会查看-XX:HandlePromotionFailure设置值是否允许担保失败
    • 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。
      • 如果大于，则尝试进行一次 Minor GC，但这次Minor GC依然是有风险的
      • 如果小于，则改为进行一次Full GC。
    • 如果 HandlePromotionFailure=false，则改为进行一次Full GC
  • 在JDK6 Update24之后（也可以理解为JDK7），HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略，观察OpenJDK中的源码变化，虽然源码中还定义了HandlePromotionFailure参数，但是在代码中已经不会再使用它。JDK6 Update24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。

堆是分配对象存储的唯一选择嘛？

  • 在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述：随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了

  • 在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过逃逸分析（Escape Analysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。

  • 此外，前面提到的基于 OpenJDK深度定制的 Taobao，其中创新的GCIH（GC invisible heap）技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。

  • 如何将堆上的对象分配到栈，需要使用逃逸分析手段。

  • 这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。

  • 通过逃逸分析，Java HotSpot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

  • 逃逸分析的基本行为就是分析对象动态作用域：

    • 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
    • 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中
    • 没有发生逃逸的对象，则可以分配到栈上，随着方法执行的结束，栈空间就被移除。

  • 参数设置

    • 在JDK6u23（即JDK7）版本之后， HotSpot中默认就已经开启了逃逸分析。
    • 如果使用的是较早的版本，则可以通过：
      • 选项“-XX:+DOEscapeAnalysis"显式开启逃逸分析
      • 通过选项“-XX:+PrintEscapeAnalysis"查看逃逸分析的筛选结果

  • 结论：开发中能使用局部变量的，就不要使用在方法外定义

逃逸分析

使用逃逸分析，编译器可以对代码做如下优化：

  • 栈上分配。将堆分配转化为栈分配。如果一个对象在子程序中被分配要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
  • 同步省略。如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
  • 分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。
代码优化之栈上分配
  • JIT编译器在編译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。
  • 常见的栈上分配的场景
    • 在逃逸分析中，已经说明了。分别是给成员变量赋值、方法返回值、实例引用传递。
代码优化之同步省略（消除）

  • 线程同步的代价是相当高的，同步的后果是降低并发性和性能。

  • 在动态编译同步块的时候，JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。

  • 示例

    • public void f() {
    Object hollis = new Object();
    synchronized(hollis) {
        System.out.println(hollis);
    }
}

    • 代码中对hollis这个对象进行加锁，但是hollis对象的生命周期只在f()方法中，并不会被其他线程所访问到，所以在JIT编译阶段就会被优化掉。优化成：

    • public void f() {
    Object hollis = new Object();
    System.out.println(hollis);
}
代码优化之标量替换

  • **标量（Scalar）**是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。

  • 相对的，那些还可以分解的数据叫做聚合量（Aggregate），Java中的对象就是聚合量，因为它可以分解成其他聚合量和标量。

  • 在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。

  • 示例

    • public static void main(String[] args) {
    alloc();
}
private static void alloc() {
    Point point = new Point();
    System.out.println("point.x=" + point.x + "point.y=" + point.y);
}
class Point{
    private int x;
    private int y;
}

    • 以上代码，经过标量替换后，就会变成：

    • private static void alloc() {
    int x = 1;
    int y = 2;
    System.out.println("point.x=" + x + "point.y=" + y);
}

  • 可以看到，Point这个聚合量经过逃逸分析后，发现它并没有逃逸，就被替换成两个聚合量了。那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。

  • 标量替换为栈上分配提供了很好的基础。

  • 标量替换参数设置

    • 参数-XX:+EliminateAllocations：开启了标量替换（默认打开），允许将对象打散分配在栈上
逃逸分析小结：逃逸分析并不成熟
  • 关于逃逸分析的论文在1999年就已经发表了，但直到DK1.6才有实现，而且这项技术到如今也并不是十分成熟的。
  • 其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。
  • 一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
  • 虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。
  • 注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。Oracle Hotspot JVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。
  • 目前很多书籍还是基于JDK7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。

小结

  • 年轻代是对象的诞生、成长、消亡的区域，一个对象在这里产生、应用，最后被垃圾回收器收集、结束生命。
  • 老年代放置长生命周期的对象，通常都是从Survivor区域筛选拷贝过来的Java对象。当然，也有特殊情况，我们知道普通的对象会被分配在TLAB上；如果对象较大，JM会试图直接分配在Eden其他位置上；如果对象太大完全无法在新生代找到足够长的连续空闲空间，JVM就会直接分配到老年代。
  • 当GC只发生在年轻代中，回收年轻代对象的行为被称为 MinorGC。当GC发生在老年代时则被称为Major GC或者Full GC。一般的，Minor GC的发生频率要比 Major GC高很多，即老年代中垃圾回收发生的频率将大大低于年轻代。

方法区

  • 《Java虚拟机规范》中明确说明：“尽管所有的方法区在逻辑上是属于堆的一部分，但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩”。但对于 HotSpot JVM而言，方法区还有一个别名叫做Non-Heap（非堆），目的就是要和堆分开。

  • 所以，方法区看作是一块独立于Java堆的内存空间。

  • 方法区（Method Area）与Java堆一样，是各个线程共享的内存区域。

  • 方法区在JVM启动的时候被创建，并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的。

  • 方法区的大小，跟堆空间一样，可以选择固定大小或者可扩展

  • 方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区溢出，虚拟机同样会抛出内存溢出错误：java.lang.OutofMemoryError:PermGen space 或者 java.lang.OutofMemoryError:Metaspace

  • 关闭JVM就会释放这个区域的内存

演进

  • 在jdk7及以前，习惯上把方法区，称为永久代。jdk8开始，使用元空间取代了永久代。

  • 本质上，方法区和永久代并不等价。仅是对 hotspot而言的。《Java虚拟机规范》对如何实现方法区，不做统一要求。例如：BEA JRockit / IBMJ9中不存在永久代的概念。

    • 现在来看，当年使用永久代，不是好的idea。导致Java程序更容易OOM（超过-XX:MaxPermsize上限）

  • 而到了JDK8，终于完全废弃了永久代的概念，改用与 JRockit、J9一样在本地内存中实现的元空间（Metaspace）来代替

  • 元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于：元空间不在虚拟机设置的内存中，而是使用本地内存。

  • 永久代、元空间二者并不只是名字变了，内部结构也调整了

  • 根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OOM异常。

设置方法区内存的大小

  • 方法区的大小不必是固定的，JVM可以根据应用的需要动态调整。

  • jdk7及以前：

    • 通过-XX:PermSize来设置永久代初始分配空间。默认值是20.75M
    • -XX:MaxPermsize来设定永久代最大可分配空间。32位机器默认是64M，64位机器模式是82M
    • 当JVM加载的类信息容量超过了这个值，会报异常 OutofMemoryError:PermGen space。

  • jdk8及以后：

    • 元数据区大小可以使用参数-XX:MetaspaceSize和-XX:MaxMetaspaceSize指定替代上述原有的两个参数。
    • 默认值依赖于平台。windows下，-XX:MetaspaceSize是21M，-XX:MaxMetaspacesize的值是-1，即没有限制。
    • 与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。
      如果元数据区发生溢出，虚拟机一样会抛出异常 OutofMemoryError:Metaspace
    • -XX:MetaspaceSize：设置初始的元空间大小。对于一个64位的服务器端JVM来说，其默认的-XX:MetaspaceSize值为21MB。这就是初始的高水位线，一旦触及这个水位线，Full GC将会被触发并卸载没用的类（即这些类对应的类加载器不再存活）
      然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不足，那么在不超过MaxMetaspaceSize时，适当提高该值。如果释放空间过多，则适当降低该值。
    • 如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次。通过垃圾回收器的日志可以观察到FullGC多次调用。为了避免频繁地GC，建议将-XX:MetaspaceSize设置为一个相对较高的值

方法区细解

  • 《深入理解Java虚拟机》书中对方法区（Method Area）存储内容描述如下：它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。
类型信息
  • 对每个加载的类型（类class、接口interface、枚举enum、注解 annotation），JVM必须在方法区中存储以下类型信息：
    ①这个类型的完整有效名称（全名=包名. 类名）
    ②这个类型直接父类的完整有效名（对于interface或是java. lang. Object，都没有父类）
    ③这个类型的修饰符（public, abstract, final的某个子集）
    ④这个类型直接接口的一个有序列表
域（Field）信息
  • JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
  • 域的相关信息包括：域名称、域类型、域修饰符（public, private, protected, static, final, volatile, transient的某个子集）
方法（Method）信息

JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序：

  • 方法名称
  • 方法的返回类型（或 void）
  • 方法参数的数量和类型（按顺序）
  • 方法的修饰符（public, private, protected, static, final, synchronized, native, abstract的一个子集）
  • 方法的字节码（bytecodes）、操作数栈、局部变量表及大小（abstract和native方法除外）
  • 异常表（abstract和native方法除外）
    • 每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
non-final的类变量

  • 静态变量和类关联在一起，随着类的加载而加载，它们成为类数据在逻辑上的一部分。

  • 类变量被类的所有实例共享，即使没有类实例时你也可以访问它。

  • 补充说明：全局常量：static final

    • 被声明为final的类变量的处理方法则不同，每个全局常量在编译的时候就会被分配了。
运行时常量池 VS 常量池
  • 方法区，内部包含了运行时常量池。
  • 字节码文件，内部包含了常量池。
  • 要弄清楚方法区，需要理解清楚 Classfile，因为加载类的信息都在方法区
  • 要弄清楚方法区的运行时常量池，需要理解清楚ClassFile中的常量池。
常量池

  • 一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表（Constant Pool Table），包括各种字面量和对类型、域和方法的符号引用。

  • 为什么需要常量池？

    • 一个java源文件中的类、接口，编译后产生一个字节码文件。而Java中的字节码需要数据支持，通常这种数据会很大以至于不能直接存到字节码里，换另一种方式，可以存到常量池，这个字节码包含了指向常量池的引用。在动态链接的时候会用到运行时常量池，之前有介绍。

  • 常量池中有什么？

    • 几种在常量池内存储的数据类型包括：
      • 数量值
      • 字符串
      • 类引用
      • 字段引用
      • 方法引用

  • 小结：

    • 常量池，可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。
运行时常量池
  • 运行时常量池（Runtime Constant Pool）是方法区的一部分。
  • 常量池表（Constant Pool Table）是class文件的一部分，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
  • 运行时常量池，在加载类和接口到虚拟机后，就会创建对应的运行时常量池
  • JVM为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样是通过索引访问的。
  • 运行时常量池中包含多种不同的常量，包括编译期就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或者字段引用。此时不再是常量池中的符号地址了，这里换为真实地址。
    • 运行时常量池，相对于Class文件常量池的另一重要特征是：具备动态性。
  • 运行时常量池类似于传统编程语言中的符号表（ symbol table），但是它所包含的数据却比符号表要更加丰富一些。
  • 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间超过了方法区所能提供的最大值，则JVM会抛 OutofMemoryError异常。

方法区演进细节

  • 首先明确：只有 Hotspot才有永久代
    • BEA JRockit、IBM J9等来说，是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实现细节，不受《Java虚拟机规范》管束，并不要求统一。
  • Hotspot中方法区的变化：
jdk1.6及之前有永久代（permanent generation），静态变量存放在永久代上
jdk1. 7有永久代，但己经逐步“去永久代”，字符串常量池、静态变量移除，保存在堆中
jdk1.8及之后无永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍在堆

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

    • 随着Java8的到来，Hotspot VM中再也见不到永久代了。但是这并不意味着类的元数据信息也消失了。这些数据被移到了一个与堆不相连的本地内存区域，这个区域叫做元空间（Metaspace）。
    • 由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间
    • 这项改动是很有必要的，原因有：
      • 为永久代设置空间大小是很难确定的
        • 在某些场景下，如果动态加载类过多，容易产生Perm区OOM。比如某个实际Web工程中，因为功能点比较多，在运行过程中，要不断动态加载很多类，经常出现致命错误。
          Exception in thread ‘dubbo client x.x connector’ java. lang. OutOfMemoryError:PermGen
        • 而元空间和永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。
      • 对永久代进行调优是很困难的。

  • String Table为什么要调整？

    • jdk7中将 StringTable放到了堆空间中。因为永久代的回收效率很低，在full gc的时候才会触发。而full gc是老年代的空间不足、永久代不足时才会触发。这就导致 StringTable回收效率不高。而开发中会有大量的字符串被创建，回收效率低，导致永久代内存不足。放到堆里，能及时回收内存

方法区的垃圾收集

  • 有些人认为方法区（如Hotspot虚拟机中的元空间或者永久代）是没有垃圾收集行为的，其实不然。《Java虛拟机规范》对方法区的约束是非常宽松的，提到过可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在（如JDK11时期的ZGC收集器就不支持类卸载）。

  • 一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前Sun公司的Bug列表中，曾出现过的若干个严重的Bug就是由于低版本的 HotSpot虚拟机对此区域未完全回收而导致内存泄漏。

  • 方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。

  • 方法区内常量池之中主要存放的两大类常量：字面量和符号引用

    • 字面量比较接近Java语言层次的常量概念，如文本字符串、被声明为final的常量值等。而符号引用则属于编译原理方面的概念，包括下面三类常量：
      • 1、类和接口的全限定名
      • 2、字段的名称和描述符
      • 3、方法的名称和描述符

  • HotSpot虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。

  • 回收废弃常量与回收Java堆中的对象非常类似

  • 判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：

    • 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例
    • 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
    • 该类对应的java. lang. Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

  • Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收Hotspot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClass-Loading、-XX:+TraceClassUnLoading查看类加载和卸载信息

  • 在大量使用反射、动态代理、 CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常都需要Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压力。

运行时内存常见面试题

  • 百度

    • 三面：说一下JVM内存模型吧，有哪些区？分别干什么的？

  • 蚂蚁金服：

    • Java8的内存分代改进
    • JVM内存分哪几个区，每个区的作用是什么？
    • 一面：JVM内存分布/内存结构？栈和堆的区别？堆的结构？为什么两个survivor区？
    • 二面：Eden和 Survior的比例分配

  • 小米：

    • jvm内存分区，为什么要有新生代和老年代

  • 字节跳动：

    • 二面：Java的内存分区
    • 二面：讲讲jvm运行时数据区
    • 什么时候对象会进入老年代？

  • 京东

    • JVM的内存结构，Eden和 Survivor比例。
    • JVM内存为什么要分成新生代，老年代，持久代。新生代中为什么要分为Eden和 Survivor

  • 天猫

    • 一面：Jvm内存模型以及分区，需要详细到每个区放什么
    • 二面：JVM的内存模型，Java8做了什么修改

  • 拼多多：

    • JVM内存分哪几个区，每个区的作用是什么？

  • 美团：

    • java内存分配
    • jvm的永久代中会发生垃圾回收吗？
    • 一面：jvm内存分区，为什么要有新生代和老年代？

对象实例化

创建对象的方式

  • new：最常见的方式
  • Class的newInstance()：反射的方式，只能调用空参构造，且权限必须是public
  • Constructor的newInstance()：反射的方式，可以调用空参、带参的构造器，权限没有要求
  • 使用clone()：不调用任何构造器，当前类需要实现Cloneable接口，重写clone()方法
  • 使用反序列化：从文件中或网络中读取一个对象的二进制流
  • 使用第三方库，如Objenesis

创建对象的步骤

  • 1、判断对象对应的类是否加载、链接、初始化：虚拟机遇到一条new指令，首先去检查这个指令的参数能否在 Metaspace的常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化。（即判断类元信息是否存在）。如果没有，那么在双亲委派模式下，使用当前类加载器以ClassLoader+包名+类名为Key进行查找对应的 .class文件。如果没有找到文件，则抛出ClassNotFoundException异常，如果找到，则进行类加载并生成对应的Class类对象
  • 2、为对象分配内存：首先计算对象占用空间大小，接着在堆中划分一块内存给新对象。如果实例成员变量是引用变量，仅分配引用变量空间即可，即4个字节大小。
    • 如果内存规整，使用指针碰撞：如果内存是规整的，那么虚拟机将采用的是指针碰撞法（Bump The Pointer）来为对象分配内存。意思是所有用过的内存在一边，空闲的内存在另外一边，中间放着一个指针作为分界点的指示器，分配内存就仅仅是把指针向空闲那边挪动一段与对象大小相等的距离罢了。如果垃圾收集器选择的是 Serial、ParNew这种基于压缩算法的，虚拟机采用这种分配方式般使用带有compact（整理）过程的收集器时，使用指针碰撞
    • 如果内存不规整，虚拟机需要维护一个列表，使用空闲列表分配：如果内存不是规整的，已使用的内存和未使用的内存相互交错，那么虚拟机将采用的是空闲列表法来为对象分配内存。意思是虚拟机维护了一个列表，记录上哪些内存块是可用的，再分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的内容。这种分配方式成为“空闲列表（Free List）
    • 说明：选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。
  • 3、处理并发安全问题：在分配内存空间时，另外一个问题是及时保证new对象时候的线程安全性：创建对象是非常频繁的操作，虚拟机需要解决并发问题。虚拟机采用了两种方式解决并发问题
    • CAS（Compare And Swap）失败重试、区域加锁：保证指针更新操作的原子性；
    • TLAB把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲区，（TLAB, Thread Local Allocation Buffer）虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来设定。
  • 4、初始化分配到的空间：内存分配结束，虛拟机将分配到的内存空间都初始化为零值（不包括对象头）。这一步保证了对象的实例字段在Java代码中可以不用赋初始值就可以直接使用，程序能访问到这些字段的数据类型所对应的零值。
  • 5、设置对象的对象头：将对象的所属类（即类的元数据信息）、对象的 HashCode和对象的GC信息、锁信息等数据存储在对象的对象头中。这个过程的具体设置方式取决于JVM实现
  • 6、执行init方法进行初始化：在Java程序的视角看来，初始化才正式开始。初始化成员变量，执行实例化代码块，调用类的构造方法，并把堆内对象的首地址赋值给引用变量。
    因此一般来说（由字节码中是否跟随有invokespecial指令所决定），new指令之后会接着就是执行方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全创建出来。

对象的内存布局

  • 对象头（Header）
    • 运行时元数据（Mark Word）：哈希值（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳
    • 类型指针：指向类元数据InstanceClass，确定该对象所属的类型
    • 说明：如果是数组，还需要记录数组的长度。
  • 实例数据（Instance Data）
    • 说明：它是对象真正存储的有效信息，包括程序代码中定义的各种类型的字段（包括从父类继承下来的和本身拥有的字段）
    • 规则：
      • 相同宽度的字段总是被分配在一起
      • 父类中定义的变量会出现在子类之前
      • 如果CompactFields参数为true（默认为true）：子类的窄变量可能插入到父类变量的空隙
  • 对齐填充（Padding）：不是必须的，也没有特别含义，仅仅起到占位符的作用。

对象访问定位

  • JVM是如何通过栈帧中的对象引用访问到其内部的对象实例的呢？
    • 定位，通过栈上reference访问
    • 对象访问定位

对象访问方式主要有两种

  • 句柄访问：栈帧中的局部变量表中存在reference指向堆中的句柄池，通过句柄池中到对象实例数据的指针和到对象类型数据的指针分别访问堆中的对象实例数据和方法区中的对象类型数据
    • 好处：reference中存储稳定句柄地址，对象被移动（垃圾收集时移动对象很普遍）时只会改变句柄中实例数据指针即可，reference本身不需要
  • 直接指针（HotSpot采用）：栈帧中的局部变量表中存在reference指向堆中的对象实例数据，通过对象实例数据中的到对象类型数据的指针访问方法区中的对象类型数据

直接内存

  • 不是虚拟机运行时数据区的一部分，也不是《Java虚拟机规范》中定义的内存区域。

  • 直接内存是在Java堆外的、直接向系统申请的内存区间。

  • 来源于NIO，通过存在堆中的DirectByteBuffer操作Native内存

  • 通常，访问直接内存的速度会优于Java堆。即读写性能高。

    • 因此出于性能考虑，读写频繁的场合可能会考虑使用直接内存
    • Java的NIO库允许Java程序使用直接内存，用于数据缓冲区

  • 也可能导致 OutOfMemoryError异常

  • 由于直接内存在Java堆外，因此它的大小不会直接受限于-Xmx指定的最大堆大小，但是系统内存是有限的，Java堆和直接内存的总和依然受限于操作系统能给出的最大内存。

  • 缺点

    • 分配回收成本较高
    • 不受JVM内存回收管理

  • 直接内存大小可以通过 MaxDirectMemorySize设置。如果不指定，默认与堆的最大值-Xmx参数值一致

执行引擎

  • 执行引擎是Java虚拟机核心的组成部分之一

  • “虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。

  • JVM的主要任务是负责装载字节码到其内部，但字节码并不能够直接运行在操作系统之上，因为字节码指令并非等价于本地机器指令，它内部包含的仅仅只是一些能够被JM所识别的字节码指令、符号表，以及其他辅助信息。

  • 那么，如果想要让一个Java程序运行起来，执行引擎（Execution Engine）的任务就是将字节码指令解释/编译为对应平台上的本地机器指令才可以。简单来说，JVM中的执行引擎充当了将高级语言翻译为机器语言的译者。

工作过程

  • 1）执行引擎在执行的过程中究竟需要执行什么样的字节码指令完全依赖于PC寄存器。

  • 2）每当执行完一项指令操作后， PC寄存器就会更新下一条需要被执行的指令地址。

  • 3）当然方法在执行的过程中，执行引擎有可能会通过存储在局部变量表中的对象引用准确定位到存储在Java堆区中的对象实例信息，以及通过对象头中的元数据指针定位到目标对象的类型信息。

  • 从外观上来看，所有的Java虚拟机的执行引擎输入、输出都是一致的：输入的是字节码二进制流，处理过程是字节码解析执行的等效过程，输出的是执行结果。

Java代码编译和执行过程

Java代码编译和执行过程

  • 大部分的程序代码转换成物理机的目标代码或虚拟机能执行的指令集之前，都需要经过上图中的各个步骤
    • 橙色部分是由javac编译器执行的，也称为前端编译。最终遍历抽象语法树，形成线性的字节码指令流。
    • 蓝色部分是直接的编译过程，直到目标机器代码。
    • 绿色部分实际上就是解释执行过程，即逐行解释，翻译执行。
    • 对于Java而言，半编译型是指蓝色部分的过程，半解释型是指绿色部分

问题：什么是解释器（Interpreter），什么是JIT编译器？

  • 解释器：当Java虛拟机启动时会根据预定义的规范对字节码采用逐行解释的方式执行，将每条字节码文件中的内容“翻译”为对应平台的本地机器指令执行。
  • JIT（Just In Time Compiler）编译器：就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言。

问题：为什么说Java是半编译半解释型语言？

  • JDK1.θ时代，将Java语言定位为“解释执行”还是比较准确的。再后来， Java也发展出可以直接生成本地代码的编译器
  • 现在JVM在执行Java代码的时候，通常都会将解释执行与编译执行二者结合起来进行。

机器码、指令、汇编语言

机器码
  • 各种用二进制编码方式表示的指令，叫做机器指令码。开始，人们就用它采编写程序，这就是机器语言。
  • 机器语言虽然能够被计算机理解和接受，但和人们的语言差别太大，不易被人们理解和记忆，并且用它编程容易出差错。
  • 用它编写的程序一经输入计算机，CPU直接读取运行，因此和其他语言编的程序相比，执行速度最快。
  • 机器指令与CPU紧密相关，所以不同种类的CPU所对应的机器指令也就不同。
指令
  • 由于机器码是有0和1组成的二进制序列，可读性实在太差，于是人们发明了指令。
  • 指令就是把机器码中特定的0和1序列，简化成对应的指令（一般为英文简写，如mov, inc等），可读性稍好
  • 由于不同的硬件平台，执行同一个操作，对应的机器码可能不同，所以不同的硬件平台的同一种指令（比如mov），对应的机器码也可能不同。
指令集
  • 不同的硬件平台，各自支持的指令，是有差别的。因此每个平台所支持的指令，称之为对应平台的指令集。
  • 如常见的
    • x86指令集，对应的是x86架构的平台
    • ARM指令集，对应的是ARM架构的平台
汇编语言
  • 由于指令的可读性还是太差，于是人们又发明了汇编语言。
  • 在汇编语言中，用助记符（Mnemonics）代替机器指令的操作码，用地址符号（Symbol）或标号（Label）代替指令或操作数的地址
  • 在不同的硬件平台，汇编语言对应着不同的机器语言指令集，通过汇编过程转换成机器指令。
    • 由于计算机只认识指令码，所以用汇编语言编写的程序还必须翻译成机器指令码，计算机才能识别和执行。
高级语言
  • 为了使计算机用户编程序更容易些，后来就出现了各种高级计算机语言。
    高级语言比机器语言、汇编语言更接近人的语言
  • 当计算机执行高级语言编写的程序时，仍然需要把程序解释和编译成机器的指令码。完成这个过程的程序就叫做解释程序或编译程序。
字节码
  • 字节码是一种中间状态（中间码）的进制代码（文件），它比机器码更抽象，需要直译器转译后才能成为机器码
  • 字节码主要为了实现特定软件运行和软件环境、与硬件环境无关。
  • 字节码的实现方式是通过编译器和虚拟机器。编译器将源码编译成字节码特定平台上的虚拟机器将字节码转译为可以直接执行的指令。

执行过程

执行过程

解释器

  • JVM设计者们的初衷仅仅只是单纯地为了满足Java程序实现跨平台特性，因此避免采用静态编译的方式直接生成本地机器指令，从而诞生了实现解释器在运行时采用逐行解释字节码执行程序的想法。

  • 解释器真正意义上所承担的角色就是一个运行时“翻译者”，将字节码文件中的内容“翻译”为对应平台的本地机器指令执行。

  • 当一条字节码指令被解释执行完成后，接着再根据PC寄存器中记录的下一条需要被执行的字节码指令执行解释操作。

分类
  • 在Java的发展历史里，一共有两套解释执行器，即古老的字节码解释器、现在普遍使用的模板解释器。
    • 字节码解释器在执行时通过纯软件代码模拟字节码的执行，效率非常低下。
    • 而模板解释器将每一条字节码和一个模板函数相关联，模板函数中直接产生这条字节码执行时的机器码，从而很大程度上提高了解释器的性能。
      • 在 Hotspot VM中，解释器主要由Interpreter模块和Code模块构成。
        • Interpreter模块：实现了解释器的核心功能
        • Code模块：用于管理 Hotspot VM在运行时生成的本地机器指令
现状
  • 由于解释器在设计和实现上非常简单，因此除了Java语言之外，还有许多高级语言同样也是基于解释器执行的，比如 Python、Per、Ruby等。但是在今天，基于解释器执行已经沦落为低效的代名词，并且时常被一些C/C++程序员所调侃
  • 为了解决这个问题，JVM平台支持一种叫作即时编译的技术。即时编译的目的是避免函数被解释执行，而是将整个函数体编译成为机器码，每次函数执行时，只执行编译后的机器码即可，这种方式可以使执行效率大幅度提升。
  • 不过无论如何，基于解释器的执行模式仍然为中间语言的发展做出了不可磨灭的贡献。

JIT编译器

  • Java代码的执行分类

    • 第一种是将源代码编译成字节码文件，然后在运行时通过解释器将字节码文件转为机器码执行
    • 第二种是编译执行（直接编译成机器码）。现代虚拟机为了提高执行效率，会使用即时编译技术（JIT, Just In Time）将方法编译成机器码后再执行

  • HotSpot VM是目前市面上高性能虚拟机的代表作之一。它采用解释器与即时编译器并存的架构。在Java虚拟机运行时，解释器和即时编译器能够相互协作，各自取长补短，尽力去选择最合适的方式来权衡编译本地代码的时间和直接解释执行代码的时间。

  • 在今天，Jaa程序的运行性能早已脱胎换骨，已经达到了可以和C/C++程序一较高下的地步。

  • 问题：有些开发人员会感觉到诧异，既然 Hotspot VI中已经内置JIT编译器了，那么为什么还需要再使用解释器来“拖累”程序的执行性能呢？比如 JRockit VM内部就不包含解释器，字节码全部都依靠即时编译器编译后执行。

    • 首先明确：当程序启动后，解释器可以马上发挥作用，省去编译的时间，立即执行。
      编译器要想发挥作用，把代码编译成本地代码，需要一定的执行时间。但编译为本地代码后，执行效率高、

    • 所以尽管JRockit VM中程序的执行性能会非常高效，但程序在启动时必然需要花费更长的时间来进行编译。对于服务端应用来说，启动时间并非是关注重点，但对于那些看中启动时间的应用场景而言，或许就需要采用解释器与即时编译器并存的架构来换取一个平衡点

      在此模式下，当Java虚拟器启动时，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成后再执行，这样可以省去许多不必要的编译时间。随着时间的推移，编译器发挥作用，把越来越多的代码编译成本地代码，获得更高的执行效率。

    • 同时，解释执行在编译器进行激进优化不成立的时候，作为编译器的“逃生门”。

  • HotSpot JVM的执行方式

    • 当虚拟机启动的时候，解释器可以首先发挥作用，而不必等待即时编译器全部编译完成再执行，这样可以省去许多不必要的编译时间。并且随着程序运行时间的推移，即时编译器逐渐发挥作用，根据热点探测功能，将有价值的字节码编译为本地机器指令，以换取更高的程序执行效率。
JIT概念
  • Java语言的“编译期”其实是一段“不确定”的操作过程，因为它可能是指一个前端编译器（其实叫“编译器的前端”更准确一些）把 .java文件转变成 .class文件的过程
  • 也可能是指虚拟机的后端运行期编译器（JIT编译器，Just In Time Compiler）把字节码转变成机器码的过程。
  • 还可能是指使用静态提前编译器（AOT编译器，Ahead Of Time Compiler）直接把 .java文件编译成本地机器代码的过程。
  • 前端编译器：Sun的 Javac、Eclipse JDT中的增量式编译器（ECJ）。
  • JIT编译器：HotSpot VM的C1、C2编译器。
  • AOT编译器：GNU Compiler for the Java（GCJ）、Excelsior JET
热点代码及探测方式

  • 当然是否需要启动JIT编译器将字节码直接编译为对应平台的本地机器指令，则需要根据代码被调用执行的频率而定。关于那些需要被编译为本地代码的字节码，也被称之为“热点代码”，JIT编译器在运行时会针对那些频繁被调用的“热点代码”做出深度优化，将其直接编译为对应平台的本地机器指令，以此提升Java程序的执行性能。

  • 一个被多次调用的方法，或者是一个方法体内部循环次数较多的循环体都可以被称之为“热点代码”，因此都可以通过JIT编译器编译为本地机器指令。由于这种编译方式发生在方法的执行过程中，因此也被称之为栈上替换，或简称为OSR（On Stack Replacement）编译。

  • 一个方法究竟要被调用多少次，或者一个循环体究竟需要执行多少次循环才可以达到这个标准？必然需要一个明确的阈值，JIT编译器才会将这些“热点代码”编译为本地机器指令执行。这里主要依靠热点探测功能。

  • 目前HotSpot VM所采用的热点探测方式是基于计数器的热点探测

  • 采用基于计数器的热点探测，HotSpot VM将会为每一个方法都建立2个不同类型的计数器，分别为方法调用计数器（ Invocation Counter）和回边计数器（Back Edge Counter）

    • 方法调用计数器用于统计方法的调用次数
    • 回边计数器则用于统计循环体执行的循环次数

  • 方法调用计数器

    • 这个计数器就用于统计方法被调用的次数，它的默认阈值在 Client模式下是1500次，在 Server模式下是10000次。超过这个阈值，就会触发JIT编译。
    • 这个阈值可以通过虚拟机参数**-XX:ComplileThreshold**来人为设定。
    • 当一个方法被调用时，会先检査该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值。如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。

  • 热度衰减

    • 如果不做任何设置，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间之内方法被调用的次数。当超过一定的时间限度，如果方法的调用次数仍然不足以让它提交给即时编译器編译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减（Counter Decay），而这段时间就称为此方法统计的半衰周期（ Counter Half Life Time）。
    • 进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX:-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝大部分方法都会被编译成本地代码
    • 另外，可以使用-Xx:CounterHalfLifetime参数设置半衰周期的时间，单位是秒

  • 回边计数器

    • 它的作用是统计一个方法中循环体代码执行的次数，在字节码中遇到控制流向后跳转的指令称为“回边”（Back Edge）。显然，建立回边计数器统计的目的就是为了触发OSR编译。
HotSpot VM设置模式

  • 缺省情况下HotSpot VM是采用解释器与即时编译器并存的架构，当然开发人员可以根据具体的应用场景，通过命令显式地为Java虚拟机指定在运行时到底是完全采用解释器执行，还是完全采用即时编译器执行。如下所示：

    • -Xint：完全采用解释器模式执行程序；
    • -Xcomp：完全采用即时编译器模式执行程序。如果即时编译岀现问题，解释器会介入执行。
    • -Xmixed：采用解释器+即时编译器的混合模式共同执行程序。

  • 在 HotSpot VM中内嵌有两个JIT编译器，分别为Client Compiler和Server Compiler，但大多数情况下我们简称为C1编译器和C2编译器。可以通过如下命令显式指定Java虚拟机在运行时到底使用哪一种即时编译器，如下所示：

    • -client：指定Java虛拟机运行在client模式下，并使用C1编译器
      • C1编译器会对字节码进行简单和可靠的优化，耗时短。以达到更快的编译速度。
    • -server：指定Java虚拟机运行在 Server模式下，并使用C2编译器
      • C2进行耗时较长的优化，以及激进优化。但优化的代码执行效率更高

  • C1和C2编译器不同的优化策略

    • 在不同的编译器上有不同的优化策略，C1编译器上主要有方法内联，去虚拟化、冗余消除。
      • 方法内联：将引用的函数代码编译到引用点处，这样可以减少栈帧的生成，减少参数传递以及跳转过程
      • 去虚拟化：对唯一的实现类进行内联
      • 冗余消除：在运行期间把一些不会执行的代码折叠掉
    • C2的优化主要是在全局层面，逃逸分析是优化的基础。基于逃逸分析在C2上有如下几种优化：
      • 标量替换：用标量值代替聚合对象的属性值
      • 栈上分配：对于未逃逸的对象分配对象在栈而不是堆
      • 同步消除：清除同步操作，通常指synchronized

  • 分层编译（Tiered Compilation）策略：程序解释执行（不开启性能监控）可以触发C1编译，将字节码编译成机器码，可以进行简单优化，也可以加上性能监控，C2编译会根据性能监控信息进行激进优化。

    • 不过在Java7版本之后，一旦开发人员在程序中显式指定命令“- server“时，默认将会开启分层编译策略，由C1编译器和C2编译器相互协作共同来执行编译任务

  • 总结：

    • 一般来讲，JIT编译出来的机器码性能比解释器高。
    • C2编译器启动时长比C1编译器慢，系统稳定执行以后，C2编译器执行速度远远快于C1编译器。
其它相关

  • 自JDK10起， Hotspot又加入一个全新的即时编译器：Graal编译器。

  • 编译效果短短几年时间就追评了C2编译器。未来可期。

  • 目前，带着“实验状态"标签，需要使用开关参数
    -XX:+UnlockExperimentalVMOptions -XX：+UseJVMCICompiler去激活，才可以使用

  • jdk9引入了AOT编译器（静态提前编译器， Ahead Of Time Compiler）

  • Java9引入了实验性AOT编译工具jaotc。它借助了Graal编译器，将所输入的Java类文件转换为机器码，并存放至生成的动态共享库之中。

  • 所谓AOT编译，是与即时编译相对立的一个概念。我们知道，即时编译指的是在程序的运行过程中，将字节码转换为可在硬件上直接运行的机器码，并部署至托管环境中的过程。而AOT编译指的则是，在程序运行之前，便将字节码转换为机器码的过程。

  • 最大好处：Java虚拟机加载已经预编译成二进制库，τ可以直接执行。不必等待即时编译器的预热，减少Java应用给人带来“第一次运行慢”的不良体验。

  • 缺点：

    • 破坏了java”一次编译，到处运行”，必须为每个不同硬件、OS编译对应的发行包。
    • 降低了Java链接过程的动态性，加载的代码在编译期就必须全部已知。
    • 还需要继续优化中，最初只支持 Linux x64 java base

StringTable

String的基本特性

public final class String
extends Object
implements Serializable, Comparable<String>, CharSequence
  • 字符串，使用""引起来表示
  • String声明为final的，不可被继承。
  • String实现了Serializable接口表示字符串是可支持序列化的；实现了Comparable接口表示String是可以比较大小
  • String：代表不可变的字符序列。简称：不可变性。
    • 当对字符串重新赋值时，需要重写指定内存区域赋值，不能使用原有的value进行赋值。
    • 当对现有的字符串进行连接操作时，也需要重新指定内存区域赋值，不能使用原有的value进行赋值。
    • 当调用 string的 replace()方法修改指定字符或字符串时，也需要重新指定内存区域赋值，不能使用原有的 value进行赋值。
  • 通过字面量的方式（区别于new）给一个字符串赋值，此时的字符串值声明在字符串常量池中。

存储结构变更

1.8中String的两个重要属性(JDK1.8及其之前的底层原理字符串方法char[])

  • value：引用或内容
  • hash：内容所对应的哈希码

1.9中String的三个重要属性(JDK1.9及其之后的底层原理字符串方法byte[])

目的为了节约内存，但是也只有当内容全为拉丁字符(英文字母)时才能节省

  • value：引用或内容
  • coder：区分byte[]是否全是英文拉丁字符为0，有Unicode字符时为1。当二者都有时，统一当成Unicode处理
  • hash：内容所对应的哈希码

同理，String相关的类（如StringBuffer和StringBuilder）以及HotSpot内置的String结构也同样作出了相同的修改。

底层原理HashTable

字符串常量池中是不会存储相同内容的字符串的。

  • String的String Pool是一个固定大小的Hashtable，默认值大小长度是1009。字符串对象就是hash表中的key，key的不重复性是hash表的基本特性。
  • 如果放进String Pool的String非常多，就会造成Hash冲突严重，从而导致链表会很长，而链表长了后直接会造成的影响就是当调用String .intern时性能会大幅下降。
  • 使用-XX:StringTableSize可设置StringTable的长度
  • 在jdk6中StringTable是固定的，就是1009的长度，所以如果常量池中的字符串过多就会导致效率下降很快。StringTableSize设置没有要求。
  • 在jdk7中，StringTable的长度默认值是60013，StringTableSize设置没有要求。
  • 在jdk8开始，设置StringTable的长度最小值是1009

String的内存分配

  • 在Java语言中有8种基本数据类型和一种比较特殊的类型 String。这些类型为了使它们在运行过程中速度更快、更节省内存，都提供了一种常量池的概念

  • 常量池就类似一个Java系统级别提供的缓存。8种基本数据类型的常量池都是系统协调的，String类型的常量池比较特殊。它的主要使用方法有两种。

    • 直接使用双引号声明出来的 string对象会直接存储在常量池中。比如：String info = “reflect”；
    • 如果不是用双引号声明的String对象，可以使用String提供的intern()方法。

  • Java6及以前，字符串常量池存放在永久代

  • Java7中对字符串常量池的逻辑做了很大的改变，即将字符串常量池的位置调整到Java堆内。

    • 所有的字符串都保存在堆（Heap）中，和其他普通对象一样，这样可以让你在进行调优应用时仅需要调整堆大小就可以了
    • 字符串常量池概念原本使用得比较多，但是这个改动使得我们有足够的理由让我们重新考虑在Java7中使用 String. intern()。

  • Java8元空间，字符串常量池在堆

  • StringTable为什么要调整？

    • ①PermSize默认比较小，容易发生hash碰撞，性能低
    • ②永久代垃圾回收一般是Full GC，频率较低

字符串拼接

  • 常量与常量的拼接结果在常量池，原理是编译期优化

  • 常量池中不会存在相同内容的常量。

  • 只要其中有一个是变量，结果就在堆中。变量拼接的原理是 StringBuilder

  • 如果拼接的结果调用 intern()方法，则主动将常量池中还没有的字符串对象放入池中，并返回此对象地址。

  • jdk5之后字符串拼接使用StringBuilder，之前使用StringBuffer

intern()的使用

  • 如果不是用双引号声明的String对象，可以使用String提供的 intern方法：intern方法会从字符串常量池中査询当前字符串是否存在，若不存在就会将当前字符串放入常量池中。
  • 也就是说，如果在任意字符串上调用String. intern()方法，那么其返回结果所指向的那个类实例，必须和直接以常量形式出现的字符串实例完全相同。因此，下列表达式的值必定是true：
  • 通俗点讲， Interned String就是确保字符串在内存里只有一份拷贝，这样可以节约内存空间，加快字符串操作任务的执行速度。注意，这个值会被存放在字符串内部池
    （String Intern Pool）。

面试题

  • new String(“ab”)会创建几个对象？
    • 两个，堆中的new String()、常量池中的"ab"
      • 怎么知道的？看字节码。
    • 先在堆中new开辟了一个对象，再将"ab"放入字符串常量池中。因此总共有2个对象
  • new String(“a”) + new String(“b”)会创建几个对象？
    • 五个，准确来说是六个
      • +代表拼接操作，因此对象一为new StringBuilder()
      • 对象二堆中new String()、对象三常量池中的"a"；
      • 对象四堆中new String()、对象五常量池中的"b"；
      • 对象六：StringBuilder的toString()方法在底层new String()
      • 特别说明，toString()的调用，在字符串常量池中没有生成"ab"（字节码中不存在出现生成"ab"的指令）
  • 第一个在常量池中出现了"ab"，而第二个在常量池中未出现
package com.reflect.ch4;

/**
 * author: reflect0714
 * date: 1/23/2021 - 11:28 PM
 * 探究new String("ab")到底造了几个对象
 */
public class StringNewDemo {
    public static void main(String[] args) {
        String str1 = new String("ab");

        String str2 = new String("a") + new String("b");
    }
}

/*
    String str1 = new String("ab");
    两个，怎么知道的？看字节码。先在堆中new开辟了一个对象，再将"ab"放入字符串常量池中
    因此总共有2个对象


    String str2 = new String("a") + new String("b");
    分析：看字节码
    首先涉及拼接操作"+"将会创建一个StringBuilder对象
    其次new String("a")会在堆中new一个对象，以及字符串常量池中放入"a"
    new String("b")同上，也是两个对象

    最后，深入分析：最后得到的str2是由StringBuilder转换而来
    其底层使用的是StringBuilder.toString()方法，而toString方法底层又是new String()
    即此处又会new一个String对象
    因此总共有6个对象

 */

面试难题

总结String的 intern（）的使用：

  • jdk1.6中，将这个字符串对象尝试放入字符串常量池。
    • 如果StringTable中有，则并不会放入。返回已有的StringTable中的对象的地址常量
    • 如果没有，会把此对象复制一份，放入StringTable，并返回StringTable中的对象地址
  • jdk1.7起，将这个字符串对象尝试放入字符串常量池。
    • 如果StringTable中有，则并不会放入。返回己有的StringTable中的对象的地址
    • 如果没有，则会把对象的引用地址复制一份，放入StringTable，并返回StringTable中的引用地址
package com.reflect.ch4;

/**
 * author: reflect0714
 * date: 1/23/2021 - 11:39 PM
 */
public class StringIntern {
    public static void main(String[] args) {
        String s1 = new String("1");
        s1.intern();    // 调用此方法之前，字符串常量池中已经存在"1"
        String s2 = "1";
        System.out.println(s1 == s2);
        // jdk6中false   jdk7及其之后也是false
        // 因为s1指向的是new String的地址，s2指向的是字符常量池中的地址

        String s3 = new String("1") + new String("1");
        // s3变量记录的地址就是堆中的地址
        // 但是执行完上述的代码之后，字符串常量池中将不会有"11"对象
        s3.intern();    // 此处将s3的"11"放入字符串常量池。
        // jdk6中将会在字符串常量池直接创建一个新对象"11"，即有新的地址
        // jdk7及其之后，为了节省空间，将不会直接创建"11"，而是创建一个指向堆空间中"11"的地址
        String s4 = "11";
        System.out.println(s3 == s4);
        // jdk6中false   jdk7及其之后true
    }
}

G1的String去重操作

  • 背景：对许多Java应用（有大的也有小的）做的测试得出以下结果：

    • 堆存活数据集合里面String对象占了25%
    • 堆存活数据集合里面重复的String对象有13.5%
    • String对象的平均长度是45

  • 许多大规模的Java应用的瓶颈在于内存，测试表明，在这些类型的应用里面，Java堆中存活的数据集合差不多25%是String对象。更进一步，这里面差不多一半String对象是重复的，重复的意思是说string1. equals(string2) = true。堆上存在重复的String对象必然是一种内存的浪费。这个项目将在G1垃圾收集器中实现自动持续对重复的 String对象进行去重，这样就能避免浪费内存。

  • 实现

    • 当垃圾收集器工作的时候，会访问堆上存活的对象。对每一个访问的对象都会检查是否是候选的要去重的String对象。
    • 如果是，把这个对象的一个引用插入到队列中等待后续的处理。一个去重的线程在后台运行，处理这个队列。处理队列的一个元素意味着从队列删除这个元素，然后尝试去重它引用的String对象。
    • 使用一个hashtable来记录所有的被String对象使用的不重复的char数组。
      当去重的时候，会查这个hashtable，来看堆上是否已经存在一个一模一样的char数组。
    • 如果存在，String对象会被调整引用那个数组，释放对原来的数组的引用，最终会被垃圾收集器回收掉。
    • 如果查找失败，char数组会被插入到hashtable，这样以后的时候就可以共享这个数组了。

垃圾回收算法

垃圾标记算法

Java和C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外的人想进来，墙内的人想出来。

首先需要进行明确的是，哪些地方存在垃圾？

  • 主要在堆、方法区

简单来说，当一个对象已经不再被任何存活的对象引用时就是垃圾。

引用计数算法

  • 定义

    • 在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的

  • 优点

    • 实现原理简单，垃圾对象便于辨识
    • 判定效率高，回收没有延迟性

  • 使用场景

    • 微软COM技术
    • ActionScript的FlashPlayer
    • Python语言
    • 以及在游戏领域应用的Squirrel

  • 缺点

    • 需要单独字段存储计数器，增加了存储空间
    • 每次复制都需要更新计数器，增加了时间开销
    • 严重的问题

      • 循环引用无法被回收

      • 图片示例：引用计数算法

      • 代码示例（证明Java采取的不是此种算法）

package com.reflect.ch3;

/**
 * author: reflect0714
 * date: 1/18/2021 - 4:41 PM
 * 验证JVM的垃圾回收算法是否采用了 引用计数法
 * testGC()方法执行后，objA和objB会不会被GC呢？
 * VMArgs: -XX:+PrintGCDetails
 */
public class ReferenceCountingGC {

    public Object reference = null;

    /*
    这个成员属性的唯一意义就是占内存，以便于在GC日志中查看是否有过回收
     */
    private byte[] bigSize = new byte[2 * 1024 * 1024];

    public static void testGC() {
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        objA.reference = objB;
        objB.reference = objA;

        objA = null;
        objB = null;

        // 假设在这行发生GC，objA和objB是否能被回收？
        System.gc();
    }

    public static void main(String[] args) {
        testGC();
    }
}

/**
 * 当把System.gc()注释掉时，出现的详细结果，没有看到出现GC
 * Heap
 *  PSYoungGen      total 75776K, used 9299K [0x000000076b580000, 0x0000000770a00000, 0x00000007c0000000)
 *   eden space 65024K, 14% used [0x000000076b580000,0x000000076be94e88,0x000000076f500000)
 *   from space 10752K, 0% used [0x000000076ff80000,0x000000076ff80000,0x0000000770a00000)
 *   to   space 10752K, 0% used [0x000000076f500000,0x000000076f500000,0x000000076ff80000)
 *  ParOldGen       total 173568K, used 0K [0x00000006c2000000, 0x00000006cc980000, 0x000000076b580000)
 *   object space 173568K, 0% used [0x00000006c2000000,0x00000006c2000000,0x00000006cc980000)
 *  Metaspace       used 3264K, capacity 4496K, committed 4864K, reserved 1056768K
 *   class space    used 354K, capacity 388K, committed 512K, reserved 1048576K
 *
 * 当把System.gc()使用时，出现的详细结果，可以看到出现了GC
 * [GC (System.gc()) [PSYoungGen: 7998K->824K(75776K)] 7998K->832K(249344K), 0.0007723 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
 * [Full GC (System.gc()) [PSYoungGen: 824K->0K(75776K)] [ParOldGen: 8K->615K(173568K)] 832K->615K(249344K), [Metaspace: 3206K->3206K(1056768K)], 0.0032488 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
 * Heap
 *  PSYoungGen      total 75776K, used 1951K [0x000000076b580000, 0x0000000770a00000, 0x00000007c0000000)
 *   eden space 65024K, 3% used [0x000000076b580000,0x000000076b767cc8,0x000000076f500000)
 *   from space 10752K, 0% used [0x000000076f500000,0x000000076f500000,0x000000076ff80000)
 *   to   space 10752K, 0% used [0x000000076ff80000,0x000000076ff80000,0x0000000770a00000)
 *  ParOldGen       total 173568K, used 615K [0x00000006c2000000, 0x00000006cc980000, 0x000000076b580000)
 *   object space 173568K, 0% used [0x00000006c2000000,0x00000006c2099f50,0x00000006cc980000)
 *  Metaspace       used 3245K, capacity 4496K, committed 4864K, reserved 1056768K
 *   class space    used 353K, capacity 388K, committed 512K, reserved 1048576K
 * 很明显，对比两者中的eden使用率，即证明此循环引用已被JVM回收，从侧面也反映出JVM采取的不是这种算法
 */
  • 延伸
    • Python如何解决循环引用问题？
    • 手动解除：就是在合适的时机，解除引用关系即可
    • 使用弱引用weakref，weakref是Python提供的标准库，旨在解决循环引用

可达性分析算法

  • 特点

    • 也叫作根搜索算法、追踪性垃圾收集
    • 当前主流的程序语言选择的（如Java、C#）
    • 能解决循环引用问题，防止内存泄露的发生

  • 定义

    • 通过一系列根对象集合（GC Roots）为起始节点，根据引用关系向下搜索，搜索过程所走过的路径称为引用链（Reference Chain）；如果某个对象到GC Root没有任何引用链相连，则是不可达的，证明此对象是不可能再被使用的，意味着该对象已经死亡；反之能直接或间接有引用链相连的对象才是存活对象
    • 图片示例：可达性分析算法

  • 在Java体系中，固定可作为GC Roots的对象有如下几种：

    • 虚拟机栈（栈帧中的本地变量表）中引用的对象
      • 比如：各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等
    • 方法区中类静态属性引用的对象
      • 比如：Java类的引用类型静态变量
    • 方法区中常量引用的对象
      • 比如：字符串常量池（String Table）里的引用
    • 本地方法栈中JNI（通常说的Native方法）引用的对象
    • Java虚拟机内部的引用
      • 比如：基本数据类型对应的Class对象
      • 一些常驻的异常对象（如NullPointException、OutOfMemoryError）
      • 系统类加载器
    • 所有被同步锁（synchronized关键字）持有的对象
    • 反映Java虚拟机内部情况的JMXBean、JVMTI中注册回调、本地代码缓存等
    • 除了上述固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合
      • 比如：分代收集和局部回收（Partial GC）

  • 注意

    • 如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证
    • 这也是导致GC进行时必须“Stop The World”的一个重要原因。即使号称几乎不会发生停顿的CMS收集器中，枚举根节点是也是必须要停顿的

对象的finalization机制

  • 概述

    • 当垃圾回收一个对象之前，总是会先调用此对象的finalize()方法
    • finalize()方法允许在子类中重写，用于在对象被回收时进行资源释放
    • 永远不要主动调用某个对象的finalize()方法，应该交给垃圾回收机制调用。理由有三点：
      • 在finalize()时可能会导致对象复活
      • finalize()方法的执行时间是没有保障的，它完全由GC线程决定，极端情况下，若不发生GC，则finalize()方法将没有执行的机会
      • 一个糟糕的finalize()方法会严重影响GC性能
    • 从功能上来说，相当于C++中的析构函数，但在本质上并不等同。
    • 由于finalize()方法的存在，虚拟机中对象一般处于三种可能的状态

  • 即使在可达性分析算法中判定为不可达对象，也不是“非死不可”的，这时候它们还处于“缓刑”阶段。一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的，因此，虚拟机中对象有三种状态：

    • 可触及的：从根节点开始，可以到达这个对象
    • 可复活的：对象的所有引用都被释放，但可能在finalize()中复活
    • 不可触及的：对象的finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会调用一次

  • 具体过程

  • 要真正宣告一个对象死亡，至少要经历两次标记过程：

    • 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记
    • 随后进行一次筛选，条件是此对象是否有必要执行finalize()方法。
      • 如果对象没有覆盖finalize()方法，或者finalize()方法以及被JVM调用过，那么虚拟机将这两种情况视为“没有必要执行”，此对象被判定为不可触及的
      • 如果对象被判定为有必要执行finalize()方法，则会将此对象放置在一个名为F-Queue队列当中。并稍后由一条由虚拟机自动建立的、低优先级的Finalizer线程去触发它们的finalize()方法
      • finalize()方法是对象跳脱死亡的最后机会，稍后GC将对F-Queue中的对象进行第二次标记。如果对象要在finalize()中成功拯救自己——只要重新与引用链上任何一个对象建立关联即可，比如将自己（this关键字）赋给某个类变量或对象的成员变量。那么在第二次标记时，它将被移出“即将回收“的集合。如果之后再出现没有引用的情况，那么finalize()方法将不会被再次调用，对象将变成不可触及的状态而被回收。也就是说，一个对象的finalize()方法只能被调用一次。

  • 代码示例

package com.reflect.ch3;

/**
 * author: reflect0714
 * date: 1/18/2021 - 7:19 PM
 * 测试Object类中finalize方法
 */
public class FinalizeEscapeGC {

    // 类变量，属于 GC Root
    public static FinalizeEscapeGC SAVE_HOOK = null;

    public void isAlive() {
        System.out.println("Yes, I am still alive!");
    }

    // finalize()方法只能被调用一次
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("Finalize method executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) {
        try {
            SAVE_HOOK = new FinalizeEscapeGC();

            // 对象第一次成功拯救自己
            SAVE_HOOK = null;
            // 调用GC
            System.gc();
            System.out.println("This is first GC");
            // 因为Finalizer方法优先级很低，暂停2秒以等待它执行完毕
            Thread.sleep(2000);
            // 判断SAVE_HOOK是否还存活
            if (SAVE_HOOK != null) {
                SAVE_HOOK.isAlive();
            } else {
                System.out.println("No, I am dead!");
            }

            // 下面与上面完全相同，但这次却自救失败了
            SAVE_HOOK = null;
            // 调用GC
            System.gc();
            System.out.println("This is first GC");
            // 因为Finalizer方法优先级很低，暂停2秒以等待它执行完毕
            Thread.sleep(2000);
            // 判断SAVE_HOOK是否还存活
            if (SAVE_HOOK != null) {
                SAVE_HOOK.isAlive();
            } else {
                System.out.println("No, I am dead!");
            }

        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

/**
 * 注释掉finalize()方法之后，输出结果
 * This is first GC
 * No, I am dead!
 * This is first GC
 * No, I am dead!
 *
 * 重写了finalize()方法之后，输出结果
 * Finalize method executed!
 * This is first GC
 * Yes, I am still alive!
 * This is first GC
 * No, I am dead!
 */
  • 延伸
    • finalize()方法只是在Java刚诞生之际为了与C/C++靠拢的一种妥协。
    • 它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。如今已被官方明确声明为不推荐使用的语法
    • 其适合做“关闭资源”的清理性工作可以是哟try-finally或其他方式做的更好，因此可以完全遗忘finalize()方法

垃圾清除算法

标记-清除算法

  • 英文：Mark-Sweep

  • 背景

    • 最基础的垃圾收集算法
    • 于1960年运用于Lisp语言

  • 执行过程

    • 当有效空间(available memory)被耗尽时，就会进行STW，然后进行两项操作，即标记和清除
    • 标记：Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象
    • 清除：Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在Header中没有标记为可达对象，则将其回收

  • 缺点

    • 执行效率不算高，不稳定
    • 在进行GC时候，需要STW，导致用户体验差
    • 这种方式的清理的空闲内存是不连续的，产生内存碎片。需要维护一个空闲列表

  • 延伸：何为清除？

    • 所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否足够，如果足够则进行覆盖即可。

标记-复制算法

  • 简称为复制算法，（Copying）

  • 过程

    • 将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。
    • 在垃圾回收时，将正在使用的内存中的存活对象复制到未被使用的内存块中
    • 之后清除正在使用的内存块的所有对象，交换两个内存的角色，完成垃圾回收
    • 图片示例：标记-复制算法

  • 优点

    • 没有标记和清除过程，实现简单，运行高效
    • 复制能保证空间的连续性，不会出现“内存碎片”

  • 缺点

    • 缺点十分明显，需要两倍的内存空间
    • 对于G1这种拆分为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象的引用关系，不管是内存占用或时间开销也不小

  • 特别

    • 如果内存中多数对象都是存活的，那么这种算法将产生大量的内存间复制的开销，并不是很好的选择。

标记-整理算法

  • 也叫作标记-压缩、标记-清除-整理算法（Mark-Compact）

  • 执行过程

    • 第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象
    • 第二阶段将所有存活对象整理到内存的一端，按顺序排放
    • 然后清理掉边界以外的内存
    • 图片示例：标记-整理算法

  • 优点

    • 消除了标记-清除算法中，内存区域分散的缺点
    • 消除了复制算法中，内存减半的高额代价

  • 缺点

    • 从效率上说，标记-整理算法要低于复制算法
    • 移动对象的同时，如果对象被其他对象引用，还需要调整引用的地址
    • 移动过程中，需要进行STW

垃圾回收相关概念

System.gc()的理解

  • 调用System.gc()或者Runtime.getRuntime().gc()的调用，会显示触发Full GC
  • 然而System.gc()调用附带一个免责声明，即无法保证调用垃圾收集器，只是提醒JVM希望进行垃圾回收
  • 一般不用手动触发，否则会过于麻烦
  • 示例测试
package com.reflect.ch3;

/**
 * author: reflect0714
 * date: 1/23/2021 - 7:21 PM
 */
public class SystemGCDemo {
    public static void main(String[] args) {
        new SystemGCDemo();
        System.gc();    // 提醒JVM的垃圾回收期执行gc，
        // 底层就是Runtime.getRuntime().gc();

        // 加上下面这句将会保证一定调用对象的finalize方法
//        System.runFinalization();
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("SystemGCDemo重写了finalize()方法");
    }
}

/*
    进行多次测试，才可能会出现输出信息。
    System.gc()的底层源码：
        public static void gc() {
        Runtime.getRuntime().gc();
    }

 */

内存溢出与内存泄露

内存溢出（OOM）
  • 在抛出OOM之前一定会进行Full GC操作
    • 特例：分配的一个超大对象，JVM判定垃圾收集也不能解决这个问题，所以此时不会再进行GC而是直接抛出OOM
  • JavaDoc中对OutOfMemoryError的解释是：没有空闲内存，并且垃圾收集器也无法提供更多内存
内存泄漏（Memory Leak）
  • 严格来说，只有对象不会再被程序用到，但是GC又回收不了情况，才叫内存泄露
  • 举例
    • 单例模式
      • 单例的生命周期一般是和应用程序一样长，所以如果在单例程序中持有外部对象的引用时，将会导致这个外部对象一直不能被回收，导致内存泄露的产生
    • 一些提供close的资源未关闭将导致内存泄露
  • 内存泄露的图示
    • 内存泄漏

Stop The World

  • 简称STW，是指GC发生过程中，会产生应用程序的停顿。
    • 可达性分析算法中枚举根节点（GC Roots）会导致所有Java执行线程停顿
      • 分析工作必须在一个能确保一致性的快照中进行
      • 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
      • 如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性将无法保证
  • 被STW终端的应用程序将在GC完成之后恢复，频繁中断会使得用户体验较差，所以需要尽可能减少STW的发生
  • 所有的GC都有STW的发生，只能说回收效率提高，缩短暂停时间
  • STW是JVM在后台自动发起和完成的，一般不要使用System.gc()，因为会导致STW的发生

安全点与安全区域

安全点（Safepoint）

  • 程序只有在特定的位置才能停下来开始GC，这些位置称为“安全点”

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

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

    • 抢先式中断（目前没有虚拟机采用此方法）
      • 首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点
    • 主动式中断
      • 设置一个中断标志，各个线程运行到Safe Point时主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起
安全区域（Safe Region）

  • 对于例如线程处于Sleep或Blocked状态，这时候线程无法响应JVM的中断请求，JVM也不太可能等待线程被唤醒。因此出现了安全区域来解决

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

  • 实际执行过程

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

再谈引用

JDK1.2之后对引用的扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Weak Reference）

  • 强引用（Strong Reference）
    • 最传统的“引用”的定义，即Java中普遍的引用的关系，99%的引用都是这种。无论在任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象
  • 软引用（Soft Reference）
    • 在系统将要发生内存溢出OOM之前，将会把这些对象列入回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常
  • 弱引用（Weak Reference）
    • 被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象
  • 虚引用（Phantom Reference）
    • 一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知
强引用

  • 强引用可以直接访问目标对象

  • 强引用对象是可触及的，垃圾收集器永远不会回收掉被引用的对象

  • 强引用是造成Java内存泄漏的主要原因之一

软引用——内存不足即回收
  • 软引用用来描述一些还有用，但非必须的对象。只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列入回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常
  • 软引用通常用来实现内存敏感的缓存、比如MyBatis源码中就有涉及
  • 垃圾回收期在某个时刻决定回收软引用可达对象的时候，会清理软引用，并可选地把引用存放到一个引用队列（Reference Queue）
  • JDK1.2之后提供了java.lang.ref.SoftReference类来实现软引用
弱引用——发现即回收
  • 只被弱引用关联的对象只能生存到下一次垃圾收集发生为止
  • 弱引用与软引用一样，也可以指定一个引用队列，通过队列跟踪对象的回收情况。
  • 弱引用、软引用都适合用来保存可有可无的缓存数据。
  • JDK1.2之后提供了java.lang.ref.WeakReference类来实现软引用
  • 弱引用与软引用对象的最大不同就在于，当GC进行回收时，需要通过算法检查是否回收软引用对象；而对于弱引用对象，GC总是进行回收。弱引用对象更容易、更快被GC回收
虚引用——对象回收跟踪
  • 也称为“幽灵引用”或“幻影引用”
  • 一个对象是否有虚引用的存在，完全不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它跟没有引用几乎一样，随时都可能被垃圾回收器回收
  • 为一个对象设置虚引用关联的唯一目的在于跟踪回收过程。比如：能在这个对象被收集器回收时收到一个系统通知
  • 虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况
  • 由于虚引用可以跟踪对象的回收时间，因此，也可以将一些资源释放操作放置在虚引用中执行和记录
终结期引用（Final Reference）
  • 它用以实现对象的finalize()方法，也可以称为终结期引用
  • 无需手动编码，其内部配合引用队列使用
  • 在GC时，终结器引用入队。由Finalizer线程通过终结器引用找到被引用对象并调用它的finalize()方法，第二次GC时才能回收被引用对象

垃圾回收器

分类

  • 按线程数：
    • 串行垃圾回收器
    • 并行垃圾回收器
  • 按照工作模式：
    • 并发式垃圾回收器
    • 独占式垃圾回收器
  • 按照碎片处理方式：
    • 压缩式垃圾回收器
    • 非压缩式垃圾回收器
  • 按工作的内存空间
    • 年轻代垃圾回收器
    • 老年代垃圾回收器

评估GC的性能指标

  • 吞吐量：运行用户代码的时间占总运行时间的比例
    • 总运行时间 = 程序运行时间 + 内存回收的时间
  • 垃圾收集开销：吞吐量的补数，垃圾收集所用时间与总运行时间的比例
  • 暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间
  • 收集频率：相对于应用程序的执行，收集操作发生的频率
  • 内存占用：Java堆区所占的内存大小
  • 快速：一个对象从诞生到被回收所经历的时间

加粗三者共同构成一个”不可能三角“。一款优秀的收集器通常最多同时满足其中的两项。

随着硬件发展，内存占用越来越能容忍，提高了吞吐量，也导致暂停时间增加。

简单来说，主要抓住两点：吞吐量和暂停时间

现在标准：在最大吞吐量优先的情况下，降低停顿时间

7种经典的垃圾回收器

  • 新生代收集器：Serial、ParNew、Parallel Scavenge；

  • 老年代收集器：Serial Old、Parallel Old、CMS；

  • 整堆收集器：G1；

  • 垃圾收集器的组合关系

    • 垃圾收集器关系

    • 红色的虚线是在jdk8中移除的

    • 绿色的虚线是在jdk14中移除的

Serial回收器：串行回收

  • 是最基本、历史最悠久的垃圾收集器。JDK1.3之前回收新生代唯一的选择

  • 作为HotSpot中Client模式下的默认新生代垃圾收集器

  • 采用复制算法、串行回收和“Stop-The-World”机制的方式执行内存回收

  • Serial收集器还提供用于执行老年代垃圾收集的Serial Old收集器。Serial Old收集器同样也采用了串行回收和“Stop-The-World”机制，只不过内存回收算法使用的是标记-压缩算法

    • Serial Old是运行在Client模式下默认的老年代的垃圾回收器
    • Serial Old在Server模式下主要有两个用途：①与新生代的Parallel Scavenge配合使用②作为老年代CMS收集器的后备垃圾收集方案

  • 它的”单线程“意义并不仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其它所有的工作线程，直到它收集结束（Stop the world）

  • 优势：简单而高效（与其它收集器的单线程对比）

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

    • 即新生代使用Serial GC，老年代使用Serial Old GC
ParNew回收器：并行回收

  • 是Serial收集器的多线程版本

    • Par是Paraller的缩写，New只能处理新生代

  • 除了采用并行回收方式执行以外，其它几乎没有任何区别，在年轻代中也是采用复制算法、“Stop-the-world”机制

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

  • 除了Serial外，目前只有ParNew GC能与CMS收集器配合工作

  • 使用-XX:+UseParNewGC指定年轻代使用ParNew收集器，不影响老年代。

    • -XX:ParallelGCThreads限制线程数量，默认开启与CPU数相同的线程数
Parallel回收器：吞吐量优先

  • Parallel Scavenge收集器同样也采用复制算法、并行回收和“Stop-the-world”机制

  • 那么Parallel收集器的出现是否多此一举？

    • 和ParNew收集器不同，Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput），它也被成为吞吐量优先的垃圾收集器
    • 自适应调节策略也是Parallel Scavenge与ParNew一个重要区别

  • 高吞吐量则代表可以高效率利用CPU时间，主要适合在后台计算而不需要太多交互任务。

  • Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel Old收集器，用来代替老年代的Serial Old收集器

  • Parallel Old收集器采用了标记-压缩算法，但同样也是基于并行回收和“Stop-the-world”机制

  • 在jdk8中是默认的垃圾收集器

CMS回收器：低延迟
  • 在JDK1.5时期，推出CMS（Concurrent-Mark-Sweep）收集器，它是HotSpot虚拟机中第一款真正意义的并发收集器，第一次实现了垃圾收集线程与用户线程同时工作
  • 其关注点是尽可能缩短垃圾收集时用户线程的停段时间。
  • 其垃圾收集算法采用标记-清除算法，并且也会“Stop-the-world”
工作原理

主要分为4个阶段：初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段

  • 初始标记（Initial-Mark）阶段：出现STW机制导致用户线程暂停，主要任务仅仅只是标记出GC Roots能直接关联到的对象。标记完成之后就会恢复所有用户线程。由于直接关联对象一般较小，所以速度非常快，暂停时间较短。

  • 并发标记（Concurrent-Mark）阶段：从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但不需要STW，可以与垃圾收集线程一起并发运行

  • 重新标记（Remark）阶段：由于在并发标记阶段中，用户线程和垃圾收集线程并发执行，因此为了修正并发标记期间，因程序继续执行而导致标记产生变动的那一部分对象的标记记录，这个阶段通常比初始标记时间长一些，但比并发标记阶段时间短的多。

  • 并发清除（Concurrent-Sweep）阶段：此阶段清除标记阶段判断已经死亡的对象，释放内存空间。这个阶段也可以与用于线程同时并发执行。

G1回收器：区域化分代式

  • 既然前面已经有几个强大的GC，为什么还要发布Garbage First（G1）

    • 官方给G1设定的目标是在延迟可控的情况下，获得尽可能高的吞吐量，所以才担当起“全功能收集器”的重任与期望。

  • 为什么名字叫做Garbage First（G1）

    • 因为G1是一个并行回收器，它把堆内存分割为很多不相关的区域（Region）（物理上不连续）。使用不同的Region来表示Eden、幸存者0区和1区、老年代等
    • G1有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region
    • 由于这种方式的侧重点在于回收垃圾最大量的区间（Region），所以取名为垃圾优先（Garbage First）
优势

  • 与其它GC收集器相比，G1使用了全新的分区算法，特点如下：

  • 并行与并发

    • 并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力。此时会出现STW
    • 并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段完全阻塞应用程序的情况

  • 分代收集

    • 从分代上看，G1依然属于分代型垃圾回收器，它会区分年轻代和老年代。但从堆的结构上看，它不要求整个年轻代或老年代都是连续的。
    • 将堆空间分为若干个区域（Region），这些区域中包含了逻辑上的年轻代和老年代。
    • 和之前的各类回收器不同，它同时兼顾年轻代和老年代。

  • 空间整合

    • CMS：“标记-清除”算法、内存碎片、若干次GC后进行一次碎片整理

    • G1将内存划分为一个个的region。内存的回收是以region作为基本单位的。

      Region之间是复制算法，但整体上实际可以看成标记-压缩算法。这两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。尤其是当Java堆非常大的时候，G1优势更加明显。

  • 可预测的停顿时间模型（即：软实时soft real-time）

    • 即明确一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
    • 由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收的范围，因此对于全局停顿情况的发生也能取得较好的控制
    • G1跟踪各个Region里面的垃圾堆积价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。保证G1在有限的时间内可以获取尽可能高的收集效率。
    • 相比CMS，G1未必能做到CMS在最好情况下的延时停顿，但是最差情况要好很多。
缺点
  • 相较于CMS，G1还不是全方位、压倒性优势。比如G1无论是为了垃圾收集产生的内存占用（Footprint）还是程序运行时的额外执行负载（Overload）都要比CMS要高
  • 从经验上来说，在小内存应用上CMS的表现大概率会优于G1，而G1在带内存应用上则会发挥其优势。平衡点在6-8GB之间
适用场景
  • 最主要应用是需要GC低延迟，并具有大堆的程序。
  • 在以下情况，G1可能比CMS好
    • 超过50%的Java堆被活动数据占用
    • 对象分配频率或年代提升频率变化很大
    • GC停顿时间过长（长于0.5至1秒）
Region分区：化整为零
  • G1收集器会将整个Java堆划分为约2048个大小相同的独立Region块，每个Region大小根据堆空间的实际大小而定，整体控制在1MB到32MB之间，且为2的N次幂。可以通过参数设定。所有的Region大小相同，且在JVM生命周期不会被改变。
  • 虽然还保留新生代和老年代的概念，但它们不再是连续的区域了，而是一部分Region（不需要连续）的集合。通过Region的动态分配实现逻辑上的连续。
  • 一个Region可能属于Eden，Survivor，Old或Humongous其中的一个。但是一个Region只能属于一个角色。G1中特殊的内存区域，叫做Humongous内存区域，主要用于存储大对象，超过1.5个Region，就放到巨型区域。
  • 设置H的原因：堆中的大对象会默认被分配到老年代，但是如果它是短期存在的，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了Humongous区专门存放大对象。如果一个H区装不下一个大对象，G1会寻找连续的H区来存储。为了能找到连续的H区，有时候不得不启动Full GC。G1大多数行为都把H区作为老年代的一部分来看待。
垃圾回收主要环节
  • G1的垃圾回收过程主要包括三个环节：
    • 年轻代GC（Young GC）
    • 老年代并发标记过程（Concurrent Marking）
    • 混合回收（Mixed GC）
    • 如果需要，单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制，即强力回收。
  • 详细过程
    • 当年轻代的Eden区用尽时开始年轻代回收过程：G1的年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期，G1暂停所有应用程序线程，启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到S区或老年代区，也可能二者都涉及。
    • 当堆空间使用达到一定值（默认是45%），开始老年代并发标记过程
    • 标记完成后马上开始混合回收过程。G1从老年区间移动存活对象到空闲区间，这些空闲空间就成为老年代的一部分。和年轻代不同，老年代的G1回收器与其它GC不同，G1的老年代回收器不需要整个老年代被回收，一次只需要扫描/回收一小部分老年代的Region即可。同时，这个老年代Region是和年轻代一起被回收的。
记忆集和写屏障
  • 为了解决一个对象可能被不同区域引用的问题
    • 一个Region不可能是孤立的，一个Region中的对象可能被其它Region中对象引用，判断对象是否存活，是否性需要扫描整个堆使得结果准确？
  • 在其它分代收集器，也存在这样的问题，只是G1更突出。
  • 回收新生代也不得不同时扫描老年代？这样将会降低Minor GC的效率
  • 解决方法
    • 无论是G1还是其它分代垃圾收集器，JVM都是使用Remembered Set来避免全局扫描
    • 每个Region都有一个对应的Remembered Set
    • 每次Reference类型数据写操作时，都会产生一个Write Barrier暂时中断操作
    • 然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region（其它收集器是检查老年代对象是否引用了新生代对象）
    • 如果不同，通过CardTable把相关引用信息记录到引用对象的所在Region对应的Remembered Set中
    • 当进行垃圾收集时，在GC根节点的枚举范围加入Remembered Set，就可以保证不进行全局扫描也不会有遗漏。
垃圾回收详细过程
回收过程一：年轻代GC

年轻代垃圾回收只会回收Eden区和Survivor区

YGC时，首先G1停止应用程序的执行（STW），G1创建回收集（Collection Set），回收集是指需要被回收的内存分段的集合，年轻代回收过程的回收集包含年轻代Eden区和Survivor区所有的内存分段

回收过程：

  • 第一阶段：扫描根
    • 根是指static变量指向的对象，正在执行的方法调用链条上的局部变量等。根引用连同RSet记录的外部引用作为扫描存活对象的入口
  • 第二阶段：更新RSet
    • 处理dirty card queue中的card，更新RSet。此阶段完成后，RSet可以准确反映老年代对所在内存分段中对象的引用。
  • 第三阶段：处理RSet
    • 识别被老年代对象指向Eden中的对象，这些被指向的Eden中的对象被认为是存活的对象。
  • 第四阶段：复制对象
    • 复制算法的具体实现。
  • 第五阶段：处理引用
    • 处理Soft，Weak，Phantom，Final，JNI Weak等引用。最终Eden空间的数据为空，GC停止工作，而目标内存中的堆都是连续存储的，没有碎片，所以复制过程可以达到内存整理的效果，减少内存碎片。
回收过程二：并发标记过程
  • 1.初始标记阶段：标记从根节点直接可达的对象。这个阶段是STW的，并且会触发一次年轻代GC
  • 2.根区域扫描（Root Region Scanning）：G1扫描Survivor区直接可达的老年代区域对象，并标记被引用的对象。这一过程必须在Young GC之前完成
  • 3.并发标记（Concurrent Marking）：在整个堆中进行并发标记（和应用程序并发执行），此过程可能被Young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那这个区域会被立即回收。同时，在并发标记过程中，会计算每个区域的对象活性（区域中存活对象的比例）
  • 4.再次标记（Remark）：由于应用程序持续进行，需要修正上一次的标记结果。此阶段是STW的。G1中采用了比CMS更快的初始快照算法：snapshot-at-the-begining（SATB）
  • 5.独占清理（cleanup，STW）：计算各个区域的存活对象和GC回收比例，并进行排序，识别可以混合回收的区域。为下个阶段做铺垫。并且此阶段STW的。
    • 此阶段并不会实际去做垃圾收集
  • 6.并发清理阶段：识别并清理完全空闲的区域
回收过程三：混合回收

Mixed GC不是一个Old GC，除了回收整个Young Region，还会回收的是一部分老年代，而不是全部老年代。可以选择哪些Old Region进行收集，从而可以对垃圾回收的耗时时间进行控制。

回收过程

  • 并发标记结束以后，老年代中百分百为垃圾的内存分段被回收了，部分为垃圾的内存分段被计算了出来。默认情况下，这些老年代的内存分段会分8次（可以通过-XX:G1 MixedGCCountTarget设置）被回收
  • 混合回收的回收集（Collection Set）包括八分之一的老年代内存分段，Eden区内存分段， Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样，只是回集多了老年代的内存分段。具体过程请参考上面的年轻代回收过程。
  • 由于老年代中的内存分段默认分8次回收，G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的，越会被先回收。并且有一个阈值会决定内存分段是否被回收， -XX:G1MixedGCLiveThresholdPercent，默认为65%，意思是垃圾占内存分段比例要达到65%才会被回收。如果垃圾占比太低，意味着存活的对象占比高，在复制的时候会花费更多的时间。
  • 混合回收并不一定要进行8次。有一个阈值-XX:G1HeapwastePercent，默认值为10%，意思是允许整个堆内存中有10%的空间被浪费，意味着如果发现可以回收的垃圾占堆内存的比例低于10%，则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少。
回收过程四：Full GC

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

  • 要避免Full GC的发生，一旦发生需要进行调整。什么时候会发生Full GC呢？比如堆内存太小，当G1在复制存活对象的时候没有空的内存分段可用则会回退到Full gc，这种情况可以通过增大内存解决。

  • 导致G1Full GC的原因可能有两个：

    • 1.Evacuation的时候没有足够的to-space来存放晋升的对象
    • 2.并发处理过程完成之前空间耗尽
总结

垃圾回收器总结

  • 如何选择垃圾回收器？

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

  • 最后需要明确一个观点

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

GC日志

  • 内存分配与垃圾回收的参数列表
    • -XX:+PrintGC：输出GC日志。类似：- verbose:gc
    • -XX:+PrintGCDetails：输出GC的详细日志
    • -XX:+PrintGCTimeStamps：输出GC的时间戳（以基准时间的形式）
    • -XX:+PrintGCDateStamps：输出GC的时间戳（以日期的形式，如2013-050421:53:59.234+0800）
    • -XX:+PrintHeapAtGC：在进行GC的前后打印出堆的信息
    • -Xloggc:…/logs/gc.log：日志文件的输出路径

ZGC

略

Class文件结构

  • 魔数
  • Class文件版本
  • 常量池
  • 访问标志
  • 类索引，父类索引，接口索引集合
  • 字段表集合
  • 方法表集合
  • 属性表集合
类型名称说明长度数量
u4magic魔数4字节1
u2minor_version副版本号（小版本）2字节1
u2major_version主版本号（大版本）2字节1
u2constant_pool_count常量池计数器2字节1
cp_infoconstant_pool常量池表n字节constant_pool_count - 1
u2access_flags访问标识2字节1
u2this_class类索引2字节1
u2super_class父类索引2字节1
u2interfaces_count接口计数器2字节1
u2interfaces接口索引集合2字节intefaces_count
u2fields_count字段计数器2字节1
field_infofields字段表n字节fields_count
u2methods_count方法计数器2字节1
method_infomethods方法表n字节methods_count
u2attributes_count属性计数器2字节1
attribute_infoattributes属性表n字节attributes_count

魔数（Magic Number）

  • 每个Class文件开头的4个字节的无符号整数称为魔数（Magic Number）
  • 它的唯一作用是确定这个文件是否为一个能被虚拟机接受的有效合法的Class文件。即：魔数是Class文件的标识符
  • 魔数值固定为0xCAFEBABE。不会改变。
  • 如果一个Class文件不以0xCAFEBABE开头，虚拟机在进行文件校验的时候就会直接抛出错误。
  • 使用魔数而不是扩展名来进行识别主要是基于安全方面的考虑，因为文件扩展名可以随意地改动。

Class文件版本

  • 紧接着魔数的4个字节存储的是Class文件的版本号。同样也是4个字节。第5个和第6个字节所代表的含义就是编译的副版本号minor_version，而第7个和第8个字节就是编译的主版本号major_version
  • 它们共同构成了class文件的格式版本号。比如某个Class文件的主版本号为M，副版本号为m，那么这个Class文件的格式版本号就确定为M.m
  • 版本号和Java编译器的对应关系如下表：
主版本（十进制）副版本（十进制）编译器版本
4531.1
4601.2
4701.3
4801.4
4901.5
5001.6
5101.7
5201.8
5301.9
5401.10
5501.11
  • Java的版本号是从45开始的，JDK1.1之后的每个JDK大版本发布主版本号向上加1
  • 不同版本的Java编译器编译的Class文件对应的版本是不一样的。目前，高版本的Java虚拟机可以执行由低版本编译器生成的c1ass文件，但是低版本的Java虚拟机不能执行由高版本编译器生成的class文件。否则JVM会抛出java.lang.UnsupportedClassVersionError异常。
  • 在实际应用中，由于开发环境和生产环境的不同，可能会导致该问题的发生。因此，需要我们在开发时，特别注意开发编译的JDK版本和生产环境中的JDK版本是否一致
    • 虚拟机JDK版本为1. k（k>=2）时，对应的class文件格式版本号的范为45.0 ~ 44+k.0（含两端）

常量池

  • 常量池是Class文件中内容最为丰富的区域之一。常量池对于Class文件中的字段和方法解析也有着至关重要的作用

  • 随着Java虚拟机的不断发展，常量池的内容也日渐丰富。可以说，常量池是整个class文件的基石

  • 在版本号之后，紧跟着的是常量池的数量，以及若干个常量池表项。

  • 常量池中常量的数量是不固定的，所以在常量池的入口需要放置一项u2类型的无符号数，代表常量池容量计数值（constant_pool count）。与Java中语言习惯不一样的是，这个容量计数是从1而不是0开始的

  • 由上表可见，Class文件使用了一个前置的容量计数器（constant_pool_count）加若干个连续的数据项（constant_pool）的形式来描述常量池内容。我们把这一系列连续常量池数据称为常量池集合

    • 常量池表项中，用于存放编译时期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放

常量池计数器（count_pool_count）

  • 由于常量池的数量不固定，时长时短，所以需要放置两个字节来表示常量池容量计数值。

  • 常量池容量计数值（u2类型）：从1开始，表示常量池中有多少项常量。即 constant_pool_count=1表示常量池中有个常量项。

  • 通常我们写代码时都是从0开始的，但是这里的常量池却是从1开始，因为它把第0项常量空出来了。这是为了满足后面某些指向常量池的索引值的数据在特定情况下需要表达“不引用任何一个常量池项目”的含义，这种情况可用索引值来表示。

常量池表（constant_pool）

  • constant_pool是一种表结构，以1 ~ constant_pool_count - 1为索引。表明了后面有多少个常量项。
  • 常量池主要存放两大类常量：字面量（Literal）和符号引用（Symbolic References）
  • 它包含了class文件结构及其子结构中引用的所有字符串常量、类或接口名、字段名和其他常量。常量池中的每一项都具备相同的特征。第1个字节作为类型标记，用于确定该项的格式，这个字节称为tag byte（标记字节、标签字节）
类型标志（或标识）描述
CONSTANT_utf8_info1UTF-8编码的字符串
CONSTANT_Integer_info3整型字面量
CONSTANT_Float_info4浮点型字面量
CONSTANT_Long_info5长整型字面量
CONSTANT_Double_info6双精度浮点型字符量
CONSTANT_Class_info7字段或接口的符号引用
CONSTANT_String_info8字符串类型字面量
CONSTANT_Fieldref_info9字段的符号引用
CONSTANT_Mrthodref_info10类中方法的符号引用
CONSTANT_InterfaceMethodref_info11接口中方法的符号引用
CONSTANT_NameAndType_info12字段或方法的符号引用
CONSTANT_MethodHandle_info15表示方法句柄
CONSTANT_MethodType_info16标志方法类型
CONSTANT_InvokeDynamic_info18表示一个动态方法调用点

字面量和符号引用

常量具体的常量
字面量文本字符串
声明为final的常量值
符号引用类和接口的全限定名
字段名称和描述符
方法名称和描述符

  • 全限定名

    • com/reflect/test/Demo这个就是类的全限定名，仅仅是把包名的".“替换成”/"，为了使连续的多个全限定名之间不产生混淆，在使用时最后一般会加入一个“；”表示全限定名结束

  • 简单名称

    • 简单名称是指没有类型和参数修饰的方法或者字段名称，上面例子中的类的add()方法和num字段的简单名称分别是add和num

  • 描述符

    • 描述符的作用是用来描述字段的数据类型、方法的参数列表（包持数量、类型以及顺序）和返回值。根据描述符规则，基本数据类（byte、char、 double、 float、int、long、 short、 boolean）以及代表无返回值的void类型都用一个大写字符来表示，而对象类型则用字符L加对象的全限定名来表示(并以;结尾)，详见下表：

    • 标志符含义
      B基本数据类型byte
      C基本数据类型char
      D基本数据类型double
      F基本数据类型float
      I基本数据类型int
      J基本数据类型long
      S基本数据类型short
      Z基本数据类型boolean
      V代表void类型
      L对象类型，比如：L java/lang/Object;
      [数组类型，代表一维数组。比如：double[ ][ ][ ] is [ [ [ D

补充说明

  • 虚拟机在加载Class文件时才会进行动态链接，也就是说，Class文件中不会保存各个方法和字段的最终内存布局信息，因此，这些字段和方法的符号引用不经过转换是无法直接被虚拟机使用的。当虚拟机运行时，需要从常量池中获得对应的符号引用，再在类加载过程中的解析阶段将其替换为直接引用，并翻译到具体的内存地址中。
  • 这里说明下符号引用和直接引用的区别与关联：
    • 符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到了内存中。
    • 直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那说明引用的目标必定已经存在于内存之中了

总结1：

  • 这14种表（或者常量项结构）的共同点是：表开始的第一位是一个u1类型的标志位（tag），代表当前这个常量项使用的是哪种表结构，即哪种常量类型
  • 在常量池列表中， CONSTANT_Utf8_info常量项是一种使用改进过的UTF-8编码格式来存储诸如文字字符串、类或者接口的全限定名、字段或者方法的简单名称以及描述符等常量字符串信息
  • 这14种常量项结构还有一个特点是，其中13个常量项占用的字节固定，只有CONSTANT_Utf8_info占用字节不固定，其大小由length决定。为什么呢？因为从常量池存放的内容可知，其存放的是字面量和符号引用，最终这些内容都会是一个字符串，这些字符串的大小是在编写程序时才确定，比如定义一个类，类名可以取长取短，所以在没编译前，大小不固定，编译后，通过utf-8编码，就可以知道其长度

总结2：

  • 常量池：可以理解为Class文件之中的资源仓库，它是Class文件结构中与其他项目关联最多的数据类型（后面的很多数据类型都会指向此处），也是占用Class文件空间最大的数据项目之一

  • 常量池中为什么要包含这些内容?

    • Java代码在进行Javac编译的时候，并不像C和C++那样有“连接”这一步骤，而是在虚拟机加载Class文件的时候进行动态链接。也就是说，在Class文件中不会保存各个方法、字段的最终内存布局信息，因此这些字段、方法的符号引用不经过运行期转换的话无法得到真正的内存入口地址，也就无法直接被虚拟机使用。当虚拟机运行时，需要从常量池获得对应的符号引用，再在类创建时或运行时解析、翻译到具体的内存地址之中。

访问标志

  • 在常量池后，紧跟着访问标记。该标记使用两个字节表示，用于识别一些类或者接口层次的访问信息，包括：这个Class是类还是接口；是否定义为 public类型；是否定义为 abstract类型；如果是类的话，是否被声明为final等。各种访问标记如下所示：
标志名称标志值含义
ACC_PUBLIC0x0001标志为public类型
ACC_FINAL0x0010标志被声明为final，只有类可以设置
ACC_SUPER0x0020标志允许使用invokespecial字节码指令的新语义。JDK1.0.2之后编译出来的类的这个标志默认为真（使用增强方法调用父类方法）
ACC_INTERFACE0x0200标志这是一个接口
ACC_ABSTRACT0x0400是否为abstract类型，对于接口或抽象类来说，此标志为真，其它类型为假
ACC_SYNTHETIC0x1000标志此类并非是由用户代码产生（即由编译器产生的类，没有源码对应）
ACC_ANNOTATION0x2000标志这是一个注解
ACC_ENUM0x4000标志这是一个枚举
  • 类的访问权限通常为ACC_开头的常量
  • 每一种类型的表示都是通过设置访问标记的32位中的特定位来实现的。比如，若是public final的类，则该标记为ACC_PUBLIC | ACC_FINAl
  • 使用ACC_ SUPER可以让类更准确地定位到父类的方法super.method()，现代编译器都会设置并且使用这个标记

补充说明：

  • 1.带有ACC_INTERFACE标志的class文件表示的是接口而不是类，反之则表示的是类而不是接口
    • 1）如果一个class文件被设置了ACC_INTERFACE标志，那么同时也得设置ACC_ABSTRACT标志。同时它不能再设置ACC_FINAL、ACC_SUPER或 ACC_ENUM标志
    • 2）如果没有设置ACC_INTERFACE标志，那么这个class文件可以具有上表中除ACC_ANNOTATION外的其他所有标志。当然，ACC_FINAL和ACC_ABSTRACT这类互斥的标志除外。这两个标志不得同时设置
  • 2.ACC_ SUPER标志用于确定类或接口里面的invokespecial指令使用的是哪一种执行语义。针对Java虚拟机指令集的编译器都应当设置这个标志。对于Java SE8及后续版本来说，无论class文件中这个标志的实际值是什么，也不管class文件的版本号是多少，Java虚拟机都认为每个class文件均设置了ACC_SUPER标志
    • 1） ACC SUPER标志是为了向后兼容由旧Java编译器所编译的代码而设计的。目前的ACC_SUPER标志在由JDK1.0.2之前的编译器所生成的access_flags中是没有确定含义的，如果设置了该标志，那么Oracle的Java虚拟机实现会将其忽略。
  • 3.ACC_SYNTHETIC标志意味着该类或接口是由编译器生成的，而不是由源代码生成的。
  • 4.注解类型必须设置ACC_ANNOTATION标志。如果设置了ACC_ANNOTATION标志，那么也必须设置ACC_INTERFACE标志
  • 5.ACC_ENUM标志表明该类或其父类为枚举类型。

类索引，父类索引，接口索引集合

  • 在访问标记后，会指定该类的类别、父类类别以及实现的接口，格式如下：
长度含义
u2this_class
u2super_class
u2interfaces_count
u2interfaces[interfaces_count]

  • 这三项数据来确定这个类的继承关系。

    • 类索引用于确定这个类的全限定名
    • 父类索引用于确定这个类的父类的全限定名。由于Java语言不允许多重继承，所以父类索引只有一个，除了java.lang.Object之外，所有的Java类都有父类，因此除了java.lang.Object外，所有Java类的父类索引都不为0
    • 接口索引集合就用来描述这个类实现了哪些接口，这些被实现的接口将按implements语句（如果这个类本身是一个接口，则应当是extends语句）后的接口顺序从左到右排列在接口索引集合中

  • 1、this class（类索引）

    • 2字节无符号整数，指向常量池的索引。它提供了类的全限定名，如com/reflect/java1/Demo.this_class的值必须是对常量池表中某项的一个有效索引值。常量池在这个素引处的成员必须为CONSTANT_Class_info类型结构体，该结构体表示这class文件所定义的类或接口

  • 2、super class（父类索引）

    • 2字节无符号整数，指向常量池的索引。它提供了当前类的父类的全限定名。如果我们没有继承任何类，其默认继承的是java/lang/Object类。同时，由于Java不支持多继承，所以其父类只有一个superclass指向的父类不能是final

  • 3、interfaces

    • 指向常量池素引集合，它提供了一个符号引用到所有已实现的接口
    • 由于一个类可以实现多个接口，因此需要以数组形式保存多个接口的索引，表示接口的每个索引也是一个指向常量池的CONSTANT_Class（当然这里就必须是接口，而不是类）

  • 3.1、interfaces_count（接口计数器）

    • interfaces_count项的值表示当前类或接口的直接超接口数量

  • 3.2、interfaces [ ]（接口索引集合）

    • interfaces[ ]中每个成员的值必须是对常量池表中某项的有效索引值，它的长度为interfaces_count。每个成员interfaces[i]必须为 CONSTANT_Class_info结构，其中0 <= i < interfaces_count。在interfaces[ ]中，各成员所表示的接口顺序和对应的源代码中给定的接口顺序（从左至右）一样，即interfaces [0]对应的是源代码中最左边的接口

字段表集合

fields

  • 用于描述接口或类中声明的变量。字段（field）包括类级变量以及实例级变量，但是不包括方法内部、代码块内部声明的局部变量。（local variables）
  • 字段叫什么名字、字段被定义为什么数据类型，这些都是无法固定的，只能引用常量池中的常量来描述
  • 它指向常量池索引集合，它描述了每个字段的完整信息。比如**字段的标识符、访问修饰符（public、private或protected）、是类变量还是实例变量（static修饰符）、是否是常量（final修饰符）**等

注意事项

  • 字段表集合中不会列出从父类或者实现的接口中继承而来的字段，但有可能列出原本Java代码之中不存在的字段。比如在内部类中为了保持对外部类的访问性，会自动添加指向外部类实例的字段
  • 在Java语言中字段是无法重载的，两个字段的数据类型，修饰符不管是否相同，都必须使用不一样的名称，但是对于字节码来讲，如果两个字段的描述符不一致，那字段重名就是合法的

字段计数器（field_count）

  • fields_count的值表示当前class文件fields表的成员个数。使用两个字节来表示
  • fields表中每个成员都是一个field_info结构，用于表示该类或接口所声明的所有类字段或者实例字段，不包括方法内部声明的变量，也不包括从父类或父接口继承的那些字段。

字段表（fields [ ]）

  • fields表中的每个成员都必须是一个fields_info结构的数据项，用于表示当前类或接口中某个字段的完整描述
  • 一个字段的信息包括如下这些信息。这些信息中，各个修饰符都是布尔值，要么有，要么没有
    • 作用域（public、private、protected修饰符）
    • 是实例变量还是类变量（static修饰符）
    • 可变性（final）
    • 并发可见性（volatile修饰符，是否强制从主内存读写）
    • 可否序列化（transient修饰符）
    • 字段数据类型（基本数据类型、对象、数组）
    • 字段名称
  • 字段表结构
类型名称含义数量
u2access_flags访问标志1
u2name_index字段名索引1
u2descriptor_index描述符索引1
u2attributes_count属性计数器1
attribute_infoattributes属性集合attributes_count
字段表访问标识
  • 一个字段可以被各种关键字去修饰，比如：作用域修饰符（public、private、protected）、static修饰符、final修饰符、 volatile修饰符等等。因此，其可像类的访问标志那样，使用一些标志来标记字段。
  • 字段的访问标志有如下：
标志名称标志值含义
ACC_PUBLIC0x0001字段是否为public
ACC_PRIVATE0x0002字段是否为private
ACC_PROTECTED0x0004字段是否为protected
ACC_STATIC0x0008字段是否为static
ACC_FINAL0x0010字段是否为final
ACC_VOLATILE0x0040字段是否为volatile
ACC_TRANSIENT0x0080字段是否为transient
ACC_SYNCHETIC0x1000字段是否为编译器自动产生
ACC_ENUM0x4000字段是否为enum
字段名索引
  • 根据字段名素引的值，查询常量池中的指定索引项即可。
描述符索引
  • 描述符的作用是用来描述字段的数据类型、方法的参数列表（包括数量、类型以及顺序）和返回值。根据描述符规则，基本数据类型（byte, char, double, float, int, long, short, boolean）及代表无返回值的void类型都用一个大写字符来表示，而对象则用字符L加对象的全限定名来表示
字符类型含义
Bbyte有符号字节型数
CcharUnicode字符，UTF-16编码
Ddouble双精度浮点数
Ffloat单精度浮点数
Iint整型数
Jlong整型数
Sshort有符号短整数
Zboolean布尔值true/false
L classname;reference一个名为Classname的实例
[reference一个一维数组
属性表集合

  • 一个字段还可能拥有一些属性，用于存储更多的额外信息。比如初始化值、一些注释信息等。属性个数存放在attribute_count中，属性具体内容存放在attributes数组中

  • 以常量属性为例，结构为

    Constantvalue_attribute {

    ​ u2 attribute_name_index

    ​ u4 attribute_length

    ​ u2 constantvalue_index

  • 说明：对于常量属性而言， attribute_ length值恒为2

方法表集合

  • methods：指向常量池索引集合，它完整描述了每个方法的签名
  • 在字节码文件中，每一个method_info项都对应着一个类或者接口中的方法信息。比如方法的访问修饰符（public、private或protected），方法的返回值类型以及方法的参数信息等
  • 如果这个方法不是抽象的或者不是native的，那么字节码中会体现出来。
  • 一方面，methods表只描述当前类或接口中声明的方法，不包括从父类或父接口继承的方法。另一方面， methods表有可能会出现由编译器自动添加的方法，最典型的便是编译器产生的方法信息（比如：类（接口）初始化方法<clinit>()和实例初始化方法<init>()。

使用注意事项

  • 在Java语言中，要重载（Overload）一个方法，除了要与原方法具有相同的简单名称之外，还要求必须拥有一个与原方法不同的特征签名，特征签名就是一个方法中各个参数在常量池中的字段符号引用的集合，也就是因为返回值不会包含在特征签名之中。因此Java语言里无法仅仅依靠返回值的不同来对一个已有方法进行重载。但在Class文件格式中，特征签名的范围更大一些，只要描述符不是完全一致的两个方法就可以共存。也就是说，如果两个方法有相同的名称和特征签名，但返回值不同，那么也是可以合法共存于同一个class文件中也就是说，尽管Java语法规范并不允许在一个类或者接口中声明多个方法签名相同的方法，但是和Java语法规范相反，字节码文件中却恰恰允许存放多个方法签名相同的方法，唯一的条件就是这些方法之间的返回值不能相同。
方法计数器（methods_count）
  • methods_count的值表示当前class文件methods表的成员个数。使用两个字节来表示。
  • methods表中每个成员都是一个method_info结构
方法表（methods [ ]）
  • methods表中的每个成员都必须是一个method_info结构，用于表示当前类或接口中某个方法的完整描述。如果某个method_info结构的access_flags项既没有设置ACC_NATIVE标志也没有设置ACC_ABSTRACT标志，那么该结构中也应包含实现这个方法所用的Java虚拟机指令
  • method_info结构可以表示类和接口中定义的所有方法，包括实例方法、类方法、实例初始化方法和类或接口初始化方法
  • 方法表的结构实际跟字段表是一样的，
  • 方法表结构如下：
类型名称含义数量
u2access_flags访问标志1
u2name_index字段名索引1
u2descriptor_index描述符索引1
u2attributes_count属性计数器1
attribute_infoattributes属性集合attributes_count
方法表访问标志

  • 跟字段表一样，方法表也有访问标志，而且它们的标志有部分相同，部分则不同，方法表的具体访问标志如下：

  • 字段的访问标志有如下：

标志名称标志值含义
ACC_PUBLIC0x0001public，方法可以从包外访问
ACC_PRIVATE0x0002private，方法只能在本类中访问
ACC_PROTECTED0x0004protected，方法只能在本类和子类中访问
ACC_STATIC0x0008static，静态方法
ACC_FINAL0x0010final，方法不能被重写
ACC_SYNCHRONIZED0x0020synchronized，方法由线程同步
ACC_BRIDGE0x0040bridge，方法由编译器产生

属性表集合（attributes）

  • 方法表集合之后的属性表集合，指的是class文件所携带的辅助信息，比如该class文件的源文件的名称。以及任何带有RetentionPolicy.CLASS或者RetentionPolicy.RUNTIME的注解。这类信息通常被用于Java虚拟机的验证和运行，以及Java程序的调试，一般无须深入了解。
  • 此外，字段表、方法表都可以有自己的属性表。用于描述某些场景专有的信息
  • 属性表集合的限制没有那么严格，不再要求各个属性表具有严格的顺序，并且只要不与已有的属性名重复，任何人实现的编译器都可以向属性表中写入自己定义的属性信息，但Java虚拟机运行时会忽略掉它不认识的属性。

字节码指令集

类的加载过程详解

概述

  • 在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载。
  • 按照Java虚拟机规范，从class文件到加载到内存中的类，到类卸载出内存为止，它的整个生命周期包括如下7个阶段：
  • 其中，验证、准备、解析3个部分统称为链接（Linking）

类加载过程

过程一：Loading（加载）阶段

  • 加载的理解
    • 所谓加载，简而言之就是将Java类的字节码文件加载到机器内存中，并在内存中构建出Java类的原型——类模板对象。所谓类模板对象，其实就是Java类在JVM内存中的一个快照，JVM将从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中，这样JVM在运行期便能通过类模板而获取Java类中的任意信息，能够对Java类的成员变量进行遍历，也能进行Java方法的调用
    • 反射的机制即基于这一基础。如果JVM没有将Java类的声明信息存储起来，则JVM在运行期也无法反射
  • 加载完成的操作
    • 加载阶段，简言之，查找并加载类的二进制数据，生成Class的实例
    • 在加载类时，Java虚拟机必须完成以下3件事情：
      • 通过类的全名，获取类的二进制数据流
      • 解析类的二进制数据流为方法区内的数据结构（Java类模型）
      • 创建java.lang.Class类的实例，表示该类型。作为方法区这个类的各种数据的访问入口

二进制流的获取方式

  • 获取方式

    • 对于类的二进制数据流，虚拟机可以通过多种途径产生或获得。（只要所读取的字节码符合W规范即可）
    • 虚拟机可能通过文件系统读入一个class后缀的文件（最常见）
    • 读入jar、zip等归档数据包，提取类文件
    • 事先存放在数据库中的类的二进制数据
    • 使用类似于HTTP之类的协议通过网络进行加载
    • 在运行时生成一段Class的二进制信息等

  • 在获取到类的二进制信息后，Java虚拟机就会处理这些数据，并最终转为一个java.lang.Class的实例。

  • 如果输入数据不是ClassFile的结构，则会抛出ClassFormatError

类模板与Class实例的位置

  • 1.类模型的位置

    • 加载的类在JVM中创建相应的类结构，类结构会存储在方法区
    • （JDK1.8之前：永久代；JDK1.8及之后：元空间）。

  • 2.Class实例的位置

    • 类将.class文件加载至元空间后，会在堆中创建一个java.lang.Class对象，用来封装类位于方法区内的数据结构，该Class对象是在加载类的过程中创建的，每个类都对应有一个Class类型的对象

  • 3.示意图

    • 示意图

  • 4.再说明

    • class类的构造方法是私有的，只有JVM能够创建
    • java.lang.Class实例是访问类型元数据的接口，也是实现反射的关键数据、入口。通过class类提供的接口，可以获得目标类所关联的.class文件中具体的数据结构：方法、字段等信息

数组类的加载

  • 创建数组类的情况稍微有些特殊，因为数组类本身并不是由类加载器负责创建，而是由JVM在运行时根据需要而直接创建的，但数组的元素类型仍然需要依靠类加载器去创建。创建数组类（下述简称A）的过程：
    • 1.如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型
    • 2.JVM使用指定的元素类型和数组维度来创建新的数组类。
  • 如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public

过程二：Linking（链接）阶段

环节一：链接阶段之Verification(验证)

  • 当类加载到系统后，就开始链接操作，验证是链接操作的第一步。
  • 它的目的是保证加载的字节码是合法、合理并符合规范的。
  • 验证的步骤比较复杂，实际要验证的项目也很繁多，大体上Java處拟机需要做以下检査，如图所示。
  • 检查过程

整体说明：

  • 验证的内容则涵盖了类数据信息的格式验证、语义检查、字节码验证，以及符号引用验证等。
    • 其中格式验证会和加载阶段一起执行。验证通过之后，类加载器才会成功将类的二进制数据信息加载到方法区中
    • 格式验证之外的验证操作将会在方法区中进行
  • 链接阶段的验证虽然拖慢了加载速度，但是它避免了在字节码运行时还需要进行各种检查。（磨刀不误砍柴工）

具体说明：

  • 1.格式验证：是否以魔数0xCAFEBABE开头，主版本和副版本号是否在当前Java虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等

  • 2.Java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机中不会给予验证通过，比如

    • 是否所有的类都有父类的存在（在Java里，除了Object外，其他类都应该有父类）
    • 是否一些被定义为final的方法或者类被重写或继承了
    • 非抽象类是否实现了所有抽象方法或者接口方法
    • 是否存在不兼容的方法（比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度；abstract情况下的方法，就不能是final的了

  • 3.Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：

    • 在字节码的执行过程中，是否会跳转到一条不存在的指令
    • 函数的调用是否传递了正确类型的参数
    • 变量的赋值是不是给了正确的数据类型等
    • 栈映射帧（StackMapTable）就是在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是，100%准确地判断一段字节码是否可以被安全执行是无法实现的，因此，该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的

  • 在前面3次检查中，已经排除了文件格式错误、语义错误以及字节码的不正确性。但是依然不能确保类是没有问题的

  • 4.校验器还将进行符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用的类无法在系统中找到，则会抛出NoClassDefFoundError，如果一个方法无法被找到，则会抛出NoSuchMethodError。

    • 注意：此阶段在解析环节才会执行

环节二：链接阶段之Preparation(准备)

  • 简言之，为类的静态变量分配内存，并将其初始化为默认值。
  • 当一个类验证通过时，虚拟机就会进入准备阶段。在这个阶段，虚拟机就会为这个类分配相应的内存空间，并设置默认初始值。
  • Java虚拟机为各类型变量默认的初始值如表所示：
类型默认初始值
byte(byte)0
short(short)0
int0
long0L
float0.0f
double0.0
char\u0000
booleanfalse
referencenull

  • 注意：Java并不支持 boolean类型，对于boolean类型，内部实现是int，由于int的默认值是0，故对应的boolean的默认值就是 false

  • 1.这里不包含基本数类型的字段用static final修饰的情况，因为final在编译的时候就会分配了，准备阶段会显式赋值

  • 2.注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中

  • 3.在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行

环节三：链接阶段之Resolution(解析)

  • 简言之，将类、接口、字段和方法的符号引用转为直接引用。

  • 符号引用就是一些字面量的引用，和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用是不够的，比如当如下 println()方法被调用时，系统需要明确知道该方法的位置。

  • 所谓解析就是将符号引用转为直接引用，也就是得到类、字段、方法在内存中的指针或者偏移量。因此，可以说，如果直接引用存在，那么可以肯定系统中存在该类、方法或者字段。但只存在符号引用，不能确定系统中一定存在该结构。
    不过Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpot VM中，加载、验证、准备和初始化会按照顺序有条不紊地执行，但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行。

过程三：Initialization（初始化）阶段

  • 简言之，为类的静态变量赋予正确的初始值。
  • 类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码。（即：到了初始化阶段，才真正开始执行类中定义的Java程序代码。）
  • 初始化阶段的重要工作是执行类的初始化方法：<clinit>()方法。
    • 该方法仅能由Java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然方法也是由字节码指令所组成
    • 它是由类静态成员的赋值语句以及static语句块合并产生的。
  • 在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的<clinit>总是在子类<clinit>之前被调用。也就是说，父类的static块优先级高于子类。
  • Java编译器并不会为所有的类都产生<clinit>()初始化方法。哪些类在编译为字节码后，字节码文件中将不会包含<clinit>()方法？
    • 一个类中并没有声明任何的类变量，也没有静态代码块时
    • 一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时
    • 一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式

static与final搭配

  • 使用static + final修饰，且显示赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显式赋值，是在链接阶段的准备环节进行。

<clinit>的线程安全性

  • 对于<clinit>()方法调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性。
  • 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕
  • 正是因为函数<clinit>()带锁线程安全的，因此，如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个线程阻塞，引发死锁。并且这种死锁是很难发现的，因为看起来它们并没有可用的锁信息
  • 如果之前的线程成功加载了类，则等在队列中的线程就没有机会再执行<clinit>()方法了。那么，当需要使用这个类时虚拟机会直接返回给它己经准备好的信息

主动使用和被动使用

Java程序对类的使用分为两种：主动使用和被动使用。

主动使用

Class只有在必须要首次使用的时候才会被装载，Java虚拟机不会无条件地装载 Class类型。Java虚拟机规定，一个类或接口在初次使用前，必须要进行初始化。这里指的“使用”，是指主动使用，主动使用只有下列几种情况：（即：如果出现如下的情况，则会对类进行初始化操作。而初始化操作之前的加载、验证、准备己经完成。）

  • 1.当创建一个类的实例时，比如使用new关键字，或者通过反射、克隆、反序列化

  • 2.当调用类的静态方法时，即当使用了字节码invokestatic指令

  • 3.当使用类、接口的静态字段时（final修饰特殊考虑），比如，使用getstatic或者 putstatic指令。（对应访问变量赋值变量操作）

  • 4.当使用java.lang.reflect包中的方法反射类的方法时。比如：Class. forName（“com, reflect.java.Test”）

  • 5.当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

  • 6.如果一个接口定义了default方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化。

  • 7.当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。

  • 8.当初次调用MethodHandle实例时，初始化该MethodHandle指向的方法所在的类。（涉及解析REF_getstatic、REF_putstatic、REF_invokeStatic方法句柄对应的类）

  • 针对5，补充说明：Java虚拟机初始化一个类时，要求它的所有父类都己经被初始化，但是这条规则并不适用于接口

    • 在初始化一个类时，并不会先初始化它所实现的接口
    • 在初始化一个接口时，并不会先初始化它的父接口

    因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化

  • 针对7，说明：JVM启动的时候通过引导类加载器加载一个初始类。这个类在调用public static void main（ String [ ]）方法之前被链接和初始化。这个方法的执行将依次导致所需的类的加载，链接和初始化

被动使用

除了以上的情况属于主动使用，其他的情况均属于被动使用。被动使用不会引起类的初始化.也就是说：并不是在代码中出现的类，就一定会被加载或者初始化。如果不符合主动使用的条件，类就不会初始化

  • 1.当访问一个静态字段时，只有真正声明这个字段的类才会被初始化。
    • 当通过子类引用父类的静态变量，不会导致子类初始化
  • 2.通过数组定义类引用，不会触发此类的初始化
  • 3.引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了
  • 4.调用Classloader类的 loadClass()方法加载一个类，并不是对类的主动使用，不会导致类的初始化

过程四：类的Using（使用）

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

过程五：类的Unloading（卸载）

类、类的加载器、类的实例之间的引用关系

  • 在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系
  • 一个类的实例总是引用代表这个类的class对象。在Object类中定义了getclass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象

类的生命周期

  • 当Sample类被加载、链接和初始化后，它的生命周期就开始了。当代表Sample类的class对象不再被引用，即不可触及时，Class对象就会结束生命周期，sample类在方法区内的数据也会被卸载，从而结束Sample类的生命周期
  • 一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。

类的卸载

  • （1）启动类加载器加载的类型在整个运行期间是不可能被卸载的（jvm和jls规范）
  • （2）被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到unreachable的可能性极小
  • （3）被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中（比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能），被加载的类型在运行期间也是几乎不太可能被卸载的（至少卸载的时间是不确定的）
  • 综合以上三点，一个己经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。同时我们可以看的出来，开发者在开发代码时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能。

再谈类加载器

类加载

分类

  • 类的加载分类：显式加载 VS 隐式加载。class文件的显式加载与隐式加载的方式是指JVM加载class文件到内存的方式。
  • 显式加载指的是在代码中通过调用ClassLoader加载class对象，如直接使用Class.forName(name)或this.getclass()，getclassLoader().loadclass()加载class对象。
  • 隐式加载则是不直接在代码中调用Classloader方法加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的class文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载任到内存中
  • 在日常开发以上两种方式一般会混合使用。

必要性

  • 一般情况下，Java开发人员并不需要在程序中显式地使用类加载器，但是了解类加载器的加载机制却显得至关重要。从以下几个方面说
    • 避免在开发中遇到java.lanng.ClassNotFoundException异常或java.lang.NoClassDefFoundError异常时手足无措。只有了解加载器的加载机制才能够在出现异常的时候快速地根据错误异常日志定位问题和解决问题
    • 需要支持类的动态加载或需要对编译后的字节码文件进行加解密操作时，就需要与类加载器打交道了
    • 开发人员可以在程序中编写自定义类加载器来重新定义类的加载规则，以便实现一些自定义的处理逻辑

命名空间

1.何为类的唯一性？

  • 对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等

2.命名空间

  • 每个类加载器都有自己的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成
  • 在同一命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类
  • 在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类
  • 在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本

类加载机制的基本特征

通常类加载机制有三个基本特征。

  • 双亲委派型。但不是所有类加载都遵守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以在标准API框架上，提供自己的实现。JDK也需要提供些默认的参考实现。例如，Java中JNDI、JDBC、文件系统、 Cipher等很多方面，都是利用的这种机制，这种情况就不会用双亲委派模型去加载，而是利用所谓的上下文加载器
  • 可见性，子类加载器可以访问父加载器加载的类型，但是反过来是不允许的。不然，因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑
  • 单一性，由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载。但是注意，类加载器“邻居”间，同一类型仍然可以被加载多次，因为互相并不可见

类加载器的分类

  • JVM支持两种类型的类加载器，分别为引导类加载器(Bootstrap Classloader)和自定义类加载器(User-Defined Classloader)

  • 从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。

  • 无论类加载器的类型如何划分，在程序中我们最常见的类加载器结构主要是如下情况

类加载器

  • 除了顶层的启动类加载器外，其余的类加载器都应当有自己的“父类”加载器
  • 不同类加载器看似是继承（Inheritance）关系，实际上是包含关系。在下层加载器中，包含着上层加载器的引用。

引导类加载器

启动类加载器（引导类加载器，Bootstrap ClassLoader）

  • 这个类加载器使用C/C++语言实现的，嵌套在JVM内部
  • 它用来加载Java的核心库（ JAVA HOME/jre/lib/rt.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
  • 并不继承自java.lang. ClassLoader，没有父加载器
  • 出于安全考虑， Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
  • 加载扩展类和应用程序类加载器，并指定为他们的父类加载器。

扩展类加载器

扩展类加载器（Extension ClassLoader）

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

系统类加载器

  • 应用程序类加载器（系统类加载器， AppClassLoader）
  • java语言编写，由sun.misc.Launcher.$AppClassLoader实现
  • 继承于ClassLoader类
  • 父类加载器为扩展类加载器
  • 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
  • 应用程序中的类加载器默认是系统类加载器。
  • 它是用户自定义类加载器的默认父加载器
  • 通过ClassLoader的getSystemClassLoader()方法可以获取到该类加载器

用户自定义类加载器

用户自定义类加载器

  • 在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的。在必要时，我们还可以自定义类加载器，来定制类的加载方式
  • 体现Java语言强大生命力和巨大魅力的关键因素之一便是，Java开发者可以自定义类加载器来实现类库的动态加载加载源可以是本地的JAR包，也可以是网络上的远程资源
  • 通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现
  • 同时，自定义加载器能够实现应用隔离，例如 Tomcat, Spring等中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C++程序要好太多，想不修改c/C++程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想
  • 自定义类加载器通常需要继承于Classloader

ClassLoader源码

双亲委派机制

  • 类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。
  • 如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。
  • 规定了类加载的顺序是：引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载

双亲委派机制加载过程

优势与劣势

两点优势

  • 避免类的重复加载，确保一个类的全局唯一性。
  • 保护程序安全，防止核心API被随意篡改

代码方面的体现

双亲委派机制在java.lang.ClassLoader.loadClass（String, boolean）接口中体现。该接口的逻辑如下
（1）先在当前加载器的缓存中查找有无目标类，如果有，直接返回。
（2）判断当前加载器的父加载器是否为空。如果不为空，则调用 parent.loadClass(name, false)接口进行加载
（3）反之，如果当前加载器的父类加载器为空，则调用findBootstrapClassOrNull(name)接口，让引导类加载器进行
（4）如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载，该接口最终会调用java.lang.Classloader接口的definedClass系列的 native接口加载目标Java类

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

思考

  • 如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)或java.lang.ClassLoader.loadClass(String, boolean)方法，抹去其中的双亲委派机制，仅保留上面这4步中的第1步与第4步，那么是不是就能够加载核心类库了呢？
  • 这也不行！因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器抑或扩展类加载器，最终都必须调用java.lang.Classloader.defineclass(String, byte[], int, int, ProtectionDomain）方法，而该方法会执行**preDefinedClass()**接口，该接口中提供了对JDK核心类库的保护

弊端

  • 检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类
  • 通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

结论

  • 由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已
  • 比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法

三次双亲委派机制的破坏

  • 双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式
  • 在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主出现过3次较大规模“被破坏”的情况

第一次破坏双亲委派机制

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

第二次破坏双亲委派机制

线程上下文类加载器

  • 双亲委派模型的第二次的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码那该怎么办呢？
  • 这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK1.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的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK6时，JDK提供了java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。

第三次破坏双亲委派机制

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如：代码热替换（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）否则，类查找失败

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

  • 这里，我们使用了“被破坏”这个词来形容上述不符合双亲委派模型原则的行为，但这里“被破坏”并不一定是带有贬义的。只要有明确的目的和充分的理由，突破旧有原则无疑是一种创新
  • 正如：OSGi中的类加载器的设计不符合传统的双亲委派的类加载器架构，且业界对其为了实现热部署而带来的额外的高复杂度还存在不少争议，但对这方面有了解的技术人员基本还是能达成一个共识，认为OSGi中对类加载器的运用是值得学习的，完全弄懂了OSGi的实现，就算是掌握了类加载器的精粹。

热替换的实现

  • 热替换是指在程序的运行过程中，不停止服务，只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断，修改必须立即表现正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的，比如：PHP，只要替换了PHP源文件，这种改动就会立即生效，而无需重启Web服务器。
  • 但对Java来说，热替换并非天生就支持，如果一个类已经加载到系统中，通过修改类文件，并无法让系统再来加载并重定义这个类，因此，在Java中实现这一功能的一个可行的方法就是灵活运用ClassLoader
  • 注意：由不同ClassLoader加载的同名类属于不同的类型，不能相互转换和容，即两个不同的Classloader加载同一个类，在虚拟机内部，会认为这2个类是完全不同的。
  • 根据这个特点，可以用来模拟热替换的实现，基本思路如下图所示：

热替换示意图

沙箱安全机制

  • 保证程序安全
  • 保护Java原生的JDK代码

Java安全模型的核心就是Java沙箱（sandbox）

  • 什么是沙箱？沙箱是一个限制程序运行的环境

  • 沙箱机制就是将Java代码限定在JVM特定的运行范围中，并且严格限制代码对本地系统资源访问。通过这样的措施来保证对代码的有限隔离，防止对本地系统造成破坏。

  • 沙箱主要限制系统资源访问，那系统资源包括什么？CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样

  • 所有的Java程序运行都可以指定沙箱，可以定制安全策略

JVM诊断工具——命令行

jps：查看正在运行的Java进程

基本情况

  • jps（Java Process Status）：显示指定系统内所有的 HotSpot虚拟机进程（查看虚拟机进程信息），可用于查询正在运行的虚拟机进程。
  • 说明：对于本地虚拟机进程来说，进程的本地虚拟机ID与操作系统的进程ID是一致的，是唯一的。

基本语法

jps [options] [hostid]

options参数

  • -q：仅仅显示LVMID（local virtual machine id），即本地虚拟机唯一id。不显示主类的名称等
  • -l：输出应用程序主类的全类名 或 如果进程执行的是jar包，则输出jar完整路径
  • -m：输出虚拟机进程启动时传递给主类main()的参数
  • -v：列出虚拟机进程启动时的JVM参数。比如：-Xms20m -Xmx50m是启动程序指定的jvm参数。
  • 说明：以上参数可以综合使用
  • 补充：如果某Java进程关闭了默认开启的UsePerfData参数（即使用参数-XX: -UsePerfData），那么jps命令（以及下面介绍的jtat）将无法探知该Java进程。

hostid参数

  • RMI注册表中注册的主机名。
  • 如果想要远程监控主机上的java程序，需要安装jstatd
  • 对于具有更严格的安全实践的网络场所而言，可能使用一个自定义的策略文件来显示对特定的可信主机或网络的访问，尽管这种技术容易受到IP地址欺诈攻击。
  • 如果安全问题无法使用一个定制的策略文件来处理，那么最安全的操作是不运行jstatd服务器，而是在本地使用jstat和jps工具

jstat：查看JVM统计信息

基本情况

  • jstat（JVM Statistics Monitoring Tool）：用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、 JIT编译等运行数据。
  • 在没有GUI图形界面，只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的首选工具。常用于检测垃圾回收问题以及内存泄漏问题。

基本语法

jstat -<option> [-t] [-h<lines] <vmid> [<interval> [<count>]]

interval参数：用于指定输出统计数据的周期，单位为毫秒。即查询间隔

count参数：用于指定查询的总次数。

-t参数：在输出信息前加上程序运行的Timestamp。

-h参数：周期性地输出多少行加上表头信息。

option参数

  • 类装载相关的：
    • -class：显示ClassLoader的相关信息，类的装载、卸载数量、总空间、类装载所消耗的时间等。
  • 垃圾回收相关的：
    • -gc：显示与GC相关的堆信息。包括Eden区、两个Survivor区、老年代、永久代等的容量、已用空间、GC时间合计等信息。
    • -gccapacity：显示内容与-gc基本相同，但输出主要关注Java堆各个区域使用到的最大、最小空间。
    • -gcutil：显示内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比。
    • -gccause：与-gcutil功能一样，但是会额外输出导最后一次或当前正在发生的GC产生的原因。
    • -gcnew：显示新生代GC状况。
    • -gcnewcapacity：显示内容与-gcnew基本相同，输出主要关注使用到的最大、最小空间。
    • -gcold：显示老年代GC状况。
    • -gcoldcapacity：显示内容与gcold基本相同，输出主要关注使用到的最大、最小空间。
    • -gcpermcapacity：显示永久代使用到的最大、最小空间。
  • JIT相关的：
    • -compiler：显示JIT编译器编译过的方法、耗时等信息。
    • -printcompilation：输出已经被JIT编译的方法。

经验：

  • 我们可以比较Java进程的启动时间以及总GC时间（GCT列），或者两次测量的间隔时间以及总GC时间的增量，来得出GC时间占运行时间的比例。
  • 如果该比例超过20%，则说明目前堆的压力较大；如果该比例超过90%，则说明堆里几乎没有可用空间，随时都可能抛出OOM异常。

补充：

  • jstat还可以用来判断是否出现内存泄漏
  • 第1步：在长时间运行的Java程序中，我们可以运行jstat命令连续获取多行性能数据，并取这几行数据中OU列（即已占用的老年代内存）的最小值。
  • 第二步：然后，我们每隔一段较长的时间重复一次上述操作，来获得多组OU最小值。如果这些值呈上涨趋势，则说明该Java程序的老年代内存己使用量在不断上涨，这意味着无法回收的对象在不断增加，因此很有可能存在内存泄漏。

jinfo：实时查看和修改JVM配置参数

基本情况

  • jinfo（Configuration Info for Java）：查看虚拟机配置参数信息，也可用于调整虚拟机的配置参数。
  • 在很多情况下，Java应用程序不会指定所有的Java虚拟机参数。而此时，开发人员可能不知道某一个具体的Java虚拟机参数的默认值。在这种情况下，可能需要通过查找文档获取某个参数的默认值。这个查找过程可能是非常艰难的。但有了jinfo工具，开发人员可以很方便地找到Java虚拟机参数的当前值。

基本语法

jinfo [options] pid

options参数

选项说明
no option输出全部的参数和系统属性
-flag name输出对应名称的参数
-flag[+ -] name开启或关闭对应名称的参数，只有被标记为manageable的参数才可以被动态修改
-flag name=value设定对应名称的参数
-flags输出全部的参数
-sysprops输出系统属性
查看
  • jinfo -sysprops PID：可以查看由System.getProperties()取得的参数。
  • jinfo -flags PID：查看曾经赋过值的一些参数。
  • jinfo -flag 具体参数 PID：查看某个java进程的具体参数的值。
修改
  • 针对boolean类型：jinfo -flag[+ -] 具体参数 PID
  • 针对非boolean类型：jinfo -flag 具体参数=具体参数值 PID
拓展
  • java -XX:+PrintFlagsIntial：查看所有JVM参数启动的初始值。
  • java -XX:+PrintFlagsFinal：查看偶有JVM参数的最终值。
  • java -XX:+PrintCommandLineFlags：查看已经被用户或jVM设置过的详细的XX参数的名称和值。

jmap：导出内存映像文件&内存使用情况

基本情况

  • jmap（JVM Memory Map）：作用一方面是获取dump文件（堆转储快照文件，二进制文件）
  • 它还可以获取目标Java进程的内存相关信息，包括Java堆各区域的使用情况、堆中对象的统计信息、类加载信息等。
  • 开发人员可以在控制台中输入命令"jmap -help"查阅jmap工具的具体使用方式和一些标准选项配置。

基本语法

jmap [option] <pid>
jmap [option] <executable> <core>
jmap [option] [server_id@] <remote server IP or hostname>

option参数

选项说明
-dump生成dump文件
-finalizerinfo以ClassLoader为统计口径输出永久代的内存状态信息
-heap输出整个堆空间的详细信息，包括GC的使用、堆配置信息，以及内存的使用信息等
-histo输出堆空间中对象的统计信息，包括类、实例数量和合计容量
-permstat以ClassLoader为统计口径输出永久代的内存状态信息
-F当虚拟机进程对-dump选项没有任何响应时，强行执行生成dump文件

jhat：JDK自带堆分析工具

基本情况

  • jhat（JVM Heap Analysis Tool）：Sun JDK提供的jhat命令与jmap命令搭配使用，用于分析jmap生成的heap dump文件（堆转储快照）。jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，用户可以在浏览器中查看分析结果（分析虚拟机转储快照信息）。
  • 使用了jat命令，就启动了一个http服务，端口是700，即http://localhost:7000/就可以在浏览器里分析。
  • 说明：jhat命令在JDK9、JDK10中已经被删除，官方建议用 VisualVM代替

jstack：打印JVM中线程快照

基本情况

  • jstack（JVM Stack Trace）：用于生成虚拟机指定进程当前时刻的线程快照（虚拟机堆栈跟踪）。线程快照就是当前虚拟机内指定进程的每一条线程正在执行的方法堆栈的集合。
  • 生成线程快照的作用：可用于定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等问题。这些都是导致线程长时间停顿的常见原因。当线程出现停顿时，就可以用jstack显示各个线程调用的堆栈情况。
  • 在thread dump中，要留意下面几种状态
    • 死锁，Deadlock（重点关注）
    • 等待资源，Waiting on condition（重点关注）
    • 等待获取监视器，Waiting on monitor entry（重点关注）
    • 阻塞，Blocked（重点关注）
    • 执行中，Runnable
    • 暂停， Suspended

基本语法

jstack option pid

option参数

  • -F：当正常输出的请求不被响应时，强制输出线程堆栈。
  • -l：除堆栈外，显示关于锁的附加信息。
  • -m：如果调用本地方法，可以显示C/C++的堆栈。
  • -h：帮助作用。

jcmd：多功能命令行

基本情况

  • 在JDK1.7以后，新增了一个命令行工具jcmd。
  • 它是一个多功能的工具，可以用来实现前面除jstat之外所有命令的功能。比如用它来导出堆、内存使用、查看Java进程、导出线程信息、执行GC、JVM运行时间等
  • jcmd拥有jmap的大部分功能，并且在Oracle的官方网站上也推荐使用jcmd命令代jmap命令

基本语法

  • jcmd：列出所有的JVM进程。
  • jcmd pid help：针对指定的进程，列出支持的所有命令。
  • jcmd pid 具体命令：显示指定进程的指令命令的数据。

jstatd：远程主机信息收集

  • 之前的指令只涉及到监控本机的Java应用程序，而在这些工具中，一些监控工具也支持对远程计算机的监控（如jps、 jstat）。为了启用远程监控，则需要配合使用jstatd工具。
  • 命令jstatd是一个RMI服务端程序，它的作用相当于代理服务器，建立本地计算机与远程监控工具的通信。 jstatd服务器将本机的Java应用程序信息传递到远程计算机。

JVM诊断工具——GUI篇

gezq0601
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Jni函数调用
kangyaping的专栏
07-04 2万+
Chap1:JNI完全手册... 3 Chap2:JNI-百度百科... 11 Chap 3：javah命令帮助信息... 16 Chap 4：用javah产生一个.h文件... 17 Chap5:jni教程(very very good) 19 Chap6: JNI传递返回值... 26 15.2.2.3 传递字符串... 28 15.2.2.4 传递整型数组... 29 15.
[options] 未与 -source 11 一起设置系统模块路径
weixin_42593549的博客
01-05 390
[options] 未与 -source 11 一起设置系统模块路径。这意味着在执行操作时，没有正确地设置用于查找系统模块的路径。这可能会导致无法找到或加载某些模块，从而导致程序运行出错。应当确保 -source 11 参数和正确的路径一起使用，以确保能够正常访问系统模块。 ...
配置android source 在ubuntu中编译环境
weixin_33881140的博客
08-05 44
在Ubuntu中可以配置 android source 编译环境，推荐使用最新的64位的Ubuntu LTS（Long Time Support）; 1.安装JDK。 AOSP主分支代码需要java7，在Ubuntu上可以使用 OpenJDK。 安装java7的命令： $ sudo apt-get update $ sudo apt-get install openjdk-7-jdk...
Jni函数调用大全
悲剧的程序猿
05-18 2415
Chap1:JNI完全手册... 3 Chap2:JNI-百度百科... 11 Chap 3：javah命令帮助信息... 16 Chap 4：用javah产生一个.h文件... 17 Chap5:jni教程(very very good) 19 Chap6: JNI传递返回值... 26 15.2.2.3 传递字符串... 28 15.2.2.4 传递整
JVM介绍
02-25
JVM是JavaVirtualMachine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机包括一套字节码指令集、一组寄存器、一...
jvm.options
07-28
jvm.options。。。elasticsearch的性能优化文件， jvm.options。。。elasticsearch的性能优化文件，
JVM思维导图
10-24
本思维导图整理了jvm学习内容，包括jvm内存模型、safepoint、java类加载、java类加载器、内存分配策略、GC判定方式、GC收集方法、GC收集器、GC发生条件、GC回收机制，可以以图学习，更容易吸收和了解。
JVM深入笔记
03-04
JVM是一个从事Java开发的软件工程师的修炼之路上必然要翻阅的一座山。当你了解了Java的基本语言特性，当你熟悉了JavaSDK中的常用API，当你写过一些或大或小的程序后，你就会有去了解JVM的需求出现。如果你现在没有...
jni函数说明
xiatiancc的专栏
04-17 4790
Chap1:JNI完全手册... 3 Chap2:JNI-百度百科... 11 Chap 3：javah命令帮助信息... 16 Chap 4：用javah产生一个.h文件... 17 Chap5:jni教程(very very good) 19 Chap6: JNI传递返回值... 26 15.2.2.3 传递字符串... 28 15.2.2.4 传递整型数组 ... 29 15
Mac中下载JDK手动更新出现“只支持10.7.3以上的系统版本”问题解决方案
weixin_30952535的博客
10-27 119
今天倒腾Hadoop，要修改源码，由于之前搞研究是基于hadoop1.0.3来做的，所以这次也用的这个版本，但是我电脑上Java的版本是1.8以上的，结果用ant编译hadoop源码报错，错误大概是这样： compile-mapred-classes: Trying to override old definition of task jsp-compile [javac] /U...
java JDK 基本命令集
夏沐的博客
11-15 433
java -help 用法: java [-options] class [args...] (执行类) 或 java [-options] -jar jarfile [args...] (执行 jar 文件) 其中选项包括: -d32 使用 32 位数据模型 (如果可用) -d64 使用 6...
IntelliJ编译时，致命错误：在路径和启动路径中找不到包java.lang
programmer_at的专栏
03-06 9138
基础知识主要是发现自己的Java没有安装成功：……\Java\jdk1.8.0_121\lib里面没有tools.jar，dt.jar而假如正确安装的话，dt.jar和tools.jar位于：{Java_Home}/lib/下，而rt.jar位于：{Java_Home}/jre/lib/下, {Java_Home}对应的本文的是……\Java\jdk1.8.0_121rt.jar是JAVA基础类库
web项目ant打包完整案例
無形的畫筆
12-13 4933
前两周做的web项目要部署到服务器上去，为了后续升级部署方便，决定采用Ant进行(开发用的myeclipse 8.5),ant打包测试也是在myeclipse上进行，build.xml测试完成后地通过本地配置的ant进行手工打包:ant -buildfile build.xml.下面将相关过程简单总结如下:    (1)运用myeclipse对web项目打war包,观察其他结构和组成,方便a
MAVEN编译报错： 警告: [options] 未与 -source 1.7 一起设置引导类路径
热门推荐
张伯毅的专栏
12-04 3万+
异常： ERROR] 警告: [options] 未与 -source 1.7 一起设置引导类路径 [ERROR] /workspace/spark-2.2.2/common/network-common/src/main/java/org/apache/spark/network/client/TransportClient.java:144: 错误: -source 1.7 中不...
tomcat jvm
最新发布
04-10
Tomcat是一个开源的Java Servlet容器，它实现了Java Servlet和JavaServer Pages（JSP）规范。它是一个用于构建和部署Java Web应用程序的服务器。 JVM（Java虚拟机）是Java程序的运行环境，它是Java语言的核心部分。JVM负责将Java字节码翻译成机器码并执行。Tomcat运行在JVM上，它使用JVM来解释和执行Servlet和JSP代码。 Tomcat和JVM之间的关系是这样的：Tomcat作为一个独立的进程运行在JVM上，它通过调用JVM来执行Java Web应用程序中的代码。当Tomcat启动时，它会创建一个JVM实例，并加载应用程序的类和资源。然后，Tomcat使用JVM来处理HTTP请求，并将结果返回给客户端。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值