欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

虚拟机之双亲委托模型

程序员文章站 2022-05-27 23:42:53
...
类加载器

虚拟机设计团队把类加载阶段中的“通过一个全限定性名获取二进制字节流”这个动作的实现放到 java 虚拟机外部去实现,以便让程序自己决定如何去获取所需要的类. 这个动作的代码模块称为“类加载器”。

任何一个类,都是由加载它的类加载器和这个类本身一同确立其在 java 虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间.
换句话说,比较两个类是否相等,只有在这两个类在同一个类加载器加载的前提下才有意义.否则就是同一个类,但是用不同的类加载器加载,那么必然也是不相等的.

这里说的相等,包括代表类的 Class 对象的 equals() 方法、isAssignableFrom() 方法、isInstance() 方法的返回结果,也包括 instanceof 关键字做对象所属关系判定等情况.

双亲委派模型

从 java 虚拟机的角度上将,只存在两种加载器,一种是启动类加载器,这个类加载器由c++实现,还有就是其他的类加载器,这些类加载器由java语言实现,独立于虚拟机外部,并全部继承自抽象类 java.lang.ClassLoader.

启动类加载器:负责 java_hone/lib 目录中的,或者被 -Xbootclasspath 参数指定的路径
扩展类加载器:负责 java_home/lib/ext 目录中的,或者被 java.ext.dirs 系统变量所指定的(sun.misc.Launcher$ExtClassLoader实现).
应用程序类加载器:这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值,所以又称系统类加载器.(sun.misc.Launcher$App-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 中实现了双亲委托的核心代码,然后调用 findClass 方法. 所以,如果我们只是改变查找类的话,可以直接重写 findClass 方法.

破坏双亲委托模型

双亲委托模型并不是一个强制性约束模型,而是 java 设计者推荐的一种.

双亲委托模型第一次被破坏: JDK1.2发布之前,由于双亲委托模型是在 JDK1.2之后才被引入的,而 ClassLoader 在 JDK1.0 时已经存在,所以 java 设计者不得不做出一些妥协,添加了 protected 方法 findClass().

双亲委托模型第二次被破坏:是由模型自身缺陷导致的,比如说基础类要回调用户代码,该怎么办了?比如典型的例子JNDI服务,它的代码由启动类加载器加载,但是它要加载厂商放在 classpath 的实现,该怎么办了?为了解决这个问题,java 设计团队引入了一个不太优雅的设计:线程上下文类加载器(Thread Context ClassLoader). 这个类加载器可以通过 Thread 类的 setContextClassLoader() 方法进行设置,如果线程创建时还没有设置,它将从父线程中继承一个,如果在引用程序的全局都没有设置过,那这个类加载器默认就是应用程序类加载器.

第三次被破坏:由于用户对程序动态性的追求所导致.每个程序模块(OSGI 中称 Bundle)都有一个自己的类加载器,当需要更换一个 Bundle 时,就把 Bundle 连同类加载器一起换掉以实现代码的热替换.

可以参考:https://www.zhihu.com/question/49667892

在 OSGI 环境下,类加载器不再是双亲委托模型中的树状结构,而是更加复杂的网状结构,当收到类加载请求时,OSGI 将按照下面的顺序进行类搜索:

1.将以 java.* 开头的类委派给父类加载器加载
2.否则,将委派列表名单内的类委派给父类加载器加载
3.否则,将 Import 列表中的类委派给 Export 这个类的 Bundle 的类加载器加载
4.否则,查找当前 Bundle 的 ClassPath,使用自己的类加载器加载
5.否则,查找类是否在自己的 Fragment Bundle 中,如果在,则委派给 Fragment Bundle 的类加载器加载
6.否则,查找 Dynamic Import 列表的 Bundle,委派给对应的 Bundle 的类加载器加载
7.否则,查找失败