Java 类加载器是用户程序和 JVM 虚拟机之间的桥梁，在 Java 程序中起了至关重要的作用，了解它有利于咱们写出更优雅的程序。本文首先介绍了 Java 虚拟机加载程序的过程，简述了 Java 类加载器的加载形式（双亲委派模式），而后介绍了几种常见的类加载器及其实用场景，最初则一个例子展现了如何自定义类加载器。本文很多中央参考了 java 官网文档对于虚拟机加载的教程，点此中转官网参考文档

基本概念

根本文件类型和概念

常见概念介绍：

1. java 源文件(.java)：.java 是 Java 的源文件后缀，外面寄存程序员编写的性能代码, 只是一个文本文件，不能被 java 虚拟机所辨认, 然而 java 语法有其本身的语法标准要求，不符合规范的 java 程序应该在编译期间报错。

2. java 字节码文件 (.class)：能够由 java 文件通过 javac 这个命令（jdk 自身提供的工具）编译生成，实质上是一种二进制文件，这个文件能够由 java 虚拟机加载（类加载），而后进 java 解释执行，这也就是运行你的程序。
   java 字节码文件(.class 文件) 看起来有点多余, 为什么 java 虚拟机不能间接执行 java 源码呢？次要是为了实现 多语言支持性：java 虚拟机自身只辨认.class 文件，所以任何语言（python、go 等）只有有适合的解释器解释为.class 文件，就能够在 java 虚拟机上执行。下文为 java 官网对于 Class 文件和虚拟机关系之间的形容原文。

   The Java Virtual Machine knows nothing of the Java programming language, only of a particular binary format, the class file format. A class file contains Java Virtual Machine instructions (or bytecodes) and a symbol table, as well as other ancillary information. For the sake of security, the Java Virtual Machine imposes strong syntactic and structural constraints on the code in a class file. However, any language with functionality that can be expressed in terms of a valid class file can be hosted by the Java Virtual Machine. Attracted by a generally available, machine-independent platform, implementors of other languages can turn to the Java Virtual Machine as a delivery vehicle for their languages.

3. java 虚拟机：Java Virtual Machine（缩写为 JVM），仅辨认.class 文件，能够把.class 文件加载到内存中，生成对应的 java 对象。还有内存治理、程序优化、锁治理等性能。所有的 java 程序最终都运行在 jvm 之上。下文为 java 官网对于 JAVA 虚拟机的形容信息

   The Java Virtual Machine is the cornerstone of the Java platform. It is the component of the technology responsible for its hardware- and operating systemindependence, the small size of its compiled code, and its ability to protect users from malicious programs. The Java Virtual Machine is an abstract computing machine. Like a real computing machine, it has an instruction set and manipulates various memory areas at run time. It is reasonably common to implement a programming language using a virtual machine;

idea 程序示例

下文将用 idea 中的 java 我的项目示例对 Java 源程序、Java 字节码、类实例别离进行示范：

idea-java 源文件

通常来说，咱们在 idea 中写的 java 程序都属于 java 源程序，idea 会把文件的 [.java] 后缀暗藏掉。咱们也能够应用任何文本编辑器编写生成 [.java] 文件。下图展现了一个典型的 JAVA 文件

idea-java 字节码

java 文件是不能被 java 虚拟机所辨认的，须要翻译为字节码文件才能够被 java 虚拟机承受。idea 中能够间接点击 build 我的项目按钮实现源文件解释为字节码的过程（实质是通过 java 中的 javac 工具实现）。

idea- 类加载

在 idea 中新建 java 的主类，并在主类中触发测试类的类加载流程（如 new 一个测试类），通过断点的形式能够查看到加载好的类的信息。

类加载器介绍

类加载器的作用

由上文中的流程图能够看出，类加载器负责读取 Java 字节代码（.class 文件），并转换成 java.lang.Class 类的一个实例。每个这样的实例用来示意一个 Java 类。通过此实例的 newInstance() 办法就能够创立出该类的一个对象。理论的状况可能更加简单，比方 Java 字节代码可能是通过工具动静生成的，也可能是通过网络下载的。

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取形容此类的二进制字节流”这个动作放到 Java 虚拟机内部去实现，以便让应用程序本人决定如何去获取所须要的类。实现这个动作的代码模块称为“类加载器”。

类加载的机会

java 类加载应用动静类加载机制，程序在启动的时候，并不会一次性加载程序所要用的所有 class 文件，而是依据程序的须要，通过 Java 的类加载机（ClassLoader）来动静加载某个 class 文件到内存当中的，从而只有 class 文件被载入到了内存之后，能力被其它 class 所援用。JVM 运行过程中，首先会加载初始类，而后再从初始类链接触发它相干的类的加载。

留神：图中的“援用”指触发类加载，一共有以下几种状况会触发类加载：

