Java中一共有四个类加载器，之所以叫类加载器，是程序要用到某个类的时候，要用类加载器载入内存。
这四个类加载器分别为：Bootstrap ClassLoader、Extension ClassLoader、AppClassLoader
和URLClassLoader，他们的作用其实从名字就可以大概推测出来了。其中AppClassLoader在很多地方被叫做System ClassLoader
Bootstrap ClassLoader是在JVM开始运行的时候加载java的核心类，是用C++编写的，它用来加载核心类库，在JVM源代码中这样写道：
static const char classpathFormat[] =
"%/lib/rt.jar:"
"%/lib/i18n.jar:"
"%/lib/sunrsasign.jar:"
"%/lib/jsse.jar:"
"%/lib/jce.jar:"
"%/lib/charsets.jar:"
"%/classes";
Extension ClassLoader是用来加载扩展类，即/lib/ext中的类。
AppClassLoader用来加载Classpath的类，是和我们关系最密切的类。
URLClassLoader用来加载网络上远程的类，暂且不讨论。
它们之间的关系:
1.Parent-Child，按顺序从大到小。不是简单的继承关系。
2.ClassLoader有个getParent的方法，但是Ext ClassLoader调用后得到的是null，bootstrap是JVM自己的，用户看不到。
3.classloader的委托机制：当等级比较低的ClassLoader要加载某个类的时候，它首先会请求Parent加载器来加载，Parent再请求它的Parent
比如现在Ext要加载了，它往上请求。如果最大的Bootstrap找不到，那么Boot会叫Ext自己找找，Ext找不到，是不会让下一级的App去找的，此时就报出ClassNotFoundException
4.类A调用类B，B会要求调用它的类的类加载器来加载它，也就是B会要求加载A的加载器来加载B。这就会有个问题，如果他们在一起，那没关系，肯定某个classloader会把它们俩都加载好。但是如果A在/lib/ext文件夹中，而B在Classpath中呢？过程是这样的首先加载A，那么一层层上到Bootstrap Classloader，boot没找到所以ext自己找，找到了，没问题；加载B，因为A调用了B，所以也从bootstrap来找，没找到，然后A的ext classloader来找还是没找到，但是再也不会往下调用了，于是报出ClassNotFoundException。
但是现实生活中有很多应用，比如JDBC核心方法在核心库而驱动在扩展库，是必定在两个地方的，那怎么办呢？要用到Context ClassLoader我们在建立一个线程Thread的时候，可以为这个线程通过setContextClassLoader方法来指定一个合适的classloader作为这个线程的context classloader，当此线程运行的时候，我们可以通过getContextClassLoader方法来获得此context classloader，就可以用它来载入我们所需要的Class。默认的是system classloader。利用这个特性，我们可以“打破”classloader委托机制了，父classloader可以获得当前线程的context classloader，而这个context classloader可以是它的子classloader或者其他的classloader，那么父classloader就可以从其获得所需的 Class，这就打破了只能向父classloader请求的限制了。这个机制可以满足当我们的classpath是在运行时才确定,并由定制的 classloader加载的时候,由system classloader(即在jvm classpath中)加载的class可以通过context classloader获得定制的classloader并加载入特定的class(通常是抽象类和接口,定制的classloader中是其实现),例如web应用中的servlet就是用这种机制加载的.