一文读懂类加载机制 --- ClassLoader

「已注销」

于 2022-07-11 07:35:00 发布

阅读量1.8k

点赞数

文章标签： jvm java 开发语言

全网优质文章转载收藏，均不代表本人立场！

本文链接：https://blog.csdn.net/lyshark_lyshark/article/details/125848236

版权

From：https://www.cnblogs.com/sunnick/p/9609326.html

【JVM笔记】classloader加载class文件的原理和机制：https://www.jianshu.com/p/52c38cf2e3d4

JVM 架构整体架构

在进入 classloader 分析之前，先了解一下 jvm 整体架构：

JVM 被分为三个主要的子系统

(1)类加载器子系统
(2)运行时数据区
(3)执行引擎

1. 类加载器子系统

大致分为 5 个阶段：

(1)加载：java类运行时候会生成一个class字节码文件，加载的过程就是去我们的操作系统寻找这个class文件。
(2)链接：这个过程就是把class文件加载到java虚拟机。
(3)初始化：在虚拟机中根据class文件进行初始化。
(4)使用：这个过程大家都明白。
(5)卸载：使用完了，java虚拟机进行清理。

对于 class.forName 和 classloader 来说针对的就是第一个过程，也就是加载过程。不过这俩虽然有一定的相似性，但是区别还是挺大的。( https://baijiahao.baidu.com/s?id=1654865863100987859 )

(1)class.forName() 除了将类的.class文件加载到 jvm 中之外，还会对类进行解释，执行类中的 static 块。当然还可以指定是否执行静态块。
(2)classLoader只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。

Java 的动态类加载功能是由类加载器子系统处理。当它在运行时(不是编译时)首次引用一个类时，它加载、链接并初始化该类文件。

1.1 加载

加载：类由此组件加载。启动类加载器 (BootStrap class Loader)、扩展类加载器(Extension class Loader)和应用程序类加载器(Application class Loader) 这三种类加载器帮助完成类的加载。

1. 启动类加载器 – 负责从启动类路径中加载类，无非就是rt.jar。这个加载器会被赋予最高优先级。
2. 扩展类加载器 – 负责加载ext 目录(jre\lib)内的类.
3. 应用程序类加载器 – 负责加载应用程序级别类路径，涉及到路径的环境变量等etc.上述的类加载器会遵循委托层次算法(Delegation Hierarchy Algorithm)加载类文件，这个在后面进行讲解。

加载过程主要完成三件事情：

通过类的全限定名来获取定义此类的二进制字节流
将这个类字节流代表的静态存储结构转为方法区的运行时数据结构
在堆中生成一个代表此类的java.lang.Class对象，作为访问方法区这些数据结构的入口。

1.2 链接

校验 – 字节码校验器会校验生成的字节码是否正确，如果校验失败，我们会得到校验错误。

文件格式验证：基于字节流验证，验证字节流符合当前的Class文件格式的规范，能被当前虚拟机处理。验证通过后，字节流才会进入内存的方法区进行存储。
元数据验证：基于方法区的存储结构验证，对字节码进行语义验证，确保不存在不符合java语言规范的元数据信息。
字节码验证：基于方法区的存储结构验证，通过对数据流和控制流的分析，保证被检验类的方法在运行时不会做出危害虚拟机的动作。
符号引用验证：基于方法区的存储结构验证，发生在解析阶段，确保能够将符号引用成功的解析为直接引用，其目的是确保解析动作正常执行。换句话说就是对类自身以外的信息进行匹配性校验。

准备 – 分配内存并初始化默认值给所有的静态变量。

public static int value=33;

这据代码的赋值过程分两次，
一是上面我们提到的阶段，此时的value将会被赋值为0；
二是 value=33 这个过程发生在类构造器的<clinit>()方法中。

解析所有符号内存引用被方法区(Method Area)的原始引用所替代。

举个例子来说明，在com.sbbic.Person类中引用了com.sbbic.Animal类，在编译阶段，Person类并不知道Animal的实际内存地址，因此只能用com.sbbic.Animal来代表Animal真实的内存地址。在解析阶段，JVM可以通过解析该符号引用，来确定com.sbbic.Animal类的真实内存地址(如果该类未被加载过，则先加载)。

主要有以下四种：类或接口的解析，字段解析，类方法解析，接口方法解析

1.3 初始化

初始化：这是类加载的最后阶段，这里所有的静态变量会被赋初始值, 并且静态块将被执行。

java中，对于初始化阶段，有且只有**以下五种情况才会对要求类立刻初始化：

使用new关键字实例化对象、访问或者设置一个类的静态字段(被final修饰、编译器优化时已经放入常量池的例外)、调用类方法，都会初始化该静态字段或者静态方法所在的类；
初始化类的时候，如果其父类没有被初始化过，则要先触发其父类初始化；
使用java.lang.reflect包的方法进行反射调用的时候，如果类没有被初始化，则要先初始化；
虚拟机启动时，用户会先初始化要执行的主类(含有main)；
jdk 1.7后，如果java.lang.invoke.MethodHandle的实例最后对应的解析结果是 REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄，并且这个方法所在类没有初始化，则先初始化；

2.运行时数据区(Runtime Data Area)

The 运行时数据区域被划分为5个主要组件：

① 方法区 (线程共享) 常量静态变量 JIT(即时编译器)编译后代码也在方法区存放

② 堆内存(线程共享) 垃圾回收的主要场地

③ 程序计数器当前线程执行的字节码的位置指示器

④ Java虚拟机栈(栈内存) :保存局部变量,基本数据类型以及堆内存中对象的引用变量

⑤ 本地方法栈 (C栈):为JVM提供使用native方法的服务

3. 执行引擎

分配给运行时数据区的字节码将由执行引擎执行。执行引擎读取字节码并逐段执行。

3.1 解释器: 解释器能快速的解释字节码，但执行却很慢。解释器的缺点就是,当一个方法被调用多次，每次都需要重新解释。

3.2 编译器：JIT编译器消除了解释器的缺点。执行引擎利用解释器转换字节码，但如果是重复的代码则使用JIT编译器将全部字节码编译成本机代码。本机代码将直接用于重复的方法调用，这提高了系统的性能。a. 中间代码生成器– 生成中间代码b. 代码优化器– 负责优化上面生成的中间代码c. 目标代码生成器– 负责生成机器代码或本机代码d. 探测器(Profiler) – 一个特殊的组件，负责寻找被多次调用的方法。

3.3 垃圾回收器: 收集并删除未引用的对象。可以通过调用"System.gc()"来触发垃圾回收，但并不保证会确实进行垃圾回收。JVM的垃圾回收只收集哪些由new关键字创建的对象。所以，如果不是用new创建的对象，你可以使用finalize函数来执行清理。Java本地接口 (JNI): JNI会与本地方法库进行交互并提供执行引擎所需的本地库。本地方法库:它是一个执行引擎所需的本地库的集合。

下面，通过一个小程序认识JVM：

package com.spark.jvm;

/**

 * 从JVM调用的角度分析java程序堆内存空间的使用：

 * 当JVM进程启动的时候，会从类加载路径中找到包含main方法的入口类HelloJVM

 * 找到HelloJVM会直接读取该文件中的二进制数据，并且把该类的信息放到运行时的Method内存区域中。

 * 然后会定位到HelloJVM中的main方法的字节码中，并开始执行Main方法中的指令

 * 此时会创建Student实例对象，并且使用student来引用该对象(或者说给该对象命名)，其内幕如下：

 * 第一步：JVM会直接到Method区域中去查找Student类的信息，此时发现没有Student类，就通过类加载器加载该Student类文件；

 * 第二步：在JVM的Method区域中加载并找到了Student类之后会在Heap区域中为Student实例对象分配内存，

 * 并且在Student的实例对象中持有指向方法区域中的Student类的引用(内存地址)；

 * 第三步：JVM实例化完成后会在当前线程中为Stack中的reference建立实际的应用关系，此时会赋值给student

 * 接下来就是调用方法

 * 在JVM中方法的调用一定是属于线程的行为，也就是说方法调用本身会发生在线程的方法调用栈：

 * 线程的方法调用栈(Method Stack Frames)，每一个方法的调用就是方法调用栈中的一个Frame，

 * 该Frame包含了方法的参数，局部变量，临时数据等 student.sayHello();

 */

public class HelloJVM {
    //在JVM运行的时候会通过反射的方式到Method区域找到入口方法main
    public static void main(String[] args) {//main方法也是放在Method方法区域中的
        /**
         * student(小写的)是放在主线程中的Stack区域中的
         * Student对象实例是放在所有线程共享的Heap区域中的
         */
        Student student = new Student("spark");

        /**
         * 首先会通过student指针(或句柄)
         * (指针就直接指向堆中的对象，句柄表明有一个中间的,student指向句柄，句柄指向对象)
         * 找 Student对象，当找到该对象后会通过对象内部指向方法区域中的指针来调用具体的方法去执行任务
         */
        student.sayHello();
    }
}

class Student {
    // name本身作为成员是放在stack区域的但是name指向的String对象是放在Heap中
    private String name;
    public Student(String name) {
        this.name = name;
    }

    //sayHello这个方法是放在方法区中的
    public void sayHello() {
        System.out.println("Hello, this is " + this.name);
    }
}

classloader 加载 class 文件的原理和机制

下面部分内容，整理自《深入分析JavaWeb技术内幕》

Classloader负责将Class加载到JVM中，并且确定由那个ClassLoader来加载(父优先的等级加载机制)。还有一个任务就是将Class字节码重新解释为JVM统一要求的格式

1.Classloader 类结构分析

(1) 主要由四个方法，分别是 defineClass ， findClass ， loadClass ， resolveClass

<1> defineClass(byte[] , int ,int) 将byte字节流解析为JVM能够识别的Class对象(直接调用这个方法生成的Class对象还没有resolve，这个resolve将会在这个对象真正实例化时resolve)
<2> findClass，通过类名去加载对应的Class对象。当我们实现自定义的classLoader通常是重写这个方法，根据传入的类名找到对应字节码的文件，并通过调用defineClass解析出Class独享
<3> loadClass运行时可以通过调用此方法加载一个类(由于类是动态加载进jvm，用多少加载多少的？)
<4> resolveClass手动调用这个使得被加到JVM的类被链接(解析resolve这个类？)

(2) 实现自定义 ClassLoader 一般会继承 URLClassLoader 类，因为这个类实现了大部分方法。

2. 常见加载类错误分析

(1) ClassNotFoundException ：通常是jvm要加载一个文件的字节码到内存时，没有找到这些字节码(如forName，loadClass等方法)
(2) NoClassDefFoundError ：通常是使用new关键字，属性引用了某个类，继承了某个类或接口，但JVM加载这些类时发现这些类不存在的异常
(3) UnsatisfiedLinkErrpr：如native的方法找不到本机的lib

3. 常用 classLoader (书本此处其实是对 tomcat 加载 servlet 使用的 classLoader 分析)

(1)AppClassLoader ：加载jvm的classpath中的类和tomcat的核心类
(2) StandardClassLoader：加载tomcat容器的classLoader，另外webAppClassLoader在loadclass时，发现类不在JVM的classPath下，在PackageTriggers(是一个字符串数组，包含一组不能使用webAppClassLoader加载的类的包名字符串)下的话，将由该加载器加载(注意：StandardClassLoader并没有覆盖loadclass方法，所以其加载的类和AppClassLoader加载没什么分别，并且使用getClassLoader返回的也是AppClassLoader)(另外，如果web应用直接放在tomcat的webapp目录下该应用就会通过StandardClassLoader加载，估计是因为webapp目录在PackageTriggers中？)
(3) webAppClassLoader 如：Servlet等web应用中的类的加载(loadclass方法的规则详见P169)

4. 自定义的 classloader

(1) 需要使用自定义 classloader 的情况

<1> 不在System.getProperty("java.class.path")中的类文件不可以被AppClassLoader找到(LoaderClass方法只会去classpath下加载特定类名的类)，当class文件的字节码不在ClassPath就需要自定义classloader
<2> 对加载的某些类需要作特殊处理
<3> 定义类的实效机制，对已经修改的类重新加载，实现热部署

(2) 加载自定义路径中的 class 文件

<1>加载特定来源的某些类：重写find方法，使特定类或者特定来源的字节码通过defineClass获得class类并返回(应该符合jvm的类加载规范，其他类仍使用父加载器加载)
<2>加载自顶一个是的class文件(如经过网络传来的经过加密的class文件字节码)：findclass中加密后再加载

5. 实现类的热部署：

(1)同一个classLoader的两个实例加载同一个类，JVM也会识别为两个
(2)不能重复加载同一个类(全名相同，并使用同一个类加载器)，会报错
(3)不应该动态加载类，因为对象呗引用后，对象的属性结构被修改会引发问题

注意：使用不同classLoader加载的同一个类文件得到的类，JVM将当作是两个不同类，使用单例模式，强制类型转换时都可能因为这个原因出问题。

6 类加载器的双亲委派模型

当一个类加载器收到一个类加载的请求，它首先会将该请求委派给父类加载器去加载，每一个层次的类加载器都是如此，因此所有的类加载请求最终都应该被传入到顶层的启动类加载器(Bootstrap ClassLoader)中，只有当父类加载器反馈无法完成这个列的加载请求时(它的搜索范围内不存在这个类)，子类加载器才尝试加载。其层次结构示意图如下：

不难发现，该种加载流程的好处在于：可以避免重复加载，父类已经加载了，子类就不需要再次加载。更加安全，很好的解决了各个类加载器的基础类的统一问题，如果不使用该种方式，那么用户可以随意定义类加载器来加载核心api，会带来相关隐患。

接下来，我们看看双亲委派模型是如何实现的：

protected Class<?> loadClass(String name, boolean resolve)

 throws ClassNotFoundException

 {

 synchronized (getClassLoadingLock(name)) {

 // 首先先检查该类已经被加载过了

 Class c = findLoadedClass(name);

 if (c == null) {//该类没有加载过，交给父类加载

 long t0 = System.nanoTime();

 try {

 if (parent != null) {//交给父类加载

 c = parent.loadClass(name, false);

 } else {//父类不存在，则交给启动类加载器加载

 c = findBootstrapClassOrNull(name);

 }

 } catch (ClassNotFoundException e) {

 //父类加载器抛出异常，无法完成类加载请求

 }

 if (c == null) {//

 long t1 = System.nanoTime();

 //父类加载器无法完成类加载请求时，调用自身的findClass方法来完成类加载

 c = findClass(name);

 sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);

 sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);

 sun.misc.PerfCounter.getFindClasses().increment();

 }

 }

 if (resolve) {

 resolveClass(c);

 }

 return c;

 }

 }

