精华内容
下载资源
问答
  • JAVA类加载器

    千次阅读 2018-09-21 18:00:44
    ”.class”文件中保存着Java代码经转换后的虚拟机指令,当需要使用某个时,虚拟机将会加载它的”.class”文件,并创建对应的class对象, 将class文件加载到虚拟机的内存,这个过程称为类加载,这里我们需要了解...

    装载验证流程

    每个编写的”.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

    参考

    原文

    展开全文
  • 深入理解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类加载器(一):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类加载器机制

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

    前言

    Java里面的类加载机制,可以说是Java虚拟机核心组件之一,掌握和理解JVM虚拟机的架构,将有助于我们站在底层原理的角度上来理解Java语言,这也是为什么我们学习一个新的知识时,如果不理解原理全靠死记硬背,我相信过不了几天便会忘记的一干二净。

    Java是一门跨平台的语言,而JVM虚拟机则在这中间扮演了非常重要的角色,对于我们编写的.java文件,在编译期间会被转换成二进制的class文件,我们也叫做bytecode(字节码),那么这些class文件是如何被加载进JVM虚拟机里面,又是如何被执行呢?

    image

    这就引入了今天我们文章要重点分析的知识之Java类加载器,在此之前我们重新来回顾下JVM的执行架构,借用网上的一张图片,可以非常直观的帮助我们了解: image

    Java虚拟机的核心由三个重要的组件构成:

    (1)类加载系统

    (2)运行时数据区域

    (3)执行引擎

    在这里面我们需要重点理解和掌握的包括,类加载机制,运行时数据区域,及执行引擎里面的GC回收器的算法和原理。

    运行时数据区域在前面文章已经介绍过,gc算法和原理打算放下一篇文章单聊,本篇文章我们重点介绍类加载器机制。

    文章开头我们提到过我们写的java源码文件,在编译后会转成二进制的字节码的class文件,如果我们想要使用它们,那么必须通过类加载器加载处理之后才能使用。

    为什么需要类加载器

    从广义的概念上Java语言里面只有两种类加载器:

    (1)Bootstrap CLassloder(引导类加载器)

    (2)User Define Classloader(用户自定义的类加载器)

    引导类加载器是本身就是JVM规范的一部分,它与OS平台有关,依赖于OS的实现方式加载类型(包括Java API的类和接口),所以在Java里面引导类加载器只能是native实现的,尽管它是所有类加载器的父加载器,但它却不是Java实现的,所以Java里面引导加载器返回的是null。

    Java的引导加载器是严格封闭的,因为其作用就是负责加载Java核心的基础库如rt.jar等,这里面就包含了我们常用的java.lang.xxx等相关类,引导类加载的库保证了类型安全,如果你想自定义一个Long类来替换Java基础库的Long类几乎是做不到的。

    而自定义的类加载器机制则提供了非常灵活的扩展机制,允许我们自定义加载器来实现一些特殊的功能。

    为什么需要自定义类加载器?

    这里列举几种场景:

    (1)加密。对字节码加密,Java的类文件可以被很容易反编译,为了提高安全性,我们再编译的时候可以加入加密算法,改变二进制文件的编码,然后在定义专门的来加载器来加载加密后文件,在加载之前解密二进制字节码,在加载,这样就可以提高安全性。

    (2)以非标准的方式加载类文件。 比如我们的类文件存放在数据库,FTP,或者在从某个网站上下载。

    (3)在运行时候动态的去系统外部加载运行一个类。

    (4)在同一个应用中,通过类加载器实现环境或者资源的隔离。

    (5)通过类加载器实现灵活的可插拔机制。

    Java类加载器的双亲委派机制

    从上面可以看到自定义类加载器的强大之处,在我们要实现自定义的类加载器之前,我们需要先了解下Java里面的类加载器是如何加载类的。

    Java里面的ClassLoader类是实现自定义类加载器的关键,ClassLoader类是一个抽象类,其提供了自定义类加载器的通用描述,其主要的子类如下:

    ClassLoader 
    
        SecureClassLoader
        
            URLClassLoader
            
               ExtClassLoader
               
               AppClassLoader
    

    根据Java平台的具体实现,实际的类加载器顺序如下:

    image

    这里大家需要注意一点,类加载器的顺序并不是所谓的继承关系,其实是逻辑组合关系。

    前面提到过引导类加载器是所有加载器的前提,尽管Java语言里面不存在具体的这个类,因为其与操作系统有关,所以是native方法实现。但其却是Java里面所有类加载器名副其实的父加载器,其加载的资源路径是:

    %JAVA_HOME%/jre/lib
    

    接着我们看ExtClassLoader加载器的,加载路径是

    %JAVA_HOME%/jre/lib/ext或者是java.ext.dirs属性里面配置的路径
    

    最后是AppClassLoader加载器,其加载的资源路径是:

    当前的classpath的路径
    

    通过上面的分析,我们能够看到其实类加载器的本质是,加载了什么路径下的资源文件,对于上面的几个类加载的路径,我们可以在Java虚拟机启动类Launcher源码中找到答案:

    其中引导类加载器的路径是:

    System.getProperty("sun.boot.class.path");
    

    ExtClassLoader类加载器的路径是:

    System.getProperty("java.ext.dirs")
    

    最后AppClassLoader类加载器的路径是:

    System.getProperty("java.class.path")
    

    通过下面这个测试方法,就可印证:

        public static void showClassLoaderForeachPath(){
    
            System.out.println();
            //BoostrapClassLoader
            String[] split=System.getProperty("sun.boot.class.path").split(":");
            for(String data:split){
                System.out.println(data);
            }
    
            System.out.println("===================");
            //ExeClassLoader
            String[] split1=System.getProperty("java.ext.dirs").split(":");
            for(String data:split1){
                System.out.println(data);
            }
    
    
    
    
            System.out.println("===================");
            //AppClassLoader
            String[] split2=System.getProperty("java.class.path").split(":");
            for(String data:split2){
                System.out.println(data);
            }
    
            System.out.println("================");
        }
    

    接着我们随便定义一个测试类,看看该类的加载器的情况:

        public static  void showClassLoaderPath(){
    
            System.out.println(ClassLoaderTest.class.getClassLoader());
            System.out.println(ClassLoaderTest.class.getClassLoader().getParent());
            System.out.println(ClassLoaderTest.class.getClassLoader().getParent().getParent());
            System.out.println("------------------------------------");
            System.out.println(int.class.getClassLoader());
            System.out.println(Long.class.getClassLoader());
    
        }
    

    输出结果:

    sun.misc.Launcher$AppClassLoader@511d50c0
    sun.misc.Launcher$ExtClassLoader@5e481248
    null
    ------------------------------------
    null
    null
    

    可以看到我们自定义的类都是由AppClassLoader这个类加载器加载的,而AppClassLoader是谁由加载呢?

    在第二行代码地方能看到是ExtClassLoader加载的,注意这里再次强调类加载器层次非继承关系。

    然后我们接着看ExtClassLoader类加载器的父类,发现输出的是null,这在前面已经说了引导加载器是native实现的,所以在Java里面是访问不到的所以是null。

    到这里,我们的疑问点集中在为什么类加载器非继承关系,因为在上面的类图里面AppClassLoader与ExtClassLoader是平级兄弟关系,那么为什么说AppClassLoader是由ExtClassLoader作为父类加载器呢?

    答案就在源码中,首先看下ClassLoader这个抽象类的构造函数:

        //1 
      protected   ClassLoader() {
            this(checkCreateClassLoader(), getSystemClassLoader());
        }
    
    //2
     protected ClassLoader(ClassLoader parent) {
            this(checkCreateClassLoader(), parent);
        }
    //3
        private ClassLoader(Void unused, ClassLoader parent) {
            this.parent = parent;
            if (ParallelLoaders.isRegistered(this.getClass())) {
                parallelLockMap = new ConcurrentHashMap<>();
                package2certs = new ConcurrentHashMap<>();
                domains =
                    Collections.synchronizedSet(new HashSet<ProtectionDomain>());
                assertionLock = new Object();
            } else {
                // no finer-grained lock; lock on the classloader instance
                parallelLockMap = null;
                package2certs = new Hashtable<>();
                domains = new HashSet<>();
                assertionLock = this;
            }
        }
        
        
    

    我们发现无参和一参的构造函数都是调用二参构造函数,二参构造函数的第二个参数恰恰就是指定的父类加载器,如果使用的是无参构造函数,默认调用是:

       public static ClassLoader getSystemClassLoader() {
            initSystemClassLoader();
            if (scl == null) {
                return null;
            }
            SecurityManager sm = System.getSecurityManager();
            if (sm != null) {
                checkClassLoaderPermission(scl, Reflection.getCallerClass());
            }
            return scl;
        }
    

    接着看initSystemClassLoader这个方法,这个方法里面有个关键的地方在于调用了sun.misc.Launcher之后,从这个类里面获取了ClassLoader实例:

       sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
                if (l != null) {
                    Throwable oops = null;
                    scl = l.getClassLoader();
                    }
    

    接着我们看下Launcher类的构造方法时如何定义的:

        public Launcher() {
            Launcher.ExtClassLoader var1;
            try {
                //1
                var1 = Launcher.ExtClassLoader.getExtClassLoader();
            } catch (IOException var10) {
                throw new InternalError("Could not create extension class loader", var10);
            }
    
            try {
               //2
                this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
            } catch (IOException var9) {
                throw new InternalError("Could not create application class loader", var9);
            }
            
            
            //........
            }
    
    

    重点看第二个地方,设置AppClassLoader的父加载器是ExtClassLoader,而ExtClassLoader没有设置,取系统的初始值就是null,此外在赋值完毕之后又把AppClassLoader的实例,赋值了给所有默认的其他自定义的类加载器的父加载器,所以如果我们自定义了一个类加载器,那么它的父加载器如果不指定就是AppClassLoader。

    ClassLoader类有几个重要的方法如下:

    
    loadClass() 使用双亲委托加载类的方法 .
    
    defineClass()  将一个字节流转成Class类实例 .
    
    findClass()  从加载器路径搜寻需要处理的类.
    
    findLoadedClass() 查询某个类是否已经被加载过.
    
    getResourceAsStream() 读取一个资源文件转成InputStream
    

    知道了类加载器的层级关系和其主要的方法,那么当我们加载一个类的时候类加载器是如何工作的呢?

    重点在于ClassLoader类的loadClass方法,我们看下其源码:

      public Class<?> loadClass(String name) throws ClassNotFoundException {
            return loadClass(name, false);
        }
    

    调用了重载的方法:

       protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
        {
            进行加锁,防止并发.
            synchronized (getClassLoadingLock(name)) {
                先判断该类是否已经加载过,如果已经加载直接返回.
                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
                        // to find the class.
                        long t1 = System.nanoTime();
                        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;
            }
        }
    

    总结一下:

    (1)自定义类加载器或者当前的类加载器先判断该类是否已经加载过,如果加载过 直接返回,否则就委托父加载器进行加载。

    (2)父加载器重复(1)步骤,先判断是否加载过,如果加载过直接返回 否则,继续递归重复(1)步骤

    (3)如果父加载器为null,那么会委托引导类加载器进行查询,如果已经加载过,那么直接返回,否则就在当前类加载器的路径下面查询,如果仍然找不到就返回上一级,上一级也就执行同样的步骤。

    (4)最终都没有找到,会在自定义的类加载器路径下面查找,如果找到了就返回,否则就抛出相关的类找不到异常。

    整个查询流程如下,借用网友的一张图非常清晰:

    image

    从上面可以看到,委托动作从下到上,而查询动作则从上到下,当然这里面有一层优化,就是从下到上的时会先判断该类是否已经被加载过,如果加载过就直接返回,没必要继续向上委托,这就是经典的双亲委托模型。

    双亲委托的模型的意义与破坏

    首先双亲委托模型并不是强制约束,而是 Java设计者推荐给开发者的类加载器实现方式,在Java 的世界中大部分的类加载器都遵循这个模型。双亲委派模型对于保证Java程序的安全稳定运作很重要,其最大的意义就在于提升了Java平台运行的安全稳定性,为什么这么说?

    因为双亲委托模型使得Java类随着它的类加载器一起具备了带有优先级的层次关系,在加载一个类的时候,如果准守这个模型,那么必定会先从处于模型最顶端的引导类加载器查询加载,因此就能保证对于一些基础类如Object,在不同的类加载器环境中使用的都是同一个类,但如果没有这个模型,比如黑客定义了一个Object类,或者说你自己定义了多个Object类,那么在使用时候会加载多份,那系统中将会出现多个不同的Object类,Java 类型体系中最基础的行为也就无法保证,应用程序也将会变得一片混乱和非常不安全。

    如何打破双亲委托模型?

    在具体实现的时候,是可以选择准守双亲模型或者不准守,如果选择准守就尽量不要动loadClass方法的逻辑,而只需要重写findClass方法即可,但如果继承了ClassLoader类,并重写了loadClass的委托逻辑,不再是像上委托查询,改为其他任何的查询加载模式,那么这种行为就能破坏双亲委托模型。

    你说你想自定义一个java.lang.String类?那么能不能做到? 答案是可以的,但不推荐这么干,通过自定义一个类加载器,然后破坏双亲委托模型,最后在重写defineClass方法(在这个native方法里面也有检查限制),绕过Java语言的各种限制,是可以达到目标的,但其实这里面存在很大安全隐患的,对于java开头的包里面的基础数据类型是没有任何理由去破坏的,这种行为属于破坏双亲委托模型的最顶级行为。尽管他们的包名和类名都一样,但自定义类加载器的String类与JVM内置的String类仍然是不相等的,因为他们属于不同的类加载器加载的。

    上面说的是顶级的破坏案例,当然还有一些是因为双亲委派模型自身的不足导致的。

    在双亲委派模式下:

    ClassLoader A -> App class loader -> Extension class loader -> Bootstrap class loader
    

    最左边的类也就是最底层的类,可以访问到顶层的类加载的类,但是反过来却不行,但在实际开发情况下,可能会遇到,顶级的加载器需要回调低级加载器加载的实现类。为了克服这个问题,双亲委派模型中又引入了ThreadContextClassLoader,可以通过Thread的setContextClassLoader和getContextClassLoader获取底层的加载器,从而通过底层加载器来加载该类来避免这个问题。

    举个常见的例子: Java里面的SPI机制,或者java.sql的驱动实例化的例子,他们的核心接口都是由Java的引导类加载器加载的,但是他们的实现却是各个厂商提供的或者根据约定设置的,这种情况下引导类加载器是看不到底层加载器的(classpath)的类的,所以只能通过底层加载器本身来加载,这个时候相当于顶层加载器需要使用底层加载器加载的类,从而间接的破坏了双亲委托模型,相当于走了后门。

    另外一种破坏双亲委托模型的例子是热加载模式,为了解决不停机或者不停服务更新应用,典型的应用场景是在OSGI里面,默认情况下对于已经加载的类双亲委派模型是不会重新再加载的,但这样就意味着更新了不会被及时感知,如果需要做到动态更新,那么对于已经加载的类也必须再次进行加载,并且要处理好旧实例与新实例状态数据拷贝问题,这种模式也是破坏了双亲委派机制。

    最后我们再思考一个问题,为什么默认情况下java的类加载系统分为3级?

    这3个类加载器在前面已经看到过,分别是引导类,扩展类,应用类加载器,简单的说这么设计的目的是为了安全性,这三层分级分别代表了不同的信任程度,比如Java的核心包安全级别最高,其次是ext扩展包,最后是应用级别的类。前面说过,如果你在应用级别定义了一个java开头的包类型,那么通常情况是不会生效的,即使它可以编译通过,java的双亲委派模型会做各种检查,防止各种试图替换其核心的数据类型的动作。

    类加载系统的阶段流程与类的生命周期

    前面写了很多,其实大部分都是关于双亲委派模型本身的利弊或者意义,按照一个类的完整的生命周期,大概分为下面几个阶段:

    (1) 初始化阶段

    在生命周期的开始阶段又分三个过程分别是load,link,initialize

    image

    (2) 中期阶段

    在生命周期的中间阶段包括对象实例化,垃圾收集和终结的过程

    (3) 销毁阶段

    在生命周期的尾部阶段,也就是虚拟机退出时类需要被unload卸载。

    按照上面的几个阶段,我们刚才仅仅介绍了初始化阶段的load过程,

    load过程可以简单认为是通过指定类的全限定名,将磁盘上或者任意位置上二进制的class文件解析成了java的内部的数据结构并存储在了堆内存中的方法区,之后又创建了Class类的实例来代表该类型。

    然后是link步骤,这个过程又分为3个子不走,首先通过verify检验class文件的格式是否符合JVM实现规范,然后在prepare步骤,会给类的静态字段赋默认值,并分配内存空间,这个步骤并不会执行任何Java代码,仅仅给静态字段赋默认值。resolve步骤是可选的,这一步会将类里面的符号引用替换为真实引用。当然这个步骤也可以延迟触发,在实例化之后程序真正引用时再执行也是可以的。举个例子:

    class X
    {
        static{   System.out.println("init class X..."); }
    
        int foo(){ return 1; }
    
        Y bar(){ return new Y(); }
    }
    

    X类引用了Y,如果relove=true,那么在X类里面出现的所有引用都会被load,如果relove=false,那么Y类不会在这个时候被load,而是会等到真正用到的时候才会被load,这算是一种延迟加载的策略。

    最后到初始化阶段initialize对应的jvm底层调用的clinit指令,这个时候会执行静态块以及对静态字段赋值我们指定的默认值。

    当第一次使用某个类的时候,才会触发某个类的初始化行为,这里有六种情况:

    (1)有new操作符出现的时候,或者隐式的条件,包括反射,克隆,反序列化等。

    (2)调用了类的静态方法

    (3)使用了某个类的通过static修饰的类,字段或者接口(final除外,因为final语句是编译时常量,其初始化在编译时就确定了)

    (4)通过反射调用类里面的相关方法

    (5)子类初始化会触发父类初始化

    (6)执行了类本身的main方法

    对于load,link,initalize的顺序,必须是顺序的,也就是或一个类要被初始化,那么它必须被link,如果一个类想要被link,那么它必须先被load。

    类加载器对于加载过的类会缓存起来,如果在load期间出现了异常或者问题并不会主动抛出,必须得等到该类第一次使用的时候才会抛出,假如这个类永远没有被使用,那么这个异常也永远不会发生。

    前面这些步骤分析完仅仅是代表这个类已经具备了使用的条件,开始阶段已经准备完毕,下面是使用阶段:

    这个阶段主要是类的实例化和实例的初始化,实例化一个类通常有下面几种方法,使用new创建,反射newInstance创建,cone创建,还有getObject的deserializing创建,在调用了实例化之后,底层其实调用的是init指令,会先对成员变量赋值,执行构造块,最后才执行构造函数。

    我们在应用程序中,可以给对象分配内存,但是却不能显式的回收内存,这一工作就是通常由JVM的垃圾回收器来回收利用,在回收内存时,我们可以通过对象的finalize方法来做一些善后工作,对于回收掉的对象仍然是可以再次使用的,这一点需要注意。

    最后关于类的卸载阶段,我们也需要简单了解一下,因为加载的类和接口是需要占用内存资源的,如果无限制的存放,那么必然会耗尽程序的内存,所以有必要对不用的对象进行回收,通常情况下由引导类加载器加载的对象和类是不会被回收的,因为这些是Java程序运行的基础,通常需要回收的是由AppClassLoader或者我们自定义的类加载器加载的类和对象,那么如何回收? 背后还是GC垃圾回收器的功劳,简单的说这个类没有显式的应用或者不存在可达路径的时候就认为这个资源无效了,这个时候就可以卸载该类来回收资源。

    学完上面这些知识, 我们再来看一个问题,下面这两种写法有什么区别?

    Class.forName("SomeClass"); 
    
    ClassLoader.getSystemClassLoader().loadClass("SomeClass");
    

    第一种使用的是反射了一个类,第二种是使用类加载器加载了一个类。

    反射的底层执行方法是:

    Class.forName(className, true, currentLoader)
    

    第二个方法代表要不要初始化该类的静态变量和执行静态块。

    而类加载器的loadClass方法底层执行的是:

    loadClass(name, false)
    

    第二个参数与初始化无关,仅仅是加载的时候是否需要执行relove解析符号引用为直接引用。

    所以使用反射的话默认是执行了类加载器初始化阶段的三个步骤包括load,link,initialize。

    而直接使用ClassLoader.loadClass()方法仅仅是执行类加载器初始化阶段的两个步骤包括load,link,但是并没有执行intialize步骤,这一点需要注意。

    典型的例子就是使用JDBC驱动的时候, 我们是通过反射初始化的。如果是通过类加载器加载的类是没有初始化的。

    关于类的初始化顺序

    掌握了类的加载机制之后,我们再来理解Java类的初始化顺序就非常简单了,如果一个子类继承了父类,在实例化子类的时候,整个顺序如下:

    父类静态块.
    子类静态块.
    父类成员变量初始化.
    父类构造块. 
    父类构造函数. 
    子类成员变量初始化.
    子类构造块.
    子类构造函数.
    

    感兴趣的朋友可以自行验证,这里我就不再粘贴代码了,如果需要可以到我的github上下载。

    总结

    本文主要介绍了Java类加载器的相关知识,并深入的分析了双亲委派机制的特点,意义,以及它的不足和如何破坏双亲委派模型,此外还详细分析了类的整个生命周期所经历的步骤,最后介绍了使用反射加载类和类加载器加载类的不同之处,掌握类的加载机制对于理解Java语言有很大的帮助,是每一位Java开发者进阶的必经之路。

    参考资料:

    https://blog.csdn.net/briblue/article/details/54973413

    https://www.artima.com/insidejvm/ed2/lifetype6.html

    https://javatutorial.net/jvm-explained

    https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.1

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

    千次阅读 2017-03-07 11:29:24
    引子Android插件化与热...Java中的类加载器Java灵活性和动态性的原因Java源代码被编译器编译成字节码,即从.java文件编译为.class文件,而.class文件就是通过类加载器加载到虚拟机内存中的。虚拟机的加载(Class Lo
  • Java类加载器

    千次阅读 2018-09-14 19:10:56
    Java虚拟机的角度来讲,只存在两种不同的类加载器: 一种是启动类加载器(Eootstrap ClassLoader), 这个类加载器使用 C++语言实现,是虚拟机自身的一部分;另外一种就是所有其他的类加载器, 这些类加载器都由Java语言...
  • 2 Java虚拟机类加载器结构简述 2.1 JVM三种预定义类型类加载器 2.2 加载双亲委派机制介绍和分析 2.3 加载双亲委派示例 3 java程序动态扩展方式 3.1 调用java.lang.Class.forName(…)加载 3.2 用户自定义...
  • Java类加载器之间的关系

    千次阅读 2020-01-07 10:55:51
    当 JVM 启动的时候,Java 缺省开始使用如下三种类型的类加载器: 启动(Bootstrap)类加载器:引导类加载器是用 本地代码实现的类加载器,它负责将 <JAVA_HOME>/lib 下面的核心类库 或 -Xbootclasspath 选项...
  • 文章目录类加载器一、预定义类型类加载器二、类加载器结构双亲委派模型一、双亲委派模型流程二、双亲委派模型源码自定义类加载器一、类加载器继承关系二、ClassLoader1、构造函数2、核心方法三、自定义类加载器实例...
  • 我们把每个模块的Jar里面的加载到一个内存map,然后再创建一个自定义类加载器,重写loadClass方法,当加载时候优先在内存map里面查找,如果存在则直接返回,否则调用默认加载方法.工程结构图如下: 将demo_...
  • java 类加载器

    万次阅读 2017-06-23 18:09:13
    顾名思义,类加载器(class loader)用来加载 Java Java 虚拟机中。 具体的说就是:Java源程序(.java 文件)在经过Java 编译器编译之后就被转换成 Java 字节代码(.class文件)。类加载器负责读取 Java字节代码...
  • Java类加载器与双亲委派模式的详解

    千次阅读 2018-08-03 10:04:20
    类加载器(ClassLoader)是Java语言的一项创新,也是Java流行的一个重要原因。在加载的第一阶段“加载”过程中,需要通过一个的全限定名来获取定义此类的二进制字节流,完成这个动作的代码块就是类加载器。这一...
  • 深入理解(3)Java类加载器(ClassLoader)

    万次阅读 2019-05-01 10:33:58
    类加载的机制的层次结构 ...这些”.java”文件经过Java编译器编译成拓展名为”.class”的文件,”.class”文件中保存着Java代码经转换后的虚拟机指令,当需要使用某个时,虚拟机将会加载它的”.cl...
  • Java类加载器与反射

    千次阅读 2016-05-03 15:16:11
    一个命令对应一个进程 当我们启动一个Java程序,即启动一...而两个mian方法,对应的是2个JVM进程,启动的是两个不同的类加载器,操作的实际上是不同的。故而不会互相影响。 加载 当我们使用一个,如果这个还未
  • Java 类加载器揭秘

    千次阅读 2018-03-13 00:00:00
    本文来自作者 加多 在 GitChat 上分享 「Java 类加载器揭秘」编辑 | 哈比什么是 ClassLoaderJava 代码要想运行,首先需要将源代码进行编译生成 .class 文件,然后 JVM 加载 .class 字节码文件到内存,而 .class ...
  • java类加载器以及spi

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

    万次阅读 热门讨论 2021-07-13 11:35:28
    JVM类加载器 JVM主要有以下几种类加载器: 引导类加载器 主要加载JVM运行核心类库,位于JRE的lib目录下,如rt.jar中的。 扩展类加载器 主要加载JVM中扩展,位于JRE的ext目录下。 应用程序类加载器 主要负责加载...
  • java 类加载器加载顺序 经典例子

    千次阅读 2017-06-02 10:36:23
    写了一个string ,和api中包名,类名都是一样的,然后去加载: 1 package java.lang; 2 public class String{ 3 public static void main(String[] args ){ 4 } 5 }  大家发现什么不同了吗?对了,我们写...
  • java类加载器是什么?

    万次阅读 多人点赞 2019-07-30 15:23:10
    答:顾名思义,类加载器(class loader)用来加载 Java Java 虚拟机中。一般来说,Java 虚拟机使用 Java 的方式如下:Java 源程序(.java 文件)在经过 Java 编译器编译之后就被转换成 Java 字节代码(.class...
  •   在深入openjdk源码全面理解Java类加载器(上 – JVM源码篇) 我们分析了JVM是如何启动,并且初始化BootStrapClassLoader的,也提到了sun.misc.Launcher被加载后会创建ExtClassLoader和AppClassLoader。这篇文章...
  • 可以看到上面这个简单流程就是我们运行java代码的整个过程,首先JVM将java源文件编译成.class字节码文件,然后用类加载器将class文件载入到内存供我们使用。可以看出ClassLoader在其中扮演着非常重要的作用。 2、...
  • 面试必问 Java类加载机制和类加载器

    千次阅读 多人点赞 2020-06-15 18:49:48
    目前,只要是Java的面试,类加载机制一定会被问到。写这篇博客,供小伙伴们参考。
  • 一、类加载器(Class Loader) ...试想,如果没有双亲委派机制模型而是由各个类加载器自行加载的话,如果用户编写了一个java.lang.Object的同名并放在ClassPath中,多个类加载器都会去加载这个到内存中,系统中将
  • jvm之java类加载机制和类加载器(ClassLoader)的详解

    万次阅读 多人点赞 2018-08-13 15:05:46
    当程序主动使用某个时,如果该还未被加载到内存中,则JVM会通过加载、连接、初始化3个步骤来对该进行初始化。如果没有意外,JVM将会连续完成3个步骤,所以有时也把这个3个步骤统称为类加载初始化。 一...
  • Tomcat容器,每个WebApp有自己的ClassLoader,加载每个WebApp的ClassPath路径上的,一旦遇到Tomcat自带的Jar包就委托给CommonClassLoader加载; 对于公司的一些核心类库,可能会把字节码加密,这样加载类的时候就...
  • 1 线程上下文类加载器 2 何时使用Thread.getContextClassLoader()? 3 类加载器与Web容器 4 类加载器与OSGi 总结 1 线程上下文类加载器  线程上下文类加载器(context class loader)是从 JDK 1.2 开始引入的...
  • Java类加载器(自定义类加载器

    千次阅读 2016-03-03 15:42:52
    为什么要有类加载器我们知道java中所有的二进制文件,最后都是要放在jvm中解释运行的。纯粹的二进制文件,其实并没有什么卵用。jvm在第一次使用或者预加载时,都要将某个的二进制文件加载进去,这时候不可避免的...
  • 深入探讨Java 类加载器

    千次阅读 2015-07-26 16:59:54
    类加载器(class loader)用来加载 Java Java 虚拟机中。一般来说,Java 虚拟机使用 Java 的方式如下:Java 源程序(.java 文件)在经过 Java 编译器编译之后就被转换成 Java 字节代码(.class 文件)。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 667,050
精华内容 266,820
关键字:

java类加载器

java 订阅