Java类加载器(一)——类加载器层次与模型-阿里云开发者社区

开发者社区> 开发与运维> 正文

Java类加载器(一)——类加载器层次与模型

简介: 类加载器   虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。

类加载器

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


类加载器层次(等级)

  从JVM的角度来讲,只存在两种不同的类加载器。
  第一类是启动类加载器(Bootstrap ClassLoader):这个类加载器主要加载JVM自身工作需要的类。这个类加载器由C++语言实现(特指HotSpot),是虚拟机自身的一部分。负责将存放在%JAVA_HOME%\lib目录中的,或者被-Xbootclasspath参数所指定的路径中,并且是虚拟机识别的(仅按照文件名识别,如rt.jar,名字不符合的类库即使放在lib目录中也不会被加载)类加载到虚拟机内存中。
  另一类就是所有其他的类加载器,这些加载器都是由java实现,独立于虚拟机外部。
  Extension ClassLoader:这个类即在其有sun.misc.Launcher$ExtClassLoader实现,它负责加载%JAVA_HOME%\lib\ext目录中,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。
  Application ClassLoader:这个类加载器由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也成它为系统类加载器。它负责加载用户类路径上指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。
  AppClassLoader的parent是ExtClassLoader。很多文章在介绍ClassLoader层次的结构时把Bootstrap ClassLoader也列在ExtClassLoader的上一级中,其实Bootstrap ClassLoader并不属于JVM的类等级层次,因为Bootstrap ClassLoader没有遵守ClassLoader的加载股则。另外Bootstrap ClassLoader没有子类,ExtClassLoader的父类也不是Bootstrap ClassLoader,ExtClassLoader并没有父类,我们在应用中能提取到的顶层父类是ExtClassLoader.
代码举例:

        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        System.out.println(cl.toString());
        System.out.println(cl.getParent());
        System.out.println(cl.getParent().getParent());

  输出结果:

sun.misc.Launcher$AppClassLoader@7dd74c03
sun.misc.Launcher$ExtClassLoader@41bf9980
null

如何获得ClassLoader

  1. this.getClass().getClassLoader();//使用当前类的ClassLoader
  2. Thread.currentThread().getContextClassLoader();//使用当前线程的ClassLoader
  3. ClassLoader.getSystemClassLoader();//使用系统ClassLoader

  代码举例:

    public void test()
    {
        System.out.println(this.getClass().getClassLoader().toString());
        System.out.println(Thread.currentThread().getContextClassLoader());
        System.out.println(ClassLoader.getSystemClassLoader());
    }

  输出:

sun.misc.Launcher$AppClassLoader@41bf9980
sun.misc.Launcher$AppClassLoader@41bf9980
sun.misc.Launcher$AppClassLoader@41bf9980

[Tips]如何获得类的class属性:
1. Class.forName(类路径全名);
2. this.getClass();
3. 使用.class,比如String.class
4. 对于基本数据类型有:Class c1 = int.class(class只是约定标记,不是成员属性) 或者Class c2 = Integer.TYPE

  JVM加载class文件到内存有两种方式:
  1. 隐式加载:所谓的隐式加载就是不通过在代码里调用ClassLoader来记载需要的类,而是通过JVM来自动加载需要的类到内存的方式。例如,当我们在类中集成或者引用某个类是,JVM在解析当前这个类时发现引用的类不在内存中,那么就会自动将这些类加载到内存中。
  2. 显示加载:相反的显示加载就是我们在代码中通过调用ClassLoader类来加载一个类的方式,例如,调用this.getClass.getClassLoader().loadClass()或者Class.forName(),或者我们自己实现的ClassLoader的findClass()方法等。