1. 创立类的实例 拜访类的动态变量(留神：当拜访类的动态并且 final 润饰的变量时，不会触发类的初始化。)，或者为动态变量赋值。
2. 调用类的静态方法（留神：调用动态且 final 的成员办法时，会触发类的初始化！肯定要和动态且 final 润饰的变量辨别开！！）
3. 应用 java.lang.reflect 包的办法对类进行反射调用的时候，如果类没有进行过初始化，则须要先触发其初始化。如：Class.forName(“bacejava.Langx”);
4. 留神通过类名.class 失去 Class 文件对象并不会触发类的加载。初始化某个类的子类

5. 间接应用 java.exe 命令来运行某个主类(java.exe 运行，实质上就是调用 main 办法，所以必须要有 main 办法才行)。

   java 官网对于类加载的形容：The Java Virtual Machine starts up by creating an initial class or interface using the bootstrap class loader or a user-defined class loader . The Java Virtual Machine then links the initial class or interface, initializes it, and invokes the public static method void main(String[]). The invocation of this method drives all further execution. Execution of the Java Virtual Machine instructions constituting the main method may cause linking (and consequently creation) of additional classes and interfaces, as well as invocation of additional methods.
   The initial class or interface is specified in an implementation-dependent manner. For example, the initial class or interface could be provided as a command line argument. Alternatively, the implementation of the Java Virtual Machine could itself provide an initial class that sets up a class loader which in turn loads an application. Other choices of the initial class or interface are possible so long as they are consistent with the specification given in the previous paragraph.

类加载器的意义

类加载器是 Java 语言的一个翻新，也是 Java 语言风行的重要起因之一。它使得 Java 类能够被动静加载到 Java 虚拟机中并执行。类加载器从 JDK 1.0 就呈现了，最后是为了满足 Java Applet 的须要而开发进去的。Java Applet 须要从近程下载 Java 类文件到浏览器中并执行。当初类加载器在 Web 容器和 OSGi 中失去了宽泛的应用。一般来说，Java 利用的开发人员不须要间接同类加载器进行交互。Java 虚拟机默认的行为就曾经足够满足大多数状况的需要了。不过如果遇到了须要与类加载器进行交互的状况，而对类加载器的机制又不是很理解的话，就很容易花大量的工夫去调试 ClassNotFoundException 和 NoClassDefFoundError 等异样。

类加载的根本流程

1. 加载：加载是通过类加载器（classLoader）实现的，它既能够是饿汉式 eagerly load 加载类（预加载），也能够是懒加载 lazy load（运行时加载）

2. 验证：确保.class 文件的字节流中蕴含的信息合乎以后虚拟机的要求，并且不会危害虚拟机本身的平安。验证阶段是否谨严，间接决定了 Java 虚拟机是否能接受恶意代码的攻打。从整体上看，验证阶段大抵上会实现上面四个阶段的测验动作：文件格式验证、元数据验证、字节码验证、符号援用验证。

3. 筹备：筹备阶段的次要工作是如下两点：为类变量分配内存；设置类变量初始值

4. 解析：解析阶段是虚拟机将常量池内的符号援用替换为间接援用的过程

5. 初始化 ：初始化阶段即虚拟机执行类结构器 \<clinit>() 办法的过程。

6. 应用：失常应用类信息

7. 卸载：满足类卸载条件时（比拟刻薄），jvm 会从内存中卸载对应的类信息

oracle 官网对于类加载只粗略划分为了三个阶段，加载(蕴含上图中的加载、验证和筹备)、链接和初始化，以下为 java 官网对于类加载的形容信息

The Java Virtual Machine dynamically loads, links and initializes classes and interfaces. Loading is the process of finding the binary representation of a class or interface type with a particular name and creating a class or interface from that binary representation. Linking is the process of taking a class or interface and combining it into the run-time state of the Java Virtual Machine so that it can be executed. Initialization of a class or interface consists of executing the class or interface initialization method \<clinit>

类加载器具体介绍

生成类对象的三种办法

oracle 官网把类加载器划分为两种类型：启动类加载器 (BootStrapClassloader) 和用户自定义类加载器，用户自定义加载器都继承自 ClassLoad 类。启动类加载器次要用于加载一些外围 java 库，如 rt.jar。用户自定义加载器则能够加载各种起源的 class 文件。以下为 java 官网对于类加载器生成形式的形容信息。

>There are two kinds of class loaders: the bootstrap class loader supplied by the Java Virtual Machine, and user-defined class loaders.Every user-defined class loader is an instance of a subclass of the abstract class ClassLoader. Applications employ user-defined class loaders in order to extend the manner in which the Java Virtual Machine dynamically loads and thereby creates classes. User-defined class loaders can be used to create classes that originate from user-defined sources. For example, a class could be downloaded across a network, generated on the fly, or extracted from an encrypted file.

数组自身也是一个对象，然而这个对象对应的类不通过类加载器加载，而是通过 JVM 生成。以下为 java 官网对于数组对象的形容信息

>Array classes do not have an external binary representation; they are created by the Java Virtual Machine rather than by a class loader.

综上所述：类的生成形式一共有三种：

1. 启动类加载器
2. 用户自定义类加载器

