类加载器

1.类加载器概述

类加载就是将磁盘上的class文件加载到内存中。虚拟机设计团队把类加载阶段的"通过一个类的全限定名获取描述此类的二进制字节流"这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为"类加载器"。类加载器是JVM执行类加载机制的前提。

ClassLoader的作用

1
2
3

# ClassLoader的作用
ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进行加载的。
ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部，转换为一个于目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader去改变类的链接和初始化行为。至于他是否可以运行，则由Execution Engine决定。

# Class、ClassLoader和实例对象的关系
在下图中：
类模板数据User Class 和ClassLoader之间是相互引用的关系。
在ClassLoader中，记录了加载类的集合，有那些类是由这个ClassLoader加载的。
我们可以通过Class创建实例对象

类加载的命名空间

# 何为类的唯一性
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。

每一个类加载器，都会拥有一个独立的类名称空间:
比较两个类是否相等，只有在这两个类是由同一类加载器加载的前提下才有意义。
否则即使这两个类源自同一Class文件，被同一个虚拟机加载，只要加载他们类加载器不同，那这两个类就必定不相等。

# 命名空间
- 每一个类加载器都有自己命名空间，命名空间由该加载器及所有的父加载器锁加载的类组成。
- 在同一命名空间中，不会出现类的完整名字(包括类的包名)相同的两个类，只加载一次类。
- 在不同的命名空间中，有可能会出现类的完整名字(包括类的包名)相同的两个类，可以加载多次。

类加载机制的特征

双亲委派机制

1	`双亲委派模型，不是所有的类加载都遵守这个模型。`

可见性

1	`子类加载器可以访问父加载器加载的类型，但是反过来是不允许的。`

单一性

1
2

由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载。
但是，类加载器"邻居"间，同一类型仍然可以被加载多次，因为互相并不可见。

2.类加载分类

JVM支持两种类型的类加载器，分别是启动类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined ClassLoader)。

从概念上讲，自定义类加载器一般指的是程序中由开发人员自定义的一类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分，在程序中我们最常见的类加载结构主要是如下情况:

除了顶层的启动类加载器，其余的类加载应当有自己的”父类“加载器。
不同类加载看似是继承关系，实际上是包含关系。在下层加载器中，包含上层加载器的引用

class ClassLoader{
    ClassLoader parent;
    
    public ClassLoader(ClassLoader parent){
        this.parent = parent;
    }
    
}

class ParentClassLoader extends ClassLoader{
    public ParentClassLoader(ClassLoader parent){
        super(parent);
    }
}

class ChildClassLoader extends ClassLoader{
    public ChildClassLoader(ClassLoader parent){
        super(parent);
    }
}

启动类加载器

这个类加载使用C/C++语言实现，嵌套在JVM内部。
用来加载Java核心库(JAVA_HOME/jre/lib/rt.jar或sun.boot.class.path路径下的内容)，用于提供JVM自身需要的类。
并不继承自java.lang.ClassLoader，没有所谓的父加载器
出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
启动类加载器还用于去加载扩展类加载器和应用程序类加载器，并指定为他们的父类加载器。

我们去加载这个一个类，去看一下它的ClassLoader

public class Test {
    public static void main(String[] args) {
    }
}

加载ClassLoader

加载自定义类加载器

public class Test {
    public static void main(String[] args) {
        ClassLoader classLoader = Provider.class.getClassLoader();
        System.out.println(classLoader);//null
    }
}

扩展类加载器

有Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
继承于ClassLoader类
父类加载器为启动类加载器
从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录下加载类库。如果用户创建的jar放在目录下，也会自动有扩展类加载器加载。

public class Test {
    public static void main(String[] args) {
        ClassLoader classLoader = SunEC.class.getClassLoader();
        System.out.println(classLoader);   
        System.out.println(classLoader.getParent());
    }
}

系统类加载器

