Java ClassLoader

最新推荐文章于 2022-12-20 23:13:46 发布

hyw520110

最新推荐文章于 2022-12-20 23:13:46 发布

阅读量91

点赞数

分类专栏： java 文章标签： Java JVM EXT C# C++

本文链接：https://blog.csdn.net/hyw520110/article/details/83910995

版权

java 专栏收录该内容

49 篇文章 0 订阅

订阅专栏

当Java编译器编译好.class文件之后，我们需要使用JVM来运行这个class文件。那么最开始的工作就是要把字节码从磁盘输入到内存中，这个过程我们叫做【加载】。加载完成之后，我们就可以进行一系列的运行前准备工作了，比如：为类静态变量开辟空间，将常量池存放在方法区内存中并实现常量池地址解析，初始化类静态变量等等。这篇文章我们要好好谈谈JVM是如何加载class文件的？

1、JVM加载类的过程

      当我们使用命令来执行某一个Java程序(比如Test.class)的时候：java Test
      (1) java.exe 会帮助我们找到 JRE ，接着找到位于 JRE 内部的 jvm.dll ，这才是真正的 Java 虚拟机器 , 最后加载动态库，激活 Java 虚拟机器。
      (2) 虚拟机器激活以后，会先做一些初始化的动作，比如说读取系统参数等。一旦初始化动作完成之后，就会产生第一个类装载器 ―― Bootstrap Loader(启动类装载器) 。
      (3) Bootstrap Loader 所做的初始工作中，除了一些基本的初始化动作之外，最重要的就是加载 Launcher.java 之中的 ExtClassLoader(扩展类装载器) ，并设定其 Parent 为 null ，代表其父加载器为 BootstrapLoader 。
      (4) 然后 Bootstrap Loader 再要求加载 Launcher.java 之中的 AppClassLoader(用户自定义类装载器) ，并设定其 Parent 为之前产生的 ExtClassLoader 实体。这两个加载器都是以静态类的形式存在的。
      这里要请大家注意的是， Launcher$ExtClassLoader.class 与 Launcher$AppClassLoader.class 都是由 Bootstrap Loader 所加载，所以 Parent 和由哪个类加载器加载没有关系。
      初学者对这个过程很难理解，我们将在下面详细的讲讲类装载器和"Parent"是什么。

2、类装载器体系结构

      JVM加载class文件必须通过一个叫做类装载器的程序，它的作用就是从磁盘文件中将要运行代码的字节码流加载进内存(JVM管理的方法区)中。下面是几个比较重要的概念：

      (1) 启动类装载器： 每个Java虚拟机实现都必须有一个启动类装载器。它只负责在系统类(核心Java API的class文件)的安装路径中查找要装入的类。这个装载器的实现由C++ 所撰写而成，是JVM实现的一部分。

      (2) 扩展类装载器和自定义类装载器： 负责除核心Java API以外的其它class文件的装载。例如、用于安装或下载标准扩展的class文件,在类路径中发现的类库的class文件,用于应用程序运行的class文件等等。这里有一点需要注意：自定义类装载器并非由应用程序员自己实现，它也是JVM

      (3) 命名空间: Java虚拟机为每一个类装载器维护一个唯一标识的命名空间。一个Java程序可以多次装载具有同一个全限定名的多个类。 Java虚拟机要确定这"多个类"的唯一性，因此,当多个类装载器都装载了同名的类时，为了唯一地标识这个类,还要在类名前加上装载该类的类装载器的标识(指出了类所位于的命名空间)。下图显示了两个类装载器有关的命名空间，显然，不同的类装载器允许装载相同的类Volcano。
      命名空间有助于安全的实现，因为你可以有效地在装入了不同命名空间的类之间设置一个防护罩。在Java虚拟机中，在同一个命名空间内的类可以直接进行交互，而不同的命名空间中的类甚至不能察觉彼此的存在，除非显式地提供了允许它们进行交互的机制。一旦加载后，如果一个恶意的类被赋予权限访问其他虚拟机加载的当前类，它就可以潜在地知道一些它不应该知道的信息，或者干扰程序的正常运行。

