ClassLoader简介

阅读量：4157 次

发布时间：2019-05-26

本文共 14592 字，大约阅读时间需要 48 分钟。

以下ClassLoader介绍转载自：http://blog.chinaunix.net/uid-21227800-id-65885.html

ClassLoader主要对类的请求提供服务，当JVM需要某类时，它根据名称向ClassLoader要求这个类，然后由ClassLoader返回这个类的class对象。 1.1 几个相关概念ClassLoader负责载入系统的所有Resources（Class，文件，来自网络的字节流等），通过ClassLoader从而将资源载入JVM

每个class都有一个reference，指向自己的ClassLoader。Class.getClassLoader()

array的ClassLoader就是其元素的ClassLoader，若是基本数据类型，则这个array没有ClassLoader

1.2 主要方法和工作过程Java1.1及从前版本中，ClassLoader主要方法：

Class loadClass( String name, boolean resolve ); ClassLoader.loadClass() 是 ClassLoader 的入口点

defineClass 方法是 ClassLoader 的主要诀窍。该方法接受由原始字节组成的数组并把它转换成 Class 对象。原始数组包含如从文件系统或网络装入的数据。

findSystemClass 方法从本地文件系统装入文件。它在本地文件系统中寻找类文件，如果存在，就使用 defineClass 将原始字节转换成 Class 对象，以将该文件转换成类。当运行 Java 应用程序时，这是 JVM 正常装入类的缺省机制。

resolveClass可以不完全地（不带解析）装入类，也可以完全地（带解析）装入类。当编写我们自己的 loadClass 时，可以调用 resolveClass，这取决于 loadClass 的 resolve 参数的值

findLoadedClass 充当一个缓存：当请求 loadClass 装入类时，它调用该方法来查看 ClassLoader 是否已装入这个类，这样可以避免重新装入已存在类所造成的麻烦。应首先调用该方法

一般load方法过程如下：

调用 findLoadedClass 来查看是否存在已装入的类。

如果没有，那么采用某种特殊的神奇方式来获取原始字节。（通过IO从文件系统，来自网络的字节流等）

如果已有原始字节，调用 defineClass 将它们转换成 Class 对象。

如果没有原始字节，然后调用 findSystemClass 查看是否从本地文件系统获取类。

如果 resolve 参数是 true，那么调用 resolveClass 解析 Class 对象。

如果还没有类，返回 ClassNotFoundException。

否则，将类返回给调用程序。

1.3 委托模型自从JDK1.2以后，ClassLoader做了改进，使用了委托模型，所有系统中的ClassLoader组成一棵树，ClassLoader在载入类库时先让Parent寻找，Parent找不到才自己找。

JVM在运行时会产生三个ClassLoader，Bootstrap ClassLoader、Extension ClassLoader和App ClassLoader。其中，Bootstrap ClassLoader是用C++编写的，在Java中看不到它，是null。它用来加载核心类库，就是在lib下的类库，Extension ClassLoader加载lib/ext下的类库，App ClassLoader加载Classpath里的类库，三者的关系为:App ClassLoader的Parent是Extension ClassLoader，而Extension ClassLoader的Parent为Bootstrap ClassLoader。加载一个类时，首先BootStrap进行寻找，找不到再由Extension ClassLoader寻找，最后才是App ClassLoader。

将ClassLoader设计成委托模型的一个重要原因是出于安全考虑，比如在Applet中，如果编写了一个java.lang.String类并具有破坏性。假如不采用这种委托机制，就会将这个具有破坏性的String加载到了用户机器上，导致破坏用户安全。但采用这种委托机制则不会出现这种情况。因为要加载java.lang.String类时，系统最终会由Bootstrap进行加载，这个具有破坏性的String永远没有机会加载。

委托模型还带来了一些问题，在某些情况下会产生混淆，如下是Tomcat的ClassLoader结构图:

Bootstrap

System

Common

Catalina Shared

Webapp1 Webapp2 ...

由 Common 类装入器装入的类决不能（根据名称）直接访问由 Web 应用程序装入的类。使这些类联系在一起的唯一方法是通过使用这两个类集都可见的接口。在这个例子中，就是包含由 Java servlet 实现的 javax.servlet.Servlet。

