JVM类加载器机制与类加载过程

烈酒焚心 提交于 2020-04-07 03:53:59

    该文章是我转载的,不过我对文中的一些地方有不同的理解,所以修改几处,还请作者见谅。

    原贴:http://m.blog.csdn.net/article/details?id=50529868

 

读完本文,你将了解到:

一、为什么说Java语言是跨平台的

二、Java虚拟机启动、加载类过程分析

三、类加载器有哪些?其组织结构是怎样的?

四、双亲加载模型的逻辑和底层代码实现是怎样的?

五、类加载器与Class<T>  实例的关系

六、线程上下文加载器

 

一、为什么说Java语言是跨平台的?

 

Java语言之所以说它是跨平台的、可以在当前绝大部分的操作系统平台下运行,是因为Java语言的运行环境是在Java虚拟机中。 
Java虚拟机消除了各个平台之间的差异,只要操作系统平台下安装了Java虚拟机,那么使用Java开发的东西都能在其上面运行。如下图所示:

这里写图片描述

         Java虚拟机对各个平台而言,实质上是各个平台上的一个可执行程序。例如在windows平台下,java虚拟机对于windows而言,就是一个java.exe进程而已。

 

二、Java虚拟机启动、加载类过程分析

下面我将定义一个非常简单的java程序并运行它,来逐步分析java虚拟机启动的过程。

package org.luanlouis.jvm.load;
import sun.security.pkcs11.P11Util;

/**
 * Created by louis on 2016/1/16.
 */
public class Main{

    public static void main(String[] args) {
        System.out.println("Hello,World!");

        ClassLoader loader = P11Util.class.getClassLoader();

        System.out.println(loader);
    }
}
在windows命令行下输入: 
java    org.luanlouis.jvm.load.Main
当输入上述的命令时: 
windows开始运行{JRE_HOME}/bin/java.exe程序,java.exe 程序将完成以下步骤: 
1.  根据JVM内存配置要求,为JVM申请特定大小的内存空间;

2.  创建一个引导类加载器实例,初步加载系统类到内存方法区区域中;

3.   创建JVM 启动器实例 Launcher,并取得类加载器ClassLoader;

4.  使用上述获取的ClassLoader实例加载我们定义的 org.luanlouis.jvm.load.Main类;

5.  加载完成时候JVM会执行Main类的main方法入口,执行Main类的main方法;

6.  结束,java程序运行结束,JVM销毁。

 

Step 1.根据JVM内存配置要求,为JVM申请特定大小的内存空间

 

为了不降低本文的理解难度,这里就不详细介绍JVM内存配置要求的话题,今概括地介绍一下内存的功能划分。

JVM启动时,按功能划分,其内存应该由以下几部分组成: 
这里写图片描述 
如上图所示,JVM内存按照功能上的划分,可以粗略地划分为 方法区(Method Area) 和 堆(Heap),而所有的类的定义信息都会被加载到 方法区中。

关于具体方法区里有什么内容,读者可以参考我的另一篇博文: 
《Java虚拟机原理图解》3、JVM运行时数据区

Step 2. 创建一个引导类加载器实例,初步加载系统类到内存方法区区域中;

JVM申请好内存空间后,JVM会创建一个 引导类加载器(Bootstrap Classloader)实例,引导类加载器是使用C++语言实现的,负责加载JVM虚拟机运行时所需的基本系统级别的类,如 java.lang.String, java.lang.Object等等。

引导类加载器(Bootstrap Classloader)会读取 {JRE_HOME}/lib 下的jar包和配置,然后将这些系统类加载到方法区内。

本例中,引导类加载器是用 {JRE_HOME}/lib加载类的,不过,你也可以使用参数 -Xbootclasspath 或 系统变量sun.boot.class.path来指定的目录来加载类。

一般而言,{JRE_HOME}/lib下存放着JVM正常工作所需要的系统类,如下表所示:

文件名 描述
rt.jar 运行环境包,rt即runtime,J2SE 的类定义都在这个包内
charsets.jar 字符集支持包
jce.jar 是一组包,它们提供用于加密、密钥生成和协商以及 Message Authentication Code(MAC)算法的框架和实现
jsse.jar 安全套接字拓展包Java(TM) Secure Socket Extension
classlist 该文件内表示是引导类加载器应该加载的类的清单
net.properties JVM 网络配置信息

