深刻JVM系列（三）之类加载、类加载器、双亲委派机制与常见问题

时间  2019-11-24
标签 深刻 jvm 系列 之类 加载 双亲 委派 机制 常见问题 栏目 Java 繁體版
原文   原文链接

一．概述


定义：虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终造成能够被虚拟机直接使用的java类型。类加载和链接的过程都是在运行期间完成的。 java

二. 类的加载方式


1）：本地编译好的class中直接加载
2）：网络加载：java.net.URLClassLoader能够加载url指定的类
3）：从jar、zip等等压缩文件加载类，自动解析jar文件找到class文件去加载util类
4）：从java源代码文件动态编译成为class文件

三．类加载的时机


1. 类加载的生命周期：加载（Loading）-->验证（Verification）-->准备（Preparation）-->解析（Resolution）-->初始化（Initialization）-->使用（Using）-->卸载（Unloading） 程序员

2. 加载：这有虚拟机自行决定。 web

3. 初始化阶段： bootstrap

a) 遇到new、getstatic、putstatic、invokestatic这4个字节码指令时，若是类没有进行过初始化，出发初始化操做。 api

b) 使用java.lang.reflect包的方法对类进行反射调用时。 tomcat

c) 当初始化一个类的时候，若是发现其父类尚未执行初始化则进行初始化。 安全

d) 虚拟机启动时用户须要指定一个须要执行的主类，虚拟机首先初始化这个主类。 服务器

注意：接口与类的初始化规则在第三点不一样，接口不要气全部的父接口都进行初始化。 网络

四．类加载的过程


4.1. 加载


a) 加载阶段的工做 数据结构

i. 经过一个类的全限定名来获取定义此类的二进制字节流。

ii. 将这个字节流所表明的静态存储结构转化为方法区的运行时数据结构。

iii. 在java堆中生成一个表明这个类的java.lang.Class对象，作为方法区这些数据的访问入口。

b) 加载阶段完成以后二进制字节流就按照虚拟机所需的格式存储在方区去中。


4.2. 验证


这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求。

a) 文件格式验证：验证字节流是否符合Class文件格式的规范，而且能被当前版本的虚拟机处理。

b) 元数据验证：对字节码描述的信息进行语义分析，以确保其描述的信息符合java语言规范的要求。

c) 字节码验证：这个阶段的主要工做是进行数据流和控制流的分析。任务是确保被验证类的方法在运行时不会作出危害虚拟机安全的行为。

d) 符号引用验证：这一阶段发生在虚拟机将符号引用转换为直接引用的时候（解析阶段），主要是对类自身之外的信息进行匹配性的校验。目的是确保解析动做可以正常执行。


4.3. 准备


准备阶段是正式为变量分配内存并设置初始值，这些内存都将在方法区中进行分配，这里的变量仅包括类标量不包括实例变量。


4.4. 解析


解析是虚拟机将常量池的符号引用替换为直接引用的过程。

a) 符号引用：符号引用以一组符号来描述所引用的目标，符号能够是任意形式的字面量，只要使用时能无歧义地定位到目标便可。符号引用与虚拟机实现的内存布局无关，引用的目标并不必定已经加载到内存中。

b) 直接引用：直接引用能够是直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。直接饮用是与内存布局相关的。

c) 类或接口的解析

d) 字段的解析

e) 类方法解析

f) 接口方法解析


4.5. 初始化


是根据程序员制定的主观计划区初始化变量和其余资源，或者能够从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。


五. JVM三种预约义类型类加载器


当一个 JVM 启动的时候，Java 缺省开始使用以下三种类型类装入器：


启动（Bootstrap）类加载器：引导类装入器是用本地代码实现的类装入器，它负责将 <Java_Runtime_Home>/lib 下面的类库加载到内存中。因为引导类加载器涉及到虚拟机本地实现细节，开发者没法直接获取到启动类加载器的引用，因此不容许直接经过引用进行操做。


标准扩展（Extension）类加载器：扩展类加载器是由 Sun 的 ExtClassLoader（sun.misc.Launcher$ExtClassLoader） 实现的。它负责将 

< Java_Runtime_Home >/lib/ext 或者由系统变量 java.ext.dir 指定位置中的类库加载到内存中。开发者能够直接使用标准扩展类加载器。


系统（System）类加载器：系统类加载器是由 Sun 的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者能够直接使用系统类加载器。


除了以上列举的三种类加载器，还有一种比较特殊的类型就是线程上下文类加载器，这个将在后面单独介绍。


a. Bootstrap ClassLoader/启动类加载器

主要负责jdk_home/lib目录下的核心 api 或 -Xbootclasspath 选项指定的jar包装入工做.

 

b. Extension ClassLoader/扩展类加载器

主要负责jdk_home/lib/ext目录下的jar包或 -Djava.ext.dirs 指定目录下的jar包装入工做

 

c. System ClassLoader/系统类加载器

