java安全沙箱（一）之ClassLoader双亲委派机制

 java是一种类型安全的语言，它有四类称为安全沙箱机制的安全机制来保证语言的安全性，这四类安全沙箱分别是：

本篇博客主要介绍“类加载体系”的基本原理；如需了解其它几类安全机制可以通过上面的博客链接进入查看。

简介

 

  • 前置知识： JDK中默认类加载器有三个：AppClassLoader、Ext ClassLoader、BootStrap ClassLoader。AppClassLoader的父加载器为Ext ClassLoader、Ext ClassLoader的父加载器为BootStrap ClassLoader。这里的父子关系并不是通过继承实现的，而是组合。

  • 什么是双亲委派机制： 加载器在加载过程中，先把类交由父类加载器进行加载，父类加载器没找到才由自身加载。

  • 双亲委派机制目的： 为了防止内存中存在多份同样的字节码（安全），使用双亲委派机制（它不会自己去尝试加载类，而是把请求委托给父加载器去完成，依次向上）

  • 类加载规则： 如果一个类由类加载器A加载，那么这个类的依赖类也是由「相同的类加载器」加载。

  • 如何打破双亲委派机制： 自定义ClassLoader，重写loadClass方法（只要不依次往上交给父加载器进行加载，就算是打破双亲委派机制）

  • 打破双亲委派机制案例： Tomcat

    • 为了Web应用程序类之间隔离，为每个应用程序创建WebAppClassLoader类加载器
    • 为了Web应用程序类之间共享，把ShareClassLoader作为WebAppClassLoader的父类加载器，如果WebAppClassLoader加载器找不到，则尝试用ShareClassLoader进行加载
    • 为了Tomcat本身与Web应用程序类隔离，用CatalinaClassLoader类加载器进行隔离，CatalinaClassLoader加载Tomcat本身的类
    • 为了Tomcat与Web应用程序类共享，用CommonClassLoader作为CatalinaClassLoader和ShareClassLoader的父类加载器
    • ShareClassLoader、CatalinaClassLoader、CommonClassLoader的目录可以在Tomcat的catalina.properties进行配置

  • 线程上下文加载器： 由于类加载的规则，很可能导致父加载器加载时依赖子加载器的类，导致无法加载成功（BootStrap ClassLoader无法加载第三方库的类），所以存在「线程上下文加载器」来进行加载。

 

“类加载体系”及ClassLoader双亲委派机制。java程序中的 .java文件编译完会生成 .class文件，而 .class文件就是通过被称为类加载器的ClassLoader加载的，而ClassLoder在加载过程中会使用“双亲委派机制”来加载 .class文件，先上图：

看着图从上往下介绍：

  1. BootStrapClassLoader：启动类加载器，该ClassLoader是jvm在启动时创建的，用于加载 $JAVA_HOME/jre/lib下面的类库（或者通过参数-Xbootclasspath指定）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不能直接通过引用进行操作。--jdk中的本地方法类一般由它加载

  2. ExtClassLoader：扩展类加载器，该ClassLoader是在sun.misc.Launcher里作为一个内部类ExtClassLoader定义的（即 sun.misc.Launcher$ExtClassLoader），ExtClassLoader会加载 $JAVA_HOME/jre/lib/ext下的类库（或者通过参数-Djava.ext.dirs指定）。--jdk中内部实现的扩展类一般由它加载

  3. AppClassLoader：应用程序类加载器，该ClassLoader同样是在sun.misc.Launcher里作为一个内部类AppClassLoader定义的（即 sun.misc.Launcher$AppClassLoader），AppClassLoader会加载java环境变量CLASSPATH所指定的路径下的类库，而CLASSPATH所指定的路径可以通过System.getProperty("java.class.path")获取；当然，该变量也可以覆盖，可以使用参数-cp，例如：java -cp 路径 （可以指定要执行的class目录）。--程序中的类文件一般由它加载

  4. CustomClassLoader：自定义类加载器，该ClassLoader是指我们自定义的ClassLoader，比如tomcat的StandardClassLoader属于这一类；当然，大部分情况下使用AppClassLoader就足够了。

ClassLoader初始化源码

下面贴下jdk关于类加载的源码，上述四种类加载器中CustomClassLoader是用户自定义的，BootStrapClassLoader是jvm创建的，就不展示了；这里展示下AppClassLoader和ExtClassLoader的启动过程，前面介绍过，AppClassLoader和ExtClassLoader都是在sun.misc.Launcher里定义的，而我的sun.misc.Launcher没有源码，大家将就看看反编译的代码吧。如果想看sun.*包下的类源码，大家可以下载openjdk来查看。

