JVM-01-类加载子系统

综述

以上两张图分别从简到全的描述了JVM虚拟机的内存结构

类加载子系统作用

类加载子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。
ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。
加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

类的加载过程

加载阶段（装载）

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

补充：加载.class文件的方式

从本地系统中直接加载
通过网络获取，典型场景：Web Applet
从zip压缩包中读取，称为日后jar、war格式的基础
运行时计算生成，使用最多的是：动态代理技术
由其他文件生成，典型场景：JSP应用
从专有数据库中提取.class文件，比较少见
从加密文件中获取，典型的防Class文件被反编译的保护措施

链接阶段

验证Verify

目的在于确保class文件的字节流中包含信息符合当前虚拟机的要求，保证被加载类的正确性，不会危害虚拟机自身安全。
主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。
- 格式检查:是否以魔数0xCAFEBABE开头，主版本和副版本是否在当前Java虚拟机的支持范围内，数据中每一项是否都拥有正确的长度等

准备Prepare

为类变量分配内存并且设置该类变量的默认初始值，即零值
- 这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化
```
例如这段代码：
  public class Hello{
    private static int a = 1; //prepare:a=0; initial阶段:a=1
  }
```
这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中

解析Resolve

将常量池内的符号引用转换为直接引用的过程
事实上，解析操作往往会随着JVM在执行完初始化之后再执行
- 虚拟机在加载Class文件时才会进行动态链接,也就是说,Class文件中不会保存各个方法和字段的最终内存布局信息,因此,这些字段和方法的符号引用不经过转换是无法直接被虚拟机使用的。当虚拟机运行起来时,需要从常量池中获得对应的符号引用,再在类加载过程中(初始化阶段)将其替换直接引用,并翻译到具体的内存地址中
符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中，符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到了内存中
直接引用就是直接指向目标的指针，相对偏移量或一个间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用不会相同。如果有了直接引用，就说明引用的目标必定已经存在于内存之中了。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。
不过Java虚拟机规范并没有明确要求解析阶段一定要按照顺序执行。在HotSpot VM中,加载、验证、准备和初始化会按照顺序有条不紊地执行,但链接阶段中的解析操作往往会伴随着JVM在执行完初始化之后再执行
符号引号有:类和接口的权限定名、字段的名称和描述符、方法的名称和描述符
符号引用和直接引用

1.会议室里有个空的位子没坐人，座位前写着xxx的座位(符号引用),后来xxx进来坐下去摘掉牌子（符号引用换成直接引用）
2.我们去做菜,看菜谱,步骤都是什么样的(这是符号引号),当我们实际上去做,这个过程是直接引用

ex：
```
输出操作System.out.println()对应的字节码：
```
invokevirtual #24 <java/io/PrintStream.println>

以方法为例，Java虚拟机为每个类都准备了一张方法表，将其所有的方法都列在表中，当需要调用一个类的方法的时候，只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作，符号引用就可以转变为目标方法在类中方法表中的位置，从而使得方法被成功调用。

初始化阶段

初始化阶段就是执行类构造器<clinit>()的过程
- Java编译器并不会为所有的类都产生()初始化方法。以下情况下类在编译为字节码后，字节码文件中将不会包含<clinit>()方法：
- 一个类中并没有声明任何的类变量，也没有静态代码块时
- 一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时
- 一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式 (如果这个static final 不是通过方法或者构造器,则在链接阶段)
此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来

构造器方法中指令按语句在原文件中出现的顺序执行

    static{
        num = 100;
      	System.out.println(num); //error 非法的前向引用
    }

    private static int num = 1;

对应字节码文件为

0 bipush 100
2 putstatic #7 <com/zoran/Main.num>
5 iconst_1
6 putstatic #7 <com/zoran/Main.num>
9 return

<clinit>()不同于类构造器（关联：构造器是虚拟机视角下的<init>()）
若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕
```
public class ClinitTest1 {
    static class Father {
        public static int A = 1;
        static {
            A = 2;
        }
    }

    static class Son extends Father {
        public static int b = A;
    }

    public static void main(String[] args) {
        System.out.println(Son.b);
    }
}
```
上述代码的执行结果为2，也就是说类加载ClinitTest1时，执行Son的初始化，但由于Son继承了Father，因此去执行Father的初始化，同时A先后被赋值为1，2，最后返回

虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

public class DeadThreadTest {
    public static void main(String[] args) {
        new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + "	 线程t1开始");
            new DeadThread();
        }, "t1").start();

        new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + "	 线程t2开始");
            new DeadThread();
        }, "t2").start();
    }
}
class DeadThread {
    static {
        if (true) {
            System.out.println(Thread.currentThread().getName() + "	 初始化当前类");
            while(true) {

            }
        }
    }
}

输出结果为
```
线程t1开始
线程t2开始
线程t2 初始化当前类
```
从上面可以看出初始化后，只能够执行一次初始化，这也就是同步加锁的过程。因此,如果在一个类的<clinit>()方法中有耗时很长的操作,就可能造成多个线程阻塞,引发死锁。并且这种死锁是很难发现的,因为看起来它们并没有可用的锁信息。

关于static final修饰的类变量

使用static + final修饰的字段的显式赋值的操作

情况1：在链接阶段的准备环节赋值

对于基本数据类型的字段来说，如果使用static final修饰，则显式赋值(直接赋值常量，而非调用方法）通常是在链接阶段的准备环节进行

对于String来说，如果使用字面量的方式赋值，使用static final修饰的话，则显式赋值通常是在链接阶段的准备环节进行

情况2：在初始化阶段<clinit>()中赋值

排除上述的在准备环节赋值的情况之外的情况。

最终结论：使用static + final修饰，且显示赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显式赋值，是在链接阶段的准备环节进行。
public static int a = 1;//在初始化阶段<clinit>()中赋值
public static final int INT_CONSTANT = 10;//在链接阶段的准备环节赋值

public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100);//在初始化阶段<clinit>()中赋值
public static Integer INTEGER_CONSTANT2 = Integer.valueOf(1000);//在初始化阶段<clinit>()中赋值