3. JVM 生成数组对象

   The Java Virtual Machine uses one of three procedures to create class or interface C denoted by N:
   • If N denotes a nonarray class or an interface, one of the two following methods is used to load and thereby create C:
   – If D was defined by the bootstrap class loader, then the bootstrap class loader initiates loading of C .
   – If D was defined by a user-defined class loader, then that same user-defined class loader initiates loading of C.
   • Otherwise N denotes an array class. An array class is created directly by the Java Virtual Machine, not by a class loader. However, the defining class loader of D is used in the process of creating array class C.

启动类加载器

启动类加载器次要加载的是 JVM 本身须要的类，这个类加载应用 C ++ 语言实现的，是虚拟机本身的一部分，它负责将 \<JAVA_HOME>/lib 门路下的外围类库或 -Xbootclasspath 参数指定的门路下的 jar 包加载到内存中，留神必因为虚拟机是依照文件名辨认加载 jar 包的，如 rt.jar，如果文件名不被虚拟机辨认，即便把 jar 包丢到 lib 目录下也是没有作用的 (出于平安思考，Bootstrap 启动类加载器只加载包名为 java、javax、sun 等结尾的类)。
双亲委派模型中，如果一个类加载器的父类加载器为 null，则示意该类加载器的父类加载器是启动类加载器

Bootstrap class loader. It is the virtual machine’s built-in class loader, typically represented as null, and does not have a parent.
The following steps are used to load and thereby create the nonarray class or interface C denoted by N using the bootstrap class loader. First, the Java Virtual Machine determines whether the bootstrap class loader has already been recorded as an initiating loader of a class or interface denoted by N. If so, this class or interface is C, and no class creation is necessary. Otherwise, the Java Virtual Machine passes the argument N to an invocation of a method on the bootstrap class loader to search for a purported representation of C in a platform-dependent manner. Typically, a class or interface will be represented using a file in a hierarchical file system, and the name of the class or interface will be encoded in the pathname of the file. Note that there is no guarantee that a purported representation found is valid or is a representation of C. This phase of loading must detect the following error:

 • If no purported representation of C is found, loading throws an instance of

ClassNotFoundException.

用户自定义类加载器

用户自定义类加载器能够分为两种类型：

1. java 库中的平台类加载器和应用程序类加载器等
2. 用户本人写的类加载器，比方通过网络加载类等机制

数组类加载器

数组的 Class 类是由 jvm 生成的，然而数组类的 Class.getClassLoader() 和数组元素的类加载器保持一致，如果数组的元素是根本类型，那么数组类的类加载器会为空。

Class objects for array classes are not created by class loaders, but are created automatically as required by the Java runtime. The class loader for an array class, as returned by Class.getClassLoader() is the same as the class loader for its element type; if the element type is a primitive type, then the array class has no class loader.

用户自定义类加载器介绍

本章节会具体介绍下图中的各个类加载器：

根本类加载器 ClassLoader

参考文档：https://docs.oracle.com/en/ja…

ClassLoader 类是所有类加载器的基类。ClassLoader 类根本职责就是依据一个指定的类的名称，找到或者生成其对应的字节代码，而后从这些字节代码中定义出一个 Java 类，即 java.lang.Class 类的一个实例。除此之外，ClassLoader 还负责加载 Java 利用所需的资源，如图像文件和配置文件等。不过本节只探讨其加载类的性能。为了实现加载类的这个职责，ClassLoader 提供了一系列的办法，比拟重要的办法如 java.lang.ClassLoader 类介绍 所示。对于这些办法的细节会在上面进行介绍。

A class loader is an object that is responsible for loading classes. The class ClassLoader is an abstract class. Given the binary name of a class, a class loader should attempt to locate or generate data that constitutes a definition for the class. A typical strategy is to transform the name into a file name and then read a “class file” of that name from a file system. Every Class object contains a reference to the ClassLoader that defined it.

ClassLoader 默认反对并发加载，能够通过 ClassLoader.registerAsParallelCapable 办法被动勾销并发加载操作，ClassLoader 实现并发加载的原理如下：当 ClassLoader 加载类时，如果该类是第一次加载，则会以该类的齐全限定名称作为 Key，一个 new Object()对象为 Value，存入一个 ConcurrentHashMap 的中。并以该 object 对象为锁进行同步控制。同一时间如果有其它线程再次申请加载该类时，则取出 map 中的对象 object，发现该对象已被占用，则阻塞。也就是说 ClassLoader 的并发加载通过一个 ConcurrentHashMap 实现的。

    // java 加载类时获取锁的流程
    protected Object getClassLoadingLock(String className) {
        // 不开启并发加载的状况下，应用 ClassLoader 对象自身加锁
        Object lock = this;
        // 开启并发加载的状况下，从 ConcurrentHashMap 中获取须要加载的类对象进行加锁。if (parallelLockMap != null) {Object newLock = new Object();
            lock = parallelLockMap.putIfAbsent(className, newLock);
            if (lock == null) {lock = newLock;}
        }
        return lock;
    }

