JVM篇-类加载器

最新推荐文章于 2024-06-25 11:36:59 发布

Spring是框架不是春天

最新推荐文章于 2024-06-25 11:36:59 发布

阅读量108

点赞数

分类专栏： Java Java架构师沿途风景文章标签： jvm java

本文链接：https://blog.csdn.net/u012667477/article/details/112745662

版权

Java 同时被 2 个专栏收录

29 篇文章 1 订阅

订阅专栏

Java架构师沿途风景

19 篇文章 1 订阅

订阅专栏

上文提到类加载过程阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类，实现这个动作的代码模块就是类加载器。

类与类加载器

任意一个类。都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机的唯一性，每一个类加载器都拥有一个独立的类名称空间。即使两个类来源于同一个class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等。

不同类加载器对instanceof的影响

类加载器

启动类加载器（Bootstrap ClassLoader）：使用C++语言实现（大名鼎鼎的HotSpot）。将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库（仅按照文件名识别，名字不符合的类库即使放在lib目录中也不会被加载）加载到虚拟机内存中。
扩展类加载器（Extension ClassLoader）：由sun.misc.Launcher$ExtClassLoader实现，他负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中所有的类库，开发者可直接使用。
应用程序类加载器（Application ClassLoader）：由sun.misc.Launcher$AppClassLoader实现，也叫系统类加载器。负责加载用户类路径（classpath）上所指定的类库，开发者可直接使用。

类加载器之间的层次关系

双亲委派模型

如上图所示的模型被称之为“双亲委派模型”。

双亲委派模型工作流程：

如果一个类加载器收到了类加载的请求，它首先会把这个请求委派给父类加载器，每一层类加载器都是如此（注意：启动类加载器没有父类，若委派到启动类加载器时还没有找到这个类，会抛弃异常：ClassNotFoundException）。因此所有的加载请求最终都应该委派到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去完成加载。

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;
        }
    }

JDK类加载源码解读:
先检查请求加载的类是否已经被加载过，若没有被加载过则调用父类加载器的loadClass()方法，若父类加载器为空则默认使用启动类加载器作为父加载器。若父加载器加载失败，抛出ClassNotFoundException，此时才调用自己的findClass()方法尝试加载。加载完成后若加载类没有被解析过，则进行解析。

打破双亲委派

双亲委派有一个很大的局限性就是无法做到不委派或向下委派。

如java.sql.Driver的实现需要各个数据库的服务商（MySQL/Oracle…）来提供，由于Driver接口定义在jdk当中的，DriverManager（也由jdk提供）要加载各个实现了Driver接口的实现类，然后进行管理，但是DriverManager由启动类加载器加载，只能记载JAVA_HOME的lib下文件，而它的实现是由服务商提供的，此时就需要启动类加载器来委托子类来加载Driver实现，从而打破双亲委派。这就是常说的SPI(Service Provider Interface)机制。

向下委派

通过java.util.ServiceLoader可以实现向下委派。

public static <S> ServiceLoader<S> load(Class<S> service) {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }