zoukankan      html  css  js  c++  java
  • java classloader原理深究

    前面已经写过一篇关于java classloader的拙文java classloader原理初探

    时隔几年,再看一遍,觉得有些地方显得太过苍白,于是再来一篇:

    完成一个Java类之后,经过javac编译,会生成一个class文件,这个class文件中包含跟这个类相关的所有基本信息:属性字段,方法等。这些都属于一个类的元数据,是不变的部分。在执行过程,则需要根据类的元数据信息生成一个实例对象,这个实例对象可以根据不同场景拥有不同状态。也就是说同一个class对应了运行过程中的不同状态。(请注意这里是class,不是object)每一个java文件在被编译之后,编译器都会给加入一个public的静态字段叫:class。在程序中,我们就可以通过SomeObject.class的方式来获取一个Class对象。
    Java中通过包路径和类名来确定一个类,通过java api我们知道Class中有个方法是getClassLoader(),但如果一个类被两个不同classloader加载, 这个方法就会返回不同结果,在这种情况下,虽然是同一个class,但被不同class loader加载,那对应的Class对象就不是同一个。

    为什么要设置环境变量:JAVA_HOME, CLASSPATH?JAVA_HOME对应的是java的安装根路径,为了能在系统中随处都能用到java给我们提供的命令行工具,所以要把JAVA_HOME/bin的路径添加到PATH中。但是CLASSPATH呢,为什么需要在CLASSPATH中指定那三个jar(tools.jar, dt.jar, rt.jar)?
    先说明一下tools.jar主要是一些java 工具类,可以从openjdk上下载jdk的源码,找langtools这个路径下的文件来看看, 如果想写一些工具类,比如通过java来分析或编译java文件,可以查看一下tools里面的javac相关的api;dt.jar主要是swing相关的一些类。而rt.jar则是运行时相关的,是java的核心库中的java类。
    再来理解一下java在启动时类的代理模式加载顺序。JAVA中除了Bootstrap class loader 都有一个parent class loader。参阅java 官方对于“Understanding Extension Class Loading”的说明。里面提到了三个方面的加载内容:一是rt.jar和i18n.jar等基础类包;二是扩展包;三就是我们classpath指定的依赖包。对于第一部分,由Bootstrap class loader负责加载,所以java包中的类的class loader就是bootstrap class loader,而扩展路径(一般是在jre/lib/ext)下由 extension class loader(ExtClassLoader)负责. 第三部分的加载就需要应用class loader(AppClassLoader)来负责了。一般情况下,直接通过java启动时,会注明一下-classpath 或 -cp来标识出依赖包列表(注意,不是一个路径,而是文件列表)。代码中负责初始化相关class loader的过程是在sun.misc.Launcher类中, 下面是Launcher的constructor方法中的实现。
    public Launcher() {
            // Create the extension class loader
            ClassLoader extcl;
            try {
                extcl = ExtClassLoader.getExtClassLoader();
            } catch (IOException e) {
                throw new InternalError(
                    "Could not create extension class loader", e);
            }

            // Now create the class loader to use to launch the application
            try {
                loader = AppClassLoader.getAppClassLoader(extcl);
            } catch (IOException e) {
                throw new InternalError(
                    "Could not create application class loader", e);
            }

            // Also set the context class loader for the primordial thread.
            Thread.currentThread().setContextClassLoader(loader);
    …..
    }
    对于前面提到的相关加载路径也都在这个类中有相关代码,不一一列举。

    Java Api中的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;
            }
        }

    加载某个类时,当前classloader都会先委托parent class loader尝试加载。这种处理方式,有几个方面的考虑:一是安全问题,如果攻击者模拟实现了对应的类如java.lang.String, 当通过loadClass来加载类时,会首先到parent classloader中查找,很明显可以在bootstrap class loader中找到,这样可以尽可能保护最关键的代码。一是冗余问题,通过这种方式可以最大限度的降低重复加载。每个层次的classloader负责对应路径下的类库加载,而对于应用实现来说就可以集中在应用系统中。这里可以考虑一下web container的实现,如tomcat。每个jsp页面都会最终被编译成一个class文件,并放到work路径中,所以每个web容器都会自建一个classloader来加载指定路径中的class文件。

    通过上面的说明,可以了解到jvm在启动过程中,如果发现有相同包路径的情况(不同jar,但相同包)下的同名类,则仅会加载一次,主要看哪个包在最前面。这里有个问题:为什么是在前面的包可以起作用,后面不行?如果是由同一个classloader加载还不会被覆盖么?其实如果是自己实现的classloader,那就可以调整这种策略,但java中约定的就是先加载的class会根据起binary name,将class metadata存于永久区,于是后面再有同名的类,都可以被找到,而不需要重新加载。 
  • 相关阅读:
    快速幂精讲+代码实现
    基数排序
    Java学习-常见排序算法
    C++中不清楚的函数用法汇总
    C++中的堆及常见题目汇总
    django+nginx+uwsgi+vue部署服务器
    nginx+WSGI+uwisgi+uWISI详解及nginx/uwisgi/django交互流程
    C++中的哈希表及常见题目汇总
    C++中的二叉树及相关题目汇总
    C++中的队列及常见题目汇总
  • 原文地址:https://www.cnblogs.com/ericchen/p/3662484.html
Copyright © 2011-2022 走看看