Java语言编写，由sun.misc.Launcher$AppClassLoader实现
继承于ClassLoader类
父类加载器为启动类加载器
它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
应用程序中的类加载器默认是系统类加载器。
它是用户自定义类加载器的默认父加载器。
通过ClassLoader的getSystemClassLoader()方法可以获取到该类加载器。

public class Test {
    public static void main(String[] args) {
        ClassLoader classLoader = Test.class.getClassLoader();
        System.out.println(classLoader);
        ClassLoader loader = classLoader;
        while(loader != null){
            System.out.println(loader.getParent());
            loader = loader.getParent();
        }
    }
}

用户自定义加载器

3. ClassLoader源码分析

public abstract class ClassLoader {

    private static native void registerNatives();
    static {
        registerNatives();
    }

	//该类的父类加载器
    private final ClassLoader parent;

   
	//加载名称为name的类，返回结果为java.lang.Class类的实例。
    //该方法时双亲委派机制的实现。下文详细解析
    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException{
    }
    
    //根据名称读取文件存入字节数组
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }

 
	//查找二进制名称为name的类，返回结果为java.lang.Class实例。这是一个受保护的方法，
    //jvm鼓励我们重写此方法，需要自定义加载器遵循双亲委派机制，该方法会在检查完父类加载器之后被loadClass()方法调用。
    
    //转换从Byte到类的实例
    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;
    }

    //返回父类加载器进行委派
    @CallerSensitive
    public final ClassLoader getParent() {
        if (parent == null)
            return null;
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            checkClassLoaderPermission(parent, Reflection.getCallerClass());
        }
        return parent;
    }
}

4. 双亲委派模型

类加载器用来把来加载到Java虚拟机中，从jdk1.2开始，类加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。

什么是双亲委派模型

如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个类请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。

实质上:规定了类加载的顺序是:引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

双亲委派机制的优势和劣势

优势：

避免了类的重复加载，确保一个类的全局唯一性

Java类随着它的类加载器一起具备了一种带有优先级的层级关系，通过这种层级关系可以避免类的重复加载，当父加载器已经加载了该类时，就没有必要子加载器再加载一次。
保护程序安全，防止核心API被随意篡改。

源码解释：

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) {
                    //如果不是，调用父类加载器的loadClass()
                    c = parent.loadClass(name, false);
                } else {
                    //如果为空，让引导类加载器进行加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
            }

            //如果还是为空，调用findClass()进行加载
            //最终会调用defineClass系列的native接口加载目标类。
            if (c == null) {
                long t1 = System.nanoTime();
                c = findClass(name);

                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

//双亲委派模型就隐藏在第2步和第3步上
1. 先在当前加载器的缓存中查找有无目标类，如果有，直接返回。
2. 判断当前加载器的父加载器是否为空，如果不为空，调用parent.loadClass(name,false)
3. 如果为空，调用引导类加载器加载
4. 如果还没有加载成功，调用findClass(name)接口进行加载，最终会调用defineClass加载目标类

# 问题
如果在自定义的类加载中重写java.lang.ClassLoader.loadClass(String)或java.lang.ClassLoader.loadClass(String,boolean)方法，
抹去其中的双亲委派机制，仅保留上面的第一步和第四步，是不是就能够加载类库了?

不行，因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器，最终都必须调用java.lang.ClassLoader.defineClass(String,byte[],int,int,ProtectDomain)方法，
而该方法会执行preDefineClass()接口，该接口中提供了对JDK核心类库的保护。

劣势

顶层的ClassLoader无法访问到底层的ClassLoader所加载的类

总结

Java虚拟机规范并没有明确要求类加载的加载机制一定要使用双亲委派机制，只是建议采用这种方式而已。

在Tomcat中，类加载器所采用的加载机制和传统的双亲委派机制有一定的区别，当缺省的类加载器接受到一个类的加载任务时，首先会由它自行加载，当他加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

#Java #JVM

类加载器

https://johnjoyjzw.github.io/2021/02/05/类加载器/

Author

John Joy

Posted on

February 5, 2021

Licensed under

垃圾回收机制 Previous

类加载机制 Next