这里有些童鞋会问，JVM怎么知道一个某个类加载器的父加载器呢?如果你有此疑问，请重新再看一遍.

7 类加载器的特点

运行任何一个程序时，总是由Application Loader开始加载指定的类。

一个类在收到加载类请求时，总是先交给其父类尝试加载。

Bootstrap Loader是最顶级的类加载器，其父加载器为null。

8 类加载的三种方式

通过命令行启动应用时由JVM初始化加载含有main()方法的主类。

通过Class.forName()方法动态加载，会默认执行初始化块(static{})，但是Class.forName(name,initialize,loader)中的initialze可指定是否要执行初始化块。

通过ClassLoader.loadClass()方法动态加载，不会执行初始化块。

9 自定义类加载器的两种方式

1、遵守双亲委派模型：继承ClassLoader，重写findClass()方法。 2、破坏双亲委派模型：继承ClassLoader,重写loadClass()方法。通常我们推荐采用第一种方法自定义类加载器，最大程度上的遵守双亲委派模型。自定义类加载的目的是想要手动控制类的加载,那除了通过自定义的类加载器来手动加载类这种方式,还有其他的方式么?

利用现成的类加载器进行加载:

1. 利用当前类加载器：Class.forName();

2. 通过系统类加载器：Classloader.getSystemClassLoader().loadClass();