如果在lib或者lib/ext等类库有与应用中同样的类，那么应用中的类将无法被载入。通常在jdk新版本出现有类库移动时会出现问题，例如最初我们使用自己的xml解析器，而在jdk1.4中xml解析器变成标准类库，load的优先级也高于我们自己的xml解析器，我们自己的xml解析器永远无法找到，将可能导致我们的应用无法运行。

相同的类，不同的ClassLoader，将导致ClassCastException异常

1.4 线程中的ClassLoader每个运行中的线程都有一个成员contextClassLoader，用来在运行时动态地载入其它类，可以使用方法Thread.currentThread().setContextClassLoader(...);更改当前线程的contextClassLoader，来改变其载入类的行为；也可以通过方法Thread.currentThread().getContextClassLoader()来获得当前线程的ClassLoader。

实际上，在Java应用中所有程序都运行在线程里，如果在程序中没有手工设置过ClassLoader，对于一般的java类如下两种方法获得的ClassLoader通常都是同一个

this.getClass.getClassLoader()；

Thread.currentThread().getContextClassLoader()；

方法一得到的Classloader是静态的，表明类的载入者是谁；方法二得到的Classloader是动态的，谁执行（某个线程），就是那个执行者的Classloader。对于单例模式的类，静态类等，载入一次后，这个实例会被很多程序（线程）调用，对于这些类，载入的Classloader和执行线程的Classloader通常都不同。

1.5 Web应用中的ClassLoader回到上面的例子，在Tomcat里，WebApp的ClassLoader的工作原理有点不同，它先试图自己载入类（在ContextPath/WEB-INF/...中载入类），如果无法载入，再请求父ClassLoader完成。

由此可得：

对于WEB APP线程，它的contextClassLoader是WebAppClassLoader

对于Tomcat Server线程，它的contextClassLoader是CatalinaClassLoader

1.6 获得ClassLoader的几种方法可以通过如下3种方法得到ClassLoader

this.getClass.getClassLoader(); // 使用当前类的ClassLoader

Thread.currentThread().getContextClassLoader(); // 使用当前线程的ClassLoader

ClassLoader.getSystemClassLoader(); // 使用系统ClassLoader，即系统的入口点所使用的ClassLoader。（注意，system ClassLoader与根ClassLoader并不一样。JVM下system ClassLoader通常为App ClassLoader）

1.7 几种扩展应用用户定制自己的ClassLoader可以实现以下的一些应用

安全性。类进入JVM之前先经过ClassLoader，所以可以在这边检查是否有正确的数字签名等

加密。java字节码很容易被反编译，通过定制ClassLoader使得字节码先加密防止别人下载后反编译，这里的ClassLoader相当于一个动态的解码器

归档。可能为了节省网络资源，对自己的代码做一些特殊的归档，然后用定制的ClassLoader来解档

自展开程序。把java应用程序编译成单个可执行类文件，这个文件包含压缩的和加密的类文件数据，同时有一个固定的ClassLoader，当程序运行时它在内存中完全自行解开，无需先安装

动态生成。可以生成应用其他还未生成类的类，实时创建整个类并可在任何时刻引入JVM

2.0 资源载入

所有资源都通过ClassLoader载入到JVM里，那么在载入资源时当然可以使用ClassLoader，只是对于不同的资源还可以使用一些别的方式载入，例如对于类可以直接new，对于文件可以直接做IO等。 2.1 载入类的几种方法假设有类A和类B，A在方法amethod里需要实例化B，可能的方法有3种。对于载入类的情况，用户需要知道B类的完整名字（包括包名，例如"com.rain.B"）

1. 使用Class静态方法 Class.forName

Class cls = Class.forName("com.rain.B");

B b = (B)cls.newInstance();

2. 使用ClassLoader

/* Step 1. Get ClassLoader */

ClassLoader cl; // 如何获得ClassLoader参考1.6

/* Step 2. Load the class */

Class cls = cl.loadClass("com.rain.B"); // 使用第一步得到的ClassLoader来载入B

/* Step 3. new instance */

B b = (B)cls.newInstance(); // 有B的类得到一个B的实例

3. 直接new

B b = new B();

