精华内容
下载资源
问答
  • 深入理解Java类加载器(一):Java类加载原理解析

    万次阅读 多人点赞 2017-05-15 20:47:44
    每个开发人员对java.lang...本文简述了JVM三种预定义类加载器,即启动类加载器、扩展类加载器和系统类加载器,并介绍和分析它们之间的关系和加载所采用的双亲委派机制,给出并分析了与Java类加载原理相关的若干问题。

    摘要:

    每个开发人员对java.lang.ClassNotFoundExcetpion这个异常肯定都不陌生,这个异常背后涉及到的是Java技术体系中的类加载机制。本文简述了JVM三种预定义类加载器,即启动类加载器、扩展类加载器和系统类加载器,并介绍和分析它们之间的关系和类加载所采用的双亲委派机制,给出并分析了与Java类加载原理相关的若干问题。


    版权声明:

    本文作者:书呆子Rico
    作者博客地址:http://blog.csdn.net/justloveyou_/


    一、引子

    每个开发人员对java.lang.ClassNotFoundExcetpion这个异常肯定都不陌生,其实,这个异常背后涉及到的是Java技术体系中的类加载。Java类加载机制虽然和大部分开发人员直接打交道的机会不多,但是对其机理的理解有助于排查程序出现的类加载失败等技术问题,对理解Java虚拟机的连接模型和Java语言的动态性都有很大帮助。


    二. Java 虚拟机类加载器结构简述

    1、JVM三种预定义类型类加载器

    当JVM启动的时候,Java开始使用如下三种类型的类加载器:

    启动(Bootstrap)类加载器:启动类加载器是用本地代码实现的类加载器,它负责将JAVA_HOME/lib下面的核心类库或-Xbootclasspath选项指定的jar包等虚拟机识别的类库加载到内存中。由于启动类加载器涉及到虚拟机本地实现细节,开发者无法直接获取到启动类加载器的引用。具体可由启动类加载器加载到的路径可通过System.getProperty(“sun.boot.class.path”)查看。

    扩展(Extension)类加载器:扩展类加载器是由Sun的ExtClassLoader(sun.misc.Launcher$ExtClassLoader)实现的,它负责将JAVA_HOME /lib/ext或者由系统变量-Djava.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器,具体可由扩展类加载器加载到的路径可通过System.getProperty("java.ext.dirs")查看。

    系统(System)类加载器:系统类加载器是由 Sun 的 AppClassLoader(sun.misc.Launcher$AppClassLoader)实现的,它负责将用户类路径(java -classpath或-Djava.class.path变量所指的目录,即当前类所在路径及其引用的第三方类库的路径,如第四节中的问题6所述)下的类库加载到内存中。开发者可以直接使用系统类加载器,具体可由系统类加载器加载到的路径可通过System.getProperty("java.class.path")查看。

    Ps: 除了以上列举的三种类加载器,还有一种比较特殊的类型就是线程上下文类加载器,这个将在《深入理解Java类加载器(二):线程上下文类加载器》一文中进行单独介绍。


    2、类加载双亲委派机制介绍和分析

    JVM在加载类时默认采用的是双亲委派机制。通俗的讲,就是某个特定的类加载器在接到加载类的请求时,首先将加载任务委托给父类加载器,依次递归 (本质上就是loadClass函数的递归调用),因此所有的加载请求最终都应该传送到顶层的启动类加载器中。如果父类加载器可以完成这个类加载请求,就成功返回;只有当父类加载器无法完成此加载请求时,子加载器才会尝试自己去加载。事实上,大多数情况下,越基础的类由越上层的加载器进行加载,因为这些基础类之所以称为“基础”,是因为它们总是作为被用户代码调用的API(当然,也存在基础类回调用户用户代码的情形,即破坏双亲委派模型的情形)。 关于虚拟机默认的双亲委派机制,我们可以从系统类加载器和扩展类加载器为例作简单分析。
    标准扩展类加载器继承层次图-17.2kB
    系统类加载器继承层次图-16.4kB
      上面两张图分别是扩展类加载器继承层次图和系统类加载器继承层次图。通过这两张图我们可以看出,扩展类加载器和系统类加载器均是继承自 java.lang.ClassLoader抽象类。我们下面我们就看简要介绍一下抽象类 java.lang.ClassLoader 中几个最重要的方法:

    //加载指定名称(包括包名)的二进制类型,供用户调用的接口  
    public Class<?> loadClass(String name) throws ClassNotFoundException{}  
      
    //加载指定名称(包括包名)的二进制类型,同时指定是否解析(但是这里的resolve参数不一定真正能达到解析的效果),供继承用  
    protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{}  
      
    //findClass方法一般被loadClass方法调用去加载指定名称类,供继承用  
    protected Class<?> findClass(String name) throws ClassNotFoundException {}  
      
    //定义类型,一般在findClass方法中读取到对应字节码后调用,final的,不能被继承  
    //这也从侧面说明:JVM已经实现了对应的具体功能,解析对应的字节码,产生对应的内部数据结构放置到方法区,所以无需覆写,直接调用就可以了)  
    protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError{}  
    

    通过进一步分析标准扩展类加载器和系统类加载器的代码以及其公共父类(java.net.URLClassLoader和java.security.SecureClassLoader)的代码可以看出,都没有覆写java.lang.ClassLoader中默认的加载委派规则 — loadClass(…)方法。既然这样,我们就可以从java.lang.ClassLoader中的loadClass(String name)方法的代码中分析出虚拟机默认采用的双亲委派机制到底是什么模样:

    public Class<?> loadClass(String name) throws ClassNotFoundException {  
        return loadClass(name, false);  
    }  
      
    protected synchronized Class<?> loadClass(String name, boolean resolve)  
            throws ClassNotFoundException {  
      
        // 首先判断该类型是否已经被加载  
        Class c = findLoadedClass(name);  
        if (c == null) {  
            //如果没有被加载,就委托给父类加载或者委派给启动类加载器加载  
            try {  
                if (parent != null) {  
                    //如果存在父类加载器,就委派给父类加载器加载  
                    c = parent.loadClass(name, false);  
                } else {    // 递归终止条件
                    // 由于启动类加载器无法被Java程序直接引用,因此默认用 null 替代
                    // parent == null就意味着由启动类加载器尝试加载该类,  
                    // 即通过调用 native方法 findBootstrapClass0(String name)加载  
                    c = findBootstrapClass0(name);  
                }  
            } catch (ClassNotFoundException e) {  
                // 如果父类加载器不能完成加载请求时,再调用自身的findClass方法进行类加载,若加载成功,findClass方法返回的是defineClass方法的返回值
                // 注意,若自身也加载不了,会产生ClassNotFoundException异常并向上抛出
                c = findClass(name);  
            }  
        }  
        if (resolve) {  
            resolveClass(c);  
        }  
        return c;  
    }  
    

    通过上面的代码分析,我们可以对JVM采用的双亲委派类加载机制有了更直接的认识。下面我们就接着分析一下启动类加载器、标准扩展类加载器和系统类加载器三者之间的关系。可能大家已经从各种资料上面看到了如下类似的一幅图片:

    类加载器默认委派关系图-11.2kB

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

    public class LoaderTest {  
      
        public static void main(String[] args) {  
            try {  
                System.out.println(ClassLoader.getSystemClassLoader());  
                System.out.println(ClassLoader.getSystemClassLoader().getParent());  
                System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
        }  
    }/* Output: 
            sun.misc.Launcher$AppClassLoader@6d06d69c  
            sun.misc.Launcher$ExtClassLoader@70dea4e  
            null  
     *///:~
    

    通过以上的代码输出,我们知道:通过java.lang.ClassLoader.getSystemClassLoader()可以直接获取到系统类加载器 ,并且可以判定系统类加载器的父加载器是标准扩展类加载器,但是我们试图获取标准扩展类加载器的父类加载器时却得到了null。事实上,由于启动类加载器无法被Java程序直接引用,因此JVM默认直接使用 null 代表启动类加载器。我们还是借助于代码分析一下,首先看一下java.lang.ClassLoader抽象类中默认实现的两个构造函数:

    protected ClassLoader() {  
        SecurityManager security = System.getSecurityManager();  
        if (security != null) {  
            security.checkCreateClassLoader();  
        }  
        //默认将父类加载器设置为系统类加载器,getSystemClassLoader()获取系统类加载器  
        this.parent = getSystemClassLoader();  
        initialized = true;  
    }  
    
    protected ClassLoader(ClassLoader parent) {  
        SecurityManager security = System.getSecurityManager();  
        if (security != null) {  
            security.checkCreateClassLoader();  
        }  
        //强制设置父类加载器  
        this.parent = parent;  
        initialized = true;  
    }  
    

    紧接着,我们再看一下ClassLoader抽象类中parent成员的声明:

    // The parent class loader for delegation  
    private ClassLoader parent; 
    

    声明为私有变量的同时并没有对外提供可供派生类访问的public或者protected设置器接口(对应的setter方法),结合前面的测试代码的输出,我们可以推断出:

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

    2.扩展类加载器(ExtClassLoader)调用ClassLoader(ClassLoader parent)构造函数将父类加载器设置为null(null 本身就代表着引导类加载器)。(因为如果不强制设置,默认会通过调用getSystemClassLoader()方法获取并设置成系统类加载器,这显然和测试输出结果不符。)

    事实上,这就是启动类加载器、标准扩展类加载器和系统类加载器之间的委派关系。


    3、类加载双亲委派示例

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

    package classloader.test.bean;  
    
    public class TestBean {  
          
        public TestBean() { }  
    }  
    

    在现有当前工程中另外建立一个测试类(ClassLoaderTest.java)内容如下:

    package classloader.test.bean;  
      
    public class ClassLoaderTest {  
      
        public static void main(String[] args) {  
            try {  
                //查看当前系统类路径中包含的路径条目  
                System.out.println(System.getProperty("java.class.path"));  
                //调用加载当前类的类加载器(这里即为系统类加载器)加载TestBean  
                Class typeLoaded = Class.forName("classloader.test.bean.TestBean");  
                //查看被加载的TestBean类型是被那个类加载器加载的  
                System.out.println(typeLoaded.getClassLoader());  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
        }  
    }/* Output: 
            I:\AlgorithmPractice\TestClassLoader\bin
            sun.misc.Launcher$AppClassLoader@6150818a
     *///:~  
    

    将当前工程输出目录下的TestBean.class打包进test.jar剪贴到<Java_Runtime_Home>/lib/ext目录下(现在工程输出目录下和JRE扩展目录下都有待加载类型的class文件)。再运行测试一测试代码,结果如下:

        I:\AlgorithmPractice\TestClassLoader\bin
        sun.misc.Launcher$ExtClassLoader@15db9742
    

    对比上面的两个结果,我们明显可以验证前面说的双亲委派机制:系统类加载器在接到加载classloader.test.bean.TestBean类型的请求时,首先将请求委派给父类加载器(标准扩展类加载器),标准扩展类加载器抢先完成了加载请求。

    最后,将test.jar拷贝一份到<Java_Runtime_Home>/lib下,运行测试代码,输出如下:

        I:\AlgorithmPractice\TestClassLoader\bin
        sun.misc.Launcher$ExtClassLoader@15db9742
    

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


    三. Java 程序动态扩展方式

    Java的连接模型允许用户运行时扩展引用程序,既可以通过当前虚拟机中预定义的加载器加载编译时已知的类或者接口,又允许用户自行定义类装载器,在运行时动态扩展用户的程序。通过用户自定义的类装载器,你的程序可以加载在编译时并不知道或者尚未存在的类或者接口,并动态连接它们并进行有选择的解析。运行时动态扩展java应用程序有如下两个途径:


    1、反射 (调用java.lang.Class.forName(…)加载类)

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

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

    这里的initialize参数是很重要的,它表示在加载同时是否完成初始化的工作(说明:单参数版本的forName方法默认是完成初始化的)。有些场景下需要将initialize设置为true来强制加载同时完成初始化,例如典型的就是加载数据库驱动问题。因为JDBC驱动程序只有被注册后才能被应用程序使用,这就要求驱动程序类必须被初始化,而不单单被加载。

    // 加载并实例化JDBC驱动类
    Class.forName(driver);
     
     // JDBC驱动类的实现
    public class Driver extends NonRegisteringDriver implements java.sql.Driver {
        public Driver() throws SQLException {
        }
    	// 将initialize设置为true来强制加载同时完成初始化,实现驱动注册
        static {
            try {
                DriverManager.registerDriver(new Driver());
            } catch (SQLException var1) {
                throw new RuntimeException("Can\'t register driver!");
            }
        }
    }
    

    2、用户自定义类加载器
      
      通过前面的分析,我们可以看出,除了和本地实现密切相关的启动类加载器之外,包括标准扩展类加载器和系统类加载器在内的所有其他类加载器我们都可以当做自定义类加载器来对待,唯一区别是是否被虚拟机默认使用。前面的内容中已经对java.lang.ClassLoader抽象类中的几个重要的方法做了介绍,这里就简要叙述一下一般用户自定义类加载器的工作流程(可以结合后面问题解答一起看):

    1、首先检查请求的类型是否已经被这个类装载器装载到命名空间中了,如果已经装载,直接返回;否则转入步骤2;

    2、委派类加载请求给父类加载器(更准确的说应该是双亲类加载器,真实虚拟机中各种类加载器最终会呈现树状结构),如果父类加载器能够完成,则返回父类加载器加载的Class实例;否则转入步骤3;

    3、调用本类加载器的findClass(…)方法,试图获取对应的字节码。如果获取的到,则调用defineClass(…)导入类型到方法区;如果获取不到对应的字节码或者其他原因失败, 向上抛异常给loadClass(…), loadClass(…)转而调用findClass(…)方法处理异常,直至完成递归调用。

    必须指出的是,这里所说的自定义类加载器是指JDK1.2以后版本的写法,即不覆写改变java.lang.loadClass(…)已有委派逻辑情况下。整个加载类的过程如下图:

    自定义类加载器加载类的过程-54.2kB


    四. 常见问题分析

    1、由不同的类加载器加载的指定类还是相同的类型吗?

    在Java中,一个类用其完全匹配类名(fully qualified class name)作为标识,这里指的完全匹配类名包括包名和类名。但在JVM中,一个类用其全名 和 一个ClassLoader的实例作为唯一标识,不同类加载器加载的类将被置于不同的命名空间。我们可以用两个自定义类加载器去加载某自定义类型(注意不要将自定义类型的字节码放置到系统路径或者扩展路径中,否则会被系统类加载器或扩展类加载器抢先加载),然后用获取到的两个Class实例进行java.lang.Object.equals(…)判断,将会得到不相等的结果,如下所示:

    public class TestBean {
    
    	public static void main(String[] args) throws Exception {
    	    // 一个简单的类加载器,逆向双亲委派机制
    	    // 可以加载与自己在同一路径下的Class文件
    		ClassLoader myClassLoader = new ClassLoader() {
    			@Override
    			public Class<?> loadClass(String name)
    					throws ClassNotFoundException {
    				try {
    					String filename = name.substring(name.lastIndexOf(".") + 1)
    							+ ".class";
    					InputStream is = getClass().getResourceAsStream(filename);
    					if (is == null) {
    						return super.loadClass(name);   // 递归调用父类加载器
    					}
    					byte[] b = new byte[is.available()];
    					is.read(b);
    					return defineClass(name, b, 0, b.length);
    				} catch (Exception e) {
    					throw new ClassNotFoundException(name);
    				}
    			}
    		};
    
    		Object obj = myClassLoader.loadClass("classloader.test.bean.TestBean")
    				.newInstance();
    		System.out.println(obj.getClass());
    		System.out.println(obj instanceof classloader.test.bean.TestBean);
    	}
    }/* Output: 
            class classloader.test.bean.TestBean
            false  
     *///:~    
    

    我们发现,obj 确实是类classloader.test.bean.TestBean实例化出来的对象,但当这个对象与类classloader.test.bean.TestBean做所属类型检查时却返回了false。这是因为虚拟机中存在了两个TestBean类,一个是由系统类加载器加载的,另一个则是由我们自定义的类加载器加载的,虽然它们来自同一个Class文件,但依然是两个独立的类,因此做所属类型检查时返回false。


    2、在代码中直接调用Class.forName(String name)方法,到底会触发那个类加载器进行类加载行为?

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

    //java.lang.Class.java  
    publicstatic Class<?> forName(String className) throws ClassNotFoundException {  
        return forName0(className, true, ClassLoader.getCallerClassLoader());  
    }  
      
    //java.lang.ClassLoader.java  
    // Returns the invoker's class loader, or null if none.  
    static ClassLoader getCallerClassLoader() {  
        // 获取调用类(caller)的类型  
        Class caller = Reflection.getCallerClass(3);  
        // This can be null if the VM is requesting it  
        if (caller == null) {  
            return null;  
        }  
        // 调用java.lang.Class中本地方法获取加载该调用类(caller)的ClassLoader  
        return caller.getClassLoader0();  
    }  
      
    //java.lang.Class.java  
    //虚拟机本地实现,获取当前类的类加载器,前面介绍的Class的getClassLoader()也使用此方法  
    native ClassLoader getClassLoader0(); 
    

    3、在编写自定义类加载器时,如果没有设定父加载器,那么父加载器是谁?
      前面讲过,在不指定父类加载器的情况下,默认采用系统类加载器。可能有人觉得不明白,现在我们来看一下JDK对应的代码实现。众所周知,我们编写自定义的类加载器直接或者间接继承自java.lang.ClassLoader抽象类,对应的无参默认构造函数实现如下:

    //摘自java.lang.ClassLoader.java  
    protected ClassLoader() {  
        SecurityManager security = System.getSecurityManager();  
        if (security != null) {  
            security.checkCreateClassLoader();  
        }  
        this.parent = getSystemClassLoader();  
        initialized = true;  
    } 
    

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

    private static synchronized void initSystemClassLoader() {  
        //...  
        sun.misc.Launcher l = sun.misc.Launcher.getLauncher();  
        scl = l.getClassLoader();  
        //...  
    }  
    

    我们可以写简单的测试代码来测试一下:

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

    本机对应输出如下:

    sun.misc.Launcher$AppClassLoader@73d16e93 
    

    所以,我们现在可以相信当自定义类加载器没有指定父类加载器的情况下,默认的父类加载器即为系统类加载器。同时,我们可以得出如下结论:即使用户自定义类加载器不指定父类加载器,那么,同样可以加载如下三个地方的类:

    • <Java_Runtime_Home>/lib下的类;
    • <Java_Runtime_Home>/lib/ext下或者由系统变量java.ext.dir指定位置中的类;
    • 当前工程类路径下或者由系统变量java.class.path指定位置中的类。

    4、在编写自定义类加载器时,如果将父类加载器强制设置为null,那么会有什么影响?如果自定义的类加载器不能加载指定类,就肯定会加载失败吗?

    JVM规范中规定如果用户自定义的类加载器将父类加载器强制设置为null,那么会自动将启动类加载器设置为当前用户自定义类加载器的父类加载器(这个问题前面已经分析过了)。同时,我们可以得出如下结论:即使用户自定义类加载器不指定父类加载器,那么,同样可以加载到<JAVA_HOME>/lib下的类,但此时就不能够加载<JAVA_HOME>/lib/ext目录下的类了。

    Ps:问题3和问题4的推断结论是基于用户自定义的类加载器本身延续了java.lang.ClassLoader.loadClass(…)默认委派逻辑,如果用户对这一默认委派逻辑进行了改变,以上推断结论就不一定成立了,详见问题 5。


    5、编写自定义类加载器时,一般有哪些注意点?

    1)、一般尽量不要覆写已有的loadClass(…)方法中的委派逻辑(Old Generation)

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

    //用户自定义类加载器WrongClassLoader.Java(覆写loadClass逻辑)  
    public class WrongClassLoader extends ClassLoader {  
      
        public Class<?> loadClass(String name) throws ClassNotFoundException {  
            return this.findClass(name);  
        }  
      
        protected Class<?> findClass(String name) throws ClassNotFoundException {  
            // 假设此处只是到工程以外的特定目录D:\library下去加载类  
            // 具体实现代码省略  
        }  
    }  
    

    通过前面的分析我们已经知道,这个自定义类加载器WrongClassLoader的默认类加载器是系统类加载器,但是现在问题4中的结论就不成立了。大家可以简单测试一下,现在<JAVA_HOME>/lib、<JAVA_HOME>/lib/ext 和 工程类路径上的类都加载不上了。

    //问题5测试代码一  
    public class WrongClassLoaderTest {  
        publicstaticvoid main(String[] args) {  
            try {  
                WrongClassLoader loader = new WrongClassLoader();  
                Class classLoaded = loader.loadClass("beans.Account");  
                System.out.println(classLoaded.getName());  
                System.out.println(classLoaded.getClassLoader());  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
        }  
    }/* Output: 
            java.io.FileNotFoundException: D:"classes"java"lang"Object.class (系统找不到指定的路径。)  
            at java.io.FileInputStream.open(Native Method)  
            at java.io.FileInputStream.<init>(FileInputStream.java:106)  
            at WrongClassLoader.findClass(WrongClassLoader.java:40)  
            at WrongClassLoader.loadClass(WrongClassLoader.java:29)  
            at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)  
            at java.lang.ClassLoader.defineClass1(Native Method)  
            at java.lang.ClassLoader.defineClass(ClassLoader.java:620)  
            at java.lang.ClassLoader.defineClass(ClassLoader.java:400)  
            at WrongClassLoader.findClass(WrongClassLoader.java:43)  
            at WrongClassLoader.loadClass(WrongClassLoader.java:29)  
            at WrongClassLoaderTest.main(WrongClassLoaderTest.java:27)  
    Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/Object  
            at java.lang.ClassLoader.defineClass1(Native Method)  
            at java.lang.ClassLoader.defineClass(ClassLoader.java:620)  
            at java.lang.ClassLoader.defineClass(ClassLoader.java:400)  
            at WrongClassLoader.findClass(WrongClassLoader.java:43)  
            at WrongClassLoader.loadClass(WrongClassLoader.java:29)  
            at WrongClassLoaderTest.main(WrongClassLoaderTest.java:27)  
     *///:~    
    

    注意,这里D:"classes"beans"Account.class是物理存在的。这说明,连要加载的类型的超类型java.lang.Object都加载不到了。这里列举的由于覆写loadClass()引起的逻辑错误明显是比较简单的,实际引起的逻辑错误可能复杂的多。

    //问题5测试二  
    //用户自定义类加载器WrongClassLoader.Java(不覆写loadClass逻辑)  
    public class WrongClassLoader extends ClassLoader {  
        protected Class<?> findClass(String name) throws ClassNotFoundException {  
            //假设此处只是到工程以外的特定目录D:\library下去加载类  
            //具体实现代码省略  
        }  
    }/* Output: 
            beans.Account  
            WrongClassLoader@1c78e57  
     *///:~  
    

    将自定义类加载器代码WrongClassLoader.Java做以上修改后,再运行测试代码,输出正确。


    2). 正确设置父类加载器

    通过上面问题4和问题5的分析我们应该已经理解,个人觉得这是自定义用户类加载器时最重要的一点,但常常被忽略或者轻易带过。有了前面JDK代码的分析作为基础,我想现在大家都可以随便举出例子了。


    3). 保证findClass(String name)方法的逻辑正确性

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


    6、如何在运行时判断系统类加载器能加载哪些路径下的类?

    一是可以直接调用ClassLoader.getSystemClassLoader()或者其他方式获取到系统类加载器(系统类加载器和扩展类加载器本身都派生自URLClassLoader),调用URLClassLoader中的getURLs()方法可以获取到。二是可以直接通过获取系统属性java.class.path来查看当前类路径上的条目信息 :System.getProperty(“java.class.path”)。如下所示,

    public class Test {
    	public static void main(String[] args) {
    		System.out.println("Rico");
    		Gson gson = new Gson();
    		System.out.println(gson.getClass().getClassLoader());
    		System.out.println(System.getProperty("java.class.path"));
    	}
    }/* Output: 
            Rico
    		sun.misc.Launcher$AppClassLoader@6c68bcef
    		I:\AlgorithmPractice\TestClassLoader\bin;I:\Java\jars\Gson\gson-2.3.1.jar
     *///:~ 
    

    如上述程序所示,Test类和Gson类由系统类加载器加载,并且其加载路径就是用户类路径,包括当前类路径和引用的第三方类库的路径。


    7、如何在运行时判断标准扩展类加载器能加载哪些路径下的类?

    利用如下方式即可判断:

    import java.net.URL;
    import java.net.URLClassLoader;  
    
    public class ClassLoaderTest {  
      
        /** 
         * @param args the command line arguments 
         */  
        public static void main(String[] args) {  
            try {  
                URL[] extURLs = ((URLClassLoader) ClassLoader.getSystemClassLoader().getParent()).getURLs();  
                for (int i = 0; i < extURLs.length; i++) {  
                    System.out.println(extURLs[i]);  
                }  
            } catch (Exception e) {  
                //…  
            }  
        }  
    } /* Output: 
            file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/access-bridge-64.jar
            file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/dnsns.jar
            file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/jaccess.jar
            file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/localedata.jar
            file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/sunec.jar
            file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/sunjce_provider.jar
            file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/sunmscapi.jar
            file:/C:/Program%20Files/Java/jdk1.7.0_79/jre/lib/ext/zipfs.jar
     *///:~ 
    

    五. 开发自己的类加载器

    在前面介绍类加载器的代理委派模型的时候,提到过类加载器会首先代理给其它类加载器来尝试加载某个类,这就意味着真正完成类的加载工作的类加载器和启动这个加载过程的类加载器,有可能不是同一个。真正完成类的加载工作是通过调用defineClass来实现的;而启动类的加载过程是通过调用loadClass来实现的。前者称为一个类的定义加载器(defining loader),后者称为初始加载器(initiating loader)。在Java虚拟机判断两个类是否相同的时候,使用的是类的定义加载器。也就是说,哪个类加载器启动类的加载过程并不重要,重要的是最终定义这个类的加载器。两种类加载器的关联之处在于:一个类的定义加载器是它引用的其它类的初始加载器。如类 com.example.Outer引用了类 com.example.Inner,则由类 com.example.Outer的定义加载器负责启动类 com.example.Inner的加载过程。

    方法 loadClass()抛出的是 java.lang.ClassNotFoundException异常;方法 defineClass()抛出的是 java.lang.NoClassDefFoundError异常。

    类加载器在成功加载某个类之后,会把得到的 java.lang.Class类的实例缓存起来。下次再请求加载该类的时候,类加载器会直接使用缓存的类的实例,而不会尝试再次加载。也就是说,对于一个类加载器实例来说,相同全名的类只加载一次,即 loadClass方法不会被重复调用。

    在绝大多数情况下,系统默认提供的类加载器实现已经可以满足需求。但是在某些情况下,您还是需要为应用开发出自己的类加载器。比如您的应用通过网络来传输Java类的字节代码,为了保证安全性,这些字节代码经过了加密处理。这个时候您就需要自己的类加载器来从某个网络地址上读取加密后的字节代码,接着进行解密和验证,最后定义出要在Java虚拟机中运行的类来。下面将通过两个具体的实例来说明类加载器的开发。


    1、文件系统类加载器

    package classloader;  
      
    import java.io.ByteArrayOutputStream;  
    import java.io.File;  
    import java.io.FileInputStream;  
    import java.io.IOException;  
    import java.io.InputStream;  
      
    // 文件系统类加载器  
    public class FileSystemClassLoader extends ClassLoader {  
      
        private String rootDir;  
      
        public FileSystemClassLoader(String rootDir) {  
            this.rootDir = rootDir;  
        }  
      
        // 获取类的字节码  
        @Override  
        protected Class<?> findClass(String name) throws ClassNotFoundException {  
            byte[] classData = getClassData(name);  // 获取类的字节数组  
            if (classData == null) {  
                throw new ClassNotFoundException();  
            } else {  
                return defineClass(name, classData, 0, classData.length);  
            }  
        }  
      
        private byte[] getClassData(String className) {  
            // 读取类文件的字节  
            String path = classNameToPath(className);  
            try {  
                InputStream ins = new FileInputStream(path);  
                ByteArrayOutputStream baos = new ByteArrayOutputStream();  
                int bufferSize = 4096;  
                byte[] buffer = new byte[bufferSize];  
                int bytesNumRead = 0;  
                // 读取类文件的字节码  
                while ((bytesNumRead = ins.read(buffer)) != -1) {  
                    baos.write(buffer, 0, bytesNumRead);  
                }  
                return baos.toByteArray();  
            } catch (IOException e) {  
                e.printStackTrace();  
            }  
            return null;  
        }  
      
        private String classNameToPath(String className) {  
            // 得到类文件的完全路径  
            return rootDir + File.separatorChar  
                    + className.replace('.', File.separatorChar) + ".class";  
        }  
    }  
    

    如上所示,类 FileSystemClassLoader继承自类java.lang.ClassLoader。在java.lang.ClassLoader类的常用方法中,一般来说,自己开发的类加载器只需要覆写 findClass(String name)方法即可。java.lang.ClassLoader类的方法loadClass()封装了前面提到的代理模式的实现。该方法会首先调用findLoadedClass()方法来检查该类是否已经被加载过;如果没有加载过的话,会调用父类加载器的loadClass()方法来尝试加载该类;如果父类加载器无法加载该类的话,就调用findClass()方法来查找该类。因此,为了保证类加载器都正确实现代理模式,在开发自己的类加载器时,最好不要覆写 loadClass()方法,而是覆写 findClass()方法。

    类 FileSystemClassLoader的 findClass()方法首先根据类的全名在硬盘上查找类的字节代码文件(.class 文件),然后读取该文件内容,最后通过defineClass()方法来把这些字节代码转换成 java.lang.Class类的实例。加载本地文件系统上的类,示例如下:

    package com.example;  
      
    public class Sample {  
      
        private Sample instance;  
      
        public void setSample(Object instance) {  
            System.out.println(instance.toString());  
            this.instance = (Sample) instance;  
        }  
    }  
    
    package classloader;  
      
    import java.lang.reflect.Method;  
      
    public class ClassIdentity {  
      
        public static void main(String[] args) {  
            new ClassIdentity().testClassIdentity();  
        }  
      
        public void testClassIdentity() {  
            String classDataRootPath = "C:\\Users\\JackZhou\\Documents\\NetBeansProjects\\classloader\\build\\classes";  
            FileSystemClassLoader fscl1 = new FileSystemClassLoader(classDataRootPath);  
            FileSystemClassLoader fscl2 = new FileSystemClassLoader(classDataRootPath);  
            String className = "com.example.Sample";  
            try {  
                Class<?> class1 = fscl1.loadClass(className);  // 加载Sample类  
                Object obj1 = class1.newInstance();  // 创建对象  
                Class<?> class2 = fscl2.loadClass(className);  
                Object obj2 = class2.newInstance();  
                Method setSampleMethod = class1.getMethod("setSample", java.lang.Object.class);  
                setSampleMethod.invoke(obj1, obj2);  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
        }  
    }/* Output: 
            com.example.Sample@7852e922
     *///:~   
    

    2、网络类加载器

    下面将通过一个网络类加载器来说明如何通过类加载器来实现组件的动态更新。即基本的场景是:Java 字节代码(.class)文件存放在服务器上,客户端通过网络的方式获取字节代码并执行。当有版本更新的时候,只需要替换掉服务器上保存的文件即可。通过类加载器可以比较简单的实现这种需求。

    类 NetworkClassLoader负责通过网络下载Java类字节代码并定义出Java类。它的实现与FileSystemClassLoader类似。

    package classloader;  
      
    import java.io.ByteArrayOutputStream;  
    import java.io.InputStream;  
    import java.net.URL;  
      
    public class NetworkClassLoader extends ClassLoader {  
      
        private String rootUrl;  
      
        public NetworkClassLoader(String rootUrl) {  
            // 指定URL  
            this.rootUrl = rootUrl;  
        }  
      
        // 获取类的字节码  
        @Override  
        protected Class<?> findClass(String name) throws ClassNotFoundException {  
            byte[] classData = getClassData(name);  
            if (classData == null) {  
                throw new ClassNotFoundException();  
            } else {  
                return defineClass(name, classData, 0, classData.length);  
            }  
        }  
      
        private byte[] getClassData(String className) {  
            // 从网络上读取的类的字节  
            String path = classNameToPath(className);  
            try {  
                URL url = new URL(path);  
                InputStream ins = url.openStream();  
                ByteArrayOutputStream baos = new ByteArrayOutputStream();  
                int bufferSize = 4096;  
                byte[] buffer = new byte[bufferSize];  
                int bytesNumRead = 0;  
                // 读取类文件的字节  
                while ((bytesNumRead = ins.read(buffer)) != -1) {  
                    baos.write(buffer, 0, bytesNumRead);  
                }  
                return baos.toByteArray();  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
            return null;  
        }  
      
        private String classNameToPath(String className) {  
            // 得到类文件的URL  
            return rootUrl + "/"  
                    + className.replace('.', '/') + ".class";  
        }  
    }  
    

    在通过NetworkClassLoader加载了某个版本的类之后,一般有两种做法来使用它。第一种做法是使用Java反射API。另外一种做法是使用接口。需要注意的是,并不能直接在客户端代码中引用从服务器上下载的类,因为客户端代码的类加载器找不到这些类。使用Java反射API可以直接调用Java类的方法。而使用接口的做法则是把接口的类放在客户端中,从服务器上加载实现此接口的不同版本的类。在客户端通过相同的接口来使用这些实现类。我们使用接口的方式。示例如下:


    客户端接口:

    package classloader;  
      
    public interface Versioned {  
      
        String getVersion();  
    }   
    
    package classloader;  
      
    public interface ICalculator extends Versioned {  
      
        String calculate(String expression);  
    }  
    

    网络上的不同版本的类:

    package com.example;  
      
    import classloader.ICalculator;  
      
    public class CalculatorBasic implements ICalculator {  
      
        @Override  
        public String calculate(String expression) {  
            return expression;  
        }  
      
        @Override  
        public String getVersion() {  
            return "1.0";  
        }  
    } 
    
    package com.example;  
      
    import classloader.ICalculator;  
      
    public class CalculatorAdvanced implements ICalculator {  
      
        @Override  
        public String calculate(String expression) {  
            return "Result is " + expression;  
        }  
      
        @Override  
        public String getVersion() {  
            return "2.0";  
        }  
    }  
    

    在客户端加载网络上的类的过程:

    package classloader;  
      
    public class CalculatorTest {  
      
        public static void main(String[] args) {  
            String url = "http://localhost:8080/ClassloaderTest/classes";  
            NetworkClassLoader ncl = new NetworkClassLoader(url);  
            String basicClassName = "com.example.CalculatorBasic";  
            String advancedClassName = "com.example.CalculatorAdvanced";  
            try {  
                Class<?> clazz = ncl.loadClass(basicClassName);  // 加载一个版本的类  
                ICalculator calculator = (ICalculator) clazz.newInstance();  // 创建对象  
                System.out.println(calculator.getVersion());  
                clazz = ncl.loadClass(advancedClassName);  // 加载另一个版本的类  
                calculator = (ICalculator) clazz.newInstance();  
                System.out.println(calculator.getVersion());  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
        }  
    }
    

    六. 更多

    双亲委派模型是Java推荐的类加载模型,但违背该模型的案例有哪些?为什么会违背,又是怎么解决这种case的?这个将在《双亲委派模型与线程上下文类加载器》一文中进行介绍。


    ##引用:
    深入探讨 Java 类加载器
    深入理解Java类加载器(1):Java类加载原理解析

    展开全文
  • 深入理解Java类加载器(ClassLoader)

    万次阅读 多人点赞 2017-06-26 09:34:08
    【版权申明】未经博主同意,谢绝转载!(请尊重原创,博主保留追究权) ...深入理解Java类型信息(Class对象)与反射机制 深入理解Java枚举类型(enum) 深入理解Java注解类型(@Annotation) 深入理解

    【版权申明】未经博主同意,谢绝转载!(请尊重原创,博主保留追究权)
    http://blog.csdn.net/javazejian/article/details/73413292
    出自【zejian的博客】

    关联文章:

    深入理解Java类型信息(Class对象)与反射机制

    深入理解Java枚举类型(enum)

    深入理解Java注解类型(@Annotation)

    深入理解Java类加载器(ClassLoader)

    深入理解Java并发之synchronized实现原理

    Java并发编程-无锁CAS与Unsafe类及其并发包Atomic

    深入理解Java内存模型(JMM)及volatile关键字

    剖析基于并发AQS的重入锁(ReetrantLock)及其Condition实现原理

    剖析基于并发AQS的共享锁的实现(基于信号量Semaphore)

    并发之阻塞队列LinkedBlockingQueue与ArrayBlockingQueue

    本篇博文主要是探讨类加载器,同时在本篇中列举的源码都基于Java8版本,不同的版本可能有些许差异。主要内容如下

    文章目录


    # 类加载的机制的层次结构
    每个编写的".java"拓展名类文件都存储着需要执行的程序逻辑,这些".java"文件经过Java编译器编译成拓展名为".class"的文件,".class"文件中保存着Java代码经转换后的虚拟机指令,当需要使用某个类时,虚拟机将会加载它的".class"文件,并创建对应的class对象,将class文件加载到虚拟机的内存,这个过程称为类加载,这里我们需要了解一下类加载的过程,如下:

    • 加载:类加载过程的一个阶段:通过一个类的完全限定查找此类字节码文件,并利用字节码文件创建一个Class对象

    • 验证:目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,不会危害虚拟机自身安全。主要包括四种验证,文件格式验证,元数据验证,字节码验证,符号引用验证。

    • 准备:为类变量(即static修饰的字段变量)分配内存并且设置该类变量的初始值即0(如static int i=5;这里只将i初始化为0,至于5的值将在初始化时赋值),这里不包含用final修饰的static,因为final在编译的时候就会分配了,注意这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。

    • 解析:主要将常量池中的符号引用替换为直接引用的过程。符号引用就是一组符号来描述目标,可以是任何字面量,而直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。有类或接口的解析,字段解析,类方法解析,接口方法解析(这里涉及到字节码变量的引用,如需更详细了解,可参考《深入Java虚拟机》)。

    • 初始化:类加载最后阶段,若该类具有超类,则对其进行初始化,执行静态初始化器和静态初始化成员变量(如前面只初始化了默认值的static变量将会在这个阶段赋值,成员变量也将被初始化)。

    这便是类加载的5个过程,而类加载器的任务是根据一个类的全限定名来读取此类的二进制字节流到JVM中,然后转换为一个与目标类对应的java.lang.Class对象实例,在虚拟机提供了3种类加载器,引导(Bootstrap)类加载器、扩展(Extension)类加载器、系统(System)类加载器(也称应用类加载器),下面分别介绍
    ##启动(Bootstrap)类加载器
    启动类加载器主要加载的是JVM自身需要的类,这个类加载使用C++语言实现的,是虚拟机自身的一部分,它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中,注意必由于虚拟机是按照文件名识别加载jar包的,如rt.jar,如果文件名不被虚拟机识别,即使把jar包丢到lib目录下也是没有作用的(出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类)。

    ##扩展(Extension)类加载器
    扩展类加载器是指Sun公司(已被Oracle收购)实现的sun.misc.Launcher$ExtClassLoader类,由Java语言实现的,是Launcher的静态内部类,它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库,开发者可以直接使用标准扩展类加载器。

    //ExtClassLoader类中获取路径的代码
    private static File[] getExtDirs() {
         //加载<JAVA_HOME>/lib/ext目录中的类库
         String s = System.getProperty("java.ext.dirs");
         File[] dirs;
         if (s != null) {
             StringTokenizer st =
                 new StringTokenizer(s, File.pathSeparator);
             int count = st.countTokens();
             dirs = new File[count];
             for (int i = 0; i < count; i++) {
                 dirs[i] = new File(st.nextToken());
             }
         } else {
             dirs = new File[0];
         }
         return dirs;
     }
    
    

    ##系统(System)类加载器
    也称应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。它负责加载系统类路径java -classpath-D java.class.path 指定路径下的类库,也就是我们经常用到的classpath路径,开发者可以直接使用系统类加载器,一般情况下该类加载是程序中默认的类加载器,通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。
      在Java的日常应用程序开发中,类的加载几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,需要注意的是,Java虚拟机对class文件采用的是按需加载的方式,也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象,而且加载某个类的class文件时,Java虚拟机采用的是双亲委派模式即把请求交由父类处理,它一种任务委派模式,下面我们进一步了解它。
    #理解双亲委派模式

    ##双亲委派模式工作原理
    双亲委派模式要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器,请注意双亲委派模式中的父子关系并非通常所说的类继承关系,而是采用组合关系来复用父类加载器的相关代码,类加载器间的关系如下:

    双亲委派模式是在Java 1.2后引入的,其工作原理的是,如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行,如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器,如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式,即每个儿子都很懒,每次有活就丢给父亲去干,直到父亲说这件事我也干不了时,儿子自己想办法去完成,这不就是传说中的实力坑爹啊?那么采用这种模式有啥用呢?

    ##双亲委派模式优势
    采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系,通过这种层级关可以避免类的重复加载,当父亲已经加载了该类时,就没有必要子ClassLoader再加载一次。其次是考虑到安全因素,java核心api中定义类型不会被随意替换,假设通过网络传递一个名为java.lang.Integer的类,通过双亲委托模式传递到启动类加载器,而启动类加载器在核心Java API发现这个名字的类,发现该类已被加载,并不会重新加载网络传递的过来的java.lang.Integer,而直接返回已加载过的Integer.class,这样便可以防止核心API库被随意篡改。可能你会想,如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢?该类并不存在java.lang中,经过双亲委托模式,传递到启动类加载器中,由于父类加载器路径下并没有该类,所以不会加载,将反向委托给子类加载器加载,最终会通过系统类加载器加载该类。但是这样做是不允许,因为java.lang是核心API包,需要访问权限,强制加载将会报出如下异常

    java.lang.SecurityException: Prohibited package name: java.lang
    

    所以无论如何都无法加载成功的。下面我们从代码层面了解几个Java中定义的类加载器及其双亲委派模式的实现,它们类图关系如下

    从图可以看出顶层的类加载器是ClassLoader类,它是一个抽象类,其后所有的类加载器都继承自ClassLoader(不包括启动类加载器),这里我们主要介绍ClassLoader中几个比较重要的方法。

    • loadClass(String)

      该方法加载指定名称(包括包名)的二进制类型,该方法在JDK1.2之后不再建议用户重写但用户可以直接调用该方法,loadClass()方法是ClassLoader类自己实现的,该方法中的逻辑就是双亲委派模式的实现,其源码如下,loadClass(String name, boolean resolve)是一个重载方法,resolve参数代表是否生成class对象的同时进行解析相关操作。:

      protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
        {
            synchronized (getClassLoadingLock(name)) {
                // 先从缓存查找该class对象,找到就不用重新加载
                Class<?> c = findLoadedClass(name);
                if (c == null) {
                    long t0 = System.nanoTime();
                    try {
                        if (parent != null) {
                            //如果找不到,则委托给父类加载器去加载
                            c = parent.loadClass(name, false);
                        } else {
                        //如果没有父类,则委托给启动加载器去加载
                            c = findBootstrapClassOrNull(name);
                        }
                    } catch (ClassNotFoundException e) {
                        // ClassNotFoundException thrown if class not found
                        // from the non-null parent class loader
                    }
      
                    if (c == null) {
                        // If still not found, then invoke findClass in order
                        // 如果都没有找到,则通过自定义实现的findClass去查找并加载
                        c = findClass(name);
      
                        // this is the defining class loader; record the stats
                        sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                        sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                        sun.misc.PerfCounter.getFindClasses().increment();
                    }
                }
                if (resolve) {//是否需要在加载时进行解析
                    resolveClass(c);
                }
                return c;
            }
        }
      

      正如loadClass方法所展示的,当类加载请求到来时,先从缓存中查找该类对象,如果存在直接返回,如果不存在则交给该类加载去的父加载器去加载,倘若没有父加载则交给顶级启动类加载器去加载,最后倘若仍没有找到,则使用findClass()方法去加载(关于findClass()稍后会进一步介绍)。从loadClass实现也可以知道如果不想重新定义加载类的规则,也没有复杂的逻辑,只想在运行时加载自己指定的类,那么我们可以直接使用this.getClass().getClassLoder.loadClass("className"),这样就可以直接调用ClassLoader的loadClass方法获取到class对象。

    • findClass(String)
      在JDK1.2之前,在自定义类加载时,总会去继承ClassLoader类并重写loadClass方法,从而实现自定义的类加载类,但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法,而是建议把自定义的类加载逻辑写在findClass()方法中,从前面的分析可知,findClass()方法是在loadClass()方法中被调用的,当loadClass()方法中父加载器加载失败后,则会调用自己的findClass()方法来完成类加载,这样就可以保证自定义的类加载器也符合双亲委托模式。需要注意的是ClassLoader类中并没有实现findClass()方法的具体代码逻辑,取而代之的是抛出ClassNotFoundException异常,同时应该知道的是findClass方法通常是和defineClass方法一起使用的(稍后会分析),ClassLoader类中findClass()方法源码如下:

      //直接抛出异常
      protected Class<?> findClass(String name) throws ClassNotFoundException {
              throw new ClassNotFoundException(name);
      }
      
    • defineClass(byte[] b, int off, int len)
      defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象(ClassLoader中已实现该方法逻辑),通过这个方法不仅能够通过class文件实例化class对象,也可以通过其他方式实例化class对象,如通过网络接收一个类的字节码,然后转换为byte字节流创建对应的Class对象,defineClass()方法通常与findClass()方法一起使用,一般情况下,在自定义类加载器时,会直接覆盖ClassLoader的findClass()方法并编写加载规则,取得要加载类的字节码后转换成流,然后调用defineClass()方法生成类的Class对象,简单例子如下:

      protected Class<?> findClass(String name) throws ClassNotFoundException {
      	  // 获取类的字节数组
            byte[] classData = getClassData(name);  
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
      	      //使用defineClass生成class对象
                return defineClass(name, classData, 0, classData.length);
            }
        }
      

    需要注意的是,如果直接调用defineClass()方法生成类的Class对象,这个类的Class对象并没有解析(也可以理解为链接阶段,毕竟解析是链接的最后一步),其解析操作需要等待初始化阶段进行。

    • resolveClass(Class≺?≻ c)
      使用该方法可以使用类的Class对象创建完成也同时被解析。前面我们说链接阶段主要是对字节码进行验证,为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。

    上述4个方法是ClassLoader类中的比较重要的方法,也是我们可能会经常用到的方法。接看SercureClassLoader扩展了 ClassLoader,新增了几个与使用相关的代码源(对代码源的位置及其证书的验证)和权限定义类验证(主要指对class源码的访问权限)的方法,一般我们不会直接跟这个类打交道,更多是与它的子类URLClassLoader有所关联,前面说过,ClassLoader是一个抽象类,很多方法是空的没有实现,比如 findClass()、findResource()等。而URLClassLoader这个实现类为这些方法提供了具体的实现,并新增了URLClassPath类协助取得Class字节码流等功能,在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己去编写findClass()方法及其获取字节码流的方式,使自定义类加载器编写更加简洁,下面是URLClassLoader的类图(利用IDEA生成的类图)

    从类图结构看出URLClassLoader中存在一个URLClassPath类,通过这个类就可以找到要加载的字节码流,也就是说URLClassPath类负责找到要加载的字节码,再读取成字节流,最后通过defineClass()方法创建类的Class对象。从URLClassLoader类的结构图可以看出其构造方法都有一个必须传递的参数URL[],该参数的元素是代表字节码文件的路径,换句话说在创建URLClassLoader对象时必须要指定这个类加载器的到那个目录下找class文件。同时也应该注意URL[]也是URLClassPath类的必传参数,在创建URLClassPath对象时,会根据传递过来的URL数组中的路径判断是文件还是jar包,然后根据不同的路径创建FileLoader或者JarLoader或默认Loader类去加载相应路径下的class文件,而当JVM调用findClass()方法时,就由这3个加载器中的一个将class文件的字节码流加载到内存中,最后利用字节码流创建类的class对象。请记住,如果我们在定义类加载器时选择继承ClassLoader类而非URLClassLoader,必须手动编写findclass()方法的加载逻辑以及获取字节码流的逻辑。了解完URLClassLoader后接着看看剩余的两个类加载器,即拓展类加载器ExtClassLoader和系统类加载器AppClassLoader,这两个类都继承自URLClassLoader,是sun.misc.Launcher的静态内部类。sun.misc.Launcher主要被系统用于启动主应用程序,ExtClassLoader和AppClassLoader都是由sun.misc.Launcher创建的,其类主要类结构如下:

    它们间的关系正如前面所阐述的那样,同时我们发现ExtClassLoader并没有重写loadClass()方法,这足矣说明其遵循双亲委派模式,而AppClassLoader重载了loadCass()方法,但最终调用的还是父类loadClass()方法,因此依然遵守双亲委派模式,重载方法源码如下:

     /**
      * Override loadClass 方法,新增包权限检测功能
      */
     public Class loadClass(String name, boolean resolve)
         throws ClassNotFoundException
     {
         int i = name.lastIndexOf('.');
         if (i != -1) {
             SecurityManager sm = System.getSecurityManager();
             if (sm != null) {
                 sm.checkPackageAccess(name.substring(0, i));
             }
         }
         //依然调用父类的方法
         return (super.loadClass(name, resolve));
     }
    

    其实无论是ExtClassLoader还是AppClassLoader都继承URLClassLoader类,因此它们都遵守双亲委托模型,这点是毋庸置疑的。ok,到此我们对ClassLoader、URLClassLoader、ExtClassLoader、AppClassLoader以及Launcher类间的关系有了比较清晰的了解,同时对一些主要的方法也有一定的认识,这里并没有对这些类的源码进行详细的分析,毕竟没有那个必要,因为我们主要弄得类与类间的关系和常用的方法同时搞清楚双亲委托模式的实现过程,为编写自定义类加载器做铺垫就足够了。ok,前面出现了很多父类加载器的说法,但每个类加载器的父类到底是谁,一直没有阐明,下面我们就通过代码验证的方式来阐明这答案。
    ##类加载器间的关系
    我们进一步了解类加载器间的关系(并非指继承关系),主要可以分为以下4点

    • 启动类加载器,由C++实现,没有父类。

    • 拓展类加载器(ExtClassLoader),由Java语言实现,父类加载器为null

    • 系统类加载器(AppClassLoader),由Java语言实现,父类加载器为ExtClassLoader

    • 自定义类加载器,父类加载器肯定为AppClassLoader。

    下面我们通过程序来验证上述阐述的观点

    /**
     * Created by zejian on 2017/6/18.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    //自定义ClassLoader,完整代码稍后分析
    class FileClassLoader extends  ClassLoader{
        private String rootDir;
    
        public FileClassLoader(String rootDir) {
            this.rootDir = rootDir;
        }
        // 编写获取类的字节码并创建class对象的逻辑
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
           //...省略逻辑代码
        }
    	//编写读取字节流的方法
        private byte[] getClassData(String className) {
            // 读取类文件的字节
            //省略代码....
        }
    }
    
    public class ClassLoaderTest {
    
        public static void main(String[] args) throws ClassNotFoundException {
           
    			 FileClassLoader loader1 = new FileClassLoader(rootDir);
    			
    			  System.out.println("自定义类加载器的父加载器: "+loader1.getParent());
    			  System.out.println("系统默认的AppClassLoader: "+ClassLoader.getSystemClassLoader());
    			  System.out.println("AppClassLoader的父类加载器: "+ClassLoader.getSystemClassLoader().getParent());
    			  System.out.println("ExtClassLoader的父类加载器: "+ClassLoader.getSystemClassLoader().getParent().getParent());
    			
    			/**
    			输出结果:
    			    自定义类加载器的父加载器: sun.misc.Launcher$AppClassLoader@29453f44
    			    系统默认的AppClassLoader: sun.misc.Launcher$AppClassLoader@29453f44
    			    AppClassLoader的父类加载器: sun.misc.Launcher$ExtClassLoader@6f94fa3e
    			    ExtClassLoader的父类加载器: null
    			*/
    
        }
    }
    

    代码中,我们自定义了一个FileClassLoader,这里我们继承了ClassLoader而非URLClassLoader,因此需要自己编写findClass()方法逻辑以及加载字节码的逻辑,关于自定义类加载器我们稍后会分析,这里仅需要知道FileClassLoader是自定义加载器即可,接着在main方法中,通过ClassLoader.getSystemClassLoader()获取到系统默认类加载器,通过获取其父类加载器及其父父类加载器,同时还获取了自定义类加载器的父类加载器,最终输出结果正如我们所预料的,AppClassLoader的父类加载器为ExtClassLoader,而ExtClassLoader没有父类加载器。如果我们实现自己的类加载器,它的父加载器都只会是AppClassLoader。这里我们不妨看看Lancher的构造器源码

    public Launcher() {
            // 首先创建拓展类加载器
            ClassLoader extcl;
            try {
                extcl = ExtClassLoader.getExtClassLoader();
            } catch (IOException e) {
                throw new InternalError(
                    "Could not create extension class loader");
            }
    
            // Now create the class loader to use to launch the application
            try {
    	        //再创建AppClassLoader并把extcl作为父加载器传递给AppClassLoader
                loader = AppClassLoader.getAppClassLoader(extcl);
            } catch (IOException e) {
                throw new InternalError(
                    "Could not create application class loader");
            }
    
            //设置线程上下文类加载器,稍后分析
            Thread.currentThread().setContextClassLoader(loader);
    //省略其他没必要的代码......
            }
        }
    

    显然Lancher初始化时首先会创建ExtClassLoader类加载器,然后再创建AppClassLoader并把ExtClassLoader传递给它作为父类加载器,这里还把AppClassLoader默认设置为线程上下文类加载器,关于线程上下文类加载器稍后会分析。那ExtClassLoader类加载器为什么是null呢?看下面的源码创建过程就明白,在创建ExtClassLoader强制设置了其父加载器为null。

    //Lancher中创建ExtClassLoader
    extcl = ExtClassLoader.getExtClassLoader();
    
    //getExtClassLoader()方法
    public static ExtClassLoader getExtClassLoader() throws IOException{
    
      //........省略其他代码 
      return new ExtClassLoader(dirs);                     
      // .........
    }
    
    //构造方法
    public ExtClassLoader(File[] dirs) throws IOException {
       //调用父类构造URLClassLoader传递null作为parent
       super(getExtURLs(dirs), null, factory);
    }
    
    //URLClassLoader构造
    public URLClassLoader(URL[] urls, ClassLoader parent,
                              URLStreamHandlerFactory factory) {
    

    显然ExtClassLoader的父类为null,而AppClassLoader的父加载器为ExtClassLoader,所有自定义的类加载器其父加载器只会是AppClassLoader,注意这里所指的父类并不是Java继承关系中的那种父子关系。

    #类与类加载器
    ##类与类加载器
    在JVM中表示两个class对象是否为同一个类对象存在两个必要条件

    • 类的完整类名必须一致,包括包名。
    • 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。

    也就是说,在JVM中,即使这个两个类对象(class对象)来源同一个Class文件,被同一个虚拟机所加载,但只要加载它们的ClassLoader实例对象不同,那么这两个类对象也是不相等的,这是因为不同的ClassLoader实例对象都拥有不同的独立的类名称空间,所以加载的class对象也会存在不同的类名空间中,但前提是覆写loadclass方法,从前面双亲委派模式对loadClass()方法的源码分析中可以知,在方法第一步会通过Class<?> c = findLoadedClass(name);从缓存查找,类名完整名称相同则不会再次被加载,因此我们必须绕过缓存查询才能重新加载class对象。当然也可直接调用findClass()方法,这样也避免从缓存查找,如下

    String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
    //创建两个不同的自定义类加载器实例
    FileClassLoader loader1 = new FileClassLoader(rootDir);
    FileClassLoader loader2 = new FileClassLoader(rootDir);
    //通过findClass创建类的Class对象
    Class<?> object1=loader1.findClass("com.zejian.classloader.DemoObj");
    Class<?> object2=loader2.findClass("com.zejian.classloader.DemoObj");
    
    System.out.println("findClass->obj1:"+object1.hashCode());
    System.out.println("findClass->obj2:"+object2.hashCode());
    
    /**
      * 直接调用findClass方法输出结果:
      * findClass->obj1:723074861
        findClass->obj2:895328852
        生成不同的实例
      */
    

    如果调用父类的loadClass方法,结果如下,除非重写loadClass()方法去掉缓存查找步骤,不过现在一般都不建议重写loadClass()方法。

    //直接调用父类的loadClass()方法
    Class<?> obj1 =loader1.loadClass("com.zejian.classloader.DemoObj");
    Class<?> obj2 =loader2.loadClass("com.zejian.classloader.DemoObj");
    
    //不同实例对象的自定义类加载器
    System.out.println("loadClass->obj1:"+obj1.hashCode());
    System.out.println("loadClass->obj2:"+obj2.hashCode());
    //系统类加载器
    System.out.println("Class->obj3:"+DemoObj.class.hashCode());
    
    /**
    * 直接调用loadClass方法的输出结果,注意并没有重写loadClass方法
    * loadClass->obj1:1872034366
      loadClass->obj2:1872034366
      Class->    obj3:1872034366
      都是同一个实例
    */
    

    所以如果不从缓存查询相同完全类名的class对象,那么只有ClassLoader的实例对象不同,同一字节码文件创建的class对象自然也不会相同。
    ##了解class文件的显示加载与隐式加载的概念
    所谓class文件的显示加载与隐式加载的方式是指JVM加载class文件到内存的方式,显示加载指的是在代码中通过调用ClassLoader加载class对象,如直接使用Class.forName(name)this.getClass().getClassLoader().loadClass()加载class对象。而隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象,而是通过虚拟机自动加载到内存中,如在加载某个类的class文件时,该类的class文件中引用了另外一个类的对象,此时额外引用的类将通过JVM自动加载到内存中。在日常开发以上两种方式一般会混合使用,这里我们知道有这么回事即可。
    #编写自己的类加载器
    通过前面的分析可知,实现自定义类加载器需要继承ClassLoader或者URLClassLoader,继承ClassLoader则需要自己重写findClass()方法并编写加载逻辑,继承URLClassLoader则可以省去编写findClass()方法以及class文件加载转换成字节码流的代码。那么编写自定义类加载器的意义何在呢?

    • 当class文件不在ClassPath路径下,默认系统类加载器无法找到该class文件,在这种情况下我们需要实现一个自定义的ClassLoader来加载特定路径下的class文件生成class对象。

    • 当一个class文件是通过网络传输并且可能会进行相应的加密操作时,需要先对class文件进行相应的解密后再加载到JVM内存中,这种情况下也需要编写自定义的ClassLoader并实现相应的逻辑。

    • 当需要实现热部署功能时(一个class文件通过不同的类加载器产生不同class对象从而实现热部署功能),需要实现自定义ClassLoader的逻辑。

    ##自定义File类加载器
    这里我们继承ClassLoader实现自定义的特定路径下的文件类加载器并加载编译后DemoObj.class,源码代码如下

    public class DemoObj {
        @Override
        public String toString() {
            return "I am DemoObj";
        }
    }
    
    package com.zejian.classloader;
    
    import java.io.*;
    
    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class FileClassLoader extends ClassLoader {
        private String rootDir;
    
        public FileClassLoader(String rootDir) {
            this.rootDir = rootDir;
        }
    
        /**
         * 编写findClass方法的逻辑
         * @param name
         * @return
         * @throws ClassNotFoundException
         */
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            // 获取类的class文件字节数组
            byte[] classData = getClassData(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
                //直接生成class对象
                return defineClass(name, classData, 0, classData.length);
            }
        }
    
        /**
         * 编写获取class文件并转换为字节码流的逻辑
         * @param className
         * @return
         */
        private byte[] getClassData(String className) {
            // 读取类文件的字节
            String path = classNameToPath(className);
            try {
                InputStream ins = new FileInputStream(path);
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                int bufferSize = 4096;
                byte[] buffer = new byte[bufferSize];
                int bytesNumRead = 0;
                // 读取类文件的字节码
                while ((bytesNumRead = ins.read(buffer)) != -1) {
                    baos.write(buffer, 0, bytesNumRead);
                }
                return baos.toByteArray();
            } catch (IOException e) {
                e.printStackTrace();
            }
            return null;
        }
    
        /**
         * 类文件的完全路径
         * @param className
         * @return
         */
        private String classNameToPath(String className) {
            return rootDir + File.separatorChar
                    + className.replace('.', File.separatorChar) + ".class";
        }
    
        public static void main(String[] args) throws ClassNotFoundException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            FileClassLoader loader = new FileClassLoader(rootDir);
    
            try {
                //加载指定的class文件
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                System.out.println(object1.newInstance().toString());
              
                //输出结果:I am DemoObj
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    
    

    显然我们通过getClassData()方法找到class文件并转换为字节流,并重写findClass()方法,利用defineClass()方法创建了类的class对象。在main方法中调用了loadClass()方法加载指定路径下的class文件,由于启动类加载器、拓展类加载器以及系统类加载器都无法在其路径下找到该类,因此最终将有自定义类加载器加载,即调用findClass()方法进行加载。如果继承URLClassLoader实现,那代码就更简洁了,如下:

    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class FileUrlClassLoader extends URLClassLoader {
    
        public FileUrlClassLoader(URL[] urls, ClassLoader parent) {
            super(urls, parent);
        }
    
        public FileUrlClassLoader(URL[] urls) {
            super(urls);
        }
    
        public FileUrlClassLoader(URL[] urls, ClassLoader parent, URLStreamHandlerFactory factory) {
            super(urls, parent, factory);
        }
    
    
        public static void main(String[] args) throws ClassNotFoundException, MalformedURLException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            File file = new File(rootDir);
            //File to URI
            URI uri=file.toURI();
            URL[] urls={uri.toURL()};
    
            FileUrlClassLoader loader = new FileUrlClassLoader(urls);
    
            try {
                //加载指定的class文件
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                System.out.println(object1.newInstance().toString());
              
                //输出结果:I am DemoObj
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    

    非常简洁除了需要重写构造器外无需编写findClass()方法及其class文件的字节流转换逻辑。
    ##自定义网络类加载器
    自定义网络类加载器,主要用于读取通过网络传递的class文件(在这里我们省略class文件的解密过程),并将其转换成字节流生成对应的class对象,如下

    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class NetClassLoader extends ClassLoader {
    
        private String url;//class文件的URL
    
        public NetClassLoader(String url) {
            this.url = url;
        }
    
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            byte[] classData = getClassDataFromNet(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
                return defineClass(name, classData, 0, classData.length);
            }
        }
    
        /**
         * 从网络获取class文件
         * @param className
         * @return
         */
        private byte[] getClassDataFromNet(String className) {
            String path = classNameToPath(className);
            try {
                URL url = new URL(path);
                InputStream ins = url.openStream();
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                int bufferSize = 4096;
                byte[] buffer = new byte[bufferSize];
                int bytesNumRead = 0;
                // 读取类文件的字节
                while ((bytesNumRead = ins.read(buffer)) != -1) {
                    baos.write(buffer, 0, bytesNumRead);
                }
                //这里省略解密的过程.......
                return baos.toByteArray();
            } catch (Exception e) {
                e.printStackTrace();
            }
            return null;
        }
    
        private String classNameToPath(String className) {
            // 得到类文件的URL
            return url + "/" + className.replace('.', '/') + ".class";
        }
    
    }
    

    比较简单,主要是在获取字节码流时的区别,从网络直接获取到字节流再转车字节数组然后利用defineClass方法创建class对象,如果继承URLClassLoader类则和前面文件路径的实现是类似的,无需担心路径是filePath还是Url,因为URLClassLoader内的URLClassPath对象会根据传递过来的URL数组中的路径判断是文件还是jar包,然后根据不同的路径创建FileLoader或者JarLoader或默认类Loader去读取对于的路径或者url下的class文件。
    ##热部署类加载器
    所谓的热部署就是利用同一个class文件不同的类加载器在内存创建出两个不同的class对象(关于这点的原因前面已分析过,即利用不同的类加载实例),由于JVM在加载类之前会检测请求的类是否已加载过(即在loadClass()方法中调用findLoadedClass()方法),如果被加载过,则直接从缓存获取,不会重新加载。注意同一个类加载器的实例和同一个class文件只能被加载器一次,多次加载将报错,因此我们实现的热部署必须让同一个class文件可以根据不同的类加载器重复加载,以实现所谓的热部署。实际上前面的实现的FileClassLoader和FileUrlClassLoader已具备这个功能,但前提是直接调用findClass()方法,而不是调用loadClass()方法,因为ClassLoader中loadClass()方法体中调用findLoadedClass()方法进行了检测是否已被加载,因此我们直接调用findClass()方法就可以绕过这个问题,当然也可以重新loadClass方法,但强烈不建议这么干。利用FileClassLoader类测试代码如下:

     public static void main(String[] args) throws ClassNotFoundException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            FileClassLoader loader = new FileClassLoader(rootDir);
            FileClassLoader loader2 = new FileClassLoader(rootDir);
    
            try {
                //加载指定的class文件,调用loadClass()
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                Class<?> object2=loader2.loadClass("com.zejian.classloader.DemoObj");
    
                System.out.println("loadClass->obj1:"+object1.hashCode());
                System.out.println("loadClass->obj2:"+object2.hashCode());
    
                //加载指定的class文件,直接调用findClass(),绕过检测机制,创建不同class对象。
                Class<?> object3=loader.findClass("com.zejian.classloader.DemoObj");
                Class<?> object4=loader2.findClass("com.zejian.classloader.DemoObj");
    
                System.out.println("loadClass->obj3:"+object3.hashCode());
                System.out.println("loadClass->obj4:"+object4.hashCode());
    
                /**
                 * 输出结果:
                 * loadClass->obj1:644117698
                   loadClass->obj2:644117698
                   findClass->obj3:723074861
                   findClass->obj4:895328852
                 */
    
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    

    #双亲委派模型的破坏者-线程上下文类加载器

        在Java应用中存在着很多服务提供者接口(Service Provider Interface,SPI),这些接口允许第三方为它们提供实现,如常见的 SPI 有 JDBC、JNDI等,这些 SPI 的接口属于 Java 核心库,一般存在rt.jar包中,由Bootstrap类加载器加载,而 SPI 的第三方实现代码则是作为Java应用所依赖的 jar 包被存放在classpath路径下,由于SPI接口中的代码经常需要加载具体的第三方实现类并调用其相关方法,但SPI的核心接口类是由引导类加载器来加载的,而Bootstrap类加载器无法直接加载SPI的实现类,同时由于双亲委派模式的存在,Bootstrap类加载器也无法反向委托AppClassLoader加载器SPI的实现类。在这种情况下,我们就需要一种特殊的类加载器来加载第三方的类库,而线程上下文类加载器就是很好的选择。
        线程上下文类加载器(contextClassLoader)是从 JDK 1.2 开始引入的,我们可以通过java.lang.Thread类中的getContextClassLoader()setContextClassLoader(ClassLoader cl)方法来获取和设置线程的上下文类加载器。如果没有手动设置上下文类加载器,线程将继承其父线程的上下文类加载器,初始线程的上下文类加载器是系统类加载器(AppClassLoader),在线程中运行的代码可以通过此类加载器来加载类和资源,如下图所示,以jdbc.jar加载为例

    从图可知rt.jar核心包是有Bootstrap类加载器加载的,其内包含SPI核心接口类,由于SPI中的类经常需要调用外部实现类的方法,而jdbc.jar包含外部实现类(jdbc.jar存在于classpath路径)无法通过Bootstrap类加载器加载,因此只能委派线程上下文类加载器把jdbc.jar中的实现类加载到内存以便SPI相关类使用。显然这种线程上下文类加载器的加载方式破坏了“双亲委派模型”,它在执行过程中抛弃双亲委派加载链模式,使程序可以逆向使用类加载器,当然这也使得Java类加载器变得更加灵活。为了进一步证实这种场景,不妨看看DriverManager类的源码,DriverManager是Java核心rt.jar包中的类,该类用来管理不同数据库的实现驱动即Driver,它们都实现了Java核心包中的java.sql.Driver接口,如mysql驱动包中的com.mysql.jdbc.Driver,这里主要看看如何加载外部实现类,在DriverManager初始化时会执行如下代码

    //DriverManager是Java核心包rt.jar的类
    public class DriverManager {
    	//省略不必要的代码
        static {
            loadInitialDrivers();//执行该方法
            println("JDBC DriverManager initialized");
        }
    
    //loadInitialDrivers方法
     private static void loadInitialDrivers() {
         sun.misc.Providers()
         AccessController.doPrivileged(new PrivilegedAction<Void>() {
                public Void run() {
    				//加载外部的Driver的实现类
                    ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                  //省略不必要的代码......
                }
            });
        }
    

    在DriverManager类初始化时执行了loadInitialDrivers()方法,在该方法中通过ServiceLoader.load(Driver.class);去加载外部实现的驱动类,ServiceLoader类会去读取mysql的jdbc.jar下META-INF文件的内容,如下所示

    而com.mysql.jdbc.Driver继承类如下:

    public class Driver extends com.mysql.cj.jdbc.Driver {
        public Driver() throws SQLException {
            super();
        }
    
        static {
            System.err.println("Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. "
                    + "The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.");
        }
    }
    

    从注释可以看出平常我们使用com.mysql.jdbc.Driver已被丢弃了,取而代之的是com.mysql.cj.jdbc.Driver,也就是说官方不再建议我们使用如下代码注册mysql驱动

    //不建议使用该方式注册驱动类
    Class.forName("com.mysql.jdbc.Driver");
    String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
    // 通过java库获取数据库连接
    Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");
          
    

    而是直接去掉注册步骤,如下即可

    String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
    // 通过java库获取数据库连接
    Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");
          
    

    这样ServiceLoader会帮助我们处理一切,并最终通过load()方法加载,看看load()方法实现

    public static <S> ServiceLoader<S> load(Class<S> service) {
    	 //通过线程上下文类加载器加载
          ClassLoader cl = Thread.currentThread().getContextClassLoader();
          return ServiceLoader.load(service, cl);
      }
    

    很明显了确实通过线程上下文类加载器加载的,实际上核心包的SPI类对外部实现类的加载都是基于线程上下文类加载器执行的,通过这种方式实现了Java核心代码内部去调用外部实现类。我们知道线程上下文类加载器默认情况下就是AppClassLoader,那为什么不直接通过getSystemClassLoader()获取类加载器来加载classpath路径下的类的呢?其实是可行的,但这种直接使用getSystemClassLoader()方法获取AppClassLoader加载类有一个缺点,那就是代码部署到不同服务时会出现问题,如把代码部署到Java Web应用服务或者EJB之类的服务将会出问题,因为这些服务使用的线程上下文类加载器并非AppClassLoader,而是Java Web应用服自家的类加载器,类加载器不同。,所以我们应用该少用getSystemClassLoader()。总之不同的服务使用的可能默认ClassLoader是不同的,但使用线程上下文类加载器总能获取到与当前程序执行相同的ClassLoader,从而避免不必要的问题。ok~.关于线程上下文类加载器暂且聊到这,前面阐述的DriverManager类,大家可以自行看看源码,相信会有更多的体会,另外关于ServiceLoader本篇并没有过多的阐述,毕竟我们主题是类加载器,但ServiceLoader是个很不错的解耦机制,大家可以自行查阅其相关用法。

    ok~,本篇到此告一段落,如有误处,欢迎留言,谢谢。

    参考资料:
    http://blog.csdn.net/yangcheng33/article/details/52631940
    http://ifeve.com/wp-content/uploads/2014/03/JSR133中文版1.pdf

    《深入理解JVM虚拟机》
    《深入分析Java Web 技术内幕》

    展开全文
  • Java类加载器及Android类加载器基础

    千次阅读 2017-03-07 11:29:24
    Java语言天生就有灵活性、动态性,支持运行期间动态组装程序,而这一切的基础就是类加载器Java中的类加载器Java灵活性和动态性的原因Java源代码被编译器编译成字节码,即从.java文件编译为.class文件,而.class...

    引子

    Android插件化与热更新技术日渐成熟,当你研究这些技术时会发现类加载器在其中占据重要地位。Java语言天生就有灵活性、动态性,支持运行期间动态组装程序,而这一切的基础就是类加载器。

    Java中的类加载器

    Java灵活性和动态性的原因

    Java源代码被编译器编译成字节码,即从.java文件编译为.class文件,而.class文件就是通过类加载器加载到虚拟机内存中的。

    虚拟机的类加载(Class Loading)过程分为加载、链接(验证、准备、解析)、初始化、使用、卸载等过程。这里仅考虑加载这个阶段,在此阶段虚拟机的工作有以下几点:

    1. 通过一个类的全限定名来获取该类的二进制字节流
    2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
    3. 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口

    注意看第1条,虚拟机规范只是说来获取一个类的二进制字节流,但并没有说从哪里获取,怎样获取,这也就意味着Class文件可以来自磁盘、ZIP文件、JAR文件、数据库、甚至来自网络或者在程序运行时动态生成。上述各种来源的Class文件都是由类加载器(Class Loader)来加载的,也正因为如此,Java才拥有高度的灵活性和动态性。

    Java中的几种类加载器

    Java中的类加载器至少有三种:

    • 启动类加载器——该加载器一般由C或C++实现(如HotSpot用C++实现,其实也有虚拟机是用Java实现的),它是作为虚拟机不可分割的一部分而存在。该加载器负责加载jre/lib中的系统类,如通常从rt.jar中进行加载。启动类加载器由于属于虚拟机的一部分,因此无法被Java程序直接引用,所以例如String.class.getClassLoader()将会返回null。
    • 扩展类加载器——该加载器由Java语言实现,继承自java.lang.ClassLoader,独立于虚拟机外部,负责加载jre/lib/ext目录下的文件,如果对扩展类加载器调用getParent()也会返回null。
    • 系统类加载器(或叫应用类加载器)——该加载器由Java语言实现,继承自java.lang.ClassLoader,独立于虚拟机外部,负责加载应用程序类。如果应用程序中没有自定义的类加载器,那么此加载器就是默认的类加载器。

    此外,用户还可以继承ClassLoader类来自定义类加载器,这样就可以在向虚拟机传递字节码之前进行需求定制了。

    注意:对于任意一个Java类,它在虚拟机里的唯一性是由其类本身及其类加载器共同决定的。如果两个类来自同一个Class文件,在同一个虚拟机中,但是被不同的ClassLoader所加载,那么这两个类在虚拟机中也是不相等的。

    类加载器的双亲委派模型

    先来看下Java中的类加载器层次关系:

    这里写图片描述

    上述层次关系称为类加载器的双亲委派模型,它是在JDK 1.2中引入的,其实它并非强制性的约束,而是推荐我们使用的一种类加载机制,可以看到除了顶部的启动类加载器之外,其他加载器都有一个父类加载器。

    双亲委派模型的工作流程:当一个类加载器收到加载类的请求时,它自己先不进行加载,而是把该请求委派为父类加载器去完成,父类加载器也是如此,直到将加载类的需求传给顶层的启动类加载器;只有当父类加载器无法完成加载时(在自己的搜索范围中没有找到该类),子加载器才尝试自己去完成类加载,如果加载不了,则会抛出ClassNotFoundException异常。

    有一点需要注意:如果扩展类加载器收到请求去加载一个类,它会先委托启动类加载器去加载,如果启动类加载器加载不了,则尝试自己加载。如果扩展类加载器也无法加载,则直接抛出ClassNotFoundException异常而结束,并不会再交给下一层的应用类加载器去加载。

    说明了双亲委派模型的原理后,再来看下其源码实现,代码逻辑很简单,也证实了上述讲到的双亲委派模型的工作流程:

    public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
    }
    
    protected synchronized Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException {
        // 首先判断该类是否已经被加载过,如果已加载过就直接返回
        Class c = findLoadedClass(name);
        if (c == null) {
            // 如果没有被加载,就委托给父加载器处理或者给启动类加载器处理
            try {
                if (parent != null) {
                    // 如果存在父类加载器,就委派给父类加载器加载  
                    c = parent.loadClass(name, false);
                } else {
                    // 如果不存在父类加载器,就检查是否由启动类加载器加载  
                    // 通过调用native方法 findBootstrapClass0(String name)  
                    c = findBootstrapClass0(name);
                }
            } catch (ClassNotFoundException e) {
                // 如果父加载器和启动类加载器都不能完成加载任务,自身才尝试去加载
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }

    双亲委派模型的意义

    使用双亲委派模型来组织各种类加载器,使之遵循了一定的优先级层次,从而能保证Java运行环境的稳定与条理性。例如java.lang.Object类是所有类的基类,并且根据双亲委派模型它是由启动类加载器加载的,如果我们也自定义了一个java.lang.Object类(只是假如,其实虚拟机会对java.lang开头的自定义类抛异常)并放在应用程序的ClassPath中去加载,那么应用中就会出现多个Object类,从而会导致Java类型体系混乱而无法正常运行。

    另一个好处是避免类的二次加载。从上述loadClass源码中可知,先判断该类是否被加载过,如果已被加载过则直接返回该类。当一个类加载器委托父类加载时也是执行此逻辑,从而保证某些类只被加载一次。

    自定义类加载器

    由于自定义类加载器通常继承ClassLoader,来看下ClassLoader的几个主要方法:

    // 加载指定完整名称的二进制字节流,不建议子类加载器重写,否则可能会破坏双亲委派模型
    public Class<?> loadClass(String name) throws ClassNotFoundException{ … }
    
    // 加载指定完整名称的二进制字节流,不建议子类加载器重写,否则可能会破坏双亲委派模型
    protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{ … }
    
    // 被loadClass方法调用去加载指定名称类,官方建议子类加载器重写该方法
    protected Class<?> findClass(String name) throws ClassNotFoundException { … }
    
    // 该方法将二进制字节流转换为Class,一般在findClass方法中读取到对应字节码后调用,由于是final方法,故不可继承,其功能具体由虚拟机实现,Java层不需要关心
    protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError{ … }

    上述几个方法的说明可参考注释。

    为了遵循双亲委派模型,当自定义类加载器时,官方建议我们仅仅重写findClass()方法,而不要重写loadClass()方法,否则就有可能破坏双亲委派模型。当然前面也说了,双亲委派模型并非强制约束,如有特别需要,也可以自行确定类的加载规则。一个典型的自定义类加载器如下:

    public class CustomClassLoader extends ClassLoader {
        ……
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            // 获取类的字节数组
            byte[] classData = getClassData(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
                return defineClass(name, classData, 0, classData.length);
            }
        }
       ……
    
    }

    由此可知类加载器的各个方法的执行顺序为:loadClass—>findClass—>defineClass。

    Android中的类加载器

    Android应用通常是使用Java来开发的,也是运行在虚拟机Dalvik或ART上。虽然Android的虚拟机跟标准的Java虚拟机是不同的,但是类的加载机制都是类似的,即理论上Android也可以像Java程序一样,灵活地动态加载,如今大量的Android插件化、热更新框架都利用了此技术。

    Android中的几种类加载器

    在一个Android工程的Application中加入几行日志来打印下,代码如下:

    package com.aspook.androidnotes;
    
    import android.app.Application;
    import android.util.Log;
    
    public class MyApplication extends Application {
    
        @Override
        public void onCreate() {
            super.onCreate();
    
            ClassLoader loader = getClassLoader();
            if (loader != null) {
                Log.d("ABC", "classLoader :" + loader);
                while (loader.getParent() != null) {
                    loader = loader.getParent();
                    Log.d("ABC", "classLoader :" + loader);
                }
            }
        }
    }

    在Android Studio中启动App后,依次输出3条Log如下:

    classLoader :dalvik.system.PathClassLoader[DexPathList[[zip file “/data/app/com.aspook.androidnotes-2/base.apk”],nativeLibraryDirectories=[/data/app/com.aspook.androidnotes-2/lib/arm64, /vendor/lib64, /system/lib64]]]
    classLoader :com.android.tools.fd.runtime.IncrementalClassLoader@3faf711
    classLoader :java.lang.BootClassLoader@d913983

    这里出现了3种ClassLoader,分别是:dalvik.system.PathClassLoader、com.android.tools.fd.runtime.IncrementalClassLoader、java.lang.BootClassLoader。第二个类加载器是用于Instant Run的,如果关闭Android Studio的Instant Run功能,再运行App则只会输出两种ClassLoader。

    通过查看dalvik.system包下的源码,发现还有一种ClassLoader叫做DexClassLoader,稍后会介绍其用途。

    PathClassLoader

    其官方说明如下:

    Provides a simple ClassLoader implementation that operates on a list of files and directories in the local file system, but does not attempt to load classes from the network. Android uses this class for its system class loader and for its application class loader(s).

    PathClassLoader是ClassLoader的简单实现且只能加载本地的列表文件或目录,在Android中也就是已安装好的APK,它不能加载来自网络的类。Android中的系统类加载器与应用类加载器都是PathClassLoader。

    先来看其源码(7.0):

    package dalvik.system;
    
    import dalvik.system.BaseDexClassLoader;
    import java.io.File;
    
    public class PathClassLoader extends BaseDexClassLoader {
        public PathClassLoader(String dexPath, ClassLoader parent) {
            super(dexPath, null, null, parent);
        }
    
        public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
            super(dexPath, null, librarySearchPath, parent);
        }
    }

    从上述源码可知其仅仅提供了两个构造方法,其中各参数的具体含义如下:

    dexPath:包含dex文件的JAR/ZIP/APK文件的路径

    librarySearchPath:native library文件的路径

    parent:父类加载器

    再来看BaseDexClassLoader的源码:

    package dalvik.system;
    
    import java.io.File;
    import java.net.URL;
    import java.util.ArrayList;
    import java.util.Enumeration;
    import java.util.List;
    
    public class BaseDexClassLoader extends ClassLoader {
        private final DexPathList pathList;
    
        public BaseDexClassLoader(String dexPath, File optimizedDirectory, String librarySearchPath, ClassLoader parent) {
            super(parent);
            this.pathList = new DexPathList(this, dexPath, librarySearchPath, optimizedDirectory);
        }
    
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
            Class c = pathList.findClass(name, suppressedExceptions);
            if (c == null) {
                ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
                for (Throwable t : suppressedExceptions) {
                    cnfe.addSuppressed(t);
                }
                throw cnfe;
            }
            return c;
        }
    
        /**
         * * @hide
         */
        public void addDexPath(String dexPath) {
            pathList.addDexPath(dexPath, null /*optimizedDirectory*/);
        }
    
        @Override
        protected URL findResource(String name) {
            return pathList.findResource(name);
        }
    
        @Override
        protected Enumeration<URL> findResources(String name) {
            return pathList.findResources(name);
        }
    
        @Override
        public String findLibrary(String name) {
            return pathList.findLibrary(name);
        }
    
        @Override
        protected synchronized Package getPackage(String name) {
            if (name != null && !name.isEmpty()) {
                Package pack = super.getPackage(name);
    
                if (pack == null) {
                    pack = definePackage(name, "Unknown", "0.0", "Unknown",
                            "Unknown", "0.0", "Unknown", null);
                }
    
                return pack;
            }
    
            return null;
        }
    
        /**
         * @hide
         */
        public String getLdLibraryPath() {
            StringBuilder result = new StringBuilder();
            for (File directory : pathList.getNativeLibraryDirectories()) {
                if (result.length() > 0) {
                    result.append(':');
                }
                result.append(directory);
            }
    
            return result.toString();
        }
    
        @Override
        public String toString() {
            return getClass().getName() + "[" + pathList + "]";
        }
    }

    BaseDexClassLoader构造方法中有一个新的参数为optimizedDirectory,它表示优化后的dex文件要写入的路径,此处可以为null。

    BaseDexClassLoader继承自java.lang.ClassLoader,它跟纯Java环境下的java.lang.ClassLoader还是有些不同的,虽然双亲委派的加载机制类似。

    结合最初的Log输出可知,PathClassLoader只能加载”/data/app/com.aspook.androidnotes-2/base.apk”中的类,也就是已安装到手机中的APK,因此PathClassLoader作为默认的应用类加载器。

    DexClassLoader

    其官方说明如下:

    A class loader that loads classes from .jar and .apk files containing a classes.dex entry. This can be used to execute code not installed as part of an application.

    DexClassLoader可以从包含dex文件的JAR或APK中来加载类,而这些代码源允许不必是安装应用的一部分,因此可用于动态加载。

    先来看下DexClassLoader的源码(7.0):

    package dalvik.system;
    
    /**
     * A class loader that loads classes from {@code .jar} and {@code .apk} files
     * containing a {@code classes.dex} entry. This can be used to execute code not
     * installed as part of an application.
     *
     * <p>This class loader requires an application-private, writable directory to
     * cache optimized classes. Use {@code Context.getCodeCacheDir()} to create
     * such a directory: <pre>   {@code
     *   File dexOutputDir = context.getCodeCacheDir();
     * }</pre>
     *
     * <p><strong>Do not cache optimized classes on external storage.</strong>
     * External storage does not provide access controls necessary to protect your
     * application from code injection attacks.
     */
    import dalvik.system.BaseDexClassLoader;
    
    public class DexClassLoader extends BaseDexClassLoader {
        /**
         * Creates a {@code DexClassLoader} that finds interpreted and native
         * code.  Interpreted classes are found in a set of DEX files contained
         * in Jar or APK files.
         * <p>
         * <p>The path lists are separated using the character specified by the
         * {@code path.separator} system property, which defaults to {@code :}.
         *
         * @param dexPath            the list of jar/apk files containing classes and
         *                           resources, delimited by {@code File.pathSeparator}, which
         *                           defaults to {@code ":"} on Android
         * @param optimizedDirectory directory where optimized dex files
         *                           should be written; must not be {@code null}
         * @param librarySearchPath  the list of directories containing native
         *                           libraries, delimited by {@code File.pathSeparator}; may be
         *                           {@code null}
         * @param parent             the parent class loader
         */
    
    
        public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
            super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
    
        }
    
    }
    

    它同样继承自BaseDexClassLoader,是java.lang.ClassLoader的子类,因此DexClassLoader与PathClassLoader都默认遵循双亲委派模型。

    DexClassLoader构造方法中的参数,我们前文都已经提及,注意的一点是optimizedDirectory参数在这里不能为null。

    与PathClassLoader不同,DexClassLoader则打破了PathClassLoader的局限,它可以加载已安装应用之外的APK、JAR或ZIP中的dex文件,通常建议使用如下路径:

    File dexOutputDir = context.getCodeCacheDir();

    不建议使用外部存储,因为外部存储没有提供足够的访问权限控制,容易引发代码注入攻击。

    因此,Android中实现动态插件通常是自定义继承自DexClassLoader的类加载器;如果插件为已安装的APK,则可以使用PathClassLoader。

    BootClassLoader

    BootClassLoader直接继承自java.lang.ClassLoader,其定义如下:

    class BootClassLoader extends ClassLoader {
    
        private static BootClassLoader instance;
    
        @FindBugsSuppressWarnings("DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED")
        public static synchronized BootClassLoader getInstance() {
            if (instance == null) {
                instance = new BootClassLoader();
            }
    
            return instance;
        }
    
        public BootClassLoader() {
            super(null);
        }
    
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            return Class.classForName(name, false, null);
        }
    
        @Override
        protected URL findResource(String name) {
            return VMClassLoader.getResource(name);
        }
    
        @SuppressWarnings("unused")
        @Override
        protected Enumeration<URL> findResources(String resName) throws IOException {
            return Collections.enumeration(VMClassLoader.getResources(resName));
        }
    
        @Override
        protected Package getPackage(String name) {
            if (name != null && !name.isEmpty()) {
                synchronized (this) {
                    Package pack = super.getPackage(name);
    
                    if (pack == null) {
                        pack = definePackage(name, "Unknown", "0.0", "Unknown", "Unknown", "0.0",
                                "Unknown", null);
                    }
    
                    return pack;
                }
            }
    
            return null;
        }
    
        @Override
        public URL getResource(String resName) {
            return findResource(resName);
        }
    
        @Override
        protected Class<?> loadClass(String className, boolean resolve)
               throws ClassNotFoundException {
            Class<?> clazz = findLoadedClass(className);
    
            if (clazz == null) {
                clazz = findClass(className);
            }
    
            return clazz;
        }
    
        @Override
        public Enumeration<URL> getResources(String resName) throws IOException {
            return findResources(resName);
        }
    }

    通常在自定义类加载器时,都需要在构造方法中传入一个父加载器,而BootClassLoader的构造方法如下,没有传入parent,而是传入一个null:

    public BootClassLoader() {
        super(null);
    }

    因此调用BootClassLoader的getParent方法时返回值为null。

    BootClassLoader用来加载系统框架级别的类,例如Context.class.getClassLoader()与ListView.class.getClassLoader()的返回值类型均为BootClassLoader。

    系统类加载器

    当调用ClassLoader.getSystemClassLoader()这句代码时,会输出如下结果:

    dalvik.system.PathClassLoader[DexPathList[[directory “.”],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]]

    发现系统类加载器也是dalvik.system.PathClassLoader,与最初应用的类加载器(也是dalvik.system.PathClassLoader)不同的是DexPathList的路径不同。

    跟踪一下源码:

    public static ClassLoader getSystemClassLoader() {
        return SystemClassLoader.loader;
    }
    static private class SystemClassLoader {
        public static ClassLoader loader = ClassLoader.createSystemClassLoader();
    }
    /**
     * Encapsulates the set of parallel capable loader types.
     */
    private static ClassLoader createSystemClassLoader() {
        String classPath = System.getProperty("java.class.path", ".");
        String librarySearchPath = System.getProperty("java.library.path", "");
    
        // String[] paths = classPath.split(":");
        // URL[] urls = new URL[paths.length];
        // for (int i = 0; i < paths.length; i++) {
        // try {
        // urls[i] = new URL("file://" + paths[i]);
        // }
        // catch (Exception ex) {
        // ex.printStackTrace();
        // }
        // }
        //
        // return new java.net.URLClassLoader(urls, null);
    
        // TODO Make this a java.net.URLClassLoader once we have those?
        return new PathClassLoader(classPath, librarySearchPath, BootClassLoader.getInstance());
    }

    而System.getProperty(“java.class.path”)返回值为“.”,似乎可以解释系统类加载器的DexPathList的路径了。

    Android中类加载器的层次结构

    与Java中类加载器的层次结构类似,具体如下图:

    这里写图片描述

    总结

    本文简单介绍了类加载器的基本概念,罗列了Java及Android中常用的类加载器,并对各种类加载器的特点及功能做了说明,另外对类加载器的双亲委派机制做了详细讲解,对于Android插件化及热更新技术则不在本文的讨论之内,后续会继续分享。

    展开全文
  • JAVA类加载器

    千次阅读 2018-09-21 18:00:44
    每个编写的”.java”拓展名文件都存储着需要执行的程序逻辑,这些”.java”文件经过Java编译器编译成拓展名为”.class”的文件, ”.class”文件中保存着Java代码经转换后的虚拟机指令,当需要使用某个时,...

    装载验证流程

    每个编写的”.java”拓展名类文件都存储着需要执行的程序逻辑,这些”.java”文件经过Java编译器编译成拓展名为”.class”的文件,
    ”.class”文件中保存着Java代码经转换后的虚拟机指令,当需要使用某个类时,虚拟机将会加载它的”.class”文件,并创建对应的class对象,
    将class文件加载到虚拟机的内存,这个过程称为类加载,这里我们需要了解一下类加载的过程,如下:

    image

    加载

    类加载过程的一个阶段:通过一个类的完全限定查找此类字节码文件,并利用字节码文件创建一个Class对象

    链接

    验证

    目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,不会危害虚拟机自身安全。主要包括四种验证,文件格式验证,
    元数据验证,字节码验证,符号引用验证。

    • 文件格式的验证

    是否以0xCAFEBABE开头,版本号是否合理

    • 元数据验证

    是否有父类,继承了final类?非抽象类实现了所有的抽象方法

    • 字节码验证 (很复杂)

    运行检查,栈数据类型和操作码数据参数吻合,跳转指令指定到合理的位置

    • 符号引用验证

    常量池中描述类是否存在,访问的方法或字段是否存在且有足够的权限

    准备

    为类变量(即static修饰的字段变量)分配内存并且设置该类变量的初始值即0(如static int i=5;这里只将i初始化为0,
    至于5的值将在初始化时赋值),这里不包含用final修饰的static,因为final在编译的时候就会分配了,注意这里不会为实例变量分配初始化,
    类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。

    分配内存,并为类设置初始值 (方法区中)

    • public static int v=1;
    • 在准备阶段中,v会被设置为0
    • 在初始化的中才会被设置为1
    • 对于static final类型,在准备阶段就会被赋上正确的值
    • public static final int v=1;

    解析

    主要将常量池中的符号引用替换为直接引用的过程。符号引用就是一组符号来描述目标,可以是任何字面量,
    而直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。有类或接口的解析,字段解析,类方法解析,
    接口方法解析(这里涉及到字节码变量的引用,如需更详细了解,可参考《深入Java虚拟机》)。

    初始化

    类加载最后阶段,若该类具有超类,则对其进行初始化,执行静态初始化器和静态初始化成员变量(如前面只初始化了默认值的static变量将会在这个阶段赋值,
    成员变量也将被初始化)。

    • 执行类构造器
      • static变量 赋值语句
      • static{}语句
    • 子类的调用前保证父类的被调用
    • 是线程安全的

    这便是类加载的5个过程,而类加载器的任务是根据一个类的全限定名来读取此类的二进制字节流到JVM中,
    然后转换为一个与目标类对应的java.lang.Class对象实例,在虚拟机提供了3种类加载器,
    引导(Bootstrap)类加载器、扩展(Extension)类加载器、系统(System)类加载器(也称应用类加载器)

    加载器

    启动(Bootstrap)类加载器

    启动类加载器主要加载的是JVM自身需要的类,这个类加载使用C++语言实现的,是虚拟机自身的一部分,
    它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中,
    注意必由于虚拟机是按照文件名识别加载jar包的,如rt.jar,如果文件名不被虚拟机识别,
    即使把jar包丢到lib目录下也是没有作用的(出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类)。

    扩展(Extension)类加载器

    扩展类加载器是指Sun公司(已被Oracle收购)实现的sun.misc.Launcher$ExtClassLoader类,由Java语言实现的,
    是Launcher的静态内部类,它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库,
    开发者可以直接使用标准扩展类加载器。

    //ExtClassLoader类中获取路径的代码
    private static File[] getExtDirs() {
         //加载<JAVA_HOME>/lib/ext目录中的类库
         String s = System.getProperty("java.ext.dirs");
         File[] dirs;
         if (s != null) {
             StringTokenizer st =
                 new StringTokenizer(s, File.pathSeparator);
             int count = st.countTokens();
             dirs = new File[count];
             for (int i = 0; i < count; i++) {
                 dirs[i] = new File(st.nextToken());
             }
         } else {
             dirs = new File[0];
         }
         return dirs;
     }
    

    系统(System)类加载器

    也称应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。
    它负责加载系统类路径java -classpath或-D java.class.path 指定路径下的类库,也就是我们经常用到的classpath路径,
    开发者可以直接使用系统类加载器,一般情况下该类加载是程序中默认的类加载器,通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。
    在Java的日常应用程序开发中,类的加载几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,
    需要注意的是,Java虚拟机对class文件采用的是按需加载的方式,也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象,
    而且加载某个类的class文件时,Java虚拟机采用的是双亲委派模式即把请求交由父类处理,它一种任务委派模式,下面我们进一步了解它。

    双亲委派模式

    双亲委派模式工作原理

    双亲委派模式要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器,
    请注意双亲委派模式中的父子关系并非通常所说的类继承关系,而是采用组合关系来复用父类加载器的相关代码,
    类加载器间的关系如下:

    image

    image

    双亲委派模式是在Java 1.2后引入的,其工作原理的是,如果一个类加载器收到了类加载请求,它并不会自己先去加载,
    而是把这个请求委托给父类的加载器去执行,如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器,
    如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式,
    即每个儿子都很懒,每次有活就丢给父亲去干,直到父亲说这件事我也干不了时,儿子自己想办法去完成,这不就是传说中的实力坑爹啊?
    那么采用这种模式有啥用呢?

    双亲委派模式优势

    采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系,通过这种层级关可以避免类的重复加载,
    当父亲已经加载了该类时,就没有必要子ClassLoader再加载一次。其次是考虑到安全因素,java核心api中定义类型不会被随意替换,
    假设通过网络传递一个名为java.lang.Integer的类,通过双亲委托模式传递到启动类加载器,而启动类加载器在核心Java API发现这个名字的类,
    发现该类已被加载,并不会重新加载网络传递的过来的java.lang.Integer,而直接返回已加载过的Integer.class,这样便可以防止核心API库被随意篡改。
    可能你会想,如果我们在classpath路径下自定义一个名为java.lang.SingleInterge类(该类是胡编的)呢?该类并不存在java.lang中,
    经过双亲委托模式,传递到启动类加载器中,由于父类加载器路径下并没有该类,所以不会加载,将反向委托给子类加载器加载,
    最终会通过系统类加载器加载该类。但是这样做是不允许,因为java.lang是核心API包,需要访问权限,强制加载将会报出如下异常

    java.lang.SecurityException: Prohibited package name: java.lang
    

    编写自己的类加载器

    通过前面的分析可知,实现自定义类加载器需要继承ClassLoader或者URLClassLoader,继承ClassLoader则需要自己重写findClass()方法并编写加载逻辑,
    继承URLClassLoader则可以省去编写findClass()方法以及class文件加载转换成字节码流的代码。那么编写自定义类加载器的意义何在呢?

    • 当class文件不在ClassPath路径下,默认系统类加载器无法找到该class文件,
      在这种情况下我们需要实现一个自定义的ClassLoader来加载特定路径下的class文件生成class对象。

    • 当一个class文件是通过网络传输并且可能会进行相应的加密操作时,需要先对class文件进行相应的解密后再加载到JVM内存中,
      这种情况下也需要编写自定义的ClassLoader并实现相应的逻辑。

    • 当需要实现热部署功能时(一个class文件通过不同的类加载器产生不同class对象从而实现热部署功能),
      需要实现自定义ClassLoader的逻辑。

    自定义File类加载器

    这里我们继承ClassLoader实现自定义的特定路径下的文件类加载器并加载编译后DemoObj.class,源码代码如下

    public class DemoObj {
        @Override
        public String toString() {
            return "I am DemoObj";
        }
    }
    
    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class FileClassLoader extends ClassLoader {
        private String rootDir;
    
        public FileClassLoader(String rootDir) {
            this.rootDir = rootDir;
        }
    
        /**
         * 编写findClass方法的逻辑
         * @param name
         * @return
         * @throws ClassNotFoundException
         */
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            // 获取类的class文件字节数组
            byte[] classData = getClassData(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
                //直接生成class对象
                return defineClass(name, classData, 0, classData.length);
            }
        }
    
        /**
         * 编写获取class文件并转换为字节码流的逻辑
         * @param className
         * @return
         */
        private byte[] getClassData(String className) {
            // 读取类文件的字节
            String path = classNameToPath(className);
            try {
                InputStream ins = new FileInputStream(path);
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                int bufferSize = 4096;
                byte[] buffer = new byte[bufferSize];
                int bytesNumRead = 0;
                // 读取类文件的字节码
                while ((bytesNumRead = ins.read(buffer)) != -1) {
                    baos.write(buffer, 0, bytesNumRead);
                }
                return baos.toByteArray();
            } catch (IOException e) {
                e.printStackTrace();
            }
            return null;
        }
    
        /**
         * 类文件的完全路径
         * @param className
         * @return
         */
        private String classNameToPath(String className) {
            return rootDir + File.separatorChar
                    + className.replace('.', File.separatorChar) + ".class";
        }
    
        public static void main(String[] args) throws ClassNotFoundException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            FileClassLoader loader = new FileClassLoader(rootDir);
    
            try {
                //加载指定的class文件
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                System.out.println(object1.newInstance().toString());
    
                //输出结果:I am DemoObj
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    
    

    显然我们通过getClassData()方法找到class文件并转换为字节流,并重写findClass()方法,
    利用defineClass()方法创建了类的class对象。在main方法中调用了loadClass()方法加载指定路径下的class文件,由于启动类加载器、
    拓展类加载器以及系统类加载器都无法在其路径下找到该类,因此最终将有自定义类加载器加载,即调用findClass()方法进行加载。
    如果继承URLClassLoader实现,那代码就更简洁了,如下:

    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class FileUrlClassLoader extends URLClassLoader {
    
        public FileUrlClassLoader(URL[] urls, ClassLoader parent) {
            super(urls, parent);
        }
    
        public FileUrlClassLoader(URL[] urls) {
            super(urls);
        }
    
        public FileUrlClassLoader(URL[] urls, ClassLoader parent, URLStreamHandlerFactory factory) {
            super(urls, parent, factory);
        }
    
    
        public static void main(String[] args) throws ClassNotFoundException, MalformedURLException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            File file = new File(rootDir);
            //File to URI
            URI uri=file.toURI();
            URL[] urls={uri.toURL()};
    
            FileUrlClassLoader loader = new FileUrlClassLoader(urls);
    
            try {
                //加载指定的class文件
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                System.out.println(object1.newInstance().toString());
    
                //输出结果:I am DemoObj
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    
    

    非常简洁除了需要重写构造器外无需编写findClass()方法及其class文件的字节流转换逻辑。

    自定义网络类加载器

    自定义网络类加载器,主要用于读取通过网络传递的class文件(在这里我们省略class文件的解密过程),并将其转换成字节流生成对应的class对象,如下

    /**
     * Created by zejian on 2017/6/21.
     * Blog : http://blog.csdn.net/javazejian [原文地址,请尊重原创]
     */
    public class NetClassLoader extends ClassLoader {
    
        private String url;//class文件的URL
    
        public NetClassLoader(String url) {
            this.url = url;
        }
    
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            byte[] classData = getClassDataFromNet(name);
            if (classData == null) {
                throw new ClassNotFoundException();
            } else {
                return defineClass(name, classData, 0, classData.length);
            }
        }
    
        /**
         * 从网络获取class文件
         * @param className
         * @return
         */
        private byte[] getClassDataFromNet(String className) {
            String path = classNameToPath(className);
            try {
                URL url = new URL(path);
                InputStream ins = url.openStream();
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                int bufferSize = 4096;
                byte[] buffer = new byte[bufferSize];
                int bytesNumRead = 0;
                // 读取类文件的字节
                while ((bytesNumRead = ins.read(buffer)) != -1) {
                    baos.write(buffer, 0, bytesNumRead);
                }
                //这里省略解密的过程.......
                return baos.toByteArray();
            } catch (Exception e) {
                e.printStackTrace();
            }
            return null;
        }
    
        private String classNameToPath(String className) {
            // 得到类文件的URL
            return url + "/" + className.replace('.', '/') + ".class";
        }
    
    }
    
    

    比较简单,主要是在获取字节码流时的区别,从网络直接获取到字节流再转车字节数组然后利用defineClass方法创建class对象,
    如果继承URLClassLoader类则和前面文件路径的实现是类似的,无需担心路径是filePath还是Url,
    因为URLClassLoader内的URLClassPath对象会根据传递过来的URL数组中的路径判断是文件还是jar包,
    然后根据不同的路径创建FileLoader或者JarLoader或默认类Loader去读取对于的路径或者url下的class文件。

    热部署类加载器

    所谓的热部署就是利用同一个class文件不同的类加载器在内存创建出两个不同的class对象(关于这点的原因前面已分析过,即利用不同的类加载实例),
    由于JVM在加载类之前会检测请求的类是否已加载过(即在loadClass()方法中调用findLoadedClass()方法),如果被加载过,则直接从缓存获取,
    不会重新加载。注意同一个类加载器的实例和同一个class文件只能被加载器一次,多次加载将报错,
    因此我们实现的热部署必须让同一个class文件可以根据不同的类加载器重复加载,以实现所谓的热部署。
    实际上前面的实现的FileClassLoader和FileUrlClassLoader已具备这个功能,但前提是直接调用findClass()方法,
    而不是调用loadClass()方法,因为ClassLoader中loadClass()方法体中调用findLoadedClass()方法进行了检测是否已被加载
    ,因此我们直接调用findClass()方法就可以绕过这个问题,当然也可以重新loadClass方法,但强烈不建议这么干。利用FileClassLoader类测试代码如下:

    public static void main(String[] args) throws ClassNotFoundException {
            String rootDir="/Users/zejian/Downloads/Java8_Action/src/main/java/";
            //创建自定义文件类加载器
            FileClassLoader loader = new FileClassLoader(rootDir);
            FileClassLoader loader2 = new FileClassLoader(rootDir);
    
            try {
                //加载指定的class文件,调用loadClass()
                Class<?> object1=loader.loadClass("com.zejian.classloader.DemoObj");
                Class<?> object2=loader2.loadClass("com.zejian.classloader.DemoObj");
    
                System.out.println("loadClass->obj1:"+object1.hashCode());
                System.out.println("loadClass->obj2:"+object2.hashCode());
    
                //加载指定的class文件,直接调用findClass(),绕过检测机制,创建不同class对象。
                Class<?> object3=loader.findClass("com.zejian.classloader.DemoObj");
                Class<?> object4=loader2.findClass("com.zejian.classloader.DemoObj");
    
                System.out.println("loadClass->obj3:"+object3.hashCode());
                System.out.println("loadClass->obj4:"+object4.hashCode());
    
                /**
                 * 输出结果:
                 * loadClass->obj1:644117698
                   loadClass->obj2:644117698
                   findClass->obj3:723074861
                   findClass->obj4:895328852
                 */
    
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    

    双亲委派模型的破坏者-线程上下文类加载器

    在Java应用中存在着很多服务提供者接口(Service Provider Interface,SPI),这些接口允许第三方为它们提供实现,
    如常见的 SPI 有 JDBC、JNDI等,这些 SPI 的接口属于 Java 核心库,一般存在rt.jar包中,由Bootstrap类加载器加载,
    而 SPI 的第三方实现代码则是作为Java应用所依赖的 jar 包被存放在classpath路径下,
    由于SPI接口中的代码经常需要加载具体的第三方实现类并调用其相关方法,但SPI的核心接口类是由引导类加载器来加载的,
    而Bootstrap类加载器无法直接加载SPI的实现类,同时由于双亲委派模式的存在,Bootstrap类加载器也无法反向委托AppClassLoader加载器SPI的实现类。
    在这种情况下,我们就需要一种特殊的类加载器来加载第三方的类库,而线程上下文类加载器就是很好的选择。
    线程上下文类加载器(contextClassLoader)是从 JDK 1.2 开始引入的,我们可以通过java.lang.Thread类中的getContextClassLoader()和
    setContextClassLoader(ClassLoader cl)方法来获取和设置线程的上下文类加载器。如果没有手动设置上下文类加载器,
    线程将继承其父线程的上下文类加载器,初始线程的上下文类加载器是系统类加载器(AppClassLoader),
    在线程中运行的代码可以通过此类加载器来加载类和资源,如下图所示,以jdbc.jar加载为例

    image

    从图可知rt.jar核心包是有Bootstrap类加载器加载的,其内包含SPI核心接口类,由于SPI中的类经常需要调用外部实现类的方法,
    而jdbc.jar包含外部实现类(jdbc.jar存在于classpath路径)无法通过Bootstrap类加载器加载,
    因此只能委派线程上下文类加载器把jdbc.jar中的实现类加载到内存以便SPI相关类使用。
    显然这种线程上下文类加载器的加载方式破坏了“双亲委派模型”,它在执行过程中抛弃双亲委派加载链模式,使程序可以逆向使用类加载器,
    当然这也使得Java类加载器变得更加灵活。为了进一步证实这种场景,不妨看看DriverManager类的源码,DriverManager是Java核心rt.jar包中的类,
    该类用来管理不同数据库的实现驱动即Driver,它们都实现了Java核心包中的java.sql.Driver接口,如mysql驱动包中的com.mysql.jdbc.Driver,
    这里主要看看如何加载外部实现类,在DriverManager初始化时会执行如下代码

    //DriverManager是Java核心包rt.jar的类
    public class DriverManager {
        //省略不必要的代码
        static {
            loadInitialDrivers();//执行该方法
            println("JDBC DriverManager initialized");
        }
    
    //loadInitialDrivers方法
     private static void loadInitialDrivers() {
         sun.misc.Providers()
         AccessController.doPrivileged(new PrivilegedAction<Void>() {
                public Void run() {
                    //加载外部的Driver的实现类
                    ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                  //省略不必要的代码......
                }
            });
        }
    

    在DriverManager类初始化时执行了loadInitialDrivers()方法,在该方法中通过ServiceLoader.load(Driver.class);去加载外部实现的驱动类,
    ServiceLoader类会去读取mysql的jdbc.jar下META-INF文件的内容

    而com.mysql.jdbc.Driver继承类如下:

    public class Driver extends com.mysql.cj.jdbc.Driver {
        public Driver() throws SQLException {
            super();
        }
    
        static {
            System.err.println("Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. "
                    + "The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.");
        }
    }
    

    从注释可以看出平常我们使用com.mysql.jdbc.Driver已被丢弃了,取而代之的是com.mysql.cj.jdbc.Driver,
    也就是说官方不再建议我们使用如下代码注册mysql驱动

    //不建议使用该方式注册驱动类
    Class.forName("com.mysql.jdbc.Driver");
    String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
    // 通过java库获取数据库连接
    Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");
    

    而是直接去掉注册步骤,如下即可

    String url = "jdbc:mysql://localhost:3306/cm-storylocker?characterEncoding=UTF-8";
    // 通过java库获取数据库连接
    Connection conn = java.sql.DriverManager.getConnection(url, "root", "root@555");
    

    这样ServiceLoader会帮助我们处理一切,并最终通过load()方法加载,看看load()方法实现

    public static <S> ServiceLoader<S> load(Class<S> service) {
         //通过线程上下文类加载器加载
          ClassLoader cl = Thread.currentThread().getContextClassLoader();
          return ServiceLoader.load(service, cl);
      }
    

    很明显了确实通过线程上下文类加载器加载的,实际上核心包的SPI类对外部实现类的加载都是基于线程上下文类加载器执行的,
    通过这种方式实现了Java核心代码内部去调用外部实现类。我们知道线程上下文类加载器默认情况下就是AppClassLoader,
    那为什么不直接通过getSystemClassLoader()获取类加载器来加载classpath路径下的类的呢?其实是可行的,
    但这种直接使用getSystemClassLoader()方法获取AppClassLoader加载类有一个缺点,那就是代码部署到不同服务时会出现问题,
    如把代码部署到Java Web应用服务或者EJB之类的服务将会出问题,因为这些服务使用的线程上下文类加载器并非AppClassLoader,
    而是Java Web应用服自家的类加载器,类加载器不同。,所以我们应用该少用getSystemClassLoader()。
    总之不同的服务使用的可能默认ClassLoader是不同的,但使用线程上下文类加载器总能获取到与当前程序执行相同的ClassLoader,
    从而避免不必要的问题。ok~.关于线程上下文类加载器暂且聊到这,前面阐述的DriverManager类,大家可以自行看看源码,
    相信会有更多的体会,另外关于ServiceLoader本篇并没有过多的阐述,毕竟我们主题是类加载器,
    但ServiceLoader是个很不错的解耦机制,大家可以自行查阅其相关用法。

    Thread. setContextClassLoader()

    • 上下文加载器
    • 是一个角色
    • 用以解决顶层ClassLoader无法访问底层ClassLoader的类的问题
    • 基本思想是,在顶层ClassLoader中,传入底层ClassLoader的实例

    双亲模式的破坏

    • 双亲模式是默认的模式,但不是必须这么做
    • Tomcat的WebappClassLoader 就会先加载自己的Class,找不到再委托parent
    • OSGi的ClassLoader形成网状结构,根据需要自由加载Class

    参考

    原文

    展开全文
  • 2 Java虚拟机类加载器结构简述 2.1 JVM三种预定义类型类加载器 2.2 加载双亲委派机制介绍和分析 2.3 加载双亲委派示例 3 java程序动态扩展方式 3.1 调用java.lang.Class.forName(…)加载 3.2 用户自定义...
  • 面试必问 Java类加载机制和类加载器

    千次阅读 多人点赞 2020-06-15 18:49:48
    目前,只要是Java的面试,类加载机制一定会被问到。写这篇博客,供小伙伴们参考。
  • java类加载器以及spi

    千次阅读 2018-10-01 14:38:54
    类加载器概述: 每个编写的”.java”拓展名文件都存储着需要执行的程序逻辑,这些”.java”文件经过Java编译器编译成拓展名为”.class”的文件,”.class”文件中保存着Java代码经转换后的虚拟机指令,当需要使用...
  • 深入理解Java类加载器机制

    千次阅读 2018-09-25 10:06:24
    Java里面的类加载机制,可以说是Java虚拟机核心组件之一,掌握和理解JVM虚拟机的架构,将有助于我们站在底层原理的角度上来理解Java语言,这也是为什么我们学习一个新的知识时,如果不理解原理全靠死记硬背,我相信...
  • jvm之java类加载机制和类加载器(ClassLoader)的详解

    万次阅读 多人点赞 2018-08-13 15:05:46
    程序主动使用某个时,如果该还未被加载到内存中,则JVM会通过加载、连接、初始化3个步骤来对该进行初始化。如果没有意外,JVM将会连续完成3个步骤,所以有时也把这个3个步骤统称为类加载初始化。 一...
  • java获取类加载器

    千次阅读 2018-11-07 10:48:04
    获取类加载器的方法: //扩展类加载器Main ClassLoader classLoader = MainTest.class.... //表示当前线程的类加载器——应用程序类加载器 ClassLoader contextClassLoader = Thread.currentThread().getContext...
  • 谈到Java类加载器,大家应该都不陌生。但最近在逛面经分享时看到这样一个问题:“手写一个String能否被类加载器加载?”笔者自己试了下,发现这个问题几乎把类加载器的原理都考了一遍,不信咱们就来碰一碰它。
  • 文章目录1、Java虚拟机的加载机制概述2、Java虚拟机中的类加载器2.1、查看类加载器加载的路径2.1.1、查看启动类加载器2.1.2、查看扩展类加载器3、类加载器之间的关系3.1、每个类加载器都有一个父加载器3.2、父加载...
  • java类加载机制和自定义类加载器

    千次阅读 2018-10-11 14:45:54
    类加载顺序 上图所示的是类加载的顺序,按照大的顺序可以分为加载、链接、初始化 其中链接又可以分成验证、准备、解析三个步骤 加载 1.将的class文件读入到内存中 加载类文件的方式有: 1. 本机文件加载 2.jar包...
  • 虚拟机设计团队把加载阶段中的"通过一个的全限定名来获取描述此类的二进制字节流"这个动作放到Java虚拟机外部去实现, 以便让应用程序自己决定如何去获取所需要的. 实现这个动作的代码模块称为"类加载器".
  • Java 类加载器 什么是Java 类加载器类加载器(class loader)用来加载 Java Java 虚拟机中。 一般来说,Java 虚拟机使用 Java 的方式如下: Java程序(.java 文件)在经过 Java 编译器编译之后就被...
  • 掌握Java类加载器

    2020-03-04 11:18:22
    类加载器Java最强大的特征之一。但是开发者常常忘记加载组件。类加载器是在运行时负责寻找和加载文件的Java允许使用不同的类加载器,甚至自定义的类加载器类加载器从源文件(通常是.class 或 .jar文件)...
  • Java类加载器之间的关系

    千次阅读 2020-01-07 10:55:51
    当 JVM 启动的时候,Java 缺省开始使用如下三种类型的类加载器: 启动(Bootstrap)类加载器:引导类加载器是用 本地代码实现的类加载器,它负责将 <JAVA_HOME>/lib 下面的核心类库 或 -Xbootclasspath 选项...
  • 一、java类加载器机制 jvm想执行.class文件第一...java类加载器的作用是在运行时加载Java类加载机制指的是将java编译后生成的.class文件中的二进制数据读入到内存中,将其放到jvm构造的运行时数据区内存...
  • Java 类加载器壁上打Kong。 该库有助于允许具有由同一 VM 中的不同类加载器加载的相同文件的 Java 对象实例进行通信。 什么时候会出现这种情况,我听到你问? 好问题。 编写此文件的原始情况是一个应用程序,...
  • Java自定义类加载器实现-原理分析

    千次阅读 2019-08-15 22:57:44
    文章目录Java自定义加载为什么要自定义怎么自定义实现自定义类加载器总结   这篇文章主要聊一下如何自定义Java类加载器,关于Java加载机制,可以参考Java加载机制双亲委派模型的文章:...
  • java类加载修改源码皮诺克 Pinoc 是一个新颖的库,用于对 ...为了避免Java类加载器带来的麻烦,Pinoc没有采用Java类加载器来加载和执行对原有方法的替换或修改。 因此,原始方法的替换或修改不是用
  • 可以看到上面这个简单流程就是我们运行java代码的整个过程,首先JVM将java源文件编译成.class字节码文件,然后用类加载器将class文件载入到内存供我们使用。可以看出ClassLoader在其中扮演着非常重要的作用。 2、...
  • 文章目录类加载器一、预定义类型类加载器二、类加载器结构双亲委派模型一、双亲委派模型流程二、双亲委派模型源码自定义类加载器一、类加载器继承关系二、ClassLoader1、构造函数2、核心方法三、自定义类加载器实例...
  • 类加载器一、类加载器的作用二、Java虚拟机类加载器结构1. 引导(启动)加载器2. 扩展类加载器3. 系统类加载器三、类加载器的加载机制1. 全盘负责2. 双亲委派3. 缓存机制四、自定义类加载器 一、类加载器的作用 &...
  • Java类加载机制与Tomcat类加载器架构

    万次阅读 热门讨论 2017-02-26 10:58:11
    Java类加载机制 类加载器 虚拟机设计团队把加载阶段中的“通过一个的全...类加载器可以说是Java语言的一项创新,也是Java语言流行的重要原因之一,它最初是为了满足Java Applet的需求而开发出来的。虽然目前Java A
  • 一、类加载器(Class Loader) ...试想,如果没有双亲委派机制模型而是由各个类加载器自行加载的话,如果用户编写了一个java.lang.Object的同名并放在ClassPath中,多个类加载器都会去加载这个到内存中,系统中将
  • Java三个类加载器

    2020-06-19 16:21:46
    这里写自定义目录标题欢迎使用Markdown编辑新的改变功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、...
  • 1 线程上下文类加载器 2 何时使用Thread.getContextClassLoader()? 3 类加载器与Web容器 4 类加载器与OSGi 总结 1 线程上下文类加载器  线程上下文类加载器(context class loader)是从 JDK 1.2 开始引入的...
  • 从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期包括:加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 481,526
精华内容 192,610
关键字:

java类加载器工作流程

java 订阅