先介绍下基本概念：

类装载器是用来把类(class)装载进JVM的。

JVM规范定义了两种类型的类装载器：启动内装载器(bootstrap)和用户自定义装载器(user-defined class loader)。 

JVM在运行时会产生三个ClassLoader:Bootstrap ClassLoader、Extension ClassLoader和AppClassLoader.Bootstrap是用C++编写的，我们在Java中看不到它,是null,是JVM自带的类装载器，用来装载核心类库，如java.lang.*等。

AppClassLoader的Parent是ExtClassLoader，而ExtClassLoader的Parent为Bootstrap ClassLoader。

 

Java提供了抽象类ClassLoader，所有用户自定义类装载器都实例化自ClassLoader的子类。 System Class Loader是一个特殊的用户自定义类装载器，由JVM的实现者提供，在编程者不特别指定装载器的情况下默认装载用户类。系统类装载器可以通过ClassLoader.getSystemClassLoader() 方法得到。

java类开始执行是从appClassLoader开始的，自定义的classloader的默认parent就是appClassLoader

每个ClassLoader维护一个命名空间，一个命名空间内不准出现两个name相同的class

理解了这些，那么我们来了解一下WebApp下的ClassLoader层次，以tomcat为例

tomcat为每个app分配了一个 WebappClassLoader ，这样来避免多个app会加载相同jar包的问题，

WebappLoader的parent是 StandardClassLoader,这样多个app就能共享tomcat的类库

当tomcat为每个请求启动线程后，会将该线程的classloader设为 WebappLoader，如果不设置，那么新建的线程默认为 父线程的classloader。 

案例， 如何在request中使用自定义classloader生成了一个class 

              classloader的默认parent 为appclassloader，因此 classloader只能引用一些jdk的class，不能引用webappClassLoader范围的class，最好就将classloader 的parent设为 this.getClass().getClassLoader()。 如果你有特殊需求就需要你来根据classloader的层次和范围来进行设置。

之前我对classloader只知道分为3个层次，自定义classloader的parent的问题一直没注意，昨天写代码出现了这个问题，今天才意识到是parent的问题，自己写了一个test证实了这个问题，写出来分享一下