JVM 类的加载器分类与测试

文章目录

1. 类加载器父类说明
2. 子父类加载器关系
3. 具体类的加载器介绍
- 3.1 引导类加载器
- 3.2 扩展类加载器
- 3.3 系统类加载器
4. 用户自定义类加载器
5. 测试不同的类加载器

在这里插入图片描述

1. 类加载器父类说明

JVM 支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）。

从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。

无论类加载器的类型如何划分，在程序中我们最常见的类加载器结构主要是如下情况：

在这里插入图片描述

2. 子父类加载器关系

除了顶层的启动类加载器外，其余的类加载器都应当有自己的 “父类” 加载器。

不同类加载器看似是继承（Inheritance）关系，实际上是包含关系。在下层加载器中，包含着上层加载器的引用。

3. 具体类的加载器介绍

3.1 引导类加载器

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

3.2 扩展类加载器

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

3.3 系统类加载器

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

4. 用户自定义类加载器

● 在 Java 的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的。在必要时，我们还可以自定义类加载器，来定制类的加载方式。

● 体现Java语言强大生命力和巨大魅力的关键因素之一便是,Java开发者可以自定义类加载器来实现类库的动态加载，加载源可以是本地的JAR包，也可以是网络上的远程资源。

● 通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现。

● 同时，自定义加载器能够实现应用隔离，例如 Tomcat，Spring等中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C++程序要好太多，想不修改C/C++程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想。

● 所有用户自定义类加载器通常需要继承于抽象类java.lang.ClassLoader。

5. 测试不同的类加载器

每个 Class 对象都会包含一个定义它的 ClassLoader 的一个引用。

获取 ClassLoader 的途径

//获得当前类的ClassLoader
clazz.getClassLoader()//获得当前线程上下文的ClassLoader
Thread.currentThread().getContextClassLoader()//获得系统的ClassLoader
ClassLoader.getSystemClassLoader()