在某些不是严格遵循双亲委派模型的场景下，并发加载可能造成类加载器死锁：
举例：A 和 B 两个类应用不同的类加载器，A 类的动态初始化代码块蕴含了 B 类的初始化操作(new B)，B 类的初始化代码块也蕴含了 A 类的初始化操作(new A)；并发加载 A 和 B 的状况下，就有可能呈现死锁的状况。而且加锁操作产生在 JVM 层面，无奈用罕用的 java 类加载工具查看到死锁状况。

Class loaders that support concurrent loading of classes are known as parallel capable class loaders and are required to register themselves at their class initialization time by invoking the ClassLoader.registerAsParallelCapable method. Note that the ClassLoader class is registered as parallel capable by default. However, its subclasses still need to register themselves if they are parallel capable. In environments in which the delegation model is not strictly hierarchical, class loaders need to be parallel capable, otherwise class loading can lead to deadlocks because the loader lock is held for the duration of the class loading process (see loadClass methods).

真正实现类的加载工作是通过调用 defineClass 来实现的；而启动类的加载过程是通过调用 loadClass 来实现的。前者称为一个类的定义加载器（defining loader），后者称为初始加载器（initiating loader）。在 Java 虚拟机判断两个类是否雷同的时候，应用的是类的定义加载器。也就是说，哪个类加载器启动类的加载过程并不重要，重要的是最终定义这个类的加载器。两品种加载器的关联之处在于：一个类的定义加载器是它援用的其它类的初始加载器。如类 com.example.Outer 援用了类 com.example.Inner，则由类 com.example.Outer 的定义加载器负责启动类 com.example.Inner 的加载过程。办法 loadClass() 抛出的是 java.lang.ClassNotFoundException 异样；办法 defineClass() 抛出的是 java.lang.NoClassDefFoundError 异样。类加载器在胜利加载某个类之后，会把失去的 java.lang.Class 类的实例缓存起来。下次再申请加载该类的时候，类加载器会间接应用缓存的类的实例，而不会尝试再次加载。也就是说，对于一个类加载器实例来说，雷同全名的类只加载一次，即 loadClass 办法不会被反复调用。

权限治理类加载器 SecureClassLoader

在 ClassLoader 的根底上增加了代码源和平安管理器。

This class extends ClassLoader with additional support for defining classes with an associated code source and permissions which are retrieved by the system policy by default.

内置类加载器 BuiltinClassLoader

（倡议看看 java9 jigsaw 模块化个性）BuiltinClassLoader 加载器应用的委派模型与惯例委派模型不同，该类加载器反对从模块加载类和资源。当申请加载一个类时，这个类加载器首先将类名映射到它的包名。如果有一个模块定义给蕴含这个包的 BuiltinClassLoader，那么类加载器将间接委托给该类加载器。如果没有蕴含包的模块，那么它将搜寻委托给父类装入器，如果在父类中找不到，则会搜寻类门路。这种委托模型与通常的委托模型的次要区别在于，它容许平台类加载器委托给应用程序类加载器，这一点应该和 java9 jigsaw 模块化个性无关（毁坏了双亲委派模型）。

The delegation model used by this ClassLoader differs to the regular delegation model. When requested to load a class then this ClassLoader first maps the class name to its package name. If there is a module defined to a BuiltinClassLoader containing this package then the class loader delegates directly to that class loader. If there isn’t a module containing the package then it delegates the search to the parent class loader and if not found in the parent then it searches the class path. The main difference between this and the usual delegation model is that it allows the platform class loader to delegate to the application class loader, important with upgraded modules defined to the platform class loader.

平台类加载器 PlatformClassLoader

从 JDK9 开始，扩大类加载器被重命名为平台类加载器（Platform ClassLoader），局部不须要 AllPermission 的 Java 根底模块，被降级到平台类加载器中，相应的权限也被更精密粒度地限度起来。它用来加载 Java 的扩大库。Java 虚拟机的实现会提供一个扩大库目录。该类加载器在此目录外面查找并加载 Java 类。

Platform class loader. All platform classes are visible to the platform class loader that can be used as the parent of a ClassLoader instance. Platform classes include Java SE platform APIs, their implementation classes and JDK-specific run-time classes that are defined by the platform class loader or its ancestors.
To allow for upgrading/overriding of modules defined to the platform class loader, and where upgraded modules read modules defined to class loaders other than the platform class loader and its ancestors, then the platform class loader may have to delegate to other class loaders, the application class loader for example. In other words, classes in named modules defined to class loaders other than the platform class loader and its ancestors may be visible to the platform class loader.

应用程序类加载器 AppClassLoader

