https://www.ibm.com/developerworks/cn/java/j-lo-classloader/
类加载器（class loader）
用来加载 Java 类到 Java 虚拟机中
- 一般来说，Java 虚拟机使用 Java 类的方式如下：
Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成 Java 字节代码（.class 文件）。类加载器负责读取 Java 字节代码，并转换成 java.lang.Class类的一个实例；每个这样的实例用来表示一个 Java 类。通过此实例的 newInstance()方法就可以创建出该类的一个对象。
- 实际的情况可能更加复杂，比如 Java 字节代码可能是通过工具动态生成的，也可能是通过网络下载的
基本上所有的类加载器都是 java.lang.ClassLoader类的一个实例。
java.lang.ClassLoader类
- 根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即
java.lang.Class类的一个实例；
| 方法 | 说明 |
|---|---|
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类的实例。这个方法被声明为 final的。 |
resolveClass(Class<?> c) |
链接指定的 Java 类。 |
表示类名称的 name参数的值是类的二进制名称。需要注意的是内部类的表示，如 com.example.Sample$1和 com.example.Sample$Inner等表示方式。
- 负责加载 Java 应用所需的资源，如图像文件和配置文件等。
类加载器的树状组织结构
Java 中的类加载器大致可以分成两类，一类是系统提供的，另外一类则是由 Java 应用开发人员编写的。
- 系统提供的类加载器主要有下面3个：
引导类加载器（bootstrap class loader）：它用来加载 Java 的核心库，是用原生代码来实现的，并不继承自 java.lang.ClassLoader。
扩展类加载器（extensions class loader）：它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。
系统类加载器（system class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它。
- 除了系统提供的类加载器以外，开发人员可以通过继承
java.lang.ClassLoader类的方式实现自己的类加载器，以满足一些特殊的需求。
除了引导类加载器之外，所有的类加载器都有一个父类加载器。通过 getParent()方法可以得到。
对于系统提供的类加载器来说，系统类加载器的父类加载器是扩展类加载器，而扩展类加载器的父类加载器是引导类加载器；
对于开发人员编写的类加载器来说，其父类加载器是加载此类加载器 Java 类的类加载器。
因为类加载器 Java 类如同其它的 Java 类一样，也是要由类加载器来加载的。一般来说，开发人员编写的类加载器的父类加载器是系统类加载器。
public class ClassLoaderTree { public static void main(String[] args) { ClassLoader loader = ClassLoaderTree.class.getClassLoader(); //有些 JDK 的实现对于父类加载器是引导类加载器的情况，getParent()方法返回 null while (loader != null) { System.out.println(loader.toString()); loader = loader.getParent(); } } } //输出 sun.misc.Launcher$AppClassLoader@9304b1 //系统类加载器实例 sun.misc.Launcher$ExtClassLoader@190d11 //扩展类加载器实例
类加载器的代理模式
类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，依次类推。
- Java 虚拟机是如何判定两个 Java 类是相同的
Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器（定义加载器）是否一样。只有两者都相同的情况，才认为两个类是相同的
- 代理模式是为了保证 Java 核心库的类型安全
通过代理模式，对于 Java 核心库的类的加载工作由引导类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。
- 相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。
不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。
加载类的过程
加载 + 启动加载
- 真正完成类的加载工作是通过调用加载器的
defineClass来实现的；而启动类的加载工过程是通过调用加载器的loadClass来实现的。
前者称为一个类的定义加载器（defining loader），后者称为初始加载器（initiating loader）。
在 Java 虚拟机判断两个类是否相同的时候，使用的是类的定义加载器。
- 对于一个类加载器实例来说，相同全名的类只加载一次
线程上下文类加载器
类 java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。
如果没有通过 setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文类加载器。
Java 应用运行的初始线程的上下文类加载器是系统类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。
- 在 SPI 接口的代码中使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。
一种加载类的方法 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 数据库的驱动。
开发自己的类加载器
-
文件系统类加载器
加载存储在文件系统上的 Java 字节代码，通过 类 FileSystemClassLoader 的 defineClass()方法来把这些字节代码转换成 java.lang.Class类的实例。
- 网络类加载器
类 NetworkClassLoader负责通过网络下载 Java 类字节代码并定义出 Java 类。
类加载器与 Web 容器
- 运行在 Java EE™容器中的 Web 应用来说，类加载器的实现方式与一般的 Java 应用有所不同
每个 Web 应用都有一个对应的类加载器实例。
该类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法，其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。
这种代理模式的一个例外是：Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。
- 绝大多数情况下，Web 应用的开发人员不需要考虑与类加载器相关的细节。下面给出几条简单的原则：
每个 Web 应用自己的 Java 类文件和使用的库的 jar 包，分别放在 WEB-INF/classes和 WEB-INF/lib目录下面。
多个应用共享的 Java 类文件和 jar 包，分别放在 Web 容器指定的由所有 Web 应用共享的目录下面。
当出现找不到类的错误时，检查当前类的类加载器和当前线程的上下文类加载器是否正确。
类加载器与 OSGi
OSGi™是 Java 上的动态模块系统。它为开发人员提供了面向服务和基于组件的运行环境，并提供标准的方式用来管理软件的生命周期。
- OSGi 中的每个模块（bundle）都包含 Java 包和类
OSGi 中的每个模块都有对应的一个类加载器。它负责加载模块自己包含的 Java 包和类。当它需要加载 Java 核心库的类时（以 java开头的包和类），它会代理给父类加载器（通常是启动类加载器）来完成。当它需要加载所导入的 Java 类时，它会代理给导出此 Java 类的模块来完成加载。
- 面提供几条比较好的建议
如果一个类库只有一个模块使用，把该类库的 jar 包放在模块中，在 Bundle-ClassPath中指明即可。
如果一个类库被多个模块共用，可以为这个类库单独的创建一个模块，把其它模块需要用到的 Java 包声明为导出的。其它模块声明导入这些类。
如果类库提供了 SPI 接口，并且利用线程上下文类加载器来加载 SPI 实现的 Java 类，有可能会找不到 Java 类。如果出现了 NoClassDefFoundError异常，首先检查当前线程的上下文类加载器是否正确。通过 Thread.currentThread().getContextClassLoader()就可以得到该类加载器。该类加载器应该是该模块对应的类加载器。如果不是的话，可以首先通过 class.getClassLoader()来得到模块对应的类加载器，再通过 Thread.currentThread().setContextClassLoader()来设置当前线程的上下文类加载器。