3. 通过上下文类加载器：Thread.currentThread().getContextClassLoader().loadClass();

l 利用URLClassLoader进行加载:

URLClassLoader loader=new URLClassLoader();

loader.loadClass();

类加载实例演示：命令行下执行 HelloWorld.java

public class HelloWorld{
    public static void main(String[] args){
        System.out.println("Hello world");
    }
}

该段代码大体经过了一下步骤:

寻找jre目录，寻找jvm.dll，并初始化JVM.
产生一个Bootstrap ClassLoader；
Bootstrap ClassLoader加载器会加载他指定路径下的java核心api，并且生成Extended ClassLoader加载器的实例，然后Extended ClassLoader会加载指定路径下的扩展java api，并将其父设置为Bootstrap ClassLoader。
Bootstrap ClassLoader生成Application ClassLoader，并将其父Loader设置为Extended ClassLoader。
最后由AppClass ClassLoader加载classpath目录下定义的类——HelloWorld类。

我们上面谈到 Extended ClassLoader和Application ClassLoader是通过Launcher来创建,现在我们再看看源代码:

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 {

 //实例化AppClassLoader

 this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);

 } catch (IOException var9) {

 throw new InternalError("Could not create application class loader", var9);

 }

 //主线程设置默认的Context ClassLoader为AppClassLoader.

 //因此在主线程中创建的子线程的Context ClassLoader 也是AppClassLoader

 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);

 }

 }

