JAVA类加载器

java文件编译成二进制字节码class文件

class文件再通过类加载器加载到JVM的永久代（jdk8以后就变成了Metaspace元数据，这里说一下，永久代跟元数据都是实现方法区的手段，方法区是一种规范）

应用启动时，通过方法区中类的元信息，静态变量，静态方法（想当于制造对象的说明书）创建对象。

类加载的过程

加载

加载指的是将类的class文件读入到内存，并为之创建一个java.lang.Class对象，也就是说，当程序中使用任何类时，系统都会为之建立一个java.lang.Class对象。

类的加载由类加载器完成，类加载器通常由JVM提供，这些类加载器也是前面所有程序运行的基础，JVM提供的这些类加载器通常被称为系统类加载器。除此之外，开发者可以通过继承ClassLoader基类来创建自己的类加载器。

通过使用不同的类加载器，可以从不同来源加载类的二进制数据，通常有如下几种来源。

• 从本地文件系统加载class文件，这是前面绝大部分示例程序的类加载方式。
• 从JAR包加载class文件，这种方式也是很常见的，前面介绍JDBC编程时用到的数据库驱动类就放在JAR文件中，JVM可以从JAR文件中直接加载该class文件。
• 通过网络加载class文件。
• 把一个Java源文件动态编译，并执行加载。

类加载器通常无须等到“首次使用”该类时才加载该类，Java虚拟机规范允许系统预先加载某些类。

类加载时机

• 创建类的实例，也就是new一个对象

• 访问某个类或接口的静态变量，或者对该静态变量赋值

• 调用类的静态方法

• 反射（Class.forName("com.lyj.load")）

• 初始化一个类的子类（会首先初始化子类的父类）

• JVM启动时标明的启动类，即文件名和类名相同的那个类

• 除此之外，下面几种情形需要特别指出：

  对于一个final类型的静态变量，如果该变量的值在编译时就可以确定下来，那么这个变量相当于“宏变量”。Java编译器会在编译时直接把这个变量出现的地方替换成它的值，因此即使程序使用该静态变量，也不会导致该类的初始化。反之，如果final类型的静态Field的值不能在编译时确定下来，则必须等到运行时才可以确定该变量的值，如果通过该类来访问它的静态变量，则会导致该类被初始化。

类加载机制

• 全盘负责：所谓全盘负责，就是当一个类加载器负责加载某个Class时，该Class所依赖和引用其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
• 双亲委派：所谓的双亲委派，则是先让父类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。
• 缓存机制：缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区中搜寻该Class，只有当缓存区中不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓冲区中。这就是为很么修改了Class后，必须重新启动JVM，程序所做的修改才会生效的原因。

双亲委派机制

双亲委派模型的工作过程如下：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都会传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求（它的搜索范围内没找到这个类）时，自加载器才会尝试自己加载。

双亲委派模型是为了保证 Java 核心库的类型安全。所有 Java 应用都至少需要引用 java.lang.Object类，也就是说在运行的时候，java.lang.Object这个类需要被加载到 Java 虚拟机中。如果这个加载过程由 Java 应用自己的类加载器来完成的话，很可能就存在多个版本的 java.lang.Object类，而且这些类之间是不兼容的。通过双亲委派模型，对于 Java 核心库的类的加载工作由启动类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。

不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。

深入理解双亲委派机制

首先是两个术语：在前面介绍类加载器的双亲委派模型的时候，提到过类加载器会首先代理给其它类加载器来尝试加载某个类。这就意味着真正完成类的加载工作的类加载器和启动这个加载过程的类加载器，有可能不是同一个。真正完成类的加载工作是通过调用defineClass来实现的；而启动类的加载过程是通过调用loadClass来实现的。前者称为一个类的定义加载器（defining loader），后者称为初始加载器（initiating loader）。

注意：初始类加载器对于一个类来说经常不是一个，比如String类在加载的过程中，先是交给系统类加载器加载，但是系统类加载器代理给了扩展类加载期，扩展类加载器又代理给了引导类加载器，最后由引导类加载器加载完成，那么这个过程中的定义类加载器就是引导类加载器，但是初始类加载器是三个（系统类加载器、扩展类加载器、引导类加载器），因为这三个类加载器都调用了loadClass方法，而最后的引导类加载器还调用了defineClass方法。

JVM为每个类加载器维护的一个“表”,这个表记录了所有以此类加载器为“初始类加载器”（而不是定义类加载器，所以一个类可以存在于很多的命名空间中）加载的类的列表。属于同一个列表的类可以互相访问。这就可以解释为什么上层的类加载器加载的类无法访问下层类加载器加载的类，但是下层的类加载器加载的类可以访问上层类加载器加载的类？的疑问了。

在 Java 虚拟机判断两个类是否相同的时候，使用的是类的定义加载器。也就是说，哪个类加载器启动类的加载过程并不重要，重要的是最终定义这个类的加载器。两种类加载器的关联之处在于：一个类的定义加载器是它引用的其它类的初始加载器。如类 com.example.Outer引用了类com.example.Inner，则由类 com.example.Outer的定义加载器负责启动类 com.example.Inner的加载过程。

逆向使用类加载器（上级加载器加载类调用下级类加载器加载类）

线程上下文类加载器（ThreadContextClassLoader，下文使用TCCL表示）

Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。

