java深度学习：类加载器

类加载器是java中的一个概念，他负责将java的字节码加载到java虚拟机中，转换成为一个java class实例，以便后面执行，这个转换过程叫类的定义。后面会讲到类的加载和类的定义不是同一个概念，需要区分开。

类加载器类别

系统类加载器：在java虚拟机内置的类加载器。其中引导加载器根据不同的JDK的实现，可见性不一样。

• 引导类加载器（bootstrap class loader）：它用来加载 Java 的核心库，是用原生代码来实现的，并不继承自java.lang.ClassLoader。具体来说就是加载$JAVA_HOME/jre/lib/rt.jar
• 扩展类加载器（extensions class loader）：它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。具体来说就是加载$JAVA_HOME/jre/ext/目录下的所有jar文件
• 系统类加载器（system class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它。具体来说就是加载$CLASSPATH环境变量中的jar文件

用户类加载器：有用户编码，为满足特定功能而实现的类加载器。

类加载器的树形结构

每个类加载器都有一个getParent()来返回他的父加载器实例，每个类加载器都有一个父加载器，每个类加载器的父类加载器就是加载该加载器类的加载器。例如加载器B是通过加载器A加载的，那么加载器A就是加载器B的父加载器。类加载器的树形结构如下图所示：

类加载代理模式

类加载的时候，默认是通过一种代理模式进行加载的。即类加载器加载一个类的时候会先尝试用他的父类加载器进行加载，只有父类无法加载该类的时候，才会让该类加载器进行加载。例如在上图中，如果用户类加载器B_2要加载一个类BTest的时候，他会首先尝试让用户类加载器B进行加载。如果用户类加载器B类能够加载则让用户加载器B类进行加载，否则就用用户加载器B_2加载。当然用户加载器B也会采用代理模式去请求他的父类加载器。在这个过程中，设计到类加载器的另外两个概念。

• 初始加载器（initialing loader）：用来启动类加载过程的类
• 定义加载器（defining loader）：用来将类从字节码转换为class实例

从上面的定义来看，初始加载器和定义加载器有可能不是同一个。例如对于上面的例子来说，初始加载器应该是用户类加载器B_2，而定义加载器不一定是她，要看最后到底由谁调用了defineClass（）方法将类从字节码转换成class实例。

类的命名空间

在java虚拟机中一个类的命名空间不是由类的类名决定的。而是通过类名和类定义加载器来决定的。也就是说如果同一个class由两个定义加载器将他分别转换成为了连个class实例，那么这两个类也不是同一个I饿类实例，如果将这两个类的变量进行相互赋值则会发生java.lang.reflect.InvocationTargetException异常。

类加载默认的代理模式保证了java虚拟机中的核心对象由同一个类定义器来定义，例如ArrayList对象，我们肯定希望java应用中使用的该对象都是同一个版本。这就需要让他们在系统加载器的引导加载器中定义。

用户加载器存在的理由

类加载的默认代理模式很好，但是在很多时候，我们不希望采用默认的代理模式来加载类。例如tomcat的类加载模式就是一个例子。每个webapp希望将自己目录下的lib目录下的jar类由自己的类加载器来定义。这样就可以在不同的webapp下使用同一个类的不同版本。这就需要实现用户类加载器来实现。

还有其他的理由，例如如果基于安全的理由对java的字节码进行了加密，那么类加载前需要对其进行解密，然后进行正常的类加载流程，这个就需要用用户类加载器来实现。