10 非常重要

在这里呢我们需要注意几个问题:
1. 我们知道ClassLoader通过一个类的全限定名来获取二进制流,那么如果我们需要通过自定义类加载其来加载一个Jar包的时候,难道要自己遍历jar中的类,然后依次通过ClassLoader进行加载吗?或者说我们怎么来加载一个jar包呢?
2. 如果一个类引用的其他的类,那么这个其他的类由谁来加载?
3. 既然类可以由不同的加载器加载,那么如何确定两个类如何是同一个类?

我们来依次解答这两个问题: 对于动态加载jar而言,JVM默认会使用第一次加载该jar中指定类的类加载器作为默认的ClassLoader.假设我们现在存在名为sbbic的jar包,该包中存在ClassA和ClassB这两个类(ClassA中没有引用ClassB).现在我们通过自定义的ClassLoaderA来加载在ClassA这个类,那么此时此时ClassLoaderA就成为sbbic.jar中其他类的默认类加载器.也就是,ClassB也默认会通过ClassLoaderA去加载.

那么如果ClassA中引用了ClassB呢?当类加载器在加载ClassA的时候,发现引用了ClassB,此时类加载如果检测到ClassB还没有被加载,则先回去加载.当ClassB加载完成后,继续回来加载ClassA.换句话说,类会通过自身对应的来加载其加载其他引用的类.

