尚硅谷2020最新版宋红康JVM教程-中篇-第4章:再谈类的加载器-06-08

沙箱安全机制

前言

• 沙箱安全机制
  • 保证程序安全
  • 保护Java原生的JDK代码
• Java安全模型的核心就是Java沙箱（sandbox）。什么是沙箱？沙箱是一个限制程序运行的环境。
• 沙箱机制就是将Java代码限定在虚拟机（JVM）特定的运行范围中，并且严格限制代码对本地系统资源访问。通过这样的措施来保证对代码的有限隔离，防止对本地系统造成破坏。
• 沙箱主要限制系统资源访问，那系统资源包括什么？CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。
• 所有的Java程序运行都可以指定沙箱，可以定制安全策略。

JDK1.0时期

在Java中将执行程序分成本地代码和远程代码两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。对于授信的本地代码，可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中，安全依赖于沙箱（Sandbox）机制。如下图所示JDK1.0安全模型

JDK1.1时期

• JDK1.0中如此严格的安全机制也给程序的功能扩展带来障碍，比如当用户希望远程代码访问本地系统的文件时候，就无法实现。
• 因此在后续的Java1.1版本中，针对安全机制做了改进，增加了安全策略。允许用户指定代码对本地资源的访问权限。
• 如下图所示JDK1.1安全模型

JDK1.2时期

在Java1.2版本中，再次改进了安全机制，增加了代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。如下图所示JDK1.2安全模型：

JDK1.6时期

• 当前最新的安全机制实现，则引入了域（Domain）的概念。
• 虚拟机会把所有代码加载到不同的系统域和应用域。系统域部分专门负责与关键资源进行交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域（Protected Domain），对应不一样的权限（Permission）。存在于不同域中的类文件就具有了当前域的全部权限，如下图所示，最新的安全模型（jdk1.6）
  

域A(权限组x)是一个应用域

自定义类的加载器

自定义类加载器的好处和应用场景

为什么要自定义类加载器？

• 隔离加载类
  • 在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如:阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如:Tomcat这类Web应用服务器，内部自定义了好几种类加载器，用于隔离同一个Web应用服务器上的不同应用程序。
• 修改类加载的方式
  • 类的加载模型并非强制，除Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载
• 扩展加载源
  • 比如从数据库、网络、甚至是电视机机顶盒进行加载
• 防止源码泄漏
  • Java代码容易被编译和篡改，可以进行编译加密。那么类加载也需要自定义，还原加密的字节码。

常见的场景

• 实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面的集大成者是JavaEE和OSGI、JPMS等框架。
• 应用需要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统。或者是需要自己操纵字节码，动态修改或者生成类型。

注意

在一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。但是，如果涉及Java类型转换，则加载器反而容易产生不美好的事情。在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能进行类型转换，否则转换时会发生异常。

自定义类加载器的代码实现

实现方式

• Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。
• 在自定义ClassLoader的子类时候，我们常见的会有两种做法:
  • 方式一:重写loadClass()方法
  • 方式二:重写findclass()方法

对比

• 这两种方法本质上差不多，毕竟loadClass()也会调用findClass()，但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。建议的做法是只在findClass()里重写自定义类的加载方法，根据参数指定类的名字，返回对应的Class对象的引用。
• loadclass()这个方法是实现双亲委派模型逻辑的地方，擅自修改这个方法会导致模型被破坏，容易造成问题。因此我们最好是在双亲委派模型框架内进行小范围的改动，不破坏原有的稳定结构。同时，也避免了自己重写loadClass()方法的过程中必须写双亲委托的重复代码，从代码的复用性来看，不直接修改这个方法始终是比较好的选择。
• 当编写好自定义类加载器后，便可以在程序中调用loadClass()方法来实现类加载操作。

说明

• 其父类加载器是系统类加载器
• JVM中的所有类加载都会使用java.lang.ClassLoader.loadClass(String)接口(自定义类加载器并重写java.lang.ClassLoader.loadClass(String)接口的除外)，连JDK的核心类库也不能例外。

代码举列-自定义类加载器

package T1;