引导类加载器(Bootstrap ClassLoader) 加载系统类后,JVM内存会呈现如下格局:
这里写图片描述

  • 引导类加载器将类信息加载到方法区中,以特定方式组织,对于某一个特定的类而言,在方法区中它应该有 运行时常量池类型信息字段信息方法信息类加载器的引用对应class实例的引用等信息。
  • 类加载器的引用,由于这些类是由引导类加载器(Bootstrap Classloader)进行加载的,而 引导类加载器是有C++语言实现的,所以是无法访问的,故而该引用为NULL
  • 对应class实例的引用 类加载器在加载类信息放到方法区中后,会创建一个对应的Class 类型的实例放到堆(Heap)中, 作为开发人员访问方法区中类定义的入口和切入点。
小测试:
当我们在代码中尝试获取系统类如java.lang.Object的类加载器时,你会始终得到NULL:
System.out.println(String.class.getClassLoader());//null
        System.out.println(Object.class.getClassLoader());//null
        System.out.println(Math.class.getClassLoader());//null
        System.out.println(System.class.getClassLoader());//null

Step 3. 创建JVM 启动器实例 Launcher,并取得类加载器ClassLoader

 

上述步骤完成,JVM基本运行环境就准备就绪了。接着,我们要让JVM工作起来了:运行我们定义的程序 org.luanlouis,jvm.load.Main。

此时,JVM虚拟机调用已经加载在方法区的类sun.misc.Launcher 的静态方法getLauncher(),  获取sun.misc.Launcher 实例:

sun.misc.Launcher launcher = sun.misc.Launcher.getLauncher(); //获取Java启动器
ClassLoader classLoader = launcher.getClassLoader();          //获取类加载器ClassLoader用来加载class到内存来

sun.misc.Launcher 使用了单例模式设计,保证一个JVM虚拟机内只有一个sun.misc.Launcher实例。
在Launcher的内部,其定义了两个类加载器(ClassLoader),分别是sun.misc.Launcher.ExtClassLoadersun.misc.Launcher.AppClassLoader,两个是内部类,这两个类加载器分别被称为拓展类加载器(Extension ClassLoader) 和 应用类加载器(Application ClassLoader).如下图所示:

图例注释:除了引导类加载器(Bootstrap Class Loader )的所有类加载器,都有一个能力,就是判断某一个类是否被引导类加载器加载过,如果加载过,可以直接返回对应的Class<T> instance,如果没有,则返回null.  图上的指向引导类加载器的虚线表示类加载器的这个有限的访问 引导类加载器的功能。

      此时的  launcher.getClassLoader() 方法将会返回 AppClassLoader 实例,AppClassLoaderExtClassLoader作为自己的父加载器。

    类加载器加载类的部分源码:

//提供class类的二进制名称表示,加载对应class,加载成功,则返回表示该类对应的Class<T> instance 实例
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
    }
 
    
    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先,检查是否已经被当前的类加载器记载过了,如果已经被加载,直接返回对应的Class<T>实例
            Class<?> c = findLoadedClass(name);
                //初次加载
                if (c == null) {//当前加载器没有加载过
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        //如果有父类加载器,则先让父类加载器加载,父类加载器的loadClass方法也是当前的loadClass方法
                        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;
        }
    }

由源码可知,当AppClassLoader加载X类时的加载过程(这部分我修改过):

1、会先查找自己是否加载过X类,查找成功则返回Class<X>的实例引用;

2、如果查找失败返后,会尝试让父加载器ExtClassLoader进行加载;

3、父加载器ExtClassLoader会先查找自己是否加载过X类,如果查找成功则返回Class<X>的实例引用,AppClassLoader也直接返回父加载器ExtClassLoader返回的实例引用

4、如果父加载器ExtClassLoader没加载过该类,且父加载器ExtClassLoader没有父加载器,所以查看Bootstrap类加载器是否加载过,如果加载过,返回Class<X>的实例引用;

