在阅读公司CDP框架源码时在LongUtil.java时发现了这样一段代码
/**
* 使用当前线程的ClassLoader加载给定的类
*
* @param className 类的全称
* @return 给定的类
*/
public static Class<?> loadClass(String className) {
if ((className == null) || className.trim().length() == 0) {
log.error("loadClass error, className is null");
return null;
}
try {
return Thread.currentThread().getContextClassLoader().loadClass(className);
} catch (ClassNotFoundException e1) {
try {
return Class.forName(className);
} catch (Exception e2) {
throw new RuntimeException(e2.getMessage(), e2);
}
}
}
简单阅读后发现有趣的一点，这个工具方法为什么要优先使用Thread中的类加载器，它和Class.forName() 又有什么区别？由此开始了java类加载器的了解，阅读了很多博客和《Java核心技术》希望能得到答案，但结果不尽人意，在仔细思考后，终于明白了类加载的过程和加载思想，所以写下这篇文章希望能够为那些和我一样百思不得其解的朋友提供一点思路，以下是正文。
类加载器基本概念
- 简介
类加载器是 Java 语言的一个创新，也是 Java 语言流行的重要原因之一。它使得 Java 类可以被动态加载到 Java 虚拟机中并执行。类加载器从 JDK 1.0 就出现了，最初是为了满足 Java Applet 的需要而开发出来的。Java Applet 需要从远程下载 Java 类文件到浏览器中并执行。现在类加载器在 Web 容器和 OSGi 中得到了广泛的使用。一般来说，Java 应用的开发人员不需要直接同类加载器进行交互。Java 虚拟机默认的行为就已经足够满足大多数情况的需求了。不过如果遇到了需要与类加载器进行交互的情况，而对类加载器的机制又不是很了解的话，就很容易花大量的时间去调试 ClassNotFoundException和 NoClassDefFoundError等异常。
类加载器（class loader）用来加载 Java 类装到到 Java 虚拟机中
类加载过程
Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成 Java 字节代码（.class 文件）。类加载器负责读取 Java 字节代码，并转换成 java.lang.Class类的一个实例。每个这样的实例用来表示一个 Java 类。通过此实例的 newInstance()方法或构造器就可以创建出该类的一个对象。
java.lang.ClassLoader介绍
基本上所有的类加载器都是 java.lang.ClassLoader类的一个实例（引导加载器不在其中）
java.lang.ClassLoader类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即 java.lang.Class类的一个实例。
ClassLoader还负责加载 Java 应用所需的资源，如图像文件和配置文件等。
为了完成加载类的这个职责，ClassLoader提供了一系列的方法，比较重要的方法如下所示。
| 方法 | 说明 |
|---|---|
| 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 应用开发人员编写的。系统提供的类加载器主要有下面三个：
graph LR
E[引导类加载器]-->F[rt.jar]
C[扩展类加载器]-->D[jre/lib/ext]
A[应用类加载器]-->B[classPath]
G[自定义类加载器]-->H[自定义路径下的class]
- 引导类加载器（bootstrap class loader）：它用来加载 Java 的核心库，是用原生代码来实现的，并不继承自 java.lang.ClassLoader。
- 扩展类加载器（extensions class loader）：它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。
- 应用类加载器（app class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它。 它也叫系统类加载器，但是应用类加载器更符合该类的思想
除了系统提供的类加载器以外，开发人员可以通过继承 java.lang.ClassLoader类的方式实现自己的类加载器，以满足一些特殊的需求。比如插件等
类加载器的层次结构
graph BT
F[自定义加载器B1]-->E[应用类加载器]
G[自定义加载器B2]-->E[应用类加载器]
E[自定义加载器B]-->B[应用类加载器]
A[自定义加载器A]-->B[应用类加载器]
B[应用类加载器]-->C[扩展类加载器]
C[扩展类加载器]-->D[引导类加载器]
- 除了引导类加载器之外，所有的类加载器都有一个父类加载器。
- 通过上表中给出的 getParent()方法可以得到。对于系统提供的类加载器来说，应用类加载器的父类加载器是扩展类加载器，而扩展类加载器的父类加载器是引导类加载器；
- 对于开发人员编写的类加载器来说，其父类加载器是加载这个类的类加载器。
- 一般来说，开发人员编写的类加载器的父类加载器是应用类加载器。
- 类加载器通过这种方式组织起来，形成树状结构。树的根节点就是引导类加载器。上图 中给出了一个典型的类加载器树状组织结构示意图，其中的箭头指向的是父类加载器。
类加载的设计思想
- 文章到了这里就到了最难理解的地方，也是作者在阅读其他文档时最困惑的地方。
- 首先我们回顾classLoader类中的两个特殊方法
| 方法 | 说明 |
|---|---|
| loadClass(String name) | 加载名称为 name的类，返回的结果是 java.lang.Class类的实例。 |
| findClass(String name) | 查找名称为 name的类，返回的结果是 java.lang.Class类的实例。 |
大家有没有发现这两个核心方法是如此的相像，看似一个加载一个为查找但是实现的功能都一样，都是找到特定的类并加载，而作者一直困扰的核心问题就在这两个方法上，在下文中我们一一解惑
类加载器的委托模式（代理模式）
- 我们先看看一个类的加载过程,并剖析
类加载器在尝试去查找某个类并定义它时，会先委托给父类加载器，由父类加载器先去尝试加载这个类，依次类推。
由这句话我们可以知道一个类的加载过程如果异常一样，最先不在底层的类加载器加载而是由父类加载器加载，当父类加载器还有父类加载器时继续交给上级加载。
在介绍代理模式背后的动机之前，首先需要说明一下 Java 虚拟机是如何判定两个 Java 类是相同的。Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。
即便是同样的字节代码(同一个class文件)，被不同的类加载器加载之后所得到的类，也是不同的。比如一个 Java 类 com.example.Sample，编译之后生成了字节代码文件 Sample.class。两个不同的类加载器 ClassLoaderA和 ClassLoaderB分别读取了这个 Sample.class文件，并定义出两个 java.lang.Class类的实例来表示这个类。这两个实例是不相同的。对于 Java 虚拟机来说，它们是不同的类。试图对这两个类的对象进行相互赋值，会抛出运行时异常 ClassCastException。
明白这一点之后，就可以理解委托模式的设计动机了。委托模式是为了保证 Java 核心库的类型安全。所有 Java 应用都至少需要引用 java.lang.Object类，也就是说在运行的时候，java.lang.Object这个类需要被加载到 Java 虚拟机中。如果这个加载过程由 开发者自己定义的类加载器来完成的话，很可能就存在多个版本的 java.lang.Object类，而且这些类之间是不兼容的。通过委托模式，对于 Java 核心库的类的加载工作由引导类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。
不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。这种技术在许多框架中都被用到，比如插件，插件有非常大的几率有重名的类，使用额外的命名空间就保证了同一个应用中有多个插件存在，并运行。
断言
当写到此处时，阅读了一篇重量级的博客，才发现自以为的理解还是有偏差的，并且这篇文章已经写的非常好了，完全没必要此在赘述，有时间转载并重新排版此文章表示对大神的敬意。
- 下面这链接就是神级别的博客
http://www.blogjava.net/zhuxing/archive/2008/08/08/220841.html
- 这些是学习类加载机制时，阅读过的优秀博客
http://blog.csdn.net/fenglibing/article/details/17471659
https://www.ibm.com/developerworks/cn/java/j-lo-classloader/
http://tyrion.iteye.com/blog/1958814
http://hllvm.group.iteye.com/group/topic/38709
https://www.cnblogs.com/gaoxing/p/4703412.html
