JVM系列(6)——类加载器详解&&双亲委派

一、类加载器

类加载器是一个负责加载类的对象,用于实现类加载过程中的加载这一步。
主要作用就是加载 Java 类的字节码( .class 文件)到 JVM 中(在内存中生成一个代表该类的 Class 对象)。
加载过程可以看 JVM系列(5)——类加载过程。
类加载器有四种:
1、BootstrapClassLoader(启动类加载器): 最顶层的加载类,由 C++实现,主要用来加载 JDK 内部的核心类库( jre/lib/rt.jar)以及被 -Xbootclasspath参数指定的路径下的所有类。
2、ExtensionClassLoader(扩展类加载器): 平台类加载器,负责加载扩展jar包,比如XMl, 加密,压缩相关的功能类,主要位于jre/lib/ext/
.jar。
3、AppClassLoader(应用程序类加载器):面向我们用户的加载器,负责加载当前应用 classpath 下的所有 jar 包和类。
4、自定义加载器: 用户可自定义加载器,模板方法模式,后面细讲。

二、双亲委派模型

直接上图:
JVM系列(6)——类加载器详解&&双亲委派_第1张图片
注意的是,虽然上层的叫父加载器,但不是父子继承关系,是组合关系。
类加载的过程如图所示:
JVM系列(6)——类加载器详解&&双亲委派_第2张图片
我们用代码演示一下加载器:

  public static void main(String[] args) {
        System.out.println(String.class.getClassLoader());
        System.out.println(com.sun.java.accessibility.AccessBridge.class.getClassLoader());
        System.out.println(com.alibaba.fastjson.asm.ByteVector.class.getClassLoader());
        System.out.println(ClassLoaderTest.class.getClassLoader());
    }

JVM系列(6)——类加载器详解&&双亲委派_第3张图片

三、Classloader源码解析

sun.misc.Launcher类是java 虚拟机的入口,在启动 java应用 的时候会首先创建Launcher。在初始化Launcher对象的时候会创建一个ExtClassLoader拓展程序加载器 和 AppClassLoader应用程序类加载器,然后由这俩类加载器去加载应用程序中需要的各种类。
构造方法如下:

public Launcher() {
        Launcher.ExtClassLoader var1;
        try {
        	//创建一个ExtClassLoader
            var1 = Launcher.ExtClassLoader.getExtClassLoader();
        } catch (IOException var10) {
            throw new InternalError("Could not create extension class loader", var10);
        }

        try {
        	//创建一个AppClassLoader
            this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
        } catch (IOException var9) {
            throw new InternalError("Could not create application class loader", var9);
        }

       ...

AppClassloader源码如下:

 static class AppClassLoader extends URLClassLoader { 
        public Class<?> loadClass(String var1, boolean var2) throws ClassNotFoundException {
            // ...
            //读取路径为"java.class.path"
             final String var1 = System.getProperty("java.class.path");
             //...
            // 调用了一个 native 本地方法 knownToNotExist(),去查找该类的加载记录
            if (this.ucp.knownToNotExist(var1)) {        // 如果有该类加载记录
                Class var5 = this.findLoadedClass(var1); // 直接去已经加载的类中找
                if (var5 != null) {
                    if (var2) {
                        this.resolveClass(var5);
                    }
                    return var5;
                } else {                                 // 如果没找到报异常
                    throw new ClassNotFoundException(var1);
                }
            } else {                                     // 如果没有该类的加载记录
                return super.loadClass(var1, var2);      // 调用父类 ClassLoader 的 loadClass()
            }
        }
}

ExtClassLoader源码其中一段如下:

  //读取路径为"java.ext.dirs"
 String var0 = System.getProperty("java.ext.dirs");

ExtClassLoader 并没有对 loadClass() 方法进行重写,也就是说它直接调用其父类 ClassLoader 的 loadClass() 方法。
AppClassLoader 和ExtClassLoader 都继承了URLClassLoader 继承 SecureClassLoader 继承 ClassLoader。
ClassLoader源码如下:

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
    	 加载一个类的时候,锁住对应的类加载器对象
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            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;
        }
    }

由上面代码可以看出,双亲委派模型主要是由loadClass这个方法决定的。
而不管是App还是Exe加载器,都继承了ClassLoader类,应用了其中的loadClass这个方法,这个模式是什么呢?
没错,就是模板方法模式,也因此,我们可以很简单的自定义类加载器。

四、自定义类加载器

要自定义自己的类加载器,很明显需要继承 ClassLoader抽象类。而jvm官方的API 文档中写到:

建议 ClassLoader的子类重写 findClass(String name)方法而不是loadClass(String name, boolean resolve) 方法。

如果我们不想打破双亲委派模型,就重写 ClassLoader 类中的 findClass() 方法即可,无法被父类加载器加载的类最终会通过这个方法被加载。但是,如果想打破双亲委派模型则需要重写 loadClass() 方法。
findclass()源码如下:

    protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }

可以看出,留着就是给我们重写的。哈哈哈哈哈哈哈哈
自定义类加载器代码如下,主要是将class文件转成二进制流,并且返回一个Class对象

@Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // IO流读取字节码文件为二进制流
        try (BufferedInputStream bis = new BufferedInputStream((new FileInputStream("home/app/" + ".class")));
             ByteArrayOutputStream bos = new ByteArrayOutputStream()) {
            int len;
            byte[] bytes = new byte[1024];
            while ((len = bis.read(bytes)) != -1) {
                bos.write(bytes, 0, len);
            }
            bos.flush();
            bytes = bos.toByteArray();
            return defineClass(null,bytes,0,bytes.length);
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }

defineClass方法也是ClassLoader的方法,源码如下:

    @Deprecated
    protected final Class<?> defineClass(byte[] b, int off, int len)
        throws ClassFormatError
    {
        return defineClass(null, b, off, len, null);
    }
    ...
    protected final Class<?> defineClass(String name, byte[] b, int off, int len,
                                         ProtectionDomain protectionDomain)
        throws ClassFormatError
    {
        protectionDomain = preDefineClass(name, protectionDomain);
        String source = defineClassSourceLocation(protectionDomain);
        Class<?> c = defineClass1(name, b, off, len, protectionDomain, source);
        postDefineClass(c, protectionDomain);
        return c;
    }

话锋一转,打破双亲委派模型,在哪里用到了呢?

Tomcat 服务器为了能够优先加载 Web 应用目录下的类,然后再加载其他目录下的类,就自定义了类加载器WebAppClassLoader 来打破双亲委托机制。这也是 Tomcat 下 Web 应用之间的类实现隔离的具体原理。

五、双亲委派模型好处

为什么要用双亲委派模型呢?
1、安全;
举个例子:你自定义了一个String类,在这个String类里做一下泄露用户信息的操作,用户在使用你的程序时,只要用到了String类,必然会触发泄露信息,造成极大的信息安全。
2、避免资源浪费。
这个简单,类不要重复加载了,省资源。

六、总结

1、双亲委派模型:自下而上寻找,自上而下派任务去解析。
2、类加载器是模板方法模式,重写indClass() 方法自定义类加载器,重写loadClass() 打破双亲委派模型。
3、双亲委派模型安全、节省资源。

你可能感兴趣的:(jvm,java,jvm)