类加载器三杰

线程上下文类加载器

线程上下文类加载器（context class loader）是从 JDK 1.2 开始引入的。类 java.lang.Thread中的方法getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果没有通过setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文类加载器。Java 应用运行的初始线程的上下文类加载器是系统类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。

前面提到的类加载器的代理模式并不能解决 Java 应用开发中会遇到的类加载器的全部问题。Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。这些 SPI 的接口由 Java 核心库来提供，如 JAXP 的 SPI 接口定义包含在javax.xml.parsers包中。这些 SPI 的实现代码很可能是作为 Java 应用所依赖的 jar 包被包含进来，可以通过类路径（CLASSPATH）来找到，如实现了 JAXP SPI 的Apache Xerces所包含的 jar 包。SPI 接口中的代码经常需要加载具体的实现类。如 JAXP 中的javax.xml.parsers.DocumentBuilderFactory类中的 newInstance()方法用来生成一个新的DocumentBuilderFactory的实例。这里的实例的真正的类是继承自 javax.xml.parsers.DocumentBuilderFactory，由 SPI 的实现所提供的。如在 Apache Xerces 中，实现的类是org.apache.xerces.jaxp.DocumentBuilderFactoryImpl。而问题在于，SPI 的接口是 Java 核心库的一部分，是由引导类加载器来加载的；SPI 实现的 Java 类一般是由系统类加载器来加载的。引导类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的代理模式无法解决这个问题。

线程上下文类加载器正好解决了这个问题。如果不做任何的设置，Java 应用的线程的上下文类加载器默认就是系统上下文类加载器。在 SPI 接口的代码中使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。线程上下文类加载器在很多 SPI 的实现中都会用到。

下面介绍另外一种加载类的方法：Class.forName。

Class.forName

Class.forName是一个静态方法，同样可以用来加载类。该方法有两种形式：Class.forName(String name, boolean initialize, ClassLoader loader)和Class.forName(String className)。第一种形式的参数 name表示的是类的全名；initialize表示是否初始化类；loader表示加载时使用的类加载器。第二种形式则相当于设置了参数initialize的值为 true，loader的值为当前类的类加载器。Class.forName的一个很常见的用法是在加载数据库驱动的时候。如Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance()用来加载 Apache Derby 数据库的驱动。

在介绍完类加载器相关的基本概念之后，下面介绍如何开发自己的类加载器。

1.类的加载过程  

JVM将类加载过程分为三个步骤：装载（Load），链接（Link）和初始化(Initialize)链接又分为三个步骤，如下图所示：

1) 装载：查找并加载类的二进制数据；

2)链接：

验证：确保被加载类的正确性；

准备：为类的静态变量分配内存，并将其初始化为默认值；

解析：把类中的符号引用转换为直接引用；

3)初始化：为类的静态变量赋予正确的初始值；

          那为什么我要有验证这一步骤呢？首先如果由编译器生成的class文件，它肯定是符合JVM字节码格式的，但是万一有高手自己写一个class文件，让JVM加载并运行，用于恶意用途，就不妙了，因此这个class文件要先过验证这一关，不符合的话不会让它继续执行的，也是为了安全考虑吧。

        准备阶段和初始化阶段看似有点牟盾，其实是不牟盾的，如果类中有语句：private static int a = 10，它的执行过程是这样的，首先字节码文件被加载到内存后，先进行链接的验证这一步骤，验证通过后准备阶段，给a分配内存，因为变量a是static的，所以此时a等于int类型的默认初始值0，即a=0,然后到解析（后面在说），到初始化这一步骤时，才把a的真正的值10赋给a,此时a=10。

2. 类的初始化

    类什么时候才被初始化：

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

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

3）调用类的静态方法

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

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

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

         只有这6中情况才会导致类的类的初始化。

类加载器三杰

jvm有三类classloader，分别是bootstrapclassloader,extendedclassloader以及 (App)systemclassloader。

bootstrap classloader是系统在启动jvm时默认加载的。当用户在命令行输入java Test时，系统会首先加载jvm。在windows系统下，jvm的路径通常位于%JAVA_HOME%/jdk/jre/client/jvm.dll和%JAVA_HOME%/jdk/jre/server/jvm.dll.

bootstrap classloader加载后，会载入extended classloader，并将extended classloader的父类设为bootstrap classloader。然后，bootstrap classloader接着载入system classloader，并将system classloader的父类设为extended classloader。至此，bootstrap--extended--system三级继承结构形成。

bootstrap classloader在jvm启动之后自动加载。bootstrap  classloader由c实现，不属于java类。

extended classloader由java实现，通常为sun.misc.Lancher$ExtClassLoader.

system classloader由java实现，通常为sun.misc.Lancher$AppClassLoader.

其中，

• bootstrap classloader负责加载sun.boot.class.path路径下的.class文件以及jar包。
• extended classloader负责加载java.ext.dirs路径下的.class文件以及jar包。
• system classloader负责加载java.class.path路径下的.class文件以及jar包。

sun.boot.class.path通常对应环境变量CLASSPATH的路径。

java.ext.dirs通常对应JAVA_HOME/jre/lib/ext目录。

java.class.path对应用户自身的类路径。

类加载到何处

据可靠情报，jvm由方法区，堆，栈，pc寄存器和本地方法栈构成。类加载器的任务就是将class二进制文件加载到方法区，供虚拟机模制出在堆中存放的对象。

双亲委托机制

classloader加载类的过程为：

1. 检查被加载类是否被加载。
2. 如果没有被加载则调用父classloader加载该类。
3. 如果1、2不成功，则仍由自身进行类加载。

这种机制又叫双亲委派机制。

双亲委派机制的好处是，避免多个类加载器加载同一个类的不同拷贝到内存（jvm的方法区）中。因为如果类A由ClassLoaderA加载，同时，又被ClassLoaderB加载，这样，内存中就会存在两份不同的A的定义，于是形成A既是ClassLoaderA罩的，又是ClassLoaderB罩着，造成灾难性后果。

用户自定义类的加载顺序通常为：

首先调用AppClassLoader加载类，AppClassLoader调用ExtClassLoader，ExtClassLoader调用BootClassLoader，BootClassLoader在sun.boot.class.path寻找改类，没找到，加载失败；ExtClassLoader也未加载类，失败，最后由AppClassLoader加载成功。从这个加载顺序可以看出来，三个类加载器的对类的可见性是不同的。

java中的类是由java的全名以及类的classloader来限定的。只有当二者完全一样才会认为是同一个类。否则是不同的类。因此，可以定义一个同名的类，包名也一样，只要保证该类被不同的类加载器加载即可。

         类的加载的最终产品是位于堆区中的Class对象

当前类加载器和线程上下文类加载器

当前类加载器

当前类加载器是指当前方法所在的类使用的类加载器。在程序中使用Class.forName或者Class.getResource抑或Class.class时就是使用的该类加载器。

线程上下文类加载器

线程上下文类加载器可以不遵循双亲委派机制。线程的上下文类加载器有Thread.currentThread().setContextClassLoader()来为当前线程设置线程上下文类加载器。如果没有设置当前线程的上下文类加载器，则继承父类的上下文类加载器。

为什么还需要线程上下文类加载器？

考虑一种情况，当我们的程序必须由jvm的核心代码去加载第三方类的时候。比如jndi，jndi的核心是rt.jar包中实现的，由Bootstrap classloader负责加载，但是jndi必须加载第三方厂商的具体的jndi实现，这个时候调用Bootstrap加载只对其子类加载器可见的类，就会出现失败。这个时候就可以使用线程上下文类加载器。