JVM规定,对于任何一个类,都需要由加载它的类加载器和这个类本身一同确立在java虚拟机中的唯一性,通俗点就是说,在jvm中判断两个类是否是同一个类取决于类加载和类本身,也就是同一个类加载器加载的同一份Class文件生成的Class对象才是相同的,类加载器不同,那么这两个类一定不相同.

一、什么是 ClassLoader?

写好一个Java程序之后，不是管是CS还是BS应用，都是由若干个.class文件组织而成的一个完整的Java应用程序，当程序在运行时，即会调用该程序的一个入口函数来调用系统的相关功能，而这些功能都被封装在不同的class文件当中，所以经常要从这个class文件中要调用另外一个class文件中的方法，如果另外一个文件不存在的，则会引发系统异常。而程序在启动的时候，并不会一次性加载程序所要用的所有class文件，而是根据程序的需要，通过Java的类加载机制(ClassLoader)来动态加载某个class文件到内存当中的，从而只有class文件被载入到了内存之后，才能被其它class所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。

二、Java 默认提供的三个 ClassLoader

BootStrap ClassLoader：称为启动类加载器，是Java类加载层次中最顶层的类加载器，负责加载JDK中的核心类库，如：rt.jar、resources.jar、charsets.jar等。

Extension ClassLoader：称为扩展类加载器，负责加载Java的扩展类库，默认加载JAVA_HOME/jre/lib/ext/目下的所有jar。

App ClassLoader：称为系统类加载器，负责加载应用程序classpath目录下的所有jar和class文件。

注意：除了Java默认提供的三个ClassLoader之外，用户还可以根据需要定义自已的ClassLoader，而这些自定义的ClassLoader都必须继承自java.lang.ClassLoader类，也包括Java提供的另外二个ClassLoader(Extension ClassLoader和App ClassLoader)在内，但是Bootstrap ClassLoader不继承自ClassLoader，因为它不是一个普通的Java类，底层由C++编写，已嵌入到了JVM内核当中，当JVM启动后，Bootstrap ClassLoader也随着启动，负责加载完核心类库后，并构造Extension ClassLoader和App ClassLoader类加载器。

三、ClassLoader加载类的原理

