4. 类的加载器

最新推荐文章于 2024-09-11 09:50:45 发布

曾令炜

最新推荐文章于 2024-09-11 09:50:45 发布

阅读量1.8k

点赞数

文章标签： jvm java 面试

本文链接：https://blog.csdn.net/SXJMXL/article/details/127014975

版权

4. 类的加载器

4.1 概述

类的加载器是JVM执行类加载机制的前提

ClassLoader的作用：

ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进行加载的.ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader去改变类的链接和初始化行为。至于它是否可以运行，则由Execution Engine决定。

图示：

在这里插入图片描述

何为类的唯一性：

对于任意一个类都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相同。

命名空间：

①每个类加载器都有自己的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成
②在同一命名空间中，不会出现类的完整名字(包括类的包名)相同的两个类
③在不同的命名空间中，有可能会出现类的完整名字(包括类的包名)相同的两个类

类加载机制的基本特征：

①双亲委派模型。但不是所有类加载器都遵守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以在标准API框架上，提供自己的实现，JDK也需要提供些默认的参考实现。例如：Java中JNDI、JDBC、文件系统、Cipher等多个方面，都是利用的这种机制，这种情况就不会用双亲委派模型去加载，而是利用所谓的上下文加载。
②可见性。子类加载器可以访问父加载器加载的类型，但是反过来是不允许的。不然，因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器逻辑。
③单一性。由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载。但是注意，类加载器"邻居"间，同一类型任然可以被加载多次，因为互相并不可见。

4.2 类加载器分类

JVM支持两种类型的类加载器，分为引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined ClassLoader)
从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分，在程序中我们最常见的类加载器结构主要是如下情况：

在这里插入图片描述

· 除了顶层的启动类加载器外，其余的类加载器都应当有自己的"父类"加载器
· 不同类加载器看似继承(Inheritance)关系，实际上是包含关系。在下层加载器中，包含着上层加载器引用。

启动类加载器(引导类加载器，Bootstrap ClassLoader):

①这个类加载器使用C/C++语言实现的，嵌套在JVM内部。
②它用来加载Java核心库(JAVA_HOME/jre/lib/rt.jar或sun.boot.class.path路径下的内容)。用于提供JVM自身需要类。
③并不继承自java.lang.ClassLoader,没有父加载器
④出于安全性考虑，Bootstrap启动类加载器只加载包名为java/javax/sun开头的类
⑤加载扩展类和应用程序类加载器，并指定为它们的父类加载器

扩展类加载器(Extension ClassLoader)：

①Java语言编写，由sun.misc.Launcher $ ExtClassLoader实现
②继承于ClassLoader类
③父类加载器为启动类加载器
④从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录jre/lib/ext子目录下加载类库。如果用户创建的JAR放在次目录下，也会自动由扩展类加载器加载

应用程序类加载器(系统类加载器，AppClassLoader):

①java语言编写，由sun.misc.Launcher $ ExtClassLoader实现
②继承于ClassLoader类
③父类加载器为扩展类加载器
④它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
⑤应用程序中的类加载器默认是系统类加载器
⑥它是用户自定义类加载器的默认父加载器
⑦通过ClassLoader的getSystemClassLoader()方法可以获得到该类加载器

用户自定义类加载器：

①在Java的日常应用程序开发中，类的加载器几乎是由上述3种类加载器相互配合执行的。在必要的时候，我们还可以自定义类加载器，来制定的加载方式
②体现Java语言强大生命力和巨大魅力的关键因数之一便是，Java开发者可以自定义类加载器来实现类库的动态加载，加载源可以是本地的JAR包，也可以是网络上的远程资源
③通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加功能的机制，这种机制无需重新打包发布应用程序就能实现
④同时，自定义加载器能够实现应用隔离，例如Tomcat/Spring等中间件和组成框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同组件模块。这种机制比C/C++程序要好太多，想不修改C/C++程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便可阻挡住所有美好的设想
⑤自定义类的加载器通常需要继承于ClassLoader

4.3 ClassLoader源码解析

ClassLoader与现有类加载器的关系：

在这里插入图片描述

除了上述虚拟机自带的加载器外，用户还可以自定义类加载器。Java提供了抽象类java.lang.ClassLoader,所有用户自定义的类加载器都应该继承ClassLoader类