public static final String s0 = "helloworld0";//在链接阶段的准备环节赋值
public static final String s1 = new String("helloworld1");//在初始化阶段<clinit>()中赋值

public static String s2 = "helloworld2";
public static final int NUM1 = new Random().nextInt(10);//在初始化阶段<clinit>()中赋值

类加载器分类

上图的四者之间是包含关系，不是上层和下层，也不是子系统的继承关系。

JVM支持两种类型的类加载器。分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。

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

        // 获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);//sun.misc.Launcher$AppClassLoader@18b4aac2

        // 获取其上层的：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);//sun.misc.Launcher$ExtClassLoader@1540e19d

        // 试图获取 根加载器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader);//null

        // 获取自定义类的加载器
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(classLoader);//sun.misc.Launcher$AppClassLoader@18b4aac2
        
        // 获取String类型的加载器
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1);//null

引导类加载器(Bootstrap ClassLoader)

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

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

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

扩展类加载器（Extension ClassLoader）

Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。
派生于ClassLoader类
父类加载器为启动类加载器

从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/1ib/ext子目录（扩展目录）下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。

        System.out.println("*********扩展类加载器************");
        String extDirs = System.getProperty("java.ext.dirs");
        for (String s : extDirs.split(":")) {
            System.out.println(s);
        }

*********扩展类加载器************
/Users/zorantaylor/Library/Java/Extensions
/Library/Java/JavaVirtualMachines/jdk1.8.0_281.jdk/Contents/Home/jre/lib/ext
/Library/Java/Extensions
/Network/Library/Java/Extensions
/System/Library/Java/Extensions
/usr/lib/java

应用程序类加载器（系统类加载器，AppClassLoader）

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

用户自定义类加载器

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。为什么要自定义类加载器？

隔离加载类
修改类加载的方式
扩展加载源
防止源码泄漏

用户自定义类加载器实现步骤：

开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass()方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadclass()方法，而是建议把自定义的类加载逻辑写在findclass()方法中
在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findclass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

关于ClassLoader

ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）

方法名称	描述
getParent()	返回该类加载器的超类加载器
loadClass(String name)	加载名称为name的类，返回结果为java.lang.Class类的实例
findClass(String name)	查找名称为name的类，返回结果为java.lang.Class类的实例
findLoadedClass(String name)	查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例
defineClass(String name，byte[] b,int off,int len)	把字节数组b中的内容转换为一个Java类，返回结果为java.lang.Class类的实例
resolveClass(Class<?> c)	连接指定的一个java类

继承关系

获取ClassLoader的途径

获取当前ClassLoader:clazz.getClassLoader()
获取当前线程上下文的ClassLoader:Thread.currentThread().getContextClassLoader()
获取系统的ClassLoader:ClassLoader.getSystemClassLoader()
获取调用者的ClassLoader:DriverManager.getCallerClassLoader()

双亲委派

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

工作原理

如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。
- Ex1：我们自定义了一个java.lang包下的String尝试覆盖核心类库中的String，但是由于双亲委派机制，启动加载器会加载java核心类库的String类（BootStrap启动类加载器只加载包名为java、javax、sun等开头的类），而核心类库中的String并没有main方法
```
package java.lang;

public class String {
    public static void main(String[] args) {
        System.out.println("Hello");
    }
}
```
```
Error: Main method not found in class java.lang.String, please define the main method as:
   public static void main(String[] args)
or a JavaFX application class must extend javafx.application.Application
```
- Ex2:当我们加载jdbc.jar 用于实现数据库连接的时候，首先我们需要知道的是 jdbc.jar是基于SPI接口进行实现的，所以在加载的时候，会进行双亲委派，最终从根加载器中加载 SPI核心类，然后在加载SPI接口类，接着在进行反向委派，通过线程上下文类加载器进行实现类 jdbc.jar的加载。

双亲委派的优势

避免类的重复加载

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

自定义类：java.lang.String

自定义类：java.lang.MyStart（报错：阻止在java.lang包下创建新类）

Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang
	at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)

沙箱安全机制

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

补充内容

判断两个class对象是否相同

类的完整类名必须一致，包括包名。
加载这个类的ClassLoader（指ClassLoader实例对象）必须相同。

换句话说，在JVM中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的。

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

类的主动使用和被动使用

Java程序对类的使用方式分为：王动使用和被动使用。主动使用，又分为以下情况：

创建类的实例
访问某个类或接口的静态变量，或者对该静态变量赋值
调用类的静态方法
反射（比如：Class.forName（"com.zoran.Test"））
初始化一个类的子类(当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化)
Java虚拟机启动时被标明为启动类的类,包含main()方法的那个类
JDK7开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF getStatic、REF putStatic、REF invokeStatic句柄对应的类没有初始化，则初始化

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

public class DemoB implements A{
    static{
        System.out.println("子类初始化......");
    }
    public static void main(String[] args) {

    }
}
interface A{
    public static final Thread t = new Thread() {
        {
            System.out.println("CompareB的初始化");
        }
    };
    default void method1(){
        System.out.println("====");
    }
}

CompareB的初始化
子类初始化.....

而当我们注释掉default方法，则只会打印子类初始化

除了以上情况，其他使用Java类的方式都被看作是对类的被动使用，都不会导致类的初始化，意味着没有<clinit>()的调用。

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