5、如果Bootstrap类加载器没有加载过,则父加载器ExtClassLoader在自己的加载范围{JRE_HOME}/lib/ext中尝试加载,如果加载成功,返回Class<X>的实例引用;

6、如果Bootstrap类加载器加载失败将会抛出“ClassNotFoundException”,异常处理中什么都不做;

7、最后AppClassLoader在自己的加载范围classpath(通过System.getProperty("java.class.path")查看该路径)中尝试加载,如果加载成功,返回Class<X>的实例引用;

8、如果AppClassLoader加载失败,则最终抛出“ClassNotFoundException”,

 

双亲委派模型(parent-delegation model):
上面讨论的应用类加载器AppClassLoader的加载类的模式就是我们常说的双亲委派模型(parent-delegation model).
请注意:
双亲委派模型中的"双亲"并不是指它有两个父类加载器的意思,一个类加载器只应该有一个父加载器。上面的步骤中,有两个角色:
1. 父类加载器(parent classloader):它可以替子加载器尝试加载类
2. 引导类加载器(bootstrap classloader): 子类加载器只能判断某个类是否被引导类加载器加载过,而不能委托它加载某个类;换句话说,就是子类加载器不能接触到引导类加载器,引导类加载器对其他类加载器而言是透明的。(由此可知:引导类加载器应该会在JVM启动时就将所有有可能用到的系统基础类都加载到内存,因为引导类加载器只会加载一次。而ext下的扩展类和classpath下的类则是按需加载或者按其他方式加载;PS:项目中导入的Jar包是由AppClassLoader加载的)

一般情况下,双亲加载模型如下所示:

 

 

Step 4. 使用类加载器ClassLoader加载Main类

 

通过 launcher.getClassLoader()方法返回AppClassLoader实例,接着就是AppClassLoader加载 org.luanlouis.jvm.load.Main类的时候了。

ClassLoader classloader = launcher.getClassLoader();//取得AppClassLoader类
classLoader.loadClass("org.luanlouis.jvm.load.Main");//加载自定义类

上述定义的org.luanlouis.jvm.load.Main类被编译成org.luanlouis.jvm.load.Main class二进制文件,这个class文件中有一个叫常量池(Constant Pool)的结构体来存储该class的常亮信息。常量池中有CONSTANT_CLASS_INFO类型的常量,表示该class中声明了要用到那些类:

当AppClassLoader要加载 org.luanlouis.jvm.load.Main类时,会去查看该类的定义,发现它内部声明使用了其它的类: sun.security.pkcs11.P11Util、java.lang.Object、java.lang.System、java.io.PrintStream、java.lang.Class;org.luanlouis.jvm.load.Main类要想正常工作,首先要能够保证这些其内部声明的类加载成功。所以AppClassLoader要先将这些类加载到内存中。(注:为了理解方便,这里没有考虑懒加载的情况,事实上的JVM加载类过程比这复杂的多)

加载顺序:

1. 加载java.lang.Object、java.lang.System、java.io.PrintStream、java,lang.Class

      (这几个类在{JRE_HOME}/lib下,在JVM启动时就由引导类加载器加载过)

     加载原理和上面的加载原理(红字体部分)相同,最后在上面的步骤4中(在引导类加载器加载过的类中找到),然后返回Class<T>实例引用

2. 加载sun.security.pkcs11.P11Util

    此类在{JRE_HOME}/lib/ext/sunpkcs11.jar包内,属于ExtClassLoader负责加载的范畴。在上面的步骤3中(ExtClassLoader已经加载过的类中)找到,查找成功后直接返回对应的Class<sun.security.pkcs11.P11Util>实例;

3. 加载org.luanlouis.jvm.load.Main

  该类是在这AppClassLoader的负责范围,所以在上面步骤的前6点都加载不成功。所以AppClassLoader只能自己动手负责将其加载到内存中(步骤7),例子中的Mian类是可以在此处加载到的,最后返回对应的Class<org.luanlouis.jvm.load.Main>实例引用;

以上三步骤都成功,才表示classLoader.loadClass("org.luanlouis.jvm.load.Main")完成,上述操作完成后,JVM内存方法区的格局会如下所示:

如上图所示:

  • JVM方法区的类信息区是按照类加载器进行划分的,每个类加载器会维护自己加载类信息;
  • 某个类加载器在加载相应的类时,会相应地在JVM内存堆(Heap)中创建一个对应的Class<T>,用来表示访问该类信息的入口

 

Step 5. 使用Main类的main方法作为程序入口运行程序

 

Step 6. 方法执行完毕,JVM销毁,释放内存

 

三、类加载器有哪些?其组织结构是怎样的?

             类加载器(Class Loader):顾名思义,指的是可以加载类的工具。JVM自身定义了三个类加载器:引导类加载器(Bootstrap Class Loader)、拓展类加载器(Extension Class Loader )、应用加载器(Application Class Loader)。当然,我们有时候也会自己定义一些类加载器来满足自身的需要。

            引导类加载器(Bootstrap Class Loader): 该类加载器使JVM使用C/C++底层代码实现的加载器,用以加载JVM运行时所需要的系统类,这些系统类在{JRE_HOME}/lib目录下。由于类加载器是使用平台相关的底层C/C++语言实现的, 所以该加载器不能被Java代码访问到。但是,我们可以查询某个类是否被引导类加载器加载过。我们经常使用的系统类如:java.lang.String,java.lang.Object,java.lang*....... 这些都被放在 {JRE_HOME}/lib/rt.jar包内, 当JVM系统启动的时候,引导类加载器会将其加载到 JVM内存的方法区中。

           拓展类加载器(Extension Class Loader): 该加载器是用于加载 java 的拓展类 ,拓展类一般会放在 {JRE_HOME}/lib/ext/ 目录下,用来提供除了系统类之外的额外功能拓展类加载器是是整个JVM加载器的Java代码可以访问到的类加载器的最顶端,即是超级父加载器,拓展类加载器是没有父类加载器的。

           应用类加载器(Applocatoin Class Loader): 该类加载器是用于加载用户代码,是用户代码的入口。我经常执行指令 java   xxx.x.xxx.x.x.XClass , 实际上,JVM就是使用的AppClassLoader加载 xxx.x.xxx.x.x.XClass 类的由于xxx.x.xxx.x.x.XClass是整个用户代码的入口,在Java虚拟机规范中,称其为 初始类(Initial Class).

    
           用户自定义类加载器(Customized Class Loader):用户可以自己定义类加载器来加载类。所有的类加载器都要继承java.lang.ClassLoader类。

           

 

四、双亲加载模型的逻辑和底层代码实现是怎样的?

            上面已经不厌其烦地讲解什么是双亲加载模型,以及其机制是什么,这些东西都是可以通过底层代码查看到的。

             我们也可以通过JDK源码看java.lang.ClassLoader的核心方法 loadClass()的实现:代码在上面已经给出

            相信读者看过这张图后会对双亲加载模型有了非常清晰的脉络。当然,这是JDK自身默认的加载类的行为,我们可以通过继承复写该方法,改变其行为。

 

 

五、类加载器与Class<T>  实例的关系

 

 

 

六、线程上下文加载器

             Java 任何一段代码的执行,都有对应的线程上下文。如果我们在代码中,想看当前是哪一个线程在执行当前代码,我们经常是使用如下方法:

Thread  thread = Thread.currentThread();//返回对当当前运行线程的引用

 

相应地,我们可以为当前的线程指定类加载器。在上述的例子中, 当执行   java    org.luanlouis.jvm.load.Main  的时候,JVM会创建一个Main线程,而创建应用类加载器AppClassLoader的时候,会将AppClassLoader  设置成Main线程的上下文类加载器:

 

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

        try {
            this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
        } catch (IOException var9) {
            throw new InternalError("Could not create application class loader", var9);
        }
		//将AppClassLoader设置成当前线程的上下文加载器
        Thread.currentThread().setContextClassLoader(this.loader);
        //.......

    }

线程上下文类加载器是从线程的角度来看待类的加载,为每一个线程绑定一个类加载器,可以将类的加载从单纯的 双亲加载模型解放出来,进而实现特定的加载需求。
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!