抽象类ClassLoader的主要方法(内部没有抽象方法)：

· public final ClassLoader getParent() : 返回该类加载器的超类加载器
· public Class<?> loadClass(String name) throws ClassNotFoundException : 加载名称为name的类，返回结果为 java.lang.Class类的实例。如果找不到类，则返回ClassNotFoundException异常。该方法中的逻辑就是双亲委派机制的实现。 · protected Class<?> findClass(String name) throws ClassNotFoundException : 查找二进制名称为name的类，返回结果为java.lang.Class类的实例。这是一个受保护的方法，JVM鼓励我们重写这个方法，需要自定义加载器遵循双亲委派机制，该方法会在检查完成父类加载器之后被loadClass()方法调用
· protected final Class<?> defineClass(String name,byte[] b,int off,int len) : 根据给定的字节数组b转换为Class的实例，off和len参数表示实际Class信息在byte数组中的位置和长度，其中byte数组b是ClassLoader从外部获取的。这是受保护的方法，只有在自定义ClassLoader子类中可以使用

ClassLoader子类剖析：

在这里插入图片描述

Class.forName()与ClassLoader.loadClass():
在这里插入图片描述

4.4 双亲委派模型

类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。

定义：

如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成次加载任务时，才自己去加载。

本质：

规定了类加载的顺序是：引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

在这里插入图片描述

双亲委派的优势：

· 避免类的重复加载，确保一个类的全局唯一性。Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关系可以避免类的重复加载，当父亲已经加载了该类时，就没必要子ClassLoader再加载一次。
· 保护程序安全性，防止核心API被随意篡改

代码支持：

双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)接口中体现。该接口的逻辑如下：
①先在当前加载器的缓存中查找有无目标类，如果有，直接返回
②判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name,false)接口进行加载
③反之，如果当前加载器的父类加载器为空，则调用findBootstrapClassOrNull(name)接口，让引导类加载器加载
④如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类。双亲委派的模型就隐藏在②③中

举例：

假设当前加载的是java.lang.Object这个类，很显然，该类属于JDK核心的一个类，因此一定只能由引导类加载器加载。当JVM准备加载java.lang.Object时，JVM默认会使用系统类加载器去加载，按照上面的四个步骤的逻辑，在第一步从系统类的缓存中肯定查找不到该类，于是进入第二步，由于从系统类加载器的父加载器是扩展类加载器，于是扩展类加载器继续从第一步开始重复。由于扩展类加载器的缓存中也一定查找不到该类，因此进入第二步，扩展类的父亲加载器是null，因此系统调用findClass(String),最终通过引导类加载器进行加载。

思考：

如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)或java.lang.ClassLoader.loadClass(String, boolean)方法,抹去其中的双亲委派机制,仅保留上面这4步中的第1步与第4步，那么是不是就能够加载核心类库了呢?
这也不行! 因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器抑或扩展类加载器，最终都必须调用java.lang.ClassLoader.defineClass(String, byte[],int,int,ProtectionDomain)方法，而该方法会执行preDefineClass()接口，该接口中提供了对JDK核心类库的保护。

双亲委派模式的弊端：

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

破坏双亲委派机制一：

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远古”时代。由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就己经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免1oadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

破坏双亲委派机制二：

在这里插入图片描述

破坏双亲委派机制三：

在这里插入图片描述

4.5 沙箱安全机制

沙箱安全机制概述：

· 保证程序安全性
· 保护Java原生的JDK代码

Java安全模型的核心就是Java沙箱(sandbox)。什么是沙箱？沙箱是一个限制程序运行的环境。

沙箱机制就是将Java代码限定在虚拟机（JVM）特定的运行范围中，并且严格限制代码对本地系统资源访问。通过这样的措施来保证对代码的有限隔离，防止对本地系统造成破坏。

沙箱主要限制系统资源访问，那系统资源包括什么? CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。

所有的Java程序运行都可以指定沙箱，可以定制安全策略。

JDK1.0沙箱机制：

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

在这里插入图片描述

JDK1.1沙箱机制：

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

在这里插入图片描述

JDK1.2沙箱机制：

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

在这里插入图片描述

JDK1.6沙箱机制：

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

在这里插入图片描述