零碎类加载器负责将用户类门路(java -classpath 或 -Djava.class.path 变量所指的目录，即以后类所在门路及其援用的第三方类库的路下的类库加载到内存中。如果程序员没有自定义类加载器，默认调用该加载器。

System class loader. It is also known as application class loader and is distinct from the platform class loader. The system class loader is typically used to define classes on the application class path, module path, and JDK-specific tools. The platform class loader is a parent or an ancestor of the system class loader that all platform classes are visible to it.

用户自定义类加载器

一般来说，用户自定义类加载器以 ClassLoader 为基类，重写其中的 findClass，使 findClass 能够从用户指定的地位读取字节码.class 文件。不倡议用户重写 loadClass 办法，因为 loadClass 蕴含了双亲委派模型和锁等相干逻辑。
用户自定义类加载器的父加载器能够在构造函数中指定，如果构造函数中没有指定，那么将会调用 ClassLoader 中的 getSystemClassLoader()办法获取默认类加载器：

    @CallerSensitive
    public static ClassLoader getSystemClassLoader() {switch (VM.initLevel()) {
            case 0:
            case 1:
            case 2:
                // the system class loader is the built-in app class loader during startup
                return getBuiltinAppClassLoader();
            case 3:
                String msg = "getSystemClassLoader cannot be called during the system class loader instantiation";
                throw new IllegalStateException(msg);
            default:
                // system fully initialized
                asset VM.isBooted() && scl != null;
                SecurityManager sm = System.getSecurityManager();
                if (sm != null) {checkClassLoaderPermission(scl, Reflection.getCallerClass());
                }
                return scl;
        }
    }

Normally, the Java virtual machine loads classes from the local file system in a platform-dependent manner. However, some classes may not originate from a file; they may originate from other sources, such as the network, or they could be constructed by an application. The method defineClass converts an array of bytes into an instance of class Class. Instances of this newly defined class can be created using Class.newInstance.
The methods and constructors of objects created by a class loader may reference other classes. To determine the class(es) referred to, the Java virtual machine invokes the loadClass method of the class loader that originally created the class.
For example, an application could create a network class loader to download class files from a server. Sample code might look like:

ClassLoader loader = new NetworkClassLoader(host, port);
Object main = loader.loadClass("Main", true).newInstance();
  . . .

The network class loader subclass must define the methods findClass and loadClassData to load a class from the network. Once it has downloaded the bytes that make up the class, it should use the method defineClass to create a class instance. A sample implementation is:

 class NetworkClassLoader extends ClassLoader {
     String host;
     int port;
     public Class findClass(String name) {byte[] b = loadClassData(name);
         return defineClass(name, b, 0, b.length);
     }
     private byte[] loadClassData(String name) {
         // load the class data from the connection
          . . .
     }
 }

类加载器的非凡逻辑

双亲委派模型

而通常 java 中的类加载默认是采纳双亲委派模型，即加载一个类时，首先判断本身 define 加载器有没有加载过此类，如果加载了间接获取 class 对象，如果没有查到，则交给加载器的父类加载器去反复下面过程。而 java 中加载器关系如下：

The ClassLoader class uses a delegation model to search for classes and resources. Each instance of ClassLoader has an associated parent class loader. When requested to find a class or resource, a ClassLoader instance will usually delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself.

双亲委派的具体过程如下：

1. 当一个类加载器接管到类加载工作时，先查缓存里有没有，如果没有，将工作委托给它的父加载器去执行。
2. 父加载器也做同样的事件，一层一层往上委托，直到最顶层的启动类加载器为止。
3. 如果启动类加载器没有找到所需加载的类，便将此加载工作退回给下一级类加载器去执行，而下一级的类加载器也做同样的事件。
4. 如果最底层类加载器依然没有找到所须要的 class 文件，则抛出异样。

双亲委派模型的意义 ：确保类的全局唯一性
如果你本人写的一个类与外围类库中的类重名，会发现这个类能够被失常编译，但永远无奈被加载运行。因为你写的这个类不会被利用类加载器加载，而是被委托到顶层，被启动类加载器在外围类库中找到了。如果没有双亲委托机制来确保类的全局唯一性，谁都能够编写一个 java.lang.Object 类放在 classpath 下，那应用程序就乱套了。
从平安的角度讲，通过双亲委托机制，Java 虚拟机总是先从最可信的 Java 外围 API 查找类型，能够避免不可信的类假扮被信赖的类对系统造成危害。

上下文类加载器

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 来加载类。而线程上下文类加载器毁坏了“双亲委派模型”，能够在执行线程中摈弃双亲委派加载链模式，使程序能够逆向应用类加载器。

简略来说：SPI 接口类在 java 外围库中，原本应该由启动类加载器加载，然而因为 SPI 实现类机制，所以由上下文类加载器加载 SPI 接口类，使 SPI 接口类和实现类由同一个类加载器加载。

JDBC SPI 介绍

只看文本了解有点艰难，此处用 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"); 

以上为咱们获取 JDBC 链接时罕用的语句，试验发现将的 Class.forName 正文掉之后，程序但仍然能够失常运行，这是为什么呢？这是因为从 Java1.6 开始自带的 jdbc4.0 版本已反对 SPI 服务加载机制，只有 mysql 的 jar 包在类门路中，就能够注册 mysql 驱动。
那到底是在哪一步主动注册了 mysql driver 的呢？重点就在 DriverManager.getConnection()中。咱们都是晓得调用类的静态方法会初始化该类，进而执行其动态代码块，DriverManager 的动态代码块就是：

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;}
    // 通过 SPI 加载驱动类
    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;
        }
    });
    // 持续加载零碎属性中的驱动类
    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);
            // 应用 AppClassloader 加载
            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”)获取设置，而后通过零碎类加载器加载。
   上面详细分析 SPI 加载的那段代码。