2.2 文件载入（例如配置文件等）假设在com.rain.A类里想读取文件夹 /com/rain/config 里的文件sys.properties，读取文件可以通过绝对路径或相对路径，绝对路径很简单，在Windows下以盘号开始，在Unix下以"/"开始

对于相对路径，其相对值是相对于ClassLoader的，因为ClassLoader是一棵树，所以这个相对路径和ClassLoader树上的任何一个ClassLoader相对比较后可以找到文件，那么文件就可以找到，当然，读取文件也使用委托模型

1. 直接IO

/**

* 假设当前位置是 "C:/test"，通过执行如下命令来运行A "java com.rain.A"

* 1. 在程序里可以使用绝对路径，Windows下的绝对路径以盘号开始，Unix下以"/"开始

* 2. 也可以使用相对路径，相对路径前面没有"/"

* 因为我们在 "C:/test" 目录下执行程序，程序入口点是"C:/test"，相对路径就

* 是 "com/rain/config/sys.properties"

* （例子中，当前程序的ClassLoader是App ClassLoader，system ClassLoader = 当前的

* 程序的ClassLoader，入口点是"C:/test"）

* 对于ClassLoader树，如果文件在jdk lib下，如果文件在jdk lib/ext下，如果文件在环境变量里，

* 都可以通过相对路径"sys.properties"找到，lib下的文件最先被找到

File f = new File("C:/test/com/rain/config/sys.properties"); // 使用绝对路径

//File f = new File("com/rain/config/sys.properties"); // 使用相对路径

InputStream is = new FileInputStream(f);

如果是配置文件，可以通过java.util.Properties.load(is)将内容读到Properties里，Properties默认认为is的编码是ISO-8859-1，如果配置文件是非英文的，可能出现乱码问题。

2. 使用ClassLoader

/**

* 因为有3种方法得到ClassLoader，对应有如下3种方法读取文件

* 使用的路径是相对于这个ClassLoader的那个点的相对路径，此处只能使用相对路径

InputStream is = null;

is = this.getClass().getClassLoader().getResourceAsStream(

"com/rain/config/sys.properties"); //方法1

//is = Thread.currentThread().getContextClassLoader().getResourceAsStream(

"com/rain/config/sys.properties"); //方法2

//is = ClassLoader.getSystemResourceAsStream("com/rain/config/sys.properties"); //方法3

如果是配置文件，可以通过java.util.Properties.load(is)将内容读到Properties里，这里要注意编码问题。

3. 使用ResourceBundle

ResourceBundle bundle = ResourceBundle.getBoundle("com.rain.config.sys");

这种用法通常用来载入用户的配置文件，关于ResourceBunlde更详细的用法请参考其他文档

总结：有如下3种途径来载入文件

1. 绝对路径 ---> IO

2. 相对路径 ---> IO

---> ClassLoader

3. 资源文件 ---> ResourceBundle

2.3 如何在web应用里载入资源在web应用里当然也可以使用ClassLoader来载入资源，但更常用的情况是使用ServletContext，如下是web目录结构

ContextRoot

|- JSP、HTML、Image等各种文件

|- [WEB-INF]

|- web.xml

|- [lib] Web用到的JAR文件

|- [classes] 类文件

用户程序通常在classes目录下，如果想读取classes目录里的文件，可以使用ClassLoader，如果想读取其他的文件，一般使用ServletContext.getResource()

如果使用ServletContext.getResource(path)方法，路径必须以"/"开始，路径被解释成相对于ContextRoot的路径，此处载入文件的方法和ClassLoader不同，举例"/WEB-INF/web.xml","/download/WebExAgent.rar"

-------------------------------------------------------------------------------------------------------------

要用到classloader去装载类，一般是比较复杂的系统，如存在动态类装载，reflect，ejb,aop等环境。

new的时候也是用classloader去加载的，只不过是其不同子类罢了。

另外，classloader存在下面问题：

在一个jvm中可能存在多个classloader，每个classloader拥有自己的namespace。一个classloader只能拥有一个class对象类型的实例，但是不同的classloader可能拥有相同的class对象实例，这时可能产生致命的问题。如classloadera，装载了类a的类型实例a1，而classloaderb，也装载了类a的对象实例a2。逻辑上讲a1=a2，但是由于a1和a2来自于不同的classloader，它们实际上是完全不同的，如果a中定义了一个静态变量c，则c在不同的classloader中的值是不同的。

就因为这样，classloader可以避免一些问题，比如eclipse的插件管理，不同的插件，可能有相同的包，相同的名字，用不同的classloader加载就可以避免这些问题

---------------------------------------------------------------------------------------------------------------------------------

以下文章转自：http://blog.csdn.net/sureyonder/article/details/5564181

JAVA类装载器classloader和命名空间namespace

JAVA虚拟机通过装载、连接和初始化一个JAVA类型，使该类型可以被正在运行的JAVA程序所使用。其中，装载就是把二进制形式的JAVA类型读入JAVA虚拟机中。连接就是把这种已经读入虚拟机的二进制形式的类型数据合并到虚拟机的运行时状态中去。连接阶段分为三个步骤－验证、准备和解析。验证确保了JAVA类型数据格式正确并适于JAVA虚拟机使用。准备负责为该类分配它所需的内存，比如为它的类变量分配内存。解析把常量池中的符号引用转换为直接引用，如内存地址指针。在初始化期间，激活类的静态变量的初始化代码和静态代码块。

装载步骤的最终产品是一个被装载类型的Class类的实例对象，它成为JAVA程序与内部数据结构之间的接口。对于每一个被装载的类型，虚拟机都会相应地为它创建一个Class类的实例。

1 类装载器的安全作用

JAVA类装载器在JAVA安全体系结构中起着最关重要的作用，是JAVA安全沙箱的第一道防线。类装载器体系结构在三个方面对JAVA的沙箱起作用：

1) 它防止恶意代码去干涉善意的代码

2) 它守护了被信任的类库的边界

3) 它将代码归入某类(称为保护域)，该类确定了代码可以进行哪些操作。

类装载器体系结构可以防止恶意代码去干涉善意的代码，这是通过为不同的类装载器装入的类提供不同的命名空间来实现的。

２双亲委派模型

JAVA虚拟机规范定义了两种类型的类装载器－启动类装载器和用户自定义类装载器，启动类装载器是JAVA虚拟机实现的一部分，通过继承ClassLoader类，用户可以创建自定义的类装载器来完成特定要求的加载。JAVA虚拟机已经创建了2个自定义类装载器－扩展类装载器和系统类装载器。

每一个用户自定义的类装载器在创建时被分配一个“双亲”parent类装载器。如果没有显示地传递一个双亲类装载器给用户自定义的类装载器的构造方法，系统类装载器就默认被指定为双亲。如果传递到构造方法的是一个已有的用户自定义类装载器的引用，该用户自定义类装载器就作为双亲；如果向构造方法传递了null，启动类装载器就是双亲。

启动类装载器Bootstrap Classloader：它是JAVA虚拟机实现的一部分，是c/c++实现的，它没有双亲。启动类装载器装载JAVA核心库代码。

扩展类装载器Extension Classloader：继承自URLClassLoader，初始化向构造方法传递了null，所以双亲是Bootstrap Classloaser。它从java.ext.dirs扩展目录中装载代码。

系统类装载器Application Classloader：继承自URLClassLoader，双亲是Extension Classloaser。它从CLASSPATH路径中装载应用程序代码。

其中，网络类装载器URLClassLoader是JAVA库提供的一个类装载器，用来从网络其他位置装载类。

双亲孩子类装载器委派链

在双亲委派模型下，当一个装载器被请求装载某个类时，它首先委托自己的双亲parent去装载，若parent能装载，则返回这个类所对应的Class对象，若parent不能装载，则由parent的请求者去装载。

现在假设要求Cindy去装载一个名为java.io.FileReader的类型。Cindy第一件事情就是去找Mom来装载那个类型；Mom所做的第一件事情就是去找Grandma来装载那个类型；而Grandma首先去找启动类装载器去装载。在这个例子中，启动类装载器可以装载那个类型，它就返回代表java.io.FileReader的Class实例给Grandma。Grandma传递该Class的引用 Mom，Mom再回传给Cindy，Cindy返回给程序。

在此模型下，启动类装载器可以抢在扩展类装载器之前去装载类，而扩展类装载器可以抢在系统类装载器之前去装载那个类，系统类装载器又可以抢在网络类装载器之前去装载它。这样，使用双亲-孩子委派链的方式，启动类装载器会在最可信的类库－核心JAVA API－中首先检查每个被装载的类型，然后，才依次到扩展路径、系统类路径中检查被装载的类型文件。用这种方法，类装载器的体系结构就可以防止不可靠的代码用它们自己的版本来替代可以信任的类。

３命名空间

由不同的类装载器装载的类将被放在虚拟机内部的不同命名空间。命名空间由一系列唯一的名称组成，每一个被装载的类有一个名字。JAVA虚拟机为每一个类装载器维护一个名字空间。例如，一旦JAVA虚拟机将一个名为Volcano的类装入一个特定的命名空间，它就不能再装载名为Valcano的其他类到相同的命名空间了。可以把多个Valcano类装入一个JAVA虚拟机中，因为可以通过创建多个类装载器从而在一个JAVA应用程序中创建多个命名空间。

1) 初始类装载器/ 定义类装载器

命名空间有助于安全的实现，因为你可以有效地在装入了不同命名空间的类之间设置一个防护罩。在JAVA虚拟机中，在同一个命名空间内的类可以直接进行交互，而不同的命名空间中的类甚至不能觉察彼此的存在，除非显示地提供了允许它们进行交互的机制，如获取Class对象的引用后使用反射来访问。

如果要求某个类装载器去装载一个类型，但是却返回了其他类装载器装载的类型，这种装载器被称为是那个类型的初始类装载器 ；而实际装载那个类型的类装载器被称为该类型的定义类装载器 。任何被要求装载类型，并且能够返回Class实例的引用代表这个类型的类装载器，都是这个类型的初始类装载器。在上面的一个例子中，java.io.FileReader定义类装载器是启动类装载器，Cindy、Mom、Grandma、启动类装载器都是初始类装载器。

虚拟机会为每一个类装载器维护一张列表，列表中是已经被请求过的类型的名字。这些列表包含了每一个类装载器被标记为初始类装载器的类型，它们代表了每一个类装载器的命名空间。虚拟机总是会在调用loadClass()之前检查这个内部列表，如果这个类装载器已经被标记为是这个具有该全限定名的类型的初始类装载器，就会返回表示这个类型的Class实例，这样，虚拟机永远不会自动在同一个用户自定义类装载器上调用同一个名字的类型两次。

2) 命名空间的类型共享

前面提到过只有同一个命名空间内的类才可以直接进行交互，但是我们经常在由用户自定义类装载器定义的类型中直接使用JAVA API类，这不是矛盾了吗？这是类型共享原因－如果某个类装载器把类型装载的任务委派给另外一个类装载器，而后者定义了这个类型，那么被委派的类装载器装载的这个类型，在所有被标记为该类型的初始类装载器的命名空间中共享。

例如上面的例子中，Cindy可以共享Mon、Grandma、启动类装载器的命名空间中的类型，Kenny也可以共享 Mon、Grandma、启动类装载器的命名空间中的类型，但是Cindy和Kenny的命名空间不能共享。

3) 运行时包

每个类装载器都有自己的命名空间，其中维护着由它装载的类型。所以一个JAVA程序可以多次装载具有同一个全限定名的多个类型。这样一个类型的全限定名就不足以确定在一个JAVA虚拟机中的唯一性。因此，当多个类装载器都装载了同名的类型时，为了唯一表示该类型，还要在类型名称前加上装载该类型的类装载器来表示－[classloader class]。

在允许两个类型之间对包内可见的成员进行访问前，虚拟机不但要确定这个两个类型属于同一个包，还必须确认它们属于同一个运行时包－它们必须有同一个类装载器装载的。这样，java.lang.Virus和来自核心的java.lang的类不属于同一个运行时包，java.lang.Virus就不能访问JAVA API的java.lang包中的包内可见的成员。

４自定义类装载器

JAVA类型要么由启动类装载器装载，要么通过用户自定义的类装载器装载。启动类装载器是虚拟机实现的一部分，它以与实现无关的方式装载类型，JAVA提供了抽象类java.lang.ClassLoader，用户自定义的类装载器是类ClassLoader的子类实例，它以定制的方式装载类。所有用户自定义类装载器都实例化自ClassLoader的子类。

下面提供一个简单的用户自定义类装载器。

[java]