系统、当前、线程上下文类加载概念介绍？

概念区分

在Java进行类加载时，一般会有多个ClassLoader可以使用，包括当前类加载器，指定类加载器，上下文类加载器三个，可以用多种方式进行类型加载，以下面这段代码来对这个三个概念进行说明：

class A{
    public void m(){
        A.class.getClassLoader().loaClass("B");
    }
}

上面的代码很简单，主要是为了说明下面三个概念：

CurrentClassLoader，称之为当前类加载器，简称CCL：在上面的代码中对应的就是类型A的类加载器。
SpecificClassLoader，称之为指定类加载器，简称SCL：在代码中对应的是A.class.getClassLoader()，如果使用任意的ClassLoader进行加载，这个ClassLoader都可以称之为SCL。
ThreadContextClassLoader，称之为线程上下文类加载器，简称TCCL：每个线程都可以通过Thread.currentThread().setContextClassLoader(ClassLoader)来进行切换。

SCL和TCCL都可以理解为在代码中使用CLassLoader的引用进行类加载，我们可以自定义。但是CCL的加载过程是由JVM运行时来控制的，是无法通过Java编程来更改的。

系统、当前、线程上下文类加载器，该如何选择

这个问题虽然不经常问到，但是这个问题却很难有一个正确的答案。一般来说，这个问题都来自于框架编程过程中需要动态的加载资源。一般来说，加载一个资源的时候，你会有至少三个CLassLoader可以用来加载资源，系统ClassLoader（AppClassLoader），当前CLassLoader和线程上下文ThreadContextClassLoader。如何去选择使用哪个CLassLoader呢？
首先应该被排除掉的应该是系统ClassLoader，这个就是main的入口，通过载入-classPath的资源来加载类，这段代码是从sun.mis.Launcher.AppClassLoader中摘抄：

public static ClassLoader getAppClassLoader(final ClassLoader var0) 
    throws IOException {

    final String var1 = System.getProperty("java.class.path");
    final File[] var2 = var1 == null ? new File[0] : Launcher.getClassPath(var1);

    return (ClassLoader)AccessController
        .doPrivileged(new PrivilegedAction<Launcher.AppClassLoader>() {
            public Launcher.AppClassLoader run() {
                URL[] var1x = var1 == null ? new URL[0] : Launcher.pathToURLs(var2);
                return new Launcher.AppClassLoader(var1x, var0);
            }
        });
}

其实AppClassLoader继承了URLClassLoader，它所做的工作，就是将java.class.path下的资源，转换为URL，然后加入到AppClassLoader中，除此没有别的特殊的地方。

能够通过静态方法ClassLoader.getSystemClassLoader()来获取到这个AppClassLoader。一般来说非常少的需求，需要获取到AppClassLoader，然后用它来加载一个类，因为都会使用其他的ClassLoader来加载类，并通过委派的方式到达AppClassLoader。

如果你编写的程序运行在ClassLoader是AppClassLoader的情况下，那么你的程序就只能在命令行下运行，因为你的程序需要依赖均在classpath下设置好，而如果将程序直接部署在WebApp容器中，那么肯定会出问题，因为webApp的一些资源并不在classPath下面。

接下来，只有两个选择了，当前ClassLoader和线程上下文ClassLoader，以下简称：CurrentClassLoader（CCL）和ThreadContextClassLoader（TCCL）。

当前类加载器

这里简单介绍一下这个仿佛看不到的CurrentClassLoader是如何出现的。在如下这段代码中：

class A {
     public void m() {
          B b = new B();
     }
}

B是如何加载的呢？其实等值于A.class.getClassLoader().loadClass(“B”);通过这种方式获取到B的类型。那么如果是这段代码：

class A {
     public void m() {
          Class<?> clazz = B.class;
     }
}

上面加载B的Class，相当于Class.forName("B")，而进入Class.forName()方法后，后续的载入会利用Class.class.getClassLoader().loadClass(“B”)，也就是利用bootstrap来载入B，但是事实上还是利用载入A的ClassLoader，也就是CurrentClassLoader来载入B，看一下Class.forName的实现：

