JVM之ClassLoader

      ClassLoader的继承关系是从 BootStrapClassLoader开始的，也是由它最先加载类，然后是 ExtClassLoader，接下来是 AppClassLoader（应用程序默认的），最后是用户自己的ClassLoader（通常在容器下编写代码，都是由容器自定义创建的 ClassLoader创建的类）。
（1） Bootstrapclass Loader主要用于加载一些Java自带的核心类（例如 java. lang.*），通常这些核心类的Class被签名，不能被替换掉，它是由JVM内核实现的，在 Hotspot VM中是用C＋实现的，有了它加载最核心的内容，オ会有后面的 ClassLoader的存在。(加载<JAVA_HOME>\lib目录下核心库)
（2） ExtClassLoader是加载在 jre/lib/ext/目录下的jar包,用户也可以自己将jar包放到这个目录下,通过这个 ClassLoader来加载。
（3） AppClassLoader也是用户可见的 ClassLoader．，它加载的是 classpath下面的内容，也就是和 classpath相关的类，在默认情况下都由它来加载。
（4）用户自定义的 ClassLoader要加载的内容可能不在系统的 classpath范围内（当然也可以在这个范围内），甚至不是Class文件或jar文件，也就是加载方式可以完全由自己来定义。
       例如，想要将自己写的一段Java代码动态加载到JVM进程中，就可以通过自定义的ClassLoader来实现（当然自定义的 ClasssLoader还有其他的用途，比如可以加载一些远程的jar包）。用户自定义的 Classloader一般继承于 URLClassloader，也可以继承于 ClassLoader或SecureClassLoader，它们之间本身也是继承关系，根据实际情况重写不同的方法即可。
         进程启动时，通常会加载一些JVM的核心库，它并不会加载项目中所有的 Class（因为这些Clas还是会占用很多空间的，例如项目中可能有好几百MB甚至更大的jar包，它们都不是系统启动时加的）。除了加一些JVM的核心库通常还会加引导方法（main）所在的类，以及main所在类会使用到的类。

Java虚拟机先从最核心的API开始查找，防止不可信的类扮演被信任的类。

双亲委派模型

双亲委派模型要求除顶层启动类加载器外其余类加载器都应该有自己的父类加载器；类加载器之间通过复用关系来复用父加载器的代码。
双亲委派模型工作工程：

1.当Application ClassLoader 收到一个类加载请求时，他首先不会自己去尝试加载这个类，而是将这个请求委派给父类加载器Extension ClassLoader去完成。  

2.当Extension ClassLoader收到一个类加载请求时，他首先也不会自己去尝试加载这个类，而是将请求委派给父类加载器Bootstrap ClassLoader去完成。  

3.如果Bootstrap ClassLoader加载失败(在<JAVA_HOME>\lib中未找到所需类)，就会让Extension ClassLoader尝试加载。 

4.如果Extension ClassLoader也加载失败，就会使用Application ClassLoader加载。  

5.如果Application ClassLoader也加载失败，就会使用自定义加载器去尝试加载。 

6.如果均加载失败，就会抛出ClassNotFoundException异常。 

 

 双亲委派模型的实现过程：

实现双亲委派模型的代码都集中在java.lang.ClassLoader的loadClass()方法中：  
首先会检查请求加载的类是否已经被加载过；  
若没有被加载过：  
递归调用父类加载器的loadClass();  
父类加载器为空后就使用启动类加载器加载；  
如果父类加载器和启动类加载器均无法加载请求，则调用自身的加载功能。

双亲委派模型的优点：

Java类伴随其类加载器具备了带有优先级的层次关系，确保了在各种加载环境的加载顺序。  
保证了运行的安全性，防止不可信类扮演可信任的类。