手撸jdk源码分析类加载机制

  我们一般写的java文件jvm是识别不了的,因此需要编译,编译后会变成.class文件,而要执行代码,jvm首先会去加载.class文件到内存中,那么他的流程是什么样的呢:

  1.首先肯定创建java虚拟机(就像我们运行windows的程序首先得安装windows系统一个道理) 

  2.同时会创建一个引导类加载器实例(这个由c++实现,也就是我们的BootStrap类加载器)

  3.然后c++代码会调用创建java的启动类launcher创建类加载器,去加载不同类型的类

  4.类加载完成会调用对应的main方法

  5.运行后销毁

流程如下图所示:

 

 

 具体的类加载流程:加载>>验证>>准备>>解析>>初始化>>使用>>卸载    

1.加载:加载就是找到对应的字节码文件并加载到内存

2.验证: 验证字节码文件的格式等正确性

3.准备:加载静态变量到内存并赋值

4.解析:将符号引用转换为直接引用(内存地址)

5.初始化: 将类加载到方法区,执行静态代码块,初始化静态变量值

大概了解之后,我们直接撸代码:

public Launcher() {
        Launcher.ExtClassLoader var1;
        try {
            //获取扩展类加载器extclassLoader
            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);
        }

        Thread.currentThread().setContextClassLoader(this.loader);
        String var2 = System.getProperty("java.security.manager");
        if (var2 != null) {
            SecurityManager var3 = null;
            if (!"".equals(var2) && !"default".equals(var2)) {
                try {
                    var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();  //加载
                } catch (IllegalAccessException var5) {
                } catch (InstantiationException var6) {
                } catch (ClassNotFoundException var7) {
                } catch (ClassCastException var8) {
                }
            } else {
                var3 = new SecurityManager();
            }

            if (var3 == null) {
                throw new InternalError("Could not create SecurityManager: " + var2);
            }

            System.setSecurityManager(var3);
        }

    }
    
    
    public ExtClassLoader(File[] var1) throws IOException {
            super(getExtURLs(var1), (ClassLoader)null, Launcher.factory);//这里可以看到ext的父类加载器设为null
            SharedSecrets.getJavaNetAccess().getURLClassPath(this).initLookupCache(this);
        }
        
    AppClassLoader(URL[] var1, ClassLoader var2) {  //这里可以看到app的父类加载器就是上面传进来的var1->extClassLoader
            super(var1, var2, Launcher.factory);
            this.ucp.initLookupCache(this);
        }

这就可以看到应用类加载器的父类加载器是扩展类加载器,继续看加载流程,看appClassLoader的loadClass方法:

public Class<?> loadClass(String var1, boolean var2) throws ClassNotFoundException {
            int var3 = var1.lastIndexOf(46);
            if (var3 != -1) {
                SecurityManager var4 = System.getSecurityManager();
                if (var4 != null) {
                    var4.checkPackageAccess(var1.substring(0, var3));
                }
            }

            if (this.ucp.knownToNotExist(var1)) {  //查看是否已经被加载过,获取存在直接
                Class var5 = this.findLoadedClass(var1);
                if (var5 != null) {
                    if (var2) {
                        this.resolveClass(var5);
                    }

                    return var5;
                } else {
                    throw new ClassNotFoundException(var1);
                }
            } else { //不存在调用父类
                return super.loadClass(var1, var2);
            }
        }

再看父类,extClassLoader调用的也是这个:

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);  //查询JVM,已经被加载并返回,否则返回null
            if (c == null) { //不存在
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {  //有父调用父类加载器
                        c = parent.loadClass(name, false);
                    } else { //当父类加载器不存在,如extClassLoad设置父类为null(其实是有的,但其父类bootStrapClassLoad在JVM中由c++实现,所以设置为null)
                        c = findBootstrapClassOrNull(name); //这里点进去看可以发现其实就是获取BootStrapClass
                    }
                } 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;
        }
    }

这里我们可以理一下顺序:

1.首先会去调用appClassLoad的loadClass方法,如果已经加载过,则直接获取,否则调用父加载方法

2.父类方法依旧会找一次当然还是没有,会去调用父类加载器的loadClass方法(前面我们已经知道appClassLoad父加载器为extClassLoad)

3.递归调用classLoad方法,直到父加载器为空(也就是extClassLoad),会去获取BootStrapClass类加载器调用类加载方法

4.还是获取不到则按顺序查找类,这个我们下面详细再看