public static Class<?> forName(String className)
                throws ClassNotFoundException {
    return forName0(className, true, ClassLoader.getClassLoader(Reflection.getCallerClass()));
}

Class.forName运作时，通过Reflection.getCallerClass()，能够获取是谁调用了Class.forName，这时 ClassLoader.getClassLoader()返回的就是当前ClassLoader，这就符合原有含义了。

通过Reflection.getCallerClass()可以获取到调用Class.forName的类的ClassLoader，从而虽然中间涉及到了bootstrap加载的类（Class），但是依旧能够维护当前这个语义。

Java自身除了通过Reflection.getCallerClass来获取调用的类的类型，在deSerialization中也需要知道类型的信息。在序列化后的内容中，已经包含了当前用户自定义类的类型信息，那么如何在ObjectInputStream调用中，能够拿到客户端的类型呢？通过调用Class.forName？肯定不可以，因为在ObjectInputStream中调用这个，会使用bootstrap来加载，那么它肯定加载不到所需要的类。
答案是通过查询栈信息，通过sun.misc.VM.latestUserDefinedLoader(); 获取从栈上开始计算，第一个不为空（bootstrap classloader是空）的ClassLoader便返回。
可以试想，在ObjectInputStream运作中，通过直接获取当前调用栈中，第一个非空的ClassLoader，这种做法能够非常便捷的定位用户的ClassLoader，也就是用户在进行：

1 2	ObjectInputStream ois = new ObjectInputStream(new FileInputStream(“xx.dat”)); B b = (B) ois.readObject();

这种调用的时候，依旧能够通过当前的ClassLoader正确的加载用户的类。

可以说Reflection.getCallerClass和sun.misc.VM.latestuserDefinedLoader都是用来突破双亲委派模型的一种解决方式，它能让Java在bootstrap加载的代码中运行时，能够获取到外界（用户）使用的子ClassLoader。

线程上下文类加载器

线程上下文类加载器（ThreadContextClassLoader）是从 JDK 1.2 开始引入的，我们可以通过java.lang.Thread类中的getContextClassLoader()和 setContextClassLoader(ClassLoader cl)方法来获取和设置线程的上下文类加载器。如果没有手动设置上下文类加载器，线程将继承其父线程的上下文类加载器，初始线程的上下文类加载器是系统类加载器（AppClassLoader）,在线程中运行的代码可以通过此类加载器来加载类和资源，
在介绍CurrentClassLoader中，已经说明它用来突破双亲委派模型的目的，而ThreadContextClassLoader也是为了完成这个工作。
在Java应用中存在着很多服务提供者接口（Service Provider Interface，SPI），这些接口允许第三方为它们提供实现，如常见的SPI有JDBC、JNDI等，这些SPI的接口属于Java核心库，一般存在rt.jar包中，由Bootstrap类加载器加载，而SPI的第三方实现代码则是作为Java应用所依赖的jar包被存放在classpath路径下，由于SPI接口中的代码经常需要加载具体的第三方实现类并调用其相关方法，但SPI的核心接口类是由引导类加载器来加载的，而Bootstrap类加载器无法直接加载SPI的实现类，同时由于双亲委派模式的存在，Bootstrap类加载器也无法反向委托AppClassLoader加载器SPI的实现类。在这种情况下，我们就需要一种特殊的类加载器来加载第三方的类库，而线程上下文类加载器就是很好的选择。

以jdbc.jar加载为例,类的加载如下图所示，