这些 SPI 的接口由 Java 核心库来提供，而这些 SPI 的实现代码则是作为 Java 应用所依赖的 jar 包被包含进类路径（CLASSPATH）里。SPI接口中的代码经常需要加载具体的实现类。那么问题来了，SPI的接口是Java核心库的一部分，是由启动类加载器(Bootstrap Classloader)来加载的；*SPI的实现类*是由系统类加载器(System ClassLoader)来加载的。引导类加载器是无法找到 SPI 的实现类的，因为依照双亲委派模型，BootstrapClassloader无法委派AppClassLoader来加载类。

而线程上下文类加载器破坏了“双亲委派模型”，可以在执行线程中抛弃双亲委派加载链模式，使程序可以逆向使用类加载器。

JDBC案例分析

// 加载Class到AppClassLoader（系统类加载器），然后注册驱动类
// Class.forName("com.mysql.jdbc.Driver").newInstance(); 
String url = "jdbc:mysql://localhost:3306/testdb";    
// 通过java库获取数据库连接
Connection conn = java.sql.DriverManager.getConnection(url, "name", "password"); 

以上就是mysql注册驱动及获取connection的过程，各位可以发现经常写的Class.forName被注释掉了，但依然可以正常运行，这是为什么呢？这是因为从Java1.6开始自带的jdbc4.0版本已支持SPI服务加载机制，只要mysql的jar包在类路径中，就可以注册mysql驱动。

那到底是在哪一步自动注册了mysql driver的呢？重点就在DriverManager.getConnection()中。我们都是知道调用类的静态方法会初始化该类，进而执行其静态代码块，

DriverManager的静态代码块就是：

  /**
     * Load the initial JDBC drivers by checking the System property
     * jdbc.properties and then use the {@code ServiceLoader} mechanism
     */
    static {
        loadInitialDrivers();
        println("JDBC DriverManager initialized");
    }

初始化方法loadInitialDrivers()的代码如下：

    private static void loadInitialDrivers() {
        String drivers;
        try {
            drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
                public String run() {
                    return System.getProperty("jdbc.drivers");
                }
            });
        } catch (Exception ex) {
            drivers = null;
        }
        // If the driver is packaged as a Service Provider, load it.
        // Get all the drivers through the classloader
        // exposed as a java.sql.Driver.class service.
        // ServiceLoader.load() replaces the sun.misc.Providers()

        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {

                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                Iterator<Driver> driversIterator = loadedDrivers.iterator();
                try{
                    while(driversIterator.hasNext()) {
                        driversIterator.next();
                    }
                } catch(Throwable t) {
                // Do nothing
                }
                return null;
            }
        });

        println("DriverManager.initialize: jdbc.drivers = " + drivers);

        if (drivers == null || drivers.equals("")) {
            return;
        }
        String[] driversList = drivers.split(":");
        println("number of Drivers:" + driversList.length);
        for (String aDriver : driversList) {
            try {
                println("DriverManager.Initialize: loading " + aDriver);
                Class.forName(aDriver, true,
                        ClassLoader.getSystemClassLoader());
            } catch (Exception ex) {
                println("DriverManager.Initialize: load failed: " + ex);
            }
        }
    }

从上面可以看出JDBC中的DriverManager的加载Driver的步骤顺序依次是：

1. 通过SPI方式，读取 META-INF/services 下文件中的类名，使用TCCL加载；
2. 通过System.getProperty("jdbc.drivers")获取设置，然后通过系统类加载器加载。

开发自己的类加载器

package com.qhong.basic.classLoader;

import java.io.IOException;
import java.io.InputStream;

/**
 * @author qhong
 * @date 2020/3/17 21:08
 **/
public class ClassLoaderTest {
	public static void main(String[] args) throws Exception{
		ClassLoader loader=new ClassLoader() {
			@Override
			public Class<?> loadClass(String name)throws ClassNotFoundException{
				try{
					String filename=name.substring(name.lastIndexOf(".")+1)+".class";
					InputStream is=getClass().getResourceAsStream(filename);
					if(is==null){
						return super.loadClass(name);
					}
					byte[] b=new byte[is.available()];
					is.read(b);
					return defineClass(name,b,0,b.length);
				}catch(IOException e){
					throw new ClassNotFoundException(name);
				}
			}
		};
		Object obj=loader.loadClass("com.qhong.basic.classLoader.ClassLoaderTest").newInstance();
		System.out.println(obj.getClass());
		System.out.println(obj.getClass().getClassLoader());
		System.out.println(loader);
		System.out.println(ClassLoaderTest.class.getClassLoader());
		System.out.println(obj instanceof ClassLoaderTest);

		System.out.println(
				Class.forName("com.qhong.basic.classLoader.ClassLoaderTest").newInstance().getClass().getClassLoader());

		System.out.println(Class.forName("com.qhong.basic.classLoader.ClassLoaderTest", true, loader).getClassLoader());
	}
}

output:

class com.qhong.basic.classLoader.ClassLoaderTest
com.qhong.basic.classLoader.ClassLoaderTest$1@1e80bfe8
com.qhong.basic.classLoader.ClassLoaderTest$1@1e80bfe8
sun.misc.Launcher$AppClassLoader@18b4aac2
false
sun.misc.Launcher$AppClassLoader@18b4aac2
com.qhong.basic.classLoader.ClassLoaderTest$1@1e80bfe8

参考：

一篇文章读懂Java类加载器

细说JVM（类加载器）

jvm之java类加载机制和类加载器(ClassLoader)的详解

JVM（十五）深入理解线程上下文类加载器

真正理解线程上下文类加载器（多案例分析）