Arthas从入门到精通(二) 理解的前提-ClassLoad机制剖析

最新推荐文章于 2024-03-19 09:15:00 发布

destiny4Y

最新推荐文章于 2024-03-19 09:15:00 发布

阅读量338

点赞数

分类专栏： arthas 文章标签： java

本文链接：https://blog.csdn.net/destiny4Y/article/details/119220559

版权

arthas 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

系列索引

Arthas从入门到精通(一) 整体概览

Arthas从入门到精通(二) 理解的前提-ClassLoad机制剖析

Arthas从入门到精通(三) 理解的前提-ClassLoad机制应用

Arthas从入门到精通(四) 熟练的前提-OGNL表达式

背景

arthas的查询以及更新等，很多地方都用到了classLoader作为传参，这里主要讲解一下java的classLoader机制，方便更好的理解arthas的实现原理以及实际的

Java自带的加载器

Bootstrap ClassLoader 最顶层的加载类，主要加载核心类库，%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。另外需要注意的是可以通过启动jvm时指定-Xbootclasspath和路径来改变Bootstrap ClassLoader的加载目录。比如java -Xbootclasspath/a:path被指定的文件追加到默认的bootstrap路径中。
Extention ClassLoader 扩展的类加载器，加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。还可以加载-D java.ext.dirs选项指定的目录。
Appclass Loader也称为SystemAppClass 加载当前应用的classpath的所有类。

在sun.misc.Launcher可以看到3个类的加载顺序:

public class Launcher {
    private static Launcher launcher = new Launcher();
    private static String bootClassPath =
        System.getProperty("sun.boot.class.path");

    public static Launcher getLauncher() {
        return launcher;
    }

    private ClassLoader loader;

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

        //设置AppClassLoader为线程上下文类加载器，这个文章后面部分讲解
        Thread.currentThread().setContextClassLoader(loader);
    }

    /*
     * Returns the class loader used to launch the main application.
     */
    public ClassLoader getClassLoader() {
        return loader;
    }
    /*
     * The class loader used for loading installed extensions.
     */
    static class ExtClassLoader extends URLClassLoader {}

/**
     * The class loader used for loading from java.class.path.
     * runs in a restricted security context.
     */
    static class AppClassLoader extends URLClassLoader {}

1. Launcher初始化了ExtClassLoader和AppClassLoader。

2. Launcher中并没有看见BootstrapClassLoader，但通过System.getProperty("sun.boot.class.path")得到了字符串bootClassPath,这个应该就是BootstrapClassLoader加载的jar包路径。

ExtClassLoader源码

可以看到ExtClassLoader从java.ext.dirs系统变量中加载

/*
     * The class loader used for loading installed extensions.
     */
    static class ExtClassLoader extends URLClassLoader {

        static {
            ClassLoader.registerAsParallelCapable();
        }

        /**
         * create an ExtClassLoader. The ExtClassLoader is created
         * within a context that limits which files it can read
         */
        public static ExtClassLoader getExtClassLoader() throws IOException
        {
            final File[] dirs = getExtDirs();

            try {
                // Prior implementations of this doPrivileged() block supplied
                // aa synthesized ACC via a call to the private method
                // ExtClassLoader.getContext().

                return AccessController.doPrivileged(
                    new PrivilegedExceptionAction<ExtClassLoader>() {
                        public ExtClassLoader run() throws IOException {
                            int len = dirs.length;
                            for (int i = 0; i < len; i++) {
                                MetaIndex.registerDirectory(dirs[i]);
                            }
                            return new ExtClassLoader(dirs);
                        }
                    });
            } catch (java.security.PrivilegedActionException e) {
                throw (IOException) e.getException();
            }
        }

        private static File[] getExtDirs() {
            String s = System.getProperty("java.ext.dirs");
            File[] dirs;
            if (s != null) {
                StringTokenizer st =
                    new StringTokenizer(s, File.pathSeparator);
                int count = st.countTokens();
                dirs = new File[count];
                for (int i = 0; i < count; i++) {
                    dirs[i] = new File(st.nextToken());
                }
            } else {
                dirs = new File[0];
            }
            return dirs;
        }
 
......
    }

AppClassLoader源码

可以看到AppClassLoader从java.class.path系统变量中加载。

/**
     * The class loader used for loading from java.class.path.
     * runs in a restricted security context.
     */
    static class AppClassLoader extends URLClassLoader {


        public static ClassLoader getAppClassLoader(final ClassLoader extcl)
            throws IOException
        {
            final String s = System.getProperty("java.class.path");
            final File[] path = (s == null) ? new File[0] : getClassPath(s);


            return AccessController.doPrivileged(
                new PrivilegedAction<AppClassLoader>() {
                    public AppClassLoader run() {
                    URL[] urls =
                        (s == null) ? new URL[0] : pathToURLs(path);
                    return new AppClassLoader(urls, extcl);
                }
            });
        }

        ......
    }

父加载器

classLoad的继承关系，每个类加载器都有一个父加载器(这个并不是指继承，需要区分一下，父加载器是每个classLoader的一个成员变量，并提供get方法)：

加载Main.class是由AppClassLoader完成，父加载器为AppClassLoader，AppClassLoader也有一个父加载器，通过getParent方法可以获取，为ExtClassLoader，但是通过ExtClassLoader.getParent去获取时却得到了空指针异常，同样，通过Integer.class.getClassLoader()去获取时也得到了空指针异常。

这其实是因为ExtClassLoaderd的父加载器是Bootstrap CLassLoader, Bootstrap ClassLoader是由C/C++编写的，它本身是虚拟机的一部分，所以它并不是一个JAVA类，也就是无法在java代码中获取它的引用，JVM启动时通过Bootstrap类加载器加载rt.jar等核心jar包中的class文件，之前的int.class,String.class都是由它加载。