主要负责java -classpath/-Djava.class.path所指的目录下的类与jar包装入工做.

 

d.  User Custom ClassLoader/用户自定义类加载器(java.lang.ClassLoader的子类)

在程序运行期间, 经过java.lang.ClassLoader的子类动态加载class文件, 体现java动态实时类装入特性.


六. 类加载双亲委派机制介绍和分析


       在这里，须要着重说明的是，JVM在加载类时默认采用的是双亲委派机制。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，若是父类加载器能够完成类加载任务，就成功返回；只有父类加载器没法完成此加载任务时，才本身去加载。关于虚拟机默认的双亲委派机制，咱们能够从系统类加载器和标准扩展类加载器为例做简单分析。


       图一 标准扩展类加载器继承层次图



                   
        图二 系统类加载器继承层次图


       经过图一和图二咱们能够看出，类加载器均是继承自java.lang.ClassLoader抽象类。咱们下面咱们就看简要介绍一下java.lang.ClassLoader中几个最重要的方法:


 
  1. //加载指定名称（包括包名）的二进制类型，供用户调用的接口  
  2. public Class<?> loadClass(String name) throws ClassNotFoundException{//…}  
  3. //加载指定名称（包括包名）的二进制类型，同时指定是否解析（可是，这里的resolve参数不必定真正能达到解析的效果~_~），供继承用  
  4. protectedsynchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{//…}  
  5. //findClass方法通常被loadClass方法调用去加载指定名称类，供继承用  
  6. protected Class<?> findClass(String name) throws ClassNotFoundException {//…}  
  7. //定义类型，通常在findClass方法中读取到对应字节码后调用，能够看出不可继承（说明：JVM已经实现了对应的具体功能，解析对应的字节码，产生对应的内部数据结构放置到方法区，因此无需覆写，直接调用就能够了）  
  8. protected final Class<?> defineClass(String name, byte[] b, int off, int len)  
  9. throws ClassFormatError{//…}  


       经过进一步分析标准扩展类加载器（sun.misc.Launcher$ExtClassLoader）和系统类加载器（sun.misc.Launcher$AppClassLoader）的代码以及其公共父类（java.net.URLClassLoader和java.security.SecureClassLoader）的代码能够看出，都没有覆写java.lang.ClassLoader中默认的加载委派规则---loadClass（…）方法。既然这样，咱们就能够经过分析java.lang.ClassLoader中的loadClass（String name）方法的代码就能够分析出虚拟机默认采用的双亲委派机制究竟是什么模样：

 
  1. public Class<?> loadClass(String name)throws ClassNotFoundException {  
  2.        return loadClass(name,false);  
  3. }  
  4. protectedsynchronized Class<?> loadClass(String name,boolean resolve)  
  5.            throws ClassNotFoundException {  
  6.        //首先判断该类型是否已经被加载  
  7.         Class c = findLoadedClass(name);  
  8.        if (c ==null) {  
  9.            //若是没有被加载，就委托给父类加载或者委派给启动类加载器加载  
  10.            try {  
  11.                if (parent !=null) {  
  12. //若是存在父类加载器，就委派给父类加载器加载  
  13.                     c = parent.loadClass(name,false);  
  14.                 }else {  
  15. //若是不存在父类加载器，就检查是不是由启动类加载器加载的类，经过调用本地方法native Class findBootstrapClass(String name)  
  16.                     c = findBootstrapClass0(name);  
  17.                 }  
  18.             }catch (ClassNotFoundException e) {  
  19.        //若是父类加载器和启动类加载器都不能完成加载任务，才调用自身的加载功能  
  20.                 c = findClass(name);  
  21.             }  
  22.         }  
  23.        if (resolve) {  
  24.             resolveClass(c);  
  25.         }  
  26.        return c;  
  27.     }  


   经过上面的代码分析，咱们能够对JVM采用的双亲委派类加载机制有了更感性的认识，下面咱们就接着分析一下启动类加载器、标准扩展类加载器和系统类加载器三者之间的关系。可能你们已经从各类资料上面看到了以下相似的一幅图片：


                    
         图三 类加载器默认委派关系图


上面图片给人的直观印象是系统类加载器的父类加载器是标准扩展类加载器，标准扩展类加载器的父类加载器是启动类加载器，下面咱们就用代码具体测试一下：

示例代码：

 
  1. public static void main(String[] args) {  
  2.    try {  
  3.      System.out.println(ClassLoader.getSystemClassLoader());  
  4.      System.out.println(ClassLoader.getSystemClassLoader().getParent();  
  5.      System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());  
  6.    } catch (Exception e) {  
  7.        e.printStackTrace();  
  8.    }  
  9. }  




说明：经过java.lang.ClassLoader.getSystemClassLoader()能够直接获取到系统类加载器。

 
  1. 代码输出以下：  
  2. sun.misc.Launcher$AppClassLoader@197d257  
  3. sun.misc.Launcher$ExtClassLoader@7259da  
  4. null  


   经过以上的代码输出，咱们能够断定系统类加载器的父加载器是标准扩展类加载器，可是咱们试图获取标准扩展类加载器的父类加载器时确获得了null，就是说标准扩展类加载器自己强制设定父类加载器为null。咱们仍是借助于代码分析一下：

     咱们首先看一下java.lang.ClassLoader抽象类中默认实现的两个构造函数：

   

 
  1. protected ClassLoader() {  
  2.         SecurityManager security = System.getSecurityManager();  
  3.        if (security !=null) {  
  4.             security.checkCreateClassLoader();  
  5.         }  
  6.        //默认将父类加载器设置为系统类加载器，getSystemClassLoader()获取系统类加载器  
  7.        this.parent = getSystemClassLoader();  
  8.         initialized =true;  
  9.     }  
  10.    protected ClassLoader(ClassLoader parent) {  
  11.         SecurityManager security = System.getSecurityManager();  
  12.        if (security !=null) {  
  13.             security.checkCreateClassLoader();  
  14.         }  
  15.        //强制设置父类加载器  
  16.        this.parent = parent;  
  17.         initialized =true;  
  18.     }  

   咱们再看一下ClassLoader抽象类中parent成员的声明：

 

 
  1. // The parent class loader for delegation  
  2. e ClassLoaderparent;  

声明为私有变量的同时并无对外提供可供派生类访问的public或者protected设置器接口（对应的setter方法），结合前面的测试代码的输出，咱们能够推断出：


1.系统类加载器（AppClassLoader）调用ClassLoader(ClassLoader parent)构造函数将父类加载器设置为标准扩展类加载器(ExtClassLoader)。（由于若是不强制设置，默认会经过调用getSystemClassLoader()方法获取并设置成系统类加载器，这显然和测试输出结果不符。）


2.扩展类加载器（ExtClassLoader）调用ClassLoader(ClassLoader parent)构造函数将父类加载器设置为null。（由于若是不强制设置，默认会经过调用getSystemClassLoader()方法获取并设置成系统类加载器，这显然和测试输出结果不符。）


     如今咱们可能会有这样的疑问：扩展类加载器（ExtClassLoader）的父类加载器被强制设置为null了，那么扩展类加载器为何还能将加载任务委派给启动类加载器呢？

  

    图四 标准扩展类加载器和系统类加载器成员大纲视图

                  
 
    图五扩展类加载器和系统类加载器公共父类成员大纲视图


    经过图四和图五能够看出，标准扩展类加载器和系统类加载器及其父类（java.net.URLClassLoader和java.security.SecureClassLoader）都没有覆写java.lang.ClassLoader中默认的加载委派规则---loadClass（…）方法。有关java.lang.ClassLoader中默认的加载委派规则前面已经分析过，若是父加载器为null，则会调用本地方法进行启动类加载尝试。因此，图三中，启动类加载器、标准扩展类加载器和系统类加载器之间的委派关系事实上是仍就成立的。（在后面的用户自定义类加载器部分，还会作更深刻的分析）。


七. 类加载双亲委派示例


以上已经简要介绍了虚拟机默认使用的启动类加载器、标准扩展类加载器和系统类加载器，并以三者为例结合JDK代码对JVM默认使用的双亲委派类加载机制作了分析。下面咱们就来看一个综合的例子。首先在eclipse中创建一个简单的java应用工程，而后写一个简单的JavaBean以下：

 
  1. package classloader.test.bean;  
  2.    publicclass TestBean {  
  3.        public TestBean() {}  
  4. }  


在现有当前工程中另外创建一测试类（ClassLoaderTest.java）内容以下：

测试一：

 
  1. publicclass ClassLoaderTest {  
  2.    publicstaticvoid main(String[] args) {  
  3.        try {  
  4.            //查看当前系统类路径中包含的路径条目  
  5.             System.out.println(System.getProperty("java.class.path"));  
  6. //调用加载当前类的类加载器（这里即为系统类加载器）加载TestBean  
  7. Class typeLoaded = Class.forName("classloader.test.bean.TestBean");  
  8. //查看被加载的TestBean类型是被那个类加载器加载的  
  9.             System.out.println(typeLoaded.getClassLoader());  
  10.         }catch (Exception e) {  
  11.             e.printStackTrace();  
  12.         }  
  13.     }  
  14. }  


对应的输出以下：

 
  1. D:"DEMO"dev"Study"ClassLoaderTest"bin  
  2. sun.misc.Launcher$AppClassLoader@197d257  


（说明：当前类路径默认的含有的一个条目就是工程的输出目录）


测试二：

将当前工程输出目录下的…/classloader/test/bean/TestBean.class打包进test.jar剪贴到< Java_Runtime_Home >/lib/ext目录下（如今工程输出目录下和JRE扩展目录下都有待加载类型的class文件）。再运行测试一测试代码，结果以下：

 
  1. D:"DEMO"dev"Study"ClassLoaderTest"bin  
  2. sun.misc.Launcher$ExtClassLoader@7259da  


对比测试一和测试二，咱们明显能够验证前面说的双亲委派机制，系统类加载器在接到加载classloader.test.bean.TestBean类型的请求时，首先将请求委派给父类加载器（标准扩展类加载器），标准扩展类加载器抢先完成了加载请求。


测试三：

将test.jar拷贝一份到< Java_Runtime_Home >/lib下，运行测试代码，输出以下：

 
  1. D:"DEMO"dev"Study"ClassLoaderTest"bin  
  2. sun.misc.Launcher$ExtClassLoader@7259da  


  测试三和测试二输出结果一致。那就是说，放置到< Java_Runtime_Home >/lib目录下的TestBean对应的class字节码并无被加载，这其实和前面讲的双亲委派机制并不矛盾。虚拟机出于安全等因素考虑，不会加载< Java_Runtime_Home >/lib存在的陌生类，开发者经过将要加载的非JDK自身的类放置到此目录下期待启动类加载器加载是不可能的。作个进一步验证，删除< Java_Runtime_Home >/lib/ext目录下和工程输出目录下的TestBean对应的class文件，而后再运行测试代码，则将会有ClassNotFoundException异常抛出。有关这个问题，你们能够在java.lang.ClassLoader中的loadClass(String name, boolean resolve)方法中设置相应断点运行测试三进行调试，会发现findBootstrapClass0()会抛出异常，而后在下面的findClass方法中被加载，当前运行的类加载器正是扩展类加载器（sun.misc.Launcher$ExtClassLoader），这一点能够经过JDT中变量视图查看验证。


八. 程序动态扩展方式


Java的链接模型容许用户运行时扩展引用程序，既能够经过当前虚拟机中预约义的加载器加载编译时已知的类或者接口，又容许用户自行定义类装载器，在运行时动态扩展用户的程序。经过用户自定义的类装载器，你的程序能够装载在编译时并不知道或者还没有存在的类或者接口，并动态链接它们并进行有选择的解析。

       

运行时动态扩展java应用程序有以下两个途径：


8.1.调用java.lang.Class.forName(…)


这个方法其实在前面已经讨论过，在后面的问题2解答中说明了该方法调用会触发那个类加载器开始加载任务。这里须要说明的是多参数版本的forName(…)方法：

 
  1. public static Class<?> forName(String name, boolean initialize, ClassLoader loader) throws ClassNotFoundException  


这里的initialize参数是很重要的,能够以为被加载同时是否完成初始化的工做(说明: 单参数版本的forName方法默认是不完成初始化的).有些场景下,须要将initialize设置为true来强制加载同时完成初始化,例如典型的就是利用DriverManager进行JDBC驱动程序类注册的问题,由于每个JDBC驱动程序类的静态初始化方法都用DriverManager注册驱动程序,这样才能被应用程序使用,这就要求驱动程序类必须被初始化,而不仅仅被加载.


8.2.用户自定义类加载器


经过前面的分析，咱们能够看出，除了和本地实现密切相关的启动类加载器以外，包括标准扩展类加载器和系统类加载器在内的全部其余类加载器咱们均可以当作自定义类加载器来对待，惟一区别是是否被虚拟机默认使用。前面的内容中已经对java.lang.ClassLoader抽象类中的几个重要的方法作了介绍，这里就简要叙述一下通常用户自定义类加载器的工做流程吧（能够结合后面问题解答一块儿看）：


一、首先检查请求的类型是否已经被这个类装载器装载到命名空间中了，若是已经装载，直接返回；不然转入步骤2


二、委派类加载请求给父类加载器（更准确的说应该是双亲类加载器，真个虚拟机中各类类加载器最终会呈现树状结构），若是父类加载器可以完成，则返回父类加载器加载的Class实例；不然转入步骤3


三、调用本类加载器的findClass（…）方法，试图获取对应的字节码，若是获取的到，则调用defineClass（…）导入类型到方法区；若是获取不到对应的字节码或者其余缘由失败，返回异常给loadClass（…）， loadClass（…）转抛异常，终止加载过程（注意：这里的异常种类不止一种）。

       （说明：这里说的自定义类加载器是指JDK 1.2之后版本的写法，即不覆写改变java.lang.loadClass(…)已有委派逻辑状况下）


九. 常见问题分析


9.1.由不一样的类加载器加载的指定类型仍是相同的类型吗？


在Java中，一个类用其彻底匹配类名(fully qualified class name)做为标识，这里指的彻底匹配类名包括包名和类名。但在JVM中一个类用其全名和一个加载类ClassLoader的实例做为惟一标识，不一样类加载器加载的类将被置于不一样的命名空间.咱们能够用两个自定义类加载器去加载某自定义类型（注意，不要将自定义类型的字节码放置到系统路径或者扩展路径中，不然会被系统类加载器或扩展类加载器抢先加载），而后用获取到的两个Class实例进行java.lang.Object.equals（…）判断，将会获得不相等的结果。这个你们能够写两个自定义的类加载器去加载相同的自定义类型，而后作个判断；同时，能够测试加载java.*类型，而后再对比测试一下测试结果。


9.2.在代码中直接调用Class.forName（String name）方法，到底会触发那个类加载器进行类加载行为？


Class.forName(String name)默认会使用调用类的类加载器来进行类加载。咱们直接来分析一下对应的jdk的代码：

 
  1. //java.lang.Class.java  
  2.        publicstatic Class<?>forName(String className)throws ClassNotFoundException {  
  3. return forName0(className,true, ClassLoader.getCallerClassLoader());  
  4. }  
  5. //java.lang.ClassLoader.java  
  6. // Returns the invoker's class loader, or null if none.  
  7. static ClassLoader getCallerClassLoader() {  
  8.               // 获取调用类（caller）的类型  
  9.         Class caller = Reflection.getCallerClass(3);  
  10.               // This can be null if the VM is requesting it  
  11.        if (caller ==null) {  
  12.            returnnull;  
  13.         }  
  14.        //调用java.lang.Class中本地方法获取加载该调用类（caller）的ClassLoader  
  15.        return caller.getClassLoader0();  
  16. }  
  17. //java.lang.Class.java  
  18. //虚拟机本地实现，获取当前类的类加载器，前面介绍的Class的getClassLoader()也使用此方法  
  19. native ClassLoader getClassLoader0();  


9.3.在编写自定义类加载器时，若是没有设定父加载器，那么父加载器是？


前面讲过，在不指定父类加载器的状况下，默认采用系统类加载器。可能有人以为不明白，如今咱们来看一下JDK对应的代码实现。众所周知，咱们编写自定义的类加载器直接或者间接继承自java.lang.ClassLoader抽象类，对应的无参默认构造函数实现以下：

 
  1. //摘自java.lang.ClassLoader.java  
  2. protected ClassLoader() {  
  3.            SecurityManager security = System.getSecurityManager();  
  4.           if (security !=null) {  
  5.                security.checkCreateClassLoader();  
  6.            }  
  7.           this.parent = getSystemClassLoader();  
  8.            initialized =true;  
  9. }  


咱们再来看一下对应的getSystemClassLoader()方法的实现:

 
  1. privatestaticsynchronizedvoid initSystemClassLoader() {  
  2.            //...  
  3.            sun.misc.Launcher l = sun.misc.Launcher.getLauncher();  
  4.            scl = l.getClassLoader();  
  5.            //...  
  6. }  


咱们能够写简单的测试代码来测试一下：

 
  1. System.out.println(sun.misc.Launcher.getLauncher().getClassLoader());  


本机对应输出以下:

 
  1. sun.misc.Launcher$AppClassLoader@197d257  


因此，咱们如今能够相信当自定义类加载器没有指定父类加载器的状况下，默认的父类加载器即为系统类加载器。同时，咱们能够得出以下结论：

即时用户自定义类加载器不指定父类加载器，那么，一样能够加载以下三个地方的类：

1.   <Java_Runtime_Home>/lib下的类

2.   < Java_Runtime_Home >/lib/ext下或者由系统变量java.ext.dir指定位置中的类

3.   当前工程类路径下或者由系统变量java.class.path指定位置中的类


9.4.在编写自定义类加载器时，若是将父类加载器强制设置为null，那么会有什么影响？若是自定义的类加载器不能加载指定类，就确定会加载失败吗？


JVM规范中规定若是用户自定义的类加载器将父类加载器强制设置为null，那么会自动将启动类加载器设置为当前用户自定义类加载器的父类加载器(这个问题前面已经分析过了)。同时，咱们能够得出以下结论：

即时用户自定义类加载器不指定父类加载器，那么，一样能够加载到<Java_Runtime_Home>/lib下的类，但此时就不可以加载<Java_Runtime_Home>/lib/ext目录下的类了。

   说明：问题3和问题4的推断结论是基于用户自定义的类加载器自己延续了java.lang.ClassLoader.loadClass（…）默认委派逻辑，若是用户对这一默认委派逻辑进行了改变，以上推断结论就不必定成立了，详见问题5。


9.5.编写自定义类加载器时，通常有哪些注意点？


9.5.1.通常尽可能不要覆写已有的loadClass（…）方法中的委派逻辑


通常在JDK 1.2以前的版本才这样作，并且事实证实，这样作极有可能引发系统默认的类加载器不能正常工做。在JVM规范和JDK文档中（1.2或者之后版本中），都没有建议用户覆写loadClass(…)方法，相比而言，明确提示开发者在开发自定义的类加载器时覆写findClass(…)逻辑。举一个例子来验证该问题：

 
  1. //用户自定义类加载器WrongClassLoader.Java（覆写loadClass逻辑）  
  2. publicclassWrongClassLoaderextends ClassLoader {  
  3.        public Class<?> loadClass(String name)throws ClassNotFoundException {  
  4.            returnthis.findClass(name);  
  5.         }  
  6.        protected Class<?> findClass(String name)throws ClassNotFoundException {  
  7.            //假设此处只是到工程之外的特定目录Ｄ：/library下去加载类  
  8.            具体实现代码省略  
  9.         }  
  10. }  


   经过前面的分析咱们已经知道，用户自定义类加载器（WrongClassLoader）的默

       认的类加载器是系统类加载器，可是如今问题4种的结论就不成立了。你们能够简

       单测试一下，如今<Java_Runtime_Home>/lib、< Java_Runtime_Home >/lib/ext和工

       程类路径上的类都加载不上了。

       

[
  1. //问题5测试代码一  
  2. publicclass WrongClassLoaderTest {  
  3.        publicstaticvoid main(String[] args) {  
  4.           try {  
  5.                WrongClassLoader loader =new WrongClassLoader();  
  6.                Class classLoaded = loader.loadClass("beans.Account");  
  7.                System.out.println(classLoaded.getName());  
  8.                System.out.println(classLoaded.getClassLoader());  
  9.            }catch (Exception e) {  
  10.                e.printStackTrace();  
  11.            }  
  12.         }  
  13. }  

（说明：D:"classes"beans"Account.class物理存在的）

输出结果：

 
  1. java.io.FileNotFoundException: D:"classes"java"lang"Object.class (系统找不到指定的路径。)  
  2.     at java.io.FileInputStream.open(Native Method)  
  3.     at java.io.FileInputStream.<init>(FileInputStream.java:106)  
  4.     at WrongClassLoader.findClass(WrongClassLoader.java:40)  
  5.     at WrongClassLoader.loadClass(WrongClassLoader.java:29)  
  6.     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)  
  7.     at java.lang.ClassLoader.defineClass1(Native Method)  
  8.     at java.lang.ClassLoader.defineClass(ClassLoader.java:620)  
  9.     at java.lang.ClassLoader.defineClass(ClassLoader.java:400)  
  10.     at WrongClassLoader.findClass(WrongClassLoader.java:43)  
  11.     at WrongClassLoader.loadClass(WrongClassLoader.java:29)  
  12.     at WrongClassLoaderTest.main(WrongClassLoaderTest.java:27)  
  13. Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/Object  
  14.     at java.lang.ClassLoader.defineClass1(Native Method)  
  15.     at java.lang.ClassLoader.defineClass(ClassLoader.java:620)  
  16.     at java.lang.ClassLoader.defineClass(ClassLoader.java:400)  
  17.     at WrongClassLoader.findClass(WrongClassLoader.java:43)  
  18.     at WrongClassLoader.loadClass(WrongClassLoader.java:29)  
  19.     at WrongClassLoaderTest.main(WrongClassLoaderTest.java:27)  


这说明，连要加载的类型的超类型java.lang.Object都加载不到了。这里列举的因为覆写loadClass（…）引发的逻辑错误明显是比较简单的，实际引发的逻辑错误可能复杂的多。

 
  1. //问题5测试二  
  2. //用户自定义类加载器WrongClassLoader.Java(不覆写loadClass逻辑)  
  3. publicclassWrongClassLoaderextends ClassLoader {  
  4.        protected Class<?> findClass(String name)throws ClassNotFoundException {  
  5.            //假设此处只是到工程之外的特定目录Ｄ：/library下去加载类  
  6.            具体实现代码省略  
  7.         }  
  8. }  


将自定义类加载器代码WrongClassLoader.Java作以上修改后，再运行测试代码，输出结果以下：

 
  1. beans.Account  
  2. WrongClassLoader@1c78e57  


这说明，beans.Account加载成功，且是由自定义类加载器WrongClassLoader加载。

这其中的缘由分析，我想这里就没必要解释了，你们应该能够分析的出来了。


9.5.2.正确设置父类加载器


经过上面问题4和问题5的分析咱们应该已经理解，我的以为这是自定义用户类加载器时最重要的一点，但经常被忽略或者轻易带过。有了前面JDK代码的分析做为基础，我想如今你们均可以随便举出例子了。


9.5.3.保证findClass（String）方法的逻辑正确性


事先尽可能准确理解待定义的类加载器要完成的加载任务，确保最大程度上可以获取到对应的字节码内容。


9.6.如何在运行时判断系统类加载器能加载哪些路径下的类？


一是能够直接调用ClassLoader.getSystemClassLoader()或者其余方式获取到系统类加载器（系统类加载器和扩展类加载器自己都派生自URLClassLoader），调用URLClassLoader中的getURLs()方法能够获取到；


二是能够直接经过获取系统属性java.class.path 来查看当前类路径上的条目信息 ， System.getProperty("java.class.path")


9.7.如何在运行时判断标准扩展类加载器能加载哪些路径下的类？


方法之一：

 
  1. try {  
  2.                URL[] extURLs = ((URLClassLoader)ClassLoader.getSystemClassLoader().getParent()).getURLs();  
  3.               for (int i = 0; i < extURLs.length; i++) {  
  4.                      System.out.println(extURLs[i]);  
  5.               }  
  6.        } catch (Exception e) {//…}  


       本机对应输出以下：

 
  1. file:/D:/DEMO/jdk1.5.0_09/jre/lib/ext/dnsns.jar  
  2. file:/D:/DEMO/jdk1.5.0_09/jre/lib/ext/localedata.jar  
  3. file:/D:/DEMO/jdk1.5.0_09/jre/lib/ext/sunjce_provider.jar  
  4. file:/D:/DEMO/jdk1.5.0_09/jre/lib/ext/sunpkcs11.jar  


10、再分析类加载


10.1.类加载器的特性


1， 每一个ClassLoader都维护了一份本身的名称空间， 同一个名称空间里不能出现两个同名的类。
2， 为了实现java安全沙箱模型顶层的类加载器安全机制, java默认采用了 ” 双亲委派的加载链 ” 结构.


以下图:


Class Diagram：



类图中， BootstrapClassLoader是一个单独的java类， 其实在这里， 不该该叫他是一个java类。
由于， 它已经彻底不用java实现了。

 

它是在jvm启动时， 就被构造起来的， 负责java平台核心库。（具体上面已经有介绍）

启动类加载实现 (其实咱们不用关心这块， 可是有兴趣的， 能够研究一下 ):
bootstrap classLoader 类加载原理探索

 

10.2.自定义类加载器加载一个类的步骤

 

ClassLoader 类加载逻辑分析， 如下逻辑是除 BootstrapClassLoader 外的类加载器加载流程:

 

 
  1. // 检查类是否已被装载过    
  2.   Class c = findLoadedClass(name);    
  3.   if (c == null ) {    
  4.        // 指定类未被装载过    
  5.        try {    
  6.            if (parent != null ) {    
  7.                // 若是父类加载器不为空， 则委派给父类加载    
  8.                c = parent.loadClass(name, false );    
  9.            } else {    
  10.               // 若是父类加载器为空， 则委派给启动类加载加载    
  11.               c = findBootstrapClass0(name);    
  12.           }    
  13.       } catch (ClassNotFoundException e) {    
  14.           // 启动类加载器或父类加载器抛出异常后， 当前类加载器将其    
  15.           // 捕获， 并经过findClass方法， 由自身加载    
  16.           c = findClass(name);    
  17.       }    
  18.  }    


10.3.用Class.forName加载类


Class.forName使用的是被调用者的类加载器来加载类的.
这种特性, 证实了java类加载器中的名称空间是惟一的, 不会相互干扰.

即在通常状况下, 保证同一个类中所关联的其余类都是由当前类的类加载器所加载的.

 

 
  1. public static Class forName(String className)    
  2.         throws ClassNotFoundException {    
  3.         return forName0(className, true , ClassLoader.getCallerClassLoader());    
  4.    }    
  5.         
  6.    /** Called after security checks have been made. */    
  7.    private static native Class forName0(String name, boolean initialize,    
  8.    ClassLoader loader)    
  9.         throws ClassNotFoundException;    

 

上图中 ClassLoader.getCallerClassLoader 就是获得调用当前forName方法的类的类加载器

 

10.4.线程上下文类加载器


java默认的线程上下文类加载器是 系统类加载器(AppClassLoader).

 

 
  1. // Now create the class loader to use to launch the application    
  2.    try {    
  3.        loader = AppClassLoader.getAppClassLoader(extcl);    
  4.    } catch (IOException e) {    
  5.        throw new InternalError(    
  6.    "Could not create application class loader" );    
  7.    }    
  8.         
  9.    // Also set the context class loader for the primordial thread.    
  10.   Thread.currentThread().setContextClassLoader(loader);    

 

以上代码摘自sun.misc.Launch的无参构造函数Launch()。

使用线程上下文类加载器, 能够在执行线程中, 抛弃双亲委派加载链模式, 使用线程上下文里的类加载器加载类.


典型的例子有, 经过线程上下文来加载第三方库jndi实现, 而不依赖于双亲委派.

大部分java app服务器(jboss, tomcat..)也是采用contextClassLoader来处理web服务。


还有一些采用 hotswap 特性的框架, 也使用了线程上下文类加载器, 好比 seasar (full stack framework in japenese).

线程上下文从根本解决了通常应用不能违背双亲委派模式的问题.

使java类加载体系显得更灵活.

 

随着多核时代的来临, 相信多线程开发将会愈来愈多地进入程序员的实际编码过程当中. 所以,
在编写基础设施时， 经过使用线程上下文来加载类, 应该是一个很好的选择.

 

固然, 好东西都有利弊. 使用线程上下文加载类, 也要注意, 保证多根须要通讯的线程间的类加载器应该是同一个,
防止由于不一样的类加载器, 致使类型转换异常(ClassCastException).

 

10.5.自定义的类加载器实现


defineClass(String name, byte[] b, int off, int len,ProtectionDomain protectionDomain)
是java.lang.Classloader提供给开发人员, 用来自定义加载class的接口.

使用该接口, 能够动态的加载class文件.

 

例如,
在jdk中, URLClassLoader是配合findClass方法来使用defineClass, 能够从网络或硬盘上加载class.

而使用类加载接口, 并加上本身的实现逻辑, 还能够定制出更多的高级特性.

 

好比,

一个简单的hot swap 类加载器实现:

 

 
  1. import java.io.File;    
  2.    import java.io.FileInputStream;    
  3.    import java.lang.reflect.Method;    
  4.    import java.net.URL;    
  5.    import java.net.URLClassLoader;    
  6.         
  7.    /**  
  8.    * 能够从新载入同名类的类加载器实现  
  9.    *  
  10.      
  11.   * 放弃了双亲委派的加载链模式.  
  12.   * 须要外部维护重载后的类的成员变量状态.  
  13.   *  
  14.   * @author ken.wu  
  15.   * @mail ken.wug@gmail.com  
  16.   * 2007-9-28 下午01:37:43  
  17.   */    
  18.   public class HotSwapClassLoader extends URLClassLoader {    
  19.        
  20.       public HotSwapClassLoader(URL[] urls) {    
  21.           super (urls);    
  22.       }    
  23.        
  24.       public HotSwapClassLoader(URL[] urls, ClassLoader parent) {    
  25.           super (urls, parent);    
  26.       }    
  27.        
  28.       public Class load(String name)    
  29.             throws ClassNotFoundException {    
  30.           return load(name, false );    
  31.       }    
  32.        
  33.       public Class load(String name, boolean resolve)    
  34.             throws ClassNotFoundException {    
  35.           if ( null != super .findLoadedClass(name))    
  36.               return reload(name, resolve);    
  37.        
  38.           Class clazz = super .findClass(name);    
  39.        
  40.           if (resolve)    
  41.               super .resolveClass(clazz);    
  42.        
  43.           return clazz;    
  44.       }    
  45.        
  46.       public Class reload(String name, boolean resolve)    
  47.             throws ClassNotFoundException {    
  48.           return new HotSwapClassLoader( super .getURLs(), super .getParent()).load(    
  49.               name, resolve);    
  50.       }    
  51.   }    
  52.        
  53.   public class A {    
  54.       private B b;    
  55.        
  56.       public void setB(B b) {    
  57.            this .b = b;    
  58.       }    
  59.        
  60.       public B getB() {    
  61.            return b;    
  62.       }    
  63.   }    
  64.        
  65.   public class B {}    

 

这个类的做用是能够从新载入同名的类， 可是， 为了实现hotswap, 老的对象状态
须要经过其余方式拷贝到重载过的类生成的全新实例中来。(A类中的b实例)

而新实例所依赖的B类若是与老对象不是同一个类加载器加载的， 将会抛出类型转换异常(ClassCastException).

为了解决这种问题， HotSwapClassLoader自定义了load方法. 即当前类是由自身classLoader加载的， 而内部依赖的类

 

仍是老对象的classLoader加载的.

 

[java]   view plain  copy
  1. public class TestHotSwap {    
  2.    public static void main(String args[]) {    
  3.        A a = new A();    
  4.        B b = new B();    
  5.        a.setB(b);    
  6.         
  7.        System.out.printf("A classLoader is %s n" , a.getClass().getClassLoader());    
  8.        System.out.printf("B classLoader is %s n" , b.getClass().getClassLoader());    
  9.        System.out.printf("A.b classLoader is %s n" ,   a.getB().getClass().getClassLoader());    
  10.        
  11.       HotSwapClassLoader c1 = new HotSwapClassLoader( new URL[]{ new URL( "file:\e:\test\")} , a.getClass().getClassLoader());    
  12.       Class clazz = c1.load(" test.hotswap.A ");    
  13.       Object aInstance = clazz.newInstance();    
  14.        
  15.       Method method1 = clazz.getMethod(" setB ", B.class);    
  16.       method1.invoke(aInstance, b);    
  17.        
  18.       Method method2 = clazz.getMethod(" getB ", null);    
  19.       Object bInstance = method2.invoke(aInstance, null);    
  20.        
  21.       System.out.printf(" reloaded A.b classLoader is %s n", bInstance.getClass().getClassLoader());    
  22.   }    
  23.   }    

 

输出

 
  1. A classLoader is sun.misc.Launcher$AppClassLoader@19821f  
  2. B classLoader is sun.misc.Launcher$AppClassLoader@19821f  
  3. A.b classLoader is sun.misc.Launcher$AppClassLoader@19821f  
  4. reloaded A.b classLoader is sun.misc.Launcher$AppClassLoader@19821f
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程