1、原理介绍

ClassLoader使用的是双亲委托模型来搜索类的，每个ClassLoader实例都有一个父类加载器的引用(不是继承的关系，是一个包含的关系)，虚拟机内置的类加载器(Bootstrap ClassLoader)本身没有父类加载器，但可以用作其它 ClassLoader 实例的的父类加载器。当一个 ClassLoader 实例需要加载某个类时，它会试图亲自搜索某个类之前，先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，如果没加载到，则把任务转交给 Extension ClassLoader 试图加载，如果也没加载到，则转交给 App ClassLoader 进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。如果它们都没有加载到这个类时，则抛出ClassNotFoundException 异常。否则将这个找到的类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象。

2、为什么要使用双亲委托这种模型呢？

因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的 String 来动态替代 java 核心 api 中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为 String 已经在启动时就被引导类加载器(Bootstrcp ClassLoader)加载，所以用户自定义的 ClassLoader 永远也无法加载一个自己写的 String，除非你改变 JDK 中 ClassLoader 搜索类的默认算法。

3、但是 JVM 在搜索类的时候，又是如何判定两个class是相同的呢？

JVM 在判定两个 class 是否相同时，不仅要判断两个类名是否相同，而且要判断是否由同一个类加载器实例加载的。只有两者同时满足的情况下，JVM才认为这两个class是相同的。就算两个 class 是同一份 class 字节码，如果被两个不同的 ClassLoader 实例所加载，JVM也会认为它们是两个不同class。比如网络上的一个Java类org.classloader.simple.NetClassLoaderSimple，javac编译之后生成字节码文件NetClassLoaderSimple.class，ClassLoaderA和ClassLoaderB这两个类加载器并读取了NetClassLoaderSimple.class文件，并分别定义出了java.lang.Class实例来表示这个类，对于JVM来说，它们是两个不同的实例对象，但它们确实是同一份字节码文件，如果试图将这个Class实例生成具体的对象进行转换时，就会抛运行时异常java.lang.ClassCaseException，提示这是两个不同的类型。现在通过实例来验证上述所描述的是否正确：

1)、在 web 服务器上建一个 org.classloader.simple.NetClassLoaderSimple.java 类

package org.classloader.simple;  

public class NetClassLoaderSimple {    
   private NetClassLoaderSimple instance;  
    public void setNetClassLoaderSimple(Object obj) {  
        this.instance = (NetClassLoaderSimple)obj;  
    }  
}

org.classloader.simple.NetClassLoaderSimple 类的 setNetClassLoaderSimple方法接收一个 Object 类型参数，并将它强制转换成 org.classloader.simple.NetClassLoaderSimple 类型。

2)、测试两个class是否相同(NetWorkClassLoader.java)

package classloader;

public class NewworkClassLoaderTest {
    public static void main(String[] args) {
        try {
            //测试加载网络中的class文件
            String rootUrl = "http://localhost:8080/httpweb/classes";
            String className = "org.classloader.simple.NetClassLoaderSimple";
            NetworkClassLoader ncl1 = new NetworkClassLoader(rootUrl);
            NetworkClassLoader ncl2 = new NetworkClassLoader(rootUrl);
            Class<?> clazz1 = ncl1.loadClass(className);
            Class<?> clazz2 = ncl2.loadClass(className);
            Object obj1 = clazz1.newInstance();
            Object obj2 = clazz2.newInstance();
            clazz1.getMethod("setNetClassLoaderSimple", Object.class).invoke(obj1, obj2);
        } 
        catch (Exception e) {
            e.printStackTrace();
        }
    }
}

首先获得网络上一个class文件的二进制名称，然后通过自定义的类加载器NetworkClassLoader创建两个实例，并根据网络地址分别加载这份class，并得到这两个ClassLoader实例加载后生成的Class实例clazz1和clazz2，最后将这两个Class实例分别生成具体的实例对象obj1和obj2，再通过反射调用clazz1中的setNetClassLoaderSimple方法。

3)、查看测试结果

结论：从结果中可以看出，虽然是同一份class字节码文件，但是由于被两个不同的ClassLoader实例所加载，所以JVM认为它们就是两个不同的类。

4、ClassLoader的体系架构：

验证 ClassLoader 加载类的原理：