JDBC 中的 SPI 介绍：

SPI 机制简介
SPI 的全名为 Service Provider Interface，次要是利用于厂商自定义组件或插件中。在 java.util.ServiceLoader 的文档里有比拟具体的介绍。简略的总结下 java SPI 机制的思维：咱们零碎里形象的各个模块，往往有很多不同的实现计划，比方日志模块、xml 解析模块、jdbc 模块等计划。面向的对象的设计里，咱们个别举荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里波及具体的实现类，就违反了可拔插的准则，如果须要替换一种实现，就须要批改代码。为了实现在模块拆卸的时候能不在程序里动静指明，这就须要一种服务发现机制。Java SPI 就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点相似 IOC 的思维，就是将拆卸的控制权移到程序之外，在模块化设计中这个机制尤其重要。
Java SPI 的具体约定为：当服务的提供者提供了服务接口的一种实现之后，在 jar 包的 META-INF/services/ 目录里同时创立一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当内部程序拆卸这个模块的时候，就能通过该 jar 包 META-INF/services/ 里的配置文件找到具体的实现类名，并装载实例化，实现模块的注入。基于这样一个约定就能很好的找到服务接口的实现类，而不须要再代码里制订。jdk 提供服务实现查找的一个工具类：java.util.ServiceLoader。

依照上文中的 SPI 介绍, 咱们剖析一下 JDBC 的 SPI 代码:

ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();