public Launcher(){
        ExtClassLoader extclassloader;
        try{
            extclassloader = ExtClassLoader.getExtClassLoader();
        }
        catch(IOException ioexception) {
            throw new InternalError("Could not create extension class loader");
        }
        try{
            loader = AppClassLoader.getAppClassLoader(extclassloader);
        }
        catch(IOException ioexception1){
            throw new InternalError("Could not create application class loader");
        }
        Thread.currentThread().setContextClassLoader(loader);
        String s = System.getProperty("java.security.manager");
        if(s != null){
            SecurityManager securitymanager = null;
            if("".equals(s) || "default".equals(s))
                securitymanager = new SecurityManager();
            else
                try{
                    securitymanager = (SecurityManager)loader.loadClass(s).newInstance();
                }
                catch(IllegalAccessException illegalaccessexception) { }
                catch(InstantiationException instantiationexception) { }
                catch(ClassNotFoundException classnotfoundexception) { }
                catch(ClassCastException classcastexception) { }
            if(securitymanager != null)
                System.setSecurityManager(securitymanager);
            else
                throw new InternalError((new StringBuilder()).append("Could not create SecurityManager: ").append(s).toString());
        }
    }

可以看到在Launcher构造函数的执行过程如下：

  1. 通过ExtClassLoader.getExtClassLoader()创建了ExtClassLoader；

  2. 通过AppClassLoader.getAppClassLoader(ExtClassLoader)创建了AppClassLoader，并将ExtClassLoader设为AppClassLoader的parent ClassLoader；

  3. 通过Thread.currentThread().setContextClassLoader(loader)把AppClassLoader设为线程的上下文 ClassLoader；

  4. 根据jvm参数-Djava.security.manager创建安全管理器（安全管理器的相关内容会在后续博客安全管理器及Java API中介绍），此时jvm会设置系统属性"java.security.manager"为空字符串""。

再贴下ExtClassLoader源码：

public static ExtClassLoader getExtClassLoader()
            throws IOException{
            File afile[] = getExtDirs();
            return (ExtClassLoader)AccessController.doPrivileged(new PrivilegedExceptionAction(afile) {
                public Object run() throws IOException{
                    int i = dirs.length;
                    for(int j = 0; j < i; j++)
                        MetaIndex.registerDirectory(dirs[j]);
                    return new ExtClassLoader(dirs);
                }

                final File val$dirs[];

                {
                    dirs = afile;
                    super();
                }
            });
            PrivilegedActionException privilegedactionexception;
            privilegedactionexception;
            throw (IOException)privilegedactionexception.getException();
        }
        
private static File[] getExtDirs()
        {
            String s = System.getProperty("java.ext.dirs");
            File afile[];
            if(s != null)
            {
                StringTokenizer stringtokenizer = new StringTokenizer(s, File.pathSeparator);
                int i = stringtokenizer.countTokens();
                afile = new File[i];
                for(int j = 0; j < i; j++)
                    afile[j] = new File(stringtokenizer.nextToken());

            } else
            {
                afile = new File[0];
            }
            return afile;
        }

反编译的源码，大家将就看下；这里大家关注下getExtDirs()这个方法，它会获取属性"java.ext.dirs"所对应的值，然后通过系统分隔符分割，然后加载分割后的字符串对应的目录作为ClassLoader的类加载库。

下面看看AppClassLoader源码：

public static ClassLoader getAppClassLoader(ClassLoader classloader) throws IOException{
            String s = System.getProperty("java.class.path");
            File afile[] = s != null ? Launcher.getClassPath(s) : new File[0];
            return (AppClassLoader)AccessController.doPrivileged(new PrivilegedAction(s, afile, classloader) {
                public Object run() {
                    URL aurl[] = s != null ? Launcher.pathToURLs(path) : new URL[0];
                    return new AppClassLoader(aurl, extcl);
                }

                final String val$s;
                final File val$path[];
                final ClassLoader val$extcl;

                {
                    s = s1;
                    path = afile;
                    extcl = classloader;
                    super();
                }
            });
        }

首先获取"java.class.path"对应的属性，并转换为URL[]并设置为ClassLoader的类加载库，注意这里的方法入参classloader就是ExtClassLoader，在创AppClassLoader会传入ExtClassLoader作为parent ClassLoader。

上面就是ClassLoader的启动和初始化过程，后面会把loader作为应用程序的默认ClassLoader使用，看下面的测试用例:

package com.jvm.study.classload;

public class Test {
    public static void main(String... args) {
        ClassLoader loader = Test.class.getClassLoader();
        System.err.println("loader:"+loader);
        while (loader != null) {
            loader = loader.getParent();
            System.err.println("in while:"+loader);
        }
    }
}

可以看到ClassLoader的层次结构，输出结果为：

