要深入了解ClassLoader，首先就要知道ClassLoader是用来干什么的，顾名思义，它就是用来加载Class文件到JVM，以供程序使用 的。我们知道，java程序可以动态加载类定义，而这个动态加载的机制就是通过ClassLoader来实现的，所以可想而知ClassLoader的重 要性如何。
既然ClassLoader是用来加载类到JVM中的，那么ClassLoader又是如何被加载呢？难道它不是java的类？
JDK 默认提供了如下几种ClassLoader:
1. Bootstrp loader
Bootstrp加载器是用C++语言写的，它是在Java虚拟机启动后初始化的，它主要负责加载%JAVA_HOME%/jre/lib,-Xbootclasspath参数指定的路径以及%JAVA_HOME%/jre/classes中的类。
1. ExtClassLoader
Bootstrp loader加载ExtClassLoader,并且将ExtClassLoader的父加载器设置为Bootstrploader.ExtClassLoader是用Java写的，具体来说就是 sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要加载%JAVA_HOME%/jre/lib/ext，此路径下的所有classes目录以及java.ext.dirs系统变量指定的路径中类库。
2. AppClassLoader
Bootstrp loader加载完ExtClassLoader后，就会加载AppClassLoader,并且将AppClassLoader的父加载器指定为 ExtClassLoader。AppClassLoader也是用Java写成的，它的实现类是sun.misc.Launcher$AppClassLoader，另外我们知道ClassLoader中有个getSystemClassLoader方法,此方法返回的正是AppclassLoader.AppClassLoader主要负责加载classpath所指定的位置的类或者是jar文档，它也是Java程序默认的类加载器。
当运行一个程序的时候，JVM启动，运行bootstrap classloader，该ClassLoader加载java核心API（ExtClassLoader和AppClassLoader也在此时被加 载），然后调用ExtClassLoader加载扩展API，最后AppClassLoader加载CLASSPATH目录下定义的Class，这就是一 个程序最基本的加载流程。
上面大概讲解了一下ClassLoader的作用以及一个最基本的加载流程，接下来将讲解一下ClassLoader加载的方式，这里就不得不讲一下ClassLoader在这里使用了双亲委托模式进行类加载。
每一个自定义ClassLoader都必须继承ClassLoader这个抽象类，而每个ClassLoader都会有一个parent ClassLoader，我们可以看一下ClassLoader这个抽象类中有一个getParent()方法，这个方法用来返回当前 ClassLoader的parent，注意，这个parent不是指的被继承的类，而是在实例化该ClassLoader时指定的一个 ClassLoader，如果这个parent为null，那么就默认该ClassLoader的parent是bootstrap classloader，这个parent有什么用呢？
我们可以考虑这样一种情况，假设我们自定义了一个ClientDefClassLoader，我们使用这个自定义的ClassLoader加载 java.lang.String，那么这里String是否会被这个ClassLoader加载呢？事实上java.lang.String这个类并不 是被这个ClientDefClassLoader加载，而是由bootstrap classloader进行加载，为什么会这样？实际上这就是双亲委托模式的原因，因为在任何一个自定义ClassLoader加载一个类之前，它都会先 委托它的父亲ClassLoader进行加载，只有当父亲ClassLoader无法加载成功后，才会由自己加载，在上面这个例子里，因为 java.lang.String是属于java核心API的一个类，所以当使用ClientDefClassLoader加载它的时候，该 ClassLoader会先委托它的父亲ClassLoader进行加载，上面讲过，当ClassLoader的parent为null 时，ClassLoader的parent就是bootstrap classloader，所以在ClassLoader的最顶层就是bootstrap classloader，因此最终委托到bootstrap classloader的时候，bootstrap classloader就会返回String的Class。
我们来看一下ClassLoader中的一段源代码：
protected synchronized Class loadClass(String name, boolean resolve) throws ClassNotFoundException{ // 首先检查该name指定的class是否有被加载 Class c = findLoadedClass(name); if (c == null) { try { if (parent != null) { //如果parent不为null，则调用parent的loadClass进行加载 c = parent.loadClass(name, false); }else{ //parent为null，则调用BootstrapClassLoader进行加载 c = findBootstrapClass0(name); } }catch(ClassNotFoundException e) { //如果仍然无法加载成功，则调用自身的findClass进行加载 c = findClass(name); } } if (resolve) { resolveClass(c); } return c; }
从上面一段代码中，我们可以看出一个类加载的大概过程与之前我所举的例子是一样的，而我们要实现一个自定义类的时候，只需要实现findClass方法即可。
为什么要使用这种双亲委托模式呢？
第一个原因就是因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。
第二个原因就是考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义类 型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时被加载，所以用户自定义类是无法加载一个自定义的 ClassLoader。
上面对ClassLoader的加载机制进行了大概的介绍，接下来不得不在此讲解一下另外一个和ClassLoader相关的类，那就是Class类，每 个被ClassLoader加载的class文件，最终都会以Class类的实例被程序员引用，我们可以把Class类当作是普通类的一个模板，JVM根 据这个模板生成对应的实例，最终被程序员所使用。
我们看到在Class类中有个静态方法forName，这个方法和ClassLoader中的loadClass方法的目的一样，都是用来加载class的，但是两者在作用上却有所区别。
那为啥要自定义classloader呢？
我觉得，主要有以下原因：
1.类隔离。不想让某些类被其他类看见。
2.安全因素。比如我有一个自定义的加密类的文件，只有用我自己的classloader才能解析成正常的类文件并运行。
3.功能因素。对类加载器有其他的需求之类。
原标题：ClassLoader究竟为何物？
关键词：
我知道了 