从图可知rt.jar核心包是有Bootstrap类加载器加载的，其内包含SPI核心接口类，由于SPI中的类经常需要调用外部实现类的方法，而jdbc.jar包含外部实现类(jdbc.jar存在于classpath路径)无法通过Bootstrap类加载器加载，因此只能委派线程上下文类加载器把jdbc.jar中的实现类加载到内存以便SPI相关类使用。显然这种线程上下文类加载器的加载方式破坏了“双亲委派模型”，它在执行过程中抛弃双亲委派加载链模式，使程序可以逆向使用类加载器，当然这也使得Java类加载器变得更加灵活。为了进一步证实这种场景，不妨看看DriverManager类的源码，DriverManager是Java核心rt.jar包中的类，该类用来管理不同数据库的实现驱动即Driver，它们都实现了Java核心包中的java.sql.Driver接口，如mysql驱动包中的com.mysql.jdbc.Driver，这里主要看看如何加载外部实现类，在DriverManager初始化时会执行如下代码

//DriverManager是Java核心包rt.jar的类
public class DriverManager {
    //省略不必要的代码
    static {
        loadInitialDrivers();//执行该方法
        println("JDBC DriverManager initialized");
    }

//loadInitialDrivers方法
 private static void loadInitialDrivers() {
     sun.misc.Providers()
     AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {
                //加载外部的Driver的实现类
                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
              //省略不必要的代码......
            }
        });
    }

在DriverManager类初始化时执行了loadInitialDrivers()方法,在该方法中通过ServiceLoader.load(Driver.class);去加载外部实现的驱动类，ServiceLoader类会去读取mysql的jdbc.jar下META-INF文件的内容，如下所示

而com.mysql.jdbc.Driver继承类如下：

public class Driver extends com.mysql.cj.jdbc.Driver {
    public Driver() throws SQLException {
        super();
    }

    static {
        System.err.println("Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. "
                + "The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.");
    }
}

从注释可以看出平常我们使用com.mysql.jdbc.Driver已被丢弃了，取而代之的是com.mysql.cj.jdbc.Driver，也就是说官方不再建议我们使用如下代码注册mysql驱动

//不建议使用该方式注册驱动类
Class.forName("com.mysql.jdbc.Driver");
String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
// 通过java库获取数据库连接
Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");

而是直接去掉注册步骤，如下即可

1
2
3

String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
// 通过java库获取数据库连接
Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");

这样ServiceLoader会帮助我们处理一切，并最终通过load()方法加载，看看load()方法实现

public static <S> ServiceLoader<S> load(Class<S> service) {
      //通过线程上下文类加载器加载
      ClassLoader cl = Thread.currentThread().getContextClassLoader();
      return ServiceLoader.load(service, cl);
  }

很明显了确实通过线程上下文类加载器加载的，实际上核心包的SPI类对外部实现类的加载都是基于线程上下文类加载器执行的，通过这种方式实现了Java核心代码内部去调用外部实现类。我们知道线程上下文类加载器默认情况下就是AppClassLoader，那为什么不直接通过getSystemClassLoader()获取类加载器来加载classpath路径下的类的呢？其实是可行的，但这种直接使用getSystemClassLoader()方法获取AppClassLoader加载类有一个缺点，那就是代码部署到不同服务时会出现问题，如把代码部署到Java Web应用服务或者EJB之类的服务将会出问题，因为这些服务使用的线程上下文类加载器并非AppClassLoader，而是Java Web应用服自家的类加载器，类加载器不同。所以我们应用该少用getSystemClassLoader()。总之不同的服务使用的可能默认ClassLoader是不同的，但使用线程上下文类加载器总能获取到与当前程序执行相同的ClassLoader，从而避免不必要的问题。ok~.关于线程上下文类加载器暂且聊到这，前面阐述的DriverManager类，大家可以自行看看源码，相信会有更多的体会，另外关于ServiceLoader本篇并没有过多的阐述，毕竟我们主题是类加载器，但ServiceLoader是个很不错的解耦机制，大家可以自行查阅其相关用法。

总结

从上面可以得出，CurrentClassLoader对用户来说是自动的，隐式的，而ThreadContextClassLoader需要显示的使用，先进行设置然后再进行使用。

参考

Find a way out of the ClassLoader maze