3、双亲委托模型

      用户自定义类装载器经常依赖其他类装载器——至少依赖于虚拟机启动时创建的启动类装载器—来帮助它实现一些类装载请求:.在版本1.2前，非启动类装载器必须显式地求助于其他类装载器，类装载器可以请求另一个用户自定义的类装载器来装载一个类，这个请求是通过对被请求的用户自定义类装载器调用 loadClass()来实现的。除此以外，类装载器也可以通过调用findSystemClass()来请求启动类装载器来装载类，这是类 ClassLoader中的一个静态方法。
      在版本1.2中，类装载器请求另一个类装载器来装载类型的过程被形式化，称为双亲委派模式。
      从版本1.2开始、除启动类装载器以外的每一个类装载器，都有一个“双亲”类装载器，在某个特定的类装载器试图以常用方式装载类型以前，它会先默认地将这个任务“委派”给它的双亲——清求它的双亲来装载这个类型。这个双亲再依次请求它自己的双亲来装载这个类型。这个委派的过程一直向上继续，直到达到启动类装载器，通常启动类装载器是委派链中的最后一个类装载器。如果一个类装载器的双亲类装载器有能力来装载这个类型。则这个类装载器返回这个类型。否则，这个类装载器试图自己来装载这个类。

     当Java虚拟机开始运行时,在应用程序开始启动以前,它至少创建一个用户自定义装载器,也可能创建多个.所有这些装载器被连接在一个Parent-Child的委托链中,在这个链的顶端是启动类装载器。

    例如：假设你写了一个应用程序,在虚拟机上运行它.虚拟机在启动时实例化了两个用户自定义类装载器:一个"扩展类装载器",一个"类路径类装载器".这些类装载器和启动类装载器一起联入一个Parent-Child委托链中,如下图所示.

       上图所示类路径类装载器的Parent是扩展类装载器, 扩展类装载器的Parent是启动类装载器.在图2中,类路径类装载器就被实例为系统类装载器.假设你的程序实例化它的网络类装载器,它就指明了系统类装载器作为它的Parent.

下面的例程说明了类装载器的父子关系.

[java] view plain copy print ?

