讲个故事：html
之前，爱捣鼓的小明忽然灵机一动，写出了下面的代码java
package java.lang;
public class String {
//...复制真正String的其余方法
public boolean equals(Object anObject) {
sendEmail(xxx)；
return equalsReal(anObject);
}
//...
}
这样，只要引用java.lang.String的人，小明能随时收到他的系统的相关信息，这简直是个天才的注意。然而实施的时候却发现，JVM并无加载这个类。缓存
这是为何呢？安全
小明能想到的事情，JVM设计者也确定能想到。微信
双亲委派模型
上述故事纯属瞎编，不过，这确实是之前JVM存在的一个问题，这几天看Tomcat源代码的时候，发现频繁出现ClassLoader为何要用这个东西呢？架构
想要解答这个问题，得先了解一个定义：双亲委派模型。app
这个词第一次看见是在《深刻理解JVM》中，目的也是为了解决上面所提出来的问题。框架
在JVM中，存在三种类型的类加载器：ide
- 启动类（Bootstrap）加载器： 用于加载本地（
Navicat）代码类的加载器，它负责装入%JAVA_HOME%/lib下面的类。因为引导类加载器涉及到虚拟机本地实现细节，开发者没法直接获取到启动类加载器的引用，因此不容许直接经过引用进行操做。 - 标准扩展（Extension）类加载器： 由
ExtClassLoader实现，负责加载%JAVA_HOME/lib/ext%或者系统变量java.ext.dir（可以使用System.out.println("java.ext.dir")查看)指定的类加载到内存中 - 系统（System）类加载器： 由
AppClassLoader实现，负责加载系统类（环境变量%CLASSPATH%）指定，默认为当前路径的类加载到内存中。
除去以上三种外，还有一种比较特殊的线程上下文类加载器。存在于Thread类中，通常使用方式为new Thread().getContextClassLoader()this
能够看出来，三种类型的加载器负责不一样的模块的加载。那怎么才能保证我所使用的String就是JDK里面的String呢？这就是双亲委派模型的功能了：
上面三种类加载器中，他们之间的关系为：
也就是Bootstrap ClassLoader做为Extension ClassLoader的父类，而Extension ClassLoader做为Application ClassLoader的父类，Application ClassLoader是做为User ClassLoader的父类的。
而双亲委派机制规定：当某个特定的类加载在接收到类加载的请求的时候，首先须要将加载任务委托给父类加载器，依次递归到顶层后，若是最高层父类可以找到须要加载的类，则成功返回，若父类没法找到相关的类，则依次传递给子类。
补充：
- 若是A类引用了B，则JVM将使用加载类A的加载器加载类B
- 类加载器存在缓存，若是某个加载器之前成功加载过某个类后，再次接受到此类加载请求则直接返回，再也不向上传递加载请求
- 能够经过
ClassLoader.loadClass()或Class.ForName(xxx,true,classLoader)指定某个加载器加载类 - 类类型由加载它的加载器和这个类自己共同决定，若是类加载器不一样，类名相同，
instanceof依然会返回false - 父加载器没法加载子加载器可以加载的类
能够看到，经过双亲委派机制，可以保证使用的类的安全性，而且能够避免类重名的状况下JVM存在多个相同的类名相同，字节码不一样的类。
回到刚开始讲的故事，虽然小明自定义了
String,包名也叫java.lang，可是当用户使用String的时候，会由普通的Application ClassLoader加载java.lang.String，此时经过双亲委派，类加载请求会上传给Application ClassLoader的父类，直到传递给Bootstrap ClassLoader，而此时，Bootstrap ClassLoader将在%JAVA_HOME%/lib中寻找java.lang.String而此时正好可以找到java.lang.String，加载成功，返回。所以小明本身写的java.lang.String并无被加载。
能够看见，若是真的想要实现小明的计划，只能将小明本身编写的
java.lang.String这个class文件替换到%JAVA_HOME%/lib/rt.jar 中的String.class
自定义ClassLoader
到这里，估计能明白为何须要双亲委派模型了，而某些时候，咱们能够看见许多框架都自定义了ClassLoader，经过自定义ClassLoader，咱们能够作不少好玩的事情，好比：设计一个从指定路径动态加载类的类加载器：
public class DiskClassLoader extends ClassLoader {
private String libPath;
public DiskClassLoader(String path){
libPath=path;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try(FileInputStream fileInputStream=new FileInputStream(new File(libPath,getFileName(name)));
BufferedInputStream bufferedInputStream=new BufferedInputStream(fileInputStream);
ByteArrayOutputStream byteArrayOutputStream=new ByteArrayOutputStream()){
for (int len=0;(len=bufferedInputStream.read())!=-1;){
byteArrayOutputStream.write(len);
}
byte[] data=byteArrayOutputStream.toByteArray();
return defineClass(name,data,0,data.length);
}catch (IOException e){
e.printStackTrace();
}
return super.findClass(name);
}
private String getFileName(String name) {
int index = name.lastIndexOf('.');
if(index == -1){
return name+".class";
}else{
return name.substring(index+1)+".class";
}
}
}
上面是一个简单的例子，能够看见想要自定义ClassLoader,只须要继承ClassLoader，而后覆盖**findClass()**方法便可，其中findClass()是负责获取指定类的字节码的，在获取到字节码后，须要手动调用defineClass()加载类。
在ClassLoader类中，咱们能找到loadClass的源代码：
protected Class<?> loadClass(String name, boolean resolve) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
if (c == null) {
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
在删减掉一些模板代码后，咱们能够看到loadClass()方法就是实现双亲委派的主要代码：首先查看类是否有缓存，若是没有，就调用父类的loadClass方法，让父类去加载，若是父类加载失败，则本身加载，若是本身加载失败，那就返回null,注意：并无再找本身的子类去寻找类，也就是在哪里发起的加载，就在哪里结束。
这里能够看到，
loadClass()方法并无被标记为final的，也就是咱们依然能够重载它的loadClass()方法，破坏本来的委派双亲模型。
破坏双亲委派机制
有些时候，双亲委派机制也会遇到一些问题，在介绍双亲委派机制的时候，我列举了一些补充。而在一些JDK中，存在一些基础API他们的加载由比较上层的加载器负责,这些API只是一些简单的接口，而具体的实现可能会由其余用户本身实现，这个时候就存在一个问题，若是这些基础的API须要调用/加载用户的代码的时候，会发现因为父类没法找到子类所能加载的类的缘由，调用失败。
最典型的例子即是JNDI服务，JNDI服务是在JDK1.3的时候放入rt.jar中，而rt.jar有Bootstrap ClassLoader加载，JNDI的功能是对资源进行集中管理和查找，它须要调用独立厂商实现部部署在应用程序的classpath下的JNDI接口提供者(SPI, Service Provider Interface)的代码，但启动类加载器不可能“认识”之些代码，该怎么办？
这就须要用到最开始讲的特殊的加载器：上下文类加载器
上下文类加载器的使用方式为：Thread.currentThread().getContextClassLoader()
上下文类加载器是什么意思呢？能够看源码，Thread初始化是经过本地方法currentThread();初始化的，而classLoader也正是经过currentThread初始化，currentThread指的是当前正在运行的线程。
而默认状况下，启动Launcher后，Launcher会将当前线程的上下文加载器设置为Application ClassLoader
public Launcher() {
//...
try {
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
Thread.currentThread().setContextClassLoader(this.loader);
//...
}
所以，上下文类加载器默认就是系统加载器，经过上下文加载器，更高级别的加载器即可以调用系统加载器加载一个类。
Tomcat 与类加载器
Tomcat做为一个Web容器，会包含各类Web应用程序，而为了使各个应用程序不互相干扰，至少须要达到如下要求：
- 部署在同一个Web容器上的两个Web应用程序所使用的Java类库能够实现相互隔离
- 部署在同一个Web容器上的两个Web应用程序所使用的Java类库能够相互共享
- Web容器须要保证自身的安全不受Web应用程序所影响
- 只是JSP的容器，须要支持热部署功能
由于这些需求，因此在Tomcat中，类的加载不能使用简单的ClassLoader来加载，而是须要自定义分级的ClassLoader。
在Tomcat中，定义了3组目录结构/common/*,/server/*和/shared/*能够存放Java类库，另外还有Web应用程序自身的结构：/WEB-INF/*，而这几级目录结构分别对应了不一样的加载器
- common： 类库能够被Tomcat和全部Web应用程序共同使用
- server： 类库能够被Tomcat使用，对其余Web程序不可见
- shared： 类库能够被全部的Web应用程序共同使用，但对Tomcat不可见
- **WEB-INF: ** 类库仅仅能被自身Web应用程序使用
所以，须要支持以上结构，能够经过自定义遵循双亲委派模型的ClassLoader来完成。
参考连接：
若是以为写得不错，欢迎关注微信公众号：逸游Java ,天天不定时发布一些有关Java干货的文章，感谢关注