JVM初始化sun.misc.Launcher并创建Extension ClassLoader和AppClassLoader实例。并将ExtClassLoader设置为AppClassLoader的父加载器。Bootstrap没有父加载器，但是它却可以作用一个ClassLoader的父加载器。比如ExtClassLoader。这也可以解释之前通过ExtClassLoader的getParent方法获取为Null的现象。

public class Main {

    public static void main(String[] args) {

        System.out.println(System.getProperty("sun.boot.class.path"));
        System.out.println(System.getProperty("java.ext.dirs"));
        System.out.println(System.getProperty("java.class.path"));

        System.out.println("------------------------------------------------------");
        // 这里输出sun.misc.Launcher$AppClassLoader@18b4aac2
        System.out.println(Main.class.getClassLoader().toString());
        // 这里输出sun.misc.Launcher$ExtClassLoader@61bbe9ba
        System.out.println(Main.class.getClassLoader().getParent().toString());
        try {
                // 这里为会有空指针
        System.out.println(Main.class.getClassLoader().getParent().getParent().toString());
        } catch (Exception e) {
            e.printStackTrace();
        }
        try {
                // 这里为会有空指针
            System.out.println(Integer.class.getClassLoader().toString());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

ClassLoader源码解析

我们可以看到getParent()实际上返回的就是一个ClassLoader对象parent，parent的赋值是在ClassLoader对象的构造方法中，它有两个情况：

1. 由外部类创建ClassLoader时直接指定一个ClassLoader为parent。

2. 由getSystemClassLoader()方法生成，也就是在sun.misc.Laucher通过getClassLoader()获取，也就是AppClassLoader。直白的说，一个ClassLoader创建时如果没有指定parent，那么它的parent默认就是AppClassLoader。

从AppClassLoader的构造过程中，也可以看出，他的父加载器是ExtClassLoaderd。

public abstract class ClassLoader {

// The parent class loader for delegation
// Note: VM hardcoded the offset of this field, thus all new fields
// must be added *after* it.
private final ClassLoader parent;
// The class loader for the system
    // @GuardedBy("ClassLoader.class")
private static ClassLoader scl;

private ClassLoader(Void unused, ClassLoader parent) {
    this.parent = parent;
    ...
}
protected ClassLoader(ClassLoader parent) {
    this(checkCreateClassLoader(), parent);
}
protected ClassLoader() {
    this(checkCreateClassLoader(), getSystemClassLoader());
}
public final ClassLoader getParent() {
    if (parent == null)
        return null;
    return parent;
}
public static ClassLoader getSystemClassLoader() {
    initSystemClassLoader();
    if (scl == null) {
        return null;
    }
    return scl;
}

private static synchronized void initSystemClassLoader() {
    if (!sclSet) {
        if (scl != null)
            throw new IllegalStateException("recursive invocation");
        sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
        if (l != null) {
            Throwable oops = null;
            //通过Launcher获取ClassLoader
            scl = l.getClassLoader();
            try {
                scl = AccessController.doPrivileged(
                    new SystemClassLoaderAction(scl));
            } catch (PrivilegedActionException pae) {
                oops = pae.getCause();
                if (oops instanceof InvocationTargetException) {
                    oops = oops.getCause();
                }
            }
            if (oops != null) {
                if (oops instanceof Error) {
                    throw (Error) oops;
                } else {
                    // wrap the exception
                    throw new Error(oops);
                }
            }
        }
        sclSet = true;
    }
}
}

双亲委托

先简单介绍下双亲委托机制：类加载器查找Class（也就是在loadClass时）所采用的是双亲委托模式，所谓双亲委托模式就是

首先判断该Class是否已经加载
如果没有则不是自身去查找而是委托给父加载器进行查找，这样依次的进行递归，直到委托到最顶层的Bootstrap ClassLoader
如果Bootstrap ClassLoader找到了该Class，就会直接返回
如果没找到，则继续依次向下查找，如果还没找到则最后会交由自身去查找

我们可以发现委托是从下向上，然后具体查找过程却是自上至下。

双亲委托源码分析:

ClassLoader类
---------
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        //首先，根据name检查类是否已经加载，若已加载，会直接返回
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    //若当前类加载器有父加载器，则调用其父加载器的loadClass()
                    c = parent.loadClass(name, false);
                } else {
                    //若当前类加载器的parent为空，则调用findBootstrapClassOrNull()
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
            }
        
            if (c == null) {
                // 1.如果到这里c依然为空的话，表示一直到最顶层的父加载器也没有找到已加载的c，那就会调用findClass进行查找
                // 2.在findClass的过程中，如果指定目录下没有，就会抛出异常ClassNotFoundException
                // 3.抛出异常后，此层调用结束，接着其子加载器继续进行findClass操作
                long t1 = System.nanoTime();
                c = findClass(name);

                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

private Class<?> findBootstrapClassOrNull(String name)
{
    if (!checkName(name)) return null;
    return findBootstrapClass(name);
}
    
private native Class<?> findBootstrapClass(String name);

使用双亲委托机制的原因?

避免重复加载，如果已经加载过一次Class，就不需要再次加载，而是先从缓存中直接读取。
安全方面的考虑，如果不使用双亲委托模式，就可以自定义一个String类来替代系统的String类，这样便会造成安全隐患，采用双亲委托模式会使得系统的String类在Java虚拟机启动时就被加载，也就无法自定义String类来替代系统的String类。

由不同的类加载器加载的类会被JVM当成同一个类吗？