import com.sun.xml.internal.messaging.saaj.util.ByteOutputStream;

import java.io.BufferedInputStream;
import java.io.ByteArrayOutputStream;
import java.io.FileInputStream;
import java.io.IOException;

public class MyClassLoad2 extends ClassLoader {

    private String byteCodePath;

    public MyClassLoad2(String byteCodePath) {
        this.byteCodePath = byteCodePath;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        BufferedInputStream bufferedInputStream = null;
        ByteArrayOutputStream byteOutputStream = null;
        try {
            // 获取完整的字节码文件路径+class文件名
            String fileName = byteCodePath + name.replace('.', '\\') + ".class";

            // 获取一个输入流
            bufferedInputStream = new BufferedInputStream(new FileInputStream(fileName));

            // 获取一个输出流
            byteOutputStream = new ByteArrayOutputStream();
            // 具体读取数据并写出的过程
            int len;
            byte[] data = new byte[1024];
            while ((len = bufferedInputStream.read(data)) != -1) {
                byteOutputStream.write(data, 0, len);
            }
            // 将输出流转成数组
            byte[] byteCode = byteOutputStream.toByteArray();

            // 调用defineClass()，将字节数组转成Class实列
            Class<?> aClass = defineClass(null, byteCode, 0, byteCode.length);
            return aClass;

        } catch (IOException e) {
            e.printStackTrace();
        } finally {

            try {
                if (bufferedInputStream != null) {
                    bufferedInputStream.close();
                }

            } catch (IOException e) {
                e.printStackTrace();
            }
            try {
                if (byteOutputStream != null) {
                    byteOutputStream.close();
                }

            } catch (IOException e) {
                e.printStackTrace();
            }
        }
        return null;
    }
}

package T1;

public class MyClassLoad2Test {
    public static void main(String[] args) throws ClassNotFoundException {
        MyClassLoad2 myClassLoad2 = new MyClassLoad2("D:\\apache-maven-3.6.3\\maven_repo\\jvm\\jvm1\\src\\main\\webapp\\java\\");
        Class<?> myClassLoad2Class = myClassLoad2.findClass("T1.Demo1");
        System.out.println(myClassLoad2Class.getClassLoader().getClass().getName()); // T1.MyClassLoad2
        System.out.println(myClassLoad2Class.getClassLoader().getParent().getClass().getName()); // sun.misc.Launcher$AppClassLoader
    }
}

Java9新特性

引言

• 为了保证兼容性，JDK9没有从根本上改变三层类加载器架构和双亲委派模型，但为了模块化系统的顺利运行，仍然发生了一些值得被注意的变动。

变化

• 扩展机制被移除，扩展类加载器由于向后兼容性的原因被保留，不过被重命名为平台类加载器(platform class loader)。可以通过classLoader的新方法getPlatformClassLoader()来获取。

  • JDK9时基于模块化进行构建(原来的rt.jar和tools.jar被拆分成数十个JMOD文件)，其中的Java类库就已天然地满足了可扩展的需求，那自然无须再保留<JAVA_HOME>\lib\ext目录，此前使用这个目录或者java.ext.dirs系统变量来扩展JDK功能的机制已经没有继续存在的价值了。
    

• 平台类加载器和应用程序类加载器都不再继承自java.net.URLClassLoader。

  • 现在启动类加载器、平台类加载器、应用程序类加载器全都继承于jdk.internal.loader.BuiltinClassLoader。

如果有程序直接依赖了这种继承关系，或者依赖了URLClassLoaderI类的特定方法，那代码很可能会在JDK9及更高版本的JDK中崩溃。

• 3.在Java9中，类加载器有了名称。该名称在构造方法中指定，可以通过getName()方法来获取。平台类加载器的名称是platform，应用类加载器的名称是app。类加载器的名称在调试与类加载器相关的问题时会非常有用。
• 4.启动类加载器现在是在jvm内部和java类库共同协作实现的类加载器（以前是C++实现），但为了与之前代码兼容，在获取启动类加载器的场景中仍然会返回null，而不会得到BootClassLoader实例。
• 5.类加载的委派关系也发生了变动。当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。