package test;
import java.net.URL;
import java.net.URLClassLoader;
public class ClassLoaderTest {
private static int count = -1;
public static void testClassLoader(Object obj) {
if (count < 0 && obj == null) {
System.out.println("Input object is NULL";
return;
}
ClassLoader cl = null;
if (obj != null && !(obj instanceof ClassLoader)) {
cl = obj.getClass().getClassLoader();
} else if (obj != null) {
cl = (ClassLoader) obj;
}
count++;
String parent = "";
for (int i = 0; i < count; i++) {
parent += "Parent ";
}
if (cl != null) {
System.out.println(
parent + "ClassLoader name = " + cl.getClass().getName());
testClassLoader(cl.getParent());
} else {
System.out.println(
parent + "ClassLoader name = BootstrapClassLoader";
count = -1;
}
}
public static void main(String[] args) {
URL[] urls = new URL[1];
URLClassLoader urlLoader = new URLClassLoader(urls);
ClassLoaderTest.testClassLoader(urlLoader);
}
}

package test; import java.net.URL; import java.net.URLClassLoader; public class ClassLoaderTest { private static int count = -1; public static void testClassLoader(Object obj) { if (count < 0 && obj == null) { System.out.println("Input object is NULL"; return; } ClassLoader cl = null; if (obj != null && !(obj instanceof ClassLoader)) { cl = obj.getClass().getClassLoader(); } else if (obj != null) { cl = (ClassLoader) obj; } count++; String parent = ""; for (int i = 0; i < count; i++) { parent += "Parent "; } if (cl != null) { System.out.println( parent + "ClassLoader name = " + cl.getClass().getName()); testClassLoader(cl.getParent()); } else { System.out.println( parent + "ClassLoader name = BootstrapClassLoader"; count = -1; } } public static void main(String[] args) { URL[] urls = new URL[1]; URLClassLoader urlLoader = new URLClassLoader(urls); ClassLoaderTest.testClassLoader(urlLoader); } }

以上例程的输出为:
ClassLoader name = java.net.URLClassLoader
Parent ClassLoader name = sun.misc.Launcher＄AppClassLoader
Parent Parent ClassLoader name = sun.misc.Launcher＄ExtClassLoader
Parent Parent Parent ClassLoader name = BootstrapClassLoader

类装载器请求过程
以上例程1为例.将main方法改为:
        ClassLoaderTest tc = new ClassLoaderTest();
        ClassLoaderTest.testClassLoader(tc);
输出为:
ClassLoader name = sun.misc.Launcher＄AppClassLoader
Parent ClassLoader name = sun.misc.Launcher＄ExtClassLoader
Parent Parent ClassLoader name = BootstrapClassLoader

     程序运行过程中，类路径类装载器发出一个装载ClassLoaderTest类的请求，类路径类装载器必须首先询问它的Parent---扩展类装载器 ---来查找并装载这个类,同样扩展类装载器首先询问启动类装载器。由于ClassLoaderTest不是 Java API(JAVA_HOME\jre\lib)中的类，也不在已安装扩展路径(JAVA_HOME\jre\lib\ext)上，这两类装载器都将返回而不会提供一个名为ClassLoaderTest的已装载类给类路径类装载器。类路径类装载器只能以它自己的方式来装载 ClassLoaderTest，它会从当前类路径上下载这个类。这样，ClassLoaderTest就可以在应用程序后面的执行中发挥作用。
      在上例中，ClassLoaderTest类的testClassLoader方法被首次调用，该方法引用了Java API中的类 java.lang.String。Java虚拟机会请求装载ClassLoaderTest类的类路径类装载器来装载 java.lang.String。就像前面一样，类路径类装载器首先将请求传递给它的Parent类装载器，然后这个请求一路被委托到启动类装载器。但是，启动类装载器可以将java.lang.String类返回给类路径类装载器，因为它可以找到这个类,这样扩展类装载器就不必在已安装扩展路径中查找这个类，类路径类装载器也不必在类路径中查找这个类。扩展类装载器和类路径类装载器仅需要返回由启动类装载器返回的类java.lang.String。从这一刻开始，不管何时ClassLoaderTest类引用了名为java.lang.String的类，虚拟机就可以直接使用这个 java.lang.String类了。

4、一个经典的实例说明

我们看看下面的代码：

[java] view plain copy print ?

package java.lang;
public class String {
public static void main(String[] args){
}
}

package java.lang; public class String { public static void main(String[] args){ } }
大家发现什么不同了吗？对了，我们写了一个与JDK中String一模一样的类，连包java.lang都一样，唯一不同的是我们自定义的String类有一个main函数。我们来运行一下：

java.lang.NoSuchMethodError: main
Exception in thread "main"

这是为什么? 我们的String类不是明明有main方法吗？

其实联系我们上面讲到的双亲委托模型，我们就能解释这个问题了。

运行这段代码，JVM会首先创建一个自定义类加载器，不妨叫做AppClassLoader，并把这个加载器链接到委托链中：AppClassLoader -> ExtClassLoader -> BootstrapLoader。

然后AppClassLoader会将加载java.lang.String的请求委托给ExtClassLoader，而 ExtClassLoader又会委托给最后的启动类加载器BootstrapLoader。

启动类加载器BootstrapLoader只能加载JAVA_HOME\jre\lib中的class类(即J2SE API)，问题是标准API中确实有一个java.lang.String(注意，这个类和我们自定义的类是完全两个类)。BootstrapLoader以为找到了这个类，毫不犹豫的加载了j2se api中的java.lang.String。

最后出现上面的加载错误(注意不是异常，是错误，JVM退出)，因为API中的String类是没有main方法的。

结论：我们当然可以自定义一个和API完全一样的类，但是由于双亲委托模型，使得我们不可能加载上我们自定义的这样一个类。所以J2SE规范中希望我们自定义的包有自己唯一的特色(网络域名)。还有一点，这种加载器原理使得JVM更加安全的运行程序，因为黑客很难随意的替代掉API中的代码了。

1.Java中的所有类，必须被装载到jvm中才能运行，这个装载工作是由jvm中的类装载器完成的，类装载器所做的工作实质是把类文件从硬盘读取到内存中

2.java中的类大致分为三种：

1.系统类

2.扩展类

3.由程序员自定义的类

3.类装载方式，有两种

1.隐式装载，程序在运行过程中当碰到通过new 等方式生成对象时，隐式调用类装载器加载对应的类到jvm中，

2.显式装载，通过class.forname()等方法，显式加载需要的类

隐式加载与显式加载的区别？两者本质是一样?

4.类加载的动态性体现

一个应用程序总是由n多个类组成，Java程序启动时，并不是一次把所有的类全部加载后再运行，它总是先把保证程序运行的基础类一次性加载到jvm中，其它类等到jvm用到的时候再加载，这样的好处是节省了内存的开销，因为java最早就是为嵌入式系统而设计的，内存宝贵，这是一种可以理解的机制，而用到时再加载这也是java动态性的一种体现

5．java类装载器

Java中的类装载器实质上也是类，功能是把类载入jvm中，值得注意的是jvm的类装载器并不是一个，而是三个，层次结构如下：

Bootstrap Loader - 负责加载系统类

- - ExtClassLoader - 负责加载扩展类

- - AppClassLoader - 负责加载应用类

为什么要有三个类加载器，一方面是分工，各自负责各自的区块，另一方面为了实现委托模型，下面会谈到该模型

6. 类加载器之间是如何协调工作的

前面说了，java中有三个类加载器，问题就来了，碰到一个类需要加载时，它们之间是如何协调工作的，即java是如何区分一个类该由哪个类加载器来完成呢。

在这里java采用了委托模型机制，这个机制简单来讲，就是“类装载器有载入类的需求时，会先请示其Parent使用其搜索路径帮忙载入，如果Parent 找不到,那么才由自己依照自己的搜索路径搜索类”，注意喔，这句话具有递归性

下面举一个例子来说明，为了更好的理解，先弄清楚几行代码：

Public class Test{

Public static void main(String[] arg){

ClassLoader c = Test.class.getClassLoader(); //获取Test类的类加载器

System.out.println(c);

ClassLoader c1 = c.getParent(); //获取c这个类加载器的父类加载器

System.out.println(c1);

ClassLoader c2 = c1.getParent();//获取c1这个类加载器的父类加载器

System.out.println(c2);

}

运行结果：

。。。AppClassLoader。。。

。。。ExtClassLoader。。。

Null

注：。。。表示省略了内容

可以看出Test是由AppClassLoader加载器加载的

AppClassLoader的Parent 加载器是 ExtClassLoader 但是ExtClassLoader的Parent为 null 是怎么回事呵，朋友们留意的话，前面有提到Bootstrap Loader是用C++语言写的，依java的观点来看，逻辑上并不存在Bootstrap Loader的类实体，所以在java程序代码里试图打印出其内容时，我们就会看到输出为null

类装载器ClassLoader（一个抽象类）描述一下JVM加载class文件的原理机制

类装载器就是寻找类或接口字节码文件进行解析并构造JVM内部对象表示的组件，在java中类装载器把一个类装入JVM，经过以下步骤：

1、装载：查找和导入Class文件

2、链接：其中解析步骤是可以选择的

（a）检查：检查载入的class文件数据的正确性

（b）准备：给类的静态变量分配存储空间

（c）解析：将符号引用转成直接引用

3、初始化：对静态变量，静态代码块执行初始化工作

类装载工作由ClassLoder和其子类负责。JVM在运行时会产生三个ClassLoader：根装载器，ExtClassLoader(扩展类装载器)和AppClassLoader，其中根装载器不是ClassLoader的子类，由C++编写，因此在java中看不到他，负责装载JRE的核心类库，如JRE目录下的rt.jar,charsets.jar等。ExtClassLoader是ClassLoder的子类，负责装载JRE扩展目录ext下的jar类包；AppClassLoader负责装载classpath路径下的类包，这三个类装载器存在父子层级关系，即根装载器是ExtClassLoader的父装载器，ExtClassLoader是AppClassLoader的父装载器。默认情况下使用AppClassLoader装载应用程序的类

Java装载类使用“全盘负责委托机制”。“全盘负责”是指当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类所依赖及引用的类也由这个ClassLoder载入；“委托机制”是指先委托父类装载器寻找目标类，只有在找不到的情况下才从自己的类路径中查找并装载目标类。这一点是从安全方面考虑的，试想如果一个人写了一个恶意的基础类（如java.lang.String）并加载到JVM将会引起严重的后果，但有了全盘负责制，java.lang.String永远是由根装载器来装载，避免以上情况发生

除了JVM默认的三个ClassLoder以外，第三方可以编写自己的类装载器，以实现一些特殊的需求。类文件被装载解析后，在JVM中都有一个对应的java.lang.Class对象，提供了类结构信息的描述。数组，枚举及基本数据类型，甚至void都拥有对应的Class对象。Class类没有public的构造方法，Class对象是在装载类时由JVM通过调用类装载器中的defineClass()方法自动构造的

ClassLoader重要方法：

（1）public Class<?> loadClass(String name)

throws ClassNotFoundException

name参数指定类装载器需要装载类的名字，必须使用全限定类名。该方法有一个重载方法loadClass(String name,Boolean resolve)，resolve参数告诉类装载器是否解析该类。在初始化类之前应考虑进行类解析的工作，但并不是所有类都需要解析，如果JVM只需要知道该类是否存在或找出该类的超类，那么就不需要进行解析

（2）

【注：以下内容大部分引用java深度历险】

弄明白了上面的示例，接下来直接进入类装载的委托模型实例，写两个文件，如下：

文件：Test1.java

Public class Test1{

Public static void main(String[] arg){

System.out.println(Test1.class.getClassLoader());

Test2 t2 = new Test2();

T2.print();

}

文件： Test2.java

Public class Test2{

Public void print(){

System.out.println(this.getClass().getClassLoader());

}

这两个类的作用就是打印出载入它们的类装载器是谁，将这两个文件保存到d:\TestClassLoder目录下，编译后，我们在复制两份，分别置于 <JRE所在目录>\classes下（没有此目录，需自己建立）与 <JRE所在目录>\lib\ext\classes下（没此目录，手工建立）, 然后切换到D:\TestClassLoder目录下开始测试（查看当前用的jdk版本号，我用的jre所在目录为是C:\ProgramFiles\Java\jdk1.6.0\jre）

测试一：

<JRE所在目录>\classes下

Test1.class

Test2.class

<JRE所在目录>\lib\ext\classes下

Test1.class

Test2.class

D:\TestClassLoder下

Test1.class

Test2.class

dos下输入运行命令，结果如下：

D:\TestClassLoder>java Test1

Null

D:\TestClassLoder>

从输出结果我们可以看出，当AppClassLoader要载入Test1.class时，先请其Parent，也就是ExtClassLoader来载入，而ExtclassLoader又请求其Parent，即Bootstrap Loader来载入Test1.class. 由于 <JRE所在目录>\Classes目录为Bootstrap Loader的搜索路径之一，所以Bootstrap Loader找到了Test1.class,因此将它载入，接着在Test1.class之内有载入Test2.class的需求，由于 Test1.class是由Bootstrap Loader所载入，所以Test2.class内定是由Bootstrap Loader根据其搜索路径来找，因Test2.class也位于Bootstrap Loader可以找到的路径下，所以也被载入了，最后我们看到Test1.class与Test2.class都是由Bootstrap Loader（null）载入。

若<JRE所在目录>\lib\ext\classes下没有这两个类文件，结果也一样都为null

测试二：

<JRE所在目录>\classes下

Test1.class

<JRE所在目录>\lib\ext\classes下

Test1.class

Test2.class

D:\TestClassLoder下

Test1.class

Test2.class

dos下输入运行命令，结果如下：

D:\TestClassLoder>java Test1

Null

Exception in thread “main” java.lang.NoClassdefFoundError:Test2 at Test1.main。。。

D:\TestClassLoder>

从输出结果我们可以看出，当AppClassLoader要载入Test1.class时，先请其Parent，也就是ExtClassLoader来载入，而ExtclassLoader又请求其Parent，即Bootstrap Loader来载入Test1.class. 由于 <JRE所在目录>\Classes目录为Bootstrap Loader的搜索路径之一，所以Bootstrap Loader找到了Test1.class,因此将它载入，接着在Test1.class之内有载入Test2.class的需求，由于 Test1.class是由Bootstrap Loader所载入，所以Test2.class内定是由Bootstrap Loader根据其搜索路径来找，但是因为Bootstrap Loader根本找不到Test2.class（被我们删除了），而Bootstrap Loader又没有Parent，所以无法载入Test2.class.最后我们看到Test1.class是由Bootstrap Loader（null）载入，而Test2.class则无法载入

若<JRE所在目录>\lib\ext\classes下没有这两个类文件，结果也一样

测试三

<JRE所在目录>\classes下

Test2.class

<JRE所在目录>\lib\ext\classes下

Test1.class

Test2.class

D:\TestClassLoder下

Test1.class

Test2.class

dos下输入运行命令，结果如下：

D:\TestClassLoder>java Test1

。。。ExtClassLoader。。。

Null

D:\TestClassLoder>

从输出结果我们可以看出，当AppClassLoader要载入Test1.class时，先请其Parent，也就是ExtClassLoader来载入，而ExtclassLoader又请求其Parent，即Bootstrap Loader来载入Test1.class.但是Bootstrap Loader无法在其搜索路径下找到Test1.class(被我们删掉了)，所以ExtClassLoader只得自己搜索，因此 ExtClassLoader在其搜索路径 <JRE所在目录>\lib\ext\classes下找到了Test1.class，因此将它载入，接着在Test1.class之内有载入Test2.class的需求，由于Test1.class是由ExtClassLoader所载入，所以Test2.class内定是由 ExtClassLoader根据其搜索路径来找，但是因为ExtClassLoader有Parent,所以先由Bootstrap Loader帮忙寻找，Test2.class位于Bootstrap Loader可以找到的路径下，所以被Bootstrap Loader载入了.最后我们看到Test1.class是由ExtClassLoader载入，而Test2.class则是由Bootstrap Loader（null）载入

了解了以上规则，请朋友们自行分析以下场景的执行结果

测试四：

<JRE所在目录>\classes下

<JRE所在目录>\lib\ext\classes下

Test1.class

Test2.class

D:\TestClassLoder下

Test1.class

Test2.class

测试五：

<JRE所在目录>\classes下

<JRE所在目录>\lib\ext\classes下