关于Java中的类加载器

相信大家都遇到过java.lang.ClassNotFoundExcetpion这个异常肯定都不陌生，这个异常背后涉及到的是Java技术体系中的类加载机制。其中Java有三种加载器:
1）根类加载器：Bootstrap ClassLoader（我们使用的String等类）
也称为引导类加载器，负责java核心类的加载。比如，System Object String等，在JDK中的JRE的lib目录下rt.jar文件中,

2）扩展类加载器：Extension ClassLoader
负责JRE的扩展目录中jre包的加载。在JDK中JRE的lib目录下ext目录
如:ExtClassLoader

3）系统类加载器:System ClassLoader（加载我们自己写的）
负责在JVM启动时加载来自java命令的class文件以及classpath环境变量所指的jar包和类路径 如:AppClassLoader

类加载双亲委派机制介绍
在这里，需要着重说明的是，JVM在加载类时默认采用的是双亲委派机制。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归 (本质上就是loadClass函数的递归调用)。因此，所有的加载请求最终都应该传送到顶层的启动类加载器中。
如果父类加载器可以完成这个类加载请求，就成功返回。 只有当父类加载器无法完成此加载请求时，子加载器才会尝试自己去加载。事实上，大多数情况下，越基础的类由越上层的加载器进行加载，因为这些基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的API（当然，也存在基础类回调用户用户代码的情形）。

为什么需要双亲委派模型？
为了使Java的核心类这样重要常用的类不会被覆盖。例如:
黑客自定义一个java.lang.String类，该String类具有系统的String类一样的功能，只是在某个函数稍作修改。比如equals函数，这个函数经常使用，如果在这这个函数中，黑客加入一些“病毒代码”。并且通过自定义类加载器加入到JVM中。此时，如果没有双亲委派模型，那么JVM就可能误以为黑客自定义的java.lang.String类是系统的String类，导致“病毒代码”被执行。

而有了双亲委派模型，黑客自定义的java.lang.String类永远都不会被加载进内存。因为首先是最顶端的类加载器加载系统的java.lang.String类，最终自定义的类加载器无法加载java.lang.String类。