对类加载器和类加载器的完善，知识包括：破坏双亲委派机制的应用、jdk9后双亲委派的改变、自定义类加载器的实现。
“破坏”并不是一种贬义，而是对技术的一种创新，通过’破坏’双亲委派机制，可以更好的满足用户对加载需要的要求。
知道java模块的（jdk9）位置，双亲委派机制出现过三次较大规模的破坏的情况。
双亲委派机制是在jdk1.2的时候引入的，为了兼顾以前的代码，所以对ClassLoader扩展的一个新的Protected的findClass()方法来让用户实现加载的时候尽量重写这个方法。即jdk1.2之前的代码不遵循双亲委派机制
是双亲委派机制这个模型本身的一些缺陷导致的。双亲委派机制的作用是：越基础的类越由上层加载器来加载，但是没有决对的事情，随着技术的发展，有些基础的类需要使用其下层的类，但是启动类加载器不可能认识下次的类，所以对双亲委派机制进行了破坏。
如jdbc，它是一种规范，需要调用其他厂商的对jdbc的实现的代码（如mysql），但是启动类加载器是不认识其他厂商（mysql）的代码的，所以引入了线程上下文类加载器。这个时候父类加载器就可以去请求子类加载器对类进行加载了。
第三次被破坏是最求的‘热替换’功能，也就是说，希望java代码可以像电脑的外设设备一样，不用关机便对设备进行替换（如鼠标）。也就是希望在运行的程序，不用继续下线，便可以重新加载更新的代码（如：jsp）。
public Class loadClass(String name, boolean resolve)
2 throws ClassNotFoundException {
3 Class clazz = null;
4 // (0) 先从自己的缓存中查找，有则返回，无则继续
5 clazz = findLoadedClass0(name);
6 if (clazz != null) {
7 if (resolve) resolveClass(clazz);
8 return (clazz);
9 }
10 // (0.1) 再从parent的缓存中查找
11 clazz = findLoadedClass(name);
12 if (clazz != null) {
13 if (resolve) resolveClass(clazz);
14 return (clazz);
15 }
16 // (0.2) 缓存中没有，则首先使用system类加载器来加载
17 clazz = system.loadClass(name);
18 if (clazz != null) {
19 if (resolve) resolveClass(clazz);
20 return (clazz);
21 }
22 //判断是否需要先让parent代理
23 boolean delegateLoad = delegate || filter(name);
24 // (1) 先让parent加载，通常delegateLoad == false，即这一步不会执行
25
26 if (delegateLoad) {
27 ClassLoader loader = parent;
28 if (loader == null)
29 loader = system;
30 clazz = loader.loadClass(name);
31 if (clazz != null) {
32 if (resolve) resolveClass(clazz);
33 return (clazz);
34 }
35 }
36 // (2) delegateLoad == false 或者 parent加载失败，调用自身的加载机制
37 clazz = findClass(name);
38 if (clazz != null) {
39 if (resolve) resolveClass(clazz);
40 return (clazz);
41 }
42 // (3) 自己加载失败，则请求parent代理加载
43
44 if (!delegateLoad) {
45 ClassLoader loader = parent;
46 if (loader == null)
47 loader = system;
48 clazz = loader.loadClass(name);
49 if (clazz != null) {
50 return (clazz);
51 }
52 }
53 throw new ClassNotFoundException(name);
54 }
流程图：
- 隔离加载类
在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如：阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如：Tomcat这类Web应用服务器，内部自定义了好几种类加载器，用于隔离同一个Web应用服务器上的不同应用程序。 （类的仲裁–>类冲突）
- 修改类加载的方式
类的加载模型并非强制，除Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载
- 扩展加载源
比如从数据库、网络、甚至是电视机机顶盒进行加载
- 防止源码泄漏
Java代码容易被编译和篡改，可以进行编译加密。那么类加载也需要自定义，还原加密的字节码。
手写自定义加载器：注意：在一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。但是，如果涉及Java类型转换，则加载器反而容易产生不美好的事情。在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能进行类型转换，否则转换时会发生异常。
public class UserClassLoader extends ClassLoader {
private String rootDir;
public UserClassLoader(String rootDir) {
this.rootDir = rootDir;
}
@Override
protected Class findClass(String name) throws ClassNotFoundException {
// 获取类的class文件字节数组
byte[] classData = getClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
} else {
//直接生成class对象,调用ClassLoader类的
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();
byte[] buffer = new byte[1024];
int len = 0;
// 读取类文件的字节码
while ((len = ins.read(buffer)) != -1) {
baos.write(buffer, 0, len);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
}
为了兼容性，jdk9没有从本质上破坏双亲委派机制，但是对双亲外派机制的结构进了修改
- 扩展类机制被移除，但是为了保证向后兼容，扩展类加载器任被保留，不过被重命名为了平台类加载器（platform class loader）。由于jdk9的模块化构建，原来的 rt.jar 和 tools.jar 被拆分成数十个 JMOD 文件，其中的 Java 类库就已天然地满足了可扩展的需求，那自然无须再保留
jdk9的加载器委派关系图：