双亲委派模型

  双亲委派模型要求畜类鼎城的启动类加载器(Bootstrap ClassLoader)之外,其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以inheritance的关系实现而是都是使用组合Composition关系来复用父类加载器的代码
  双亲委派模型不是一个强制性的约束模型,而是java设计者推荐给开发者的一种类加载器实现方式。在java的世界中大部分的类加载器都遵循这个模型,但也有例外,到目前为止,双亲委派模型主要出现过3此较大的“被破坏”情况,这个稍后再阐述。
  双亲委派模型的工作过程是:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(它搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。
  双亲委托机制的作用是防止系统jar包被本地替换,因为查找方法过程都是从最底层开始查找。 因此,一般我们自定义的classloader都需要采用这种机制,我们只需要继承java.lang.ClassLoader实现findclass即可,如果需要更多控制,自定义的classloader就需要重写loadClass方法了,比如tomcat的加载过程,这个比较复杂,可以通过其他文档资料查看相关介绍。
  双亲委派模型对于保证java程序的稳定运作很重要,实现体现在java.lang.ClassLoader的loadClass()方法中,如下:

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()方法的加载步骤为:
  1. 调用 Class c = findLoadedClass(name);来检查是否已经加载类;
  2. 在父类加载器上调用loadClass方法:
   c = parent.loadClass(name, false);
  如果父类加载器为null,则使用虚拟机的内置类加载器:
   c = findBootstrapClassOrNull(name);
  3. 在父类加载器无法加载的时候再调用本身的findClass方法来进行类加载:
   c = findClass(name);

每个ClassLoader加载Class的过程是:
1.检测此Class是否载入过(即在cache中是否有此Class),如果有到8,如果没有到2;
2.如果parent classloader不存在(没有parent,那parent一定是bootstrap classloader了),到4;
3.请求parent classloader载入,如果成功到8,不成功到5;
4.请求jvm从bootstrap classloader中载入,如果成功到8;
5.寻找Class文件(从与此classloader相关的类路径中寻找)。如果找不到则到7;
6.从文件中载入Class,到8;
7.抛出ClassNotFoundException;
8.返回Class.


破坏双亲委派模型

  上文提到了到目前为止,双亲委派模型出现过3次较大规模的“被破坏”的情况,这里详细阐述一下。
  第一次。发生在双亲委派模型出现之前(jdk1.2发布之前)。由于双亲委派模型在jdk1.2之后才被引入,而类加载器和抽象类java.lang.ClassLoader则在jdk1.0时代就已经存在,面对已经存在的用户自定义类加载器的实现代码,java设计者引入双亲委派模型时不得不做出了一些妥协。历史已经成为过去,具体的在此不赘述,需要注意的是jdk1.2之后不提倡用户再去覆盖loadClass()方法,而应当把自己的类加载逻辑写到findClass()中,这样保证符合双亲委派模型的规则。
  第二次。由模型本身的缺陷所导致的,双亲委派模型很好地解决了各个类加载器的基础类的统一问题。当父类加载器需要请求子类加载器去完成类加载动作,比如JNDI服务:它的代码由启动类加载器去加载,但JNDI的目的是对资源进行集中管理和查找,它需要调用由独立厂商实现并部署在应用程序的Classpath下的JNDI提供者(SPI)的代码,但是启动类加载器不“认识”这些代码。这是就要用到了线程上下文加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置。
  这里怎么又出来一个context classloader呢?它有什么用呢?我们在建立一个线程Thread的时候,可以为这个线程通过setContextClassLoader方法来指定一个合适的classloader作为这个线程的context classloader,当此线程运行的时候,我们可以通过getContextClassLoader方法来获得此context classloader,就可以用它来载入我们所需要的Class。默认的是system classloader。利用这个特性,我们可以“打破”classloader委托机制了,父classloader可以获得当前线程的context classloader,而这个context classloader可以是它的子classloader或者其他的classloader,那么父classloader就可以从其获得所需的 Class,这就打破了只能向父classloader请求的限制了。这个机制可以满足当我们的classpath是在运行时才确定,并由定制的 classloader加载的时候,由system classloader(即在jvm classpath中)加载的class可以通过context classloader获得定制的classloader并加载入特定的class(通常是抽象类和接口,定制的classloader中是其实现),例如web应用中的servlet就是用这种机制加载的.
  第三次。 由于用户对程序动态性的追求而导致的,这里所说的“动态性”指的是当前一些非常“热门”的名称:代码热替换、模块热部署等,类似于鼠标键盘热拔插。具体的可以看一下OSGi,在OSGi环境下,类加载器不再是双亲委派模型中的树型结构,而是一种网状结构。具体的可以翻阅一些相关资料。

版权声明:本文首发在云栖社区,遵循云栖社区版权声明:本文内容由互联网用户自发贡献,版权归用户作者所有,云栖社区不为本文内容承担相关法律责任。云栖社区已升级为阿里云开发者社区。如果您发现本文中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,阿里云开发者社区将协助删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章