类加载器是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也会采用代理模式去请求他的父类加载器。在这个过程中,设计到类加载器的另外两个概念。
从上面的定义来看,初始加载器和定义加载器有可能不是同一个。例如对于上面的例子来说,初始加载器应该是用户类加载器B_2,而定义加载器不一定是她,要看最后到底由谁调用了defineClass()方法将类从字节码转换成class实例。
- 初始加载器(initialing loader):用来启动类加载过程的类
- 定义加载器(defining loader):用来将类从字节码转换为class实例
类的命名空间
用户加载器存在的理由在java虚拟机中一个类的命名空间不是由类的类名决定的。而是通过类名和类定义加载器来决定的。也就是说如果同一个class由两个定义加载器将他分别转换成为了连个class实例,那么这两个类也不是同一个I饿类实例,如果将这两个类的变量进行相互赋值则会发生java.lang.reflect.InvocationTargetException异常。
类加载默认的代理模式保证了java虚拟机中的核心对象由同一个类定义器来定义,例如ArrayList对象,我们肯定希望java应用中使用的该对象都是同一个版本。这就需要让他们在系统加载器的引导加载器中定义。
类加载的默认代理模式很好,但是在很多时候,我们不希望采用默认的代理模式来加载类。例如tomcat的类加载模式就是一个例子。每个webapp希望将自己目录下的lib目录下的jar类由自己的类加载器来定义。这样就可以在不同的webapp下使用同一个类的不同版本。这就需要实现用户类加载器来实现。
还有其他的理由,例如如果基于安全的理由对java的字节码进行了加密,那么类加载前需要对其进行解密,然后进行正常的类加载流程,这个就需要用用户类加载器来实现。