测试 1：打印 ClassLoader类的层次结构，请看下面这段代码：

ClassLoader loader = ClassLoaderTest.class.getClassLoader();    //获得加载ClassLoaderTest.class这个类的类加载器  

while(loader != null) {  
  System.out.println(loader);  
  loader = loader.getParent();    //获得父类加载器的引用  
}  
System.out.println(loader);

打印结果：

第一行结果说明：ClassLoaderTest的类加载器是AppClassLoader。

第二行结果说明：AppClassLoader的类加器是ExtClassLoader，即parent=ExtClassLoader。

第三行结果说明：ExtClassLoader的类加器是Bootstrap ClassLoader，因为Bootstrap ClassLoader不是一个普通的Java类，所以ExtClassLoader的parent=null，所以第三行的打印结果为null就是这个原因。

测试 2：将 ClassLoaderTest.class 打包成ClassLoaderTest.jar，放到Extension ClassLoader的加载目录下(JAVA_HOME/jre/lib/ext)，然后重新运行这个程序，得到的结果会是什么样呢？

打印结果：

打印结果分析：

为什么第一行的结果是ExtClassLoader呢？

因为ClassLoader的委托模型机制，当我们要用ClassLoaderTest.class这个类的时候，AppClassLoader在试图加载之前，先委托给Bootstrcp ClassLoader，Bootstracp ClassLoader发现自己没找到，它就告诉ExtClassLoader，兄弟，我这里没有这个类，你去加载看看，然后Extension ClassLoader拿着这个类去它指定的类路径(JAVA_HOME/jre/lib/ext)试图加载，唉，它发现在ClassLoaderTest.jar这样一个文件中包含ClassLoaderTest.class这样的一个文件，然后它把找到的这个类加载到内存当中，并生成这个类的Class实例对象，最后把这个实例返回。所以ClassLoaderTest.class的类加载器是ExtClassLoader。

第二行的结果为null，是因为ExtClassLoader的父类加载器是Bootstrap ClassLoader。

测试3：用Bootstrcp ClassLoader来加载ClassLoaderTest.class，有两种方式：

1、在jvm中添加-Xbootclasspath参数，指定Bootstrcp ClassLoader加载类的路径，并追加我们自已的jar(ClassTestLoader.jar)

2、将class文件放到JAVA_HOME/jre/classes/目录下(上面有提到)

方式1：(我用的是Eclipse开发工具，用命令行是在java命令后面添加-Xbootclasspath参数)

打开Run配置对话框：

置好如图中所述的参数后，重新运行程序，产的结果如下所示：(类加载的过程，只摘下了一部份)

打印结果：

方式 2：将ClassLoaderTest.jar解压后，放到JAVA_HOME/jre/classes目录下，如下图所示：

提示：jre目录下默认没有classes目录，需要自己手动创建一个

打印结果：

从结果中可以看出，两种方式都实现了将ClassLoaderTest.class由Bootstrcp ClassLoader加载成功了。

四、定义自已的 ClassLoader

既然 JVM 已经提供了默认的类加载器，为什么还要定义自已的类加载器呢？

因为Java中提供的默认ClassLoader，只加载指定目录下的jar和class，如果我们想加载其它位置的类或jar时，比如：我要加载网络上的一个class文件，通过动态加载到内存之后，要调用这个类中的方法实现我的业务逻辑。在这样的情况下，默认的ClassLoader就不能满足我们的需求了，所以需要定义自己的ClassLoader。

定义自已的类加载器分为两步：

1、继承java.lang.ClassLoader

2、重写父类的findClass方法

读者可能在这里有疑问，父类有那么多方法，为什么偏偏只重写findClass方法？

因为JDK已经在loadClass方法中帮我们实现了ClassLoader搜索类的算法，当在loadClass方法中搜索不到类时，loadClass方法就会调用findClass方法来搜索类，所以我们只需重写该方法即可。如没有特殊的要求，一般不建议重写loadClass搜索类的算法。下图是API中ClassLoader的loadClass方法：

示例：自定义一个 NetworkClassLoader，用于加载网络上的 class 文件

package classloader;

import java.io.ByteArrayOutputStream;
import java.io.InputStream;
import java.net.URL;

/**
 * 加载网络class的ClassLoader
 */