try{while(driversIterator.hasNext()) {driversIterator.next();
    }
} catch(Throwable t) {// Do nothing}

留神 driversIterator.next()最终就是调用 Class.forName(DriverName, false, loader)办法，也就是最开始咱们正文掉的那一句代码。好，那句因 SPI 而省略的代码当初解释分明了，那咱们持续看给这个办法传的 loader 是怎么来的。

因为这句 Class.forName(DriverName, false, loader)代码所在的类在 java.util.ServiceLoader 类中，而 ServiceLoader.class 又加载在 BootrapLoader 中，因而传给 forName 的 loader 必然不能是 BootrapLoader，温习双亲委派加载机制请看：java 类加载器不残缺剖析。这时候只能应用 TCCL 了，也就是说把本人加载不了的类加载到 TCCL 中（通过 Thread.currentThread()获取，几乎舞弊啊！）。下面那篇文章开端也讲到了 TCCL 默认应用以后执行的是代码所在利用的零碎类加载器 AppClassLoader。
再看下看 ServiceLoader.load(Class)的代码，的确如此：

public static <S> ServiceLoader<S> load(Class<S> service) {ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

ContextClassLoader 默认寄存了 AppClassLoader 的援用，因为它是在运行时被放在了线程中，所以不论以后程序处于何处（BootstrapClassLoader 或是 ExtClassLoader 等），在任何须要的时候都能够用 Thread.currentThread().getContextClassLoader()取出应用程序类加载器来实现须要的操作。
到这儿差不多把 SPI 机制解释分明了。直白一点说就是，我（JDK）提供了一种帮你（第三方实现者）加载服务（如数据库驱动、日志库）的便捷形式，只有你遵循约定（把类名写在 /META-INF 里），那当我启动时我会去扫描所有 jar 包里合乎约定的类名，再调用 forName 加载，但我的 ClassLoader 是没法加载的，那就把它加载到以后执行线程的 TCCL 里，后续你想怎么操作（驱动实现类的 static 代码块）就是你的事了。
好，方才说的驱动实现类就是 com.mysql.jdbc.Driver.Class，它的动态代码块外头又写了什么呢？是否又用到了 TCCL 呢？咱们持续看下一个例子。
com.mysql.jdbc.Driver 加载后运行的动态代码块:

static {
    try {
        // Driver 曾经加载到 TCCL 中了，此时能够间接实例化
        java.sql.DriverManager.registerDriver(new com.mysql.jdbc.Driver());
    } catch (SQLException E) {throw new RuntimeException("Can't register driver!");
    }
}

registerDriver 办法将 driver 实例注册到零碎的 java.sql.DriverManager 类中，其实就是 add 到它的一个名为 registeredDrivers 的动态成员 CopyOnWriteArrayList 中 , 到此驱动注册根本实现.
更多案例参考博客:https://blog.csdn.net/yangche…

总结

通过下面的案例剖析，咱们能够总结出线程上下文类加载器的实用场景：

1. 当高层提供了对立接口让低层去实现，同时又要是在高层加载（或实例化）低层的类时，必须通过线程上下文类加载器来帮忙高层的 ClassLoader 找到并加载该类。
2. 当应用本类托管类加载，然而加载本类的 ClassLoader 未知时，为了隔离不同的调用者，能够取调用者各自的线程上下文类加载器代为托管。

3.2.3 ServiceLoader

ServiceLoader 是用于加载 SPI 服务实现类的工具，能够解决 0 个、1 个或者多个服务提供商的状况。

A facility to load implementations of a service.
A service is a well-known interface or class for which zero, one, or many service providers exist. A service provider (or just provider) is a class that implements or subclasses the well-known interface or class. A ServiceLoader is an object that locates and loads service providers deployed in the run time environment at a time of an application’s choosing. Application code refers only to the service, not to service providers, and is assumed to be capable of differentiating between multiple service providers as well as handling the possibility that no service providers are located.

应用程序通过 ServiceLoader 的静态方法加载给定的服务，如果服务提供者在另外一个模块化的程序中，那么以后模块必须申明依赖服务提供方的服务实现类。ServiceLoader 能够通过迭代器办法来定位和实例化服务的提供者，能够通过 stream 办法来获取一个能够检查和过滤的提供者流，而无需实例化它们。

An application obtains a service loader for a given service by invoking one of the static load methods of ServiceLoader. If the application is a module, then its module declaration must have a uses directive that specifies the service; this helps to locate providers and ensure they will execute reliably. In addition, if the service is not in the application module, then the module declaration must have a requires directive that specifies the module which exports the service.
A service loader can be used to locate and instantiate providers of the service by means of the iterator method. ServiceLoader also defines the stream method to obtain a stream of providers that can be inspected and filtered without instantiating them.
As an example, suppose the service is com.example.CodecFactory, an interface that defines methods for producing encoders and decoders:

下文举例说明：CodecFactory 为一个 SPI 服务接口。定义了 getEncoder 和 getDecoder 两个借口。

 package com.example;
 public interface CodecFactory {Encoder (String encodingName);
     Decoder getDecoder(String encodingName);
 }

上面的程序通过迭代器的形式获取 CodecFactory 的服务提供者：

ServiceLoader<CodecFactory> loader = ServiceLoader.load(CodecFactory.class);
    for (CodecFactory factory : loader) {Encoder enc = factory.getEncoder("PNG");
        if (enc != null)
            ... use enc to encode a PNG file
            break;
    }

有些时候，咱们可能有很多服务提供者，然而只有其中一些是有用的，这种状况下咱们就须要对 ServiceLoader 获取到的服务实现类进行过滤，比方案例中，咱们只须要 PNG 格局的 CodecFactory，那么咱们就能够对对应的服务实现类增加一个自定义的 @PNG 注解，而后通过下文过滤失去所需的服务提供者：

 ServiceLoader<CodecFactory> loader = ServiceLoader.load(CodecFactory.class);
 Set<CodecFactory> pngFactories = loader
        .stream()                                              // Note a below
        .filter(p -> p.type().isAnnotationPresent(PNG.class))  // Note b
        .map(Provider::get)                                    // Note c
        .collect(Collectors.toSet());

SPI 服务设计的准则：
服务应该遵从繁多职责准则，通常设计为接口或抽象类，不举荐设计为具体类（尽管也能够这样实现）。不同状况下设计的服务的办法不同，然而都应该恪守两个准则：

1. 服务凋谢尽量多的办法，使服务提供方能够更自在的定制本人的服务实现形式。

2. 服务应该表明本身是间接还是间接实现机制（如“代理”或“工厂”）。当某畛域特定的对象实例化绝对比较复杂时，服务提供者往往采纳间接机制如，CodecFactory 服务通过其名称示意其服务提供商是编解码器的工厂，而不是编解码器自身，因为生产某些编解码器可能很简单。

   A service is a single type, usually an interface or abstract class. A concrete class can be used, but this is not recommended. The type may have any accessibility. The methods of a service are highly domain-specific, so this API specification cannot give concrete advice about their form or function. However, there are two general guidelines:

   1. A service should declare as many methods as needed to allow service providers to communicate their domain-specific properties and other quality-of-implementation factors. An application which obtains a service loader for the service may then invoke these methods on each instance of a service provider, in order to choose the best provider for the application.
   2. A service should express whether its service providers are intended to be direct implementations of the service or to be an indirection mechanism such as a “proxy” or a “factory”. Service providers tend to be indirection mechanisms when domain-specific objects are relatively expensive to instantiate; in this case, the service should be designed so that service providers are abstractions which create the “real” implementation on demand. For example, the CodecFactory service expresses through its name that its service providers are factories for codecs, rather than codecs themselves, because it may be expensive or complicated to produce certain codecs.

有两种形式能够申明一个服务实现类：

• 通过模块化的包申明：
  provides com.example.CodecFactory with com.example.impl.StandardCodecs;
  provides com.example.CodecFactory with com.example.impl.ExtendedCodecsFactory;
  - 通过指定门路申明：META-INF/services
  如：META-INF/services/com.example.CodecFactory
  增加一行：com.example.impl.StandardCodecs # Standard codecs

开发本人的类加载器

尽管在绝大多数状况下，零碎默认提供的类加载器实现曾经能够满足需要。然而在某些状况下，您还是须要为利用开发出本人的类加载器。比方您的利用通过网络来传输 Java 类的字节代码，为了保障安全性，这些字节代码通过了加密解决。这个时候您就须要本人的类加载器来从某个网络地址上读取加密后的字节代码，接着进行解密和验证，最初定义出要在 Java 虚拟机中运行的类来。上面将通过两个具体的实例来阐明类加载器的开发。

## 文件系统类加载器

第一个类加载器用来加载存储在文件系统上的 Java 字节代码。残缺的实现如清单 6 所示。

public class FileSystemClassLoader extends ClassLoader {

    private String rootDir;

    public FileSystemClassLoader(String rootDir) {this.rootDir = rootDir;}

    protected Class<?> findClass(String name) throws ClassNotFoundException {byte[] classData = getClassData(name);
        if (classData == null) {throw new ClassNotFoundException();
        }
        else {return defineClass(name, classData, 0, classData.length);
        }
    }

    private byte[] getClassData(String className) {String path = classNameToPath(className);
        try {InputStream ins = new FileInputStream(path);
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            int bufferSize = 4096;
            byte[] buffer = new byte[bufferSize];
            int bytesNumRead = 0;
            while ((bytesNumRead = ins.read(buffer)) != -1) {baos.write(buffer, 0, bytesNumRead);
            }
            return baos.toByteArray();} catch (IOException e) {e.printStackTrace();
        }
        return null;
    }
    private String classNameToPath(String className) {
        return rootDir + File.separatorChar
                + className.replace('.', File.separatorChar) + ".class";
    }
 }

如清单 6 所示，类 FileSystemClassLoader 继承自类 java.lang.ClassLoader。在 java.lang.ClassLoader 类介绍 中列出的 java.lang.ClassLoader 类的罕用办法中，一般来说，本人开发的类加载器只须要覆写 findClass(String name) 办法即可。java.lang.ClassLoader 类的办法 loadClass() 封装了后面提到的代理模式的实现。该办法会首先调用 findLoadedClass() 办法来查看该类是否曾经被加载过；如果没有加载过的话，会调用父类加载器的 loadClass() 办法来尝试加载该类；如果父类加载器无奈加载该类的话，就调用 findClass() 办法来查找该类。因而，为了保障类加载器都正确实现代理模式，在开发本人的类加载器时，最好不要覆写 loadClass() 办法，而是覆写 findClass() 办法。

类 FileSystemClassLoader 的 findClass() 办法首先依据类的全名在硬盘上查找类的字节代码文件（.class 文件），而后读取该文件内容，最初通过 defineClass() 办法来把这些字节代码转换成 java.lang.Class 类的实例。

网络类加载器

上面将通过一个网络类加载器来阐明如何通过类加载器来实现组件的动静更新。即根本的场景是：Java 字节代码（.class）文件寄存在服务器上，客户端通过网络的形式获取字节代码并执行。当有版本更新的时候，只须要替换掉服务器上保留的文件即可。通过类加载器能够比较简单的实现这种需要。

类 NetworkClassLoader 负责通过网络下载 Java 类字节代码并定义出 Java 类。它的实现与 FileSystemClassLoader 相似。在通过 NetworkClassLoader 加载了某个版本的类之后，个别有两种做法来应用它。第一种做法是应用 Java 反射 API。另外一种做法是应用接口。须要留神的是，并不能间接在客户端代码中援用从服务器上下载的类，因为客户端代码的类加载器找不到这些类。应用 Java 反射 API 能够间接调用 Java 类的办法。而应用接口的做法则是把接口的类放在客户端中，从服务器上加载实现此接口的不同版本的类。在客户端通过雷同的接口来应用这些实现类。网络类加载器的具体代码见 下载。

在介绍完如何开发本人的类加载器之后，上面阐明类加载器和 Web 容器的关系。

类加载器与 Web 容器

对于运行在 Java EE™ 容器中的 Web 利用来说，类加载器的实现形式与个别的 Java 利用有所不同。不同的 Web 容器的实现形式也会有所不同。以 Apache Tomcat 来说，每个 Web 利用都有一个对应的类加载器实例。该类加载器也应用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与个别类加载器的程序是相同的。这是 Java Servlet 标准中的举荐做法，其目标是使得 Web 利用本人的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是：Java 外围库的类是不在查找范畴之内的。这也是为了保障 Java 外围库的类型平安。

绝大多数状况下，Web 利用的开发人员不须要思考与类加载器相干的细节。上面给出几条简略的准则：

每个 Web 利用本人的 Java 类文件和应用的库的 jar 包，别离放在 WEB-INF/classes 和 WEB-INF/lib 目录上面。
多个利用共享的 Java 类文件和 jar 包，别离放在 Web 容器指定的由所有 Web 利用共享的目录上面。
当呈现找不到类的谬误时，查看以后类的类加载器和以后线程的上下文类加载器是否正确。

欢送关注御狐神的微信公众号

本文最先公布至微信公众号，版权所有，禁止转载！