protected Class<?> findClass(final String name)
        throws ClassNotFoundException
    {
        final Class<?> result;
        try {
            result = AccessController.doPrivileged(
                new PrivilegedExceptionAction<Class<?>>() {
                    public Class<?> run() throws ClassNotFoundException {
                        String path = name.replace('.', '/').concat(".class"); //拼接class文件地址
                        Resource res = ucp.getResource(path, false);  //获取资源
                        if (res != null) {
                            try {
                                return defineClass(name, res);   //解析指定的资源类
                            } catch (IOException e) {
                                throw new ClassNotFoundException(name, e);
                            }
                        } else {
                            return null;
                        }
                    }
                }, acc);
        } catch (java.security.PrivilegedActionException pae) {
            throw (ClassNotFoundException) pae.getException();
        }
        if (result == null) {
            throw new ClassNotFoundException(name);
        }
        return result;
    }

其实就是根据类名拼接class文件地址,并解析指定的资源类,再往下基本就是分析c++代码了,这个后续有时间在研究吧.

看完代码,我们再来看一些我们之前背了又忘的理论:双亲委派机制,那么我们再来分析分析:

双亲委派机制:

   

 

 

 如上图所示,其实就是双亲委派机制,仔细看的话发现和我上面分析代码的逻辑是一样的,是的,上面loadClass递归调用其实就是我们双亲委派机制的实现,而实际的类加载,就在我们的findClass方法里。

 这个时候问题就来了,类加载一个类加载器就够了,为什么要搞这么复杂的结构呢?

  答案其实就是为了安全,可靠。我们java中有很多基础类库如Object类,算是我们开发的基石,但是如果说只用一个编辑器的话,当出现外部也定义了一个相同路径名的类时,就可能覆盖或者冲突,无论哪种情况,都会对我们的程序造成不可控的影响。而像上述图中,每个类加载器各司其职,只专注于做自己的事情,这样既不会改变基础类库,也不会出现重复加载的情况。仔细想想,这也是解耦的思想的体现。

 

双亲委派模型的特色就是,安全,可靠,不会出现重复加载,但是像tomcat这样需要加载多个应用程序的又怎么办呢----->打破双亲委派。

打破双亲委派

双亲委派机制是很厉害的,但jdk也给我们提供了自定义类加载的拓展,其实就是让我们有更多的实现,其实要打破的实现也很简单,就是重写loadClass方法,将所需要打破的直接findClass,而不去调用父类的findClass,代码如下:

 protected Class<?> loadClass(String name, boolean resolve)
                throws ClassNotFoundException {
            synchronized (getClassLoadingLock(name)) {
                Class<?> c = findLoadedClass(name);
                if (c == null) {
                    long t = System.nanoTime();
                    if(!name.startsWith("broker")){  //可以将需要打破双亲委派的单独放一个包里
                        c = super.loadClass(name);
                    }else {
                        c = findClass(name);
                    }
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
                if (resolve) {
                    resolveClass(c);
                }
                return c;
            }
        }

tomcat打破双亲委派:

  tomcat是服务部署容器,首先我们得了解他有哪些问题:

  1.在部署多应用程序时,可能出现多个程序不同版本,因此,每个程序依赖需要相互独立,互相隔离。

  2.相同版本类库不需要重新加载。

  3.web容器和应用容器隔离

  4.jsp文件热加载

 

tomcat为了解决这个问题,肯定是需要打破双亲委派模型的,毕竟应用之间有需要隔离的,web容器和应用容器也需要隔离,而jsp文件预加载则需要改动后卸载掉重新加载,总结一下就是:

第一个问题,如果使用默认的类加载器机制,那么是无法加载两个相同类库的不同版本的,默认的类加器是不管你是什么版本的,只在乎你的全限定类名,并且只有一份。

第二个问题,默认的类加载器是能够实现的,因为他的职责就是保证唯一性。

第三个问题和第一个问题一样。

我们再看第四个问题,我们想我们要怎么实现jsp文件的热加载,jsp文件其实也就是class文件,那么如果修改了,但类名还是一样,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重新加载的。那么怎么办呢?我们可以直接卸载掉这jsp文件的类加载器,所以你应该想到了,每个jsp文件对应一个唯一的类加载器,当一个jsp文件修改了,就直接卸载这个jsp类加载器。重新创建类加载器,重新加载jsp文件。

具体如下图所示:

 

tomcat类加载器分的很多,各司其职,其实我在想,可能一开始tomcat也没有那么多,也许就多一个tomcat类加载器,后来多服务部署发现不同版本兼容性等问题,于是又新增类加载器去隔离,后来jsp出现又新增,慢慢发展到这么复杂的地步吧。

 

 

总结:

  这一章呢,从分析源码入手,讲解了类加载的过程,以及双亲委派模型的实现,从源码角度去看,双亲委派机制还是很好理解的。最后介绍了tomcat如何打破双亲委派机制。类的加载流程很简单,双亲委派机制去加载不同类,但实现很复杂,需要考虑的问题太多,验证,解析等等都是非常复杂的流程。大体上算是了解了,但想理解,可能还是得去撸jvm源码了。

posted @ 2022-02-20 02:22  吃肉不长肉的小灏哥  阅读(187)  评论(0编辑  收藏  举报