public class NetworkClassLoader extends ClassLoader {
    private String rootUrl;
    public NetworkClassLoader(String rootUrl) {
        this.rootUrl = rootUrl;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        Class clazz = null;//this.findLoadedClass(name); // 父类已加载
        //if (clazz == null) {  //检查该类是否已被加载过
        byte[] classData = getClassData(name);  //根据类的二进制名称,获得该class文件的字节码数组
        if (classData == null) {
            throw new ClassNotFoundException();
        }
        clazz = defineClass(name, classData, 0, classData.length);  //将class的字节码数组转换成Class类的实例
        //}
        return clazz;
    }

    private byte[] getClassData(String name) {
        InputStream is = null;
        try {
            String path = classNameToPath(name);
            URL url = new URL(path);
            byte[] buff = new byte[1024*4];
            int len = -1;
            is = url.openStream();
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            while((len = is.read(buff)) != -1) {
                baos.write(buff,0,len);
            }
            return baos.toByteArray();
        }
        catch (Exception e) {
            e.printStackTrace();
        }
        finally {
            if (is != null) {
                try {
                    is.close();
                }
                catch(IOException e) {
                    e.printStackTrace();
                }
            }
        }
        return null;
    }

    private String classNameToPath(String name) {
        return rootUrl + "/" + name.replace(".", "/") + ".class";
    }
}

测试类：

package classloader;

public class ClassLoaderTest {
    public static void main(String[] args) {
        try {
            /*ClassLoader loader = ClassLoaderTest.class.getClassLoader();  //获得ClassLoaderTest这个类的类加载器 
            while(loader != null) { 
                System.out.println(loader); 
                loader = loader.getParent();    //获得父加载器的引用 
            } 
            System.out.println(loader);*/
            
            String rootUrl = "http://localhost:8080/httpweb/classes";
            NetworkClassLoader networkClassLoader = new NetworkClassLoader(rootUrl);
            String classname = "org.classloader.simple.NetClassLoaderTest";
            Class clazz = networkClassLoader.loadClass(classname);
            System.out.println(clazz.getClassLoader());
        } 
        catch (Exception e) {
            e.printStackTrace();
        }
    }
}

打印结果：

下图是我机器上web服务器的目录结构：

目前常用web服务器中都定义了自己的类加载器，用于加载web应用指定目录下的类库(jar或class)，如：Weblogic、Jboss、tomcat等，下面我以Tomcat为例，展示该web容器都定义了哪些个类加载器：

1、新建一个web工程httpweb
2、新建一个ClassLoaderServletTest，用于打印web容器中的ClassLoader层次结构

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


public class ClassLoaderServletTest extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        
        response.setContentType("text/html");
        PrintWriter out = response.getWriter();
        ClassLoader loader = this.getClass().getClassLoader();
        while(loader != null) {
            out.write(loader.getClass().getName()+"<br/>");
            loader = loader.getParent();
        }
        out.write(String.valueOf(loader));
        out.flush();
        out.close();
    }
    
    public void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        this.doGet(request, response);
    }
}

3、配置Servlet，并启动服务

<?xml version="1.0" encoding="UTF-8"?>  

<web-app version="2.4"   
    xmlns="http://java.sun.com/xml/ns/j2ee"   
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee   
    http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">  

  <servlet>  
    <servlet-name>ClassLoaderServletTest</servlet-name>  
    <servlet-class>ClassLoaderServletTest</servlet-class>  
  </servlet>  

  <servlet-mapping>  
    <servlet-name>ClassLoaderServletTest</servlet-name>  
    <url-pattern>/servlet/ClassLoaderServletTest</url-pattern>  
  </servlet-mapping>  

  <welcome-file-list>  
    <welcome-file>index.jsp</welcome-file>  
  </welcome-file-list>  
</web-app>

4、访问Servlet，获得显示结果

「已注销」

关注

0
点赞
踩
9

收藏

觉得还不错? 一键收藏
0
评论
一文读懂类加载机制 --- ClassLoader

From：https://www.cnblogs.com/sunnick/p/9609326.html 【JVM笔记】classloader加载class文件的原理和机制：https://www.jianshu.com/p/52c38cf2e3d4 JVM 架构整体架构在进入 classloader 分析之前，先了解一下 jvm 整体架构： ...
复制链接

扫一扫