ClassLoader双亲委派机制源码

前面谈到了ClassLoader的几类加载器，而ClassLoader使用双亲委派机制来加载class文件的。

ClassLoader的双亲委派机制是这样的（这里先忽略掉自定义类加载器CustomClassLoader）：

  1. 当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。

  2. 当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。

  3. 如果BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载；

  4. 若ExtClassLoader也加载失败，则会使用AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。

下面贴下ClassLoader的loadClass(String name, boolean resolve)源码：

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        // First, check if the class has already been loaded
        Class c = findLoadedClass(name);
        if (c == null) {
            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.
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }

代码很明朗：首先找缓存（findLoadedClass），没有的话就判断有没有parent，有的话就用parent来递归的loadClass，然而ExtClassLoader并没有设置parent，则会通过findBootstrapClassOrNull来加载class，而findBootstrapClassOrNull则会通过JNI方法”private native Class findBootstrapClass(String name)“来使用BootStrapClassLoader来加载class。

然后如果parent未找到class，则会调用findClass来加载class，findClass是一个protected的空方法，可以覆盖它以便自定义class加载过程。

另外，虽然ClassLoader加载类是使用loadClass方法，但是鼓励用 ClassLoader 的子类重写 findClass(String)，而不是重写loadClass，这样就不会覆盖了类加载默认的双亲委派机制。

双亲委派机制为什么安全

前面谈到双亲委派机制是为了安全而设计的，但是为什么就安全了呢？举个例子，ClassLoader加载的class文件来源很多，比如编译器编译生成的class、或者网络下载的字节码。而一些来源的class文件是不可靠的，比如我可以自定义一个java.lang.Integer类来覆盖jdk中默认的Integer类，例如下面这样：

package java.lang;

/**
 * hack
 */
public class Integer {
    public Integer(int value) {
        System.exit(0);
    }
}

初始化这个Integer的构造器是会退出JVM，破坏应用程序的正常进行，如果使用双亲委派机制的话该Integer类永远不会被调用，以为委托BootStrapClassLoader加载后会加载JDK中的Integer类而不会加载自定义的这个，可以看下下面这测试个用例：

        public static void main(String... args) {
        Integer i = new Integer(1);
        System.err.println(i);
    }

执行时JVM并未在new Integer(1)时退出，说明未使用自定义的Integer，于是就保证了安全性。

 

打破双亲委派机制

意思就是：只要我加载类的时候，不是从APPClassLoader->Ext ClassLoader->BootStrap ClassLoader 这个顺序找，那就算是打破了。

因为加载class核心的方法在LoaderClass类的loadClass方法上（双亲委派机制的核心实现），可看上面的源码

只要我自定义个ClassLoader，重写loadClass方法（不依照往上开始寻找类加载器），那就算是打破双亲委派机制了。

Tomcat场景（破坏了双亲委派机制）

我们是把war包放到tomcat的webapp下，这意味着一个tomcat可以运行多个Web应用程序，假设我现在有两个Web应用程序，它们都有一个类，叫做User，并且它们的类全限定名都一样，比如都是com.yyy.User。但是他们的具体实现是不一样的。那么Tomcat是如何保证它们是不会冲突的呢？

答案就是，Tomcat给每个 Web 应用创建一个类加载器实例（WebAppClassLoader），该加载器重写了loadClass方法，优先加载当前应用目录下的类，如果当前找不到了，才一层一层往上找，那这样就做到了Web应用层级的隔离。如下图：

 

 

注意：

一、并不是Web应用程序下的所有依赖都需要隔离的，比如Redis就可以Web应用程序之间共享（如果有需要的话），因为如果版本相同，没必要每个Web应用程序都独自加载一份啊。做法也很简单，Tomcat就在WebAppClassLoader上加了个父类加载器（SharedClassLoader），如果WebAppClassLoader自身没有加载到某个类，那就委托SharedClassLoader去加载。无非就是把需要应用程序之间需要共享的类放到一个共享目录下。

二、为了隔绝Web应用程序与Tomcat本身的类，又有类加载器(CatalinaClassLoader)来装载Tomcat本身的依赖，如果Tomcat本身的依赖和Web应用还需要共享，那么还有类加载器(CommonClassLoader)来装载进而达到共享，各个类加载器的加载目录可以到tomcat的catalina.properties配置文件上查看，Tomcat的类加载结构图：

 

 

 参考：https://mp.weixin.qq.com/s/9mojzm8URjNRBg3r8BamdQ

 

 

 

 

posted on 2016-11-28 10:00  duanxz  阅读(5614)  评论(0)  编辑  收藏  举报

Powered by: 博客园 Copyright © 2024 duanxz
Powered by .NET 8.0 on Kubernetes