Java类加载器

1.* 类加载器详解

类加载器负责将.class文件（可能在磁盘上，也可能在网络上）加载到内存中，并为之生成对应的java.lang.Class对象。尽管在Java开发中无须过分关心类加载机制，但编程人员都应该了解其工作机制，明白如何做才能让其更好地满足我们的需要。

1.*.& 类加载器简介

类加载器负责加载所有的类，系统为所有被载入内存中的类生成一个java.lang.Class实例。一旦一个类被载入JVM中，同一个类就不会被再次载入了。现在的问题是，怎么样才算“同一个类”？

正如一个对象有一个唯一的标识一样，一个载入JVM的类也有一个唯一的标识。在Java中，一个类用其全限定类名（包括包名和类名）作为标识；但在JVM中，一个类用其全限定类名和其类加载器作为其唯一标识。

当JVM启动时，会形成由3个类加载器组成的初始类加载器层次结构：

• Bootstrap ClassLoader：根类加载器。
• Extension ClassLoader：扩展类加载器。
• System ClassLoader：应用类加载器。

Bootstrap ClassLoader被称为引导（也称为原始或根）类加载器，它负责加载Java的核心类。在Sun的JVM中，当执行java.exe命令时，使用-Xbootclasspath选项或使用-D选项指定sun.boot.class.path系统属性值可以指定加载附加的类。

根类加载器非常特殊，它并不是java.lang.ClassLoader的子类，而是由JVM自身实现的。

下面程序可以获得根类加载器所加载的核心类库：

查看代码

运行的结果：

看到这个运行结果，读者应该明白为什么程序中可以使用String、System这些核心类库——因为这些核心类库都在D:/Program Files/Java/jre/lib/rt.jar文件中，读者使用WinRAR来查看该文件的内容即可发现这一点。

Extension Classloader被称为扩展类加载器，它负责加载JRE的扩展目录（%JAVA_HOME%/jre/lib/ext或者由java.ext.dirs系统属性指定的目录）中JAR包的类。

通过这种方式，就可以为Java扩展核心类以外的新功能，只要我们把自己开发的类打包成JAR文件，然后放入JAVA_HOME/jre/lib/ext路径即可（对于笔者的安装环境来说，扩展路径为：D:/Java/jdk1.7.0/jre/lib/ext）。

Application Classloader被称为应用（也称为系统）类加载器，它负责在JVM启动时加载来自java命令的-classpath选项、java.class.path系统属性，或CLASSPATH环境变量所指定的JAR包和类路径。程序可以通过ClassLoader的静态方法getSystemClassLoader()来获取应用类加载器。如果没有特别指定，则用户自定义的类加载器都以应用类加载器作为父加载器。

1.*.& 类加载机制

JVM的类加载机制主要有如下3种：

• 全盘负责。所谓全盘负责，就是当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显式使用另外一个类加载器来载入。
• 父类委托。所谓父类委托，则是先让parent（父）类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。
• 缓存机制。缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区中搜寻该Class，只有当缓存区中不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区中。这就是为什么修改了Class后，必须重新启动JVM，程序所做的修改才会生效的原因。

注意：类加载器之间的父子关系并不是类继承上的父子关系，这里的父子关系是类加载器实例之间的关系。

除了可以使用Java提供的类加载器之外，开发者也可以实现自己的类加载器，自定义的类加载器通过继承ClassLoader来实现。

JVM中这4种类加载器的层次结构如图：

查看代码

运行上面程序，会看到如下运行结果：

从上面运行结果可以看出，应用类加载器的加载路径是程序运行的当前路径，扩展类加载器的加载路径是/Users/hzhiping/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_333.jdk/Contents/Home/jre/lib/ext，但我们看到扩展类加载器的父加载器是null，并不是根类加载器。这是因为根类加载器并没有继承ClassLoader抽象类，所以扩展类加载器的getParent()方法返回null。但实际上，扩展类加载器的父类加载器是根类加载器，只是根类加载器并不是Java实现的。

应用类加载器是AppClassLoader的实例，扩展类加载器是ExtClassLoader的实例。实际上，这两个类都是URLClassLoader类的实例。

类加载器加载Class大致要经过如下8个步骤：

1、检测此Class是否载入过（即在缓存区中是否有此Class），如果有则直接进入第8步，否则接着执行第2步。

注意：JVM的根类加载器并不是Java实现的，而且由于程序通常无须访问根类加载器，因此访问扩展类加载器的父类加载器时返回null。

2、如果父类加载器不存在（如果没有父类加载器，则要么parent一定是根类加载器，要么本身就是根类加载器），则跳到第4步执行；如果父类加载器存在，则接着执行第3步。

3、请求使用父类加载器去载入目标类，如果成功载入则跳到第8步，否则接着执行第5步。

4、请求使用根类加载器来载入目标类，如果成功载入则跳到第8步，否则跳到第7步。

5、当前类加载器尝试寻找Class文件（从与此ClassLoader相关的类路径中寻找），如果找到则执行第6步，如果找不到则跳到第7步。

6、从文件中载入Class，成功载入后跳到第8步。

7、抛出ClassNotFoundException异常。

8、返回对应的java.lang.Class对象。

其中，第5、6步允许重写ClassLoader的findClass()方法来实现自己的载入策略，甚至重写loadClass()方法来实现自己的载入过程。

1.*.& 创建并使用自定义的类加载器

JVM中除根类加载器之外的所有类加载器都是ClassLoader子类的实例，开发者可以通过扩展ClassLoader的子类，并重写该ClassLoader所包含的方法来实现自定义的类加载器。查阅API文档中关于ClassLoader的方法不难发现，ClassLoader中包含了大量的protected方法——这些方法都可被子类重写。

ClassLoader类有如下两个关键方法：

• loadClass(String name, boolean resolve)：该方法为ClassLoader的入口点，根据指定的二进制名称来加载类，系统就是调用ClassLoader的该方法来获取指定类对应的Class对象。
• findClass(String name)：根据二进制名称来查找类。

如果需要实现自定义的ClassLoader，则可以通过重写以上两个方法来实现，当然我们推荐重写findClass()方法，而不是重写loadClass()方法。loadClass()方法的执行步骤如下：

1、用findLoadedClass(String)来检查是否已经加载类，如果已经加载则直接返回。

2、在父类加载器上调用loadClass()方法。如果父类加载器为null，则使用根类加载器来加载。

3、调用findClass(String)方法查找类。

从上面步骤中可以看出，重写findClass()方法可以避免覆盖默认类加载器的父类委托、缓冲机制两种策略；如果重写loadClass()方法，则实现逻辑更为复杂。

在ClassLoader里还有一个核心方法：Class defineClass(String name, byte[] b, int off, int len)，该方法负责将指定类的字节码文件（即Class文件，如Hello.class）读入字节数组byte[] b内，并把它转换为Class对象，该字节码文件可以来源于文件、网络等。

defineClass()方法管理JVM的许多复杂的实现，它负责将字节码分析成运行时数据结构，并校验有效性等。不过不用担心，程序员无须重写该方法。事实上，该方法是final型，即使我们想重写也没有机会。

除此之外，ClassLoader里还包含如下一些普通方法：

• findSystemClass(String name)：从本地文件系统装入文件。它在本地文件系统中寻找类文件，如果存在，就使用defineClass()方法将原始字节转换成Class对象，以将该文件转换成类。
• static getSystemClassLoader()：这是一个静态方法，用于返回应用类加载器。
• getParent()：获取该类加载器的父类加载器。
• resolveClass(Class<?> c)：链接指定的类。类加载器可以使用此方法来链接类c。读者无须理会关于此方法的太多细节。
• findLoadedClass(String name)：如果此Java虚拟机已加载了名为name的类，则直接返回该类对应的Class实例，否则返回null。该方法是Java类加载缓存机制的体现。

下面程序开发了一个自定义的ClassLoader，该ClassLoader通过重写findClass()方法来实现自定义的类加载机制。这个ClassLoader可以在加载类之前先编译该类的源文件，从而实现运行Java之前先编译该程序的目标，这样即可通过该ClassLoader直接运行Java源文件：

查看代码

上面程序中的代码重写了findClass()方法，通过重写该方法就可以实现自定义的类加载机制。在本类的findClass()方法中先检查需要加载类的Class文件是否存在，如果不存在则先编译源文件，再调用ClassLoader的defineClass()方法来加载这个Class文件，并生成相应的Class对象。

提示：上面程序的main()方法中的代码使用了反射来调用方法。

接下来我们可以随意提供一个简单的主类，该主类无须编译就可以使用上面的CompileClassLoader来运行它：

查看代码

无须编译该Hello.java，可以直接使用如下命令来运行该Hello.java程序：

java CompileClassLoader Hello 疯狂Java讲义

运行结果如下：

CompileClassLoader: 正在编译 Hello.java...
运行Hello的参数：疯狂Java讲义

本示例程序提供的类加载器功能比较简单，仅仅提供了在运行之前先编译Java源文件的功能。实际上，使用自定义的类加载器，可以实现如下常见功能：

• 执行代码前自动验证数字签名。
• 根据用户提供的密码解密代码，从而可以实现代码混淆器来避免反编译Class文件。
• 根据用户需求来动态地加载类。
• 根据应用需求把其他数据以字节码的形式加载到应用中。

1.*.& URLClassLoader类

Java为ClassLoader提供了一个URLClassLoader实现类，该类也是应用类加载器和扩展类加载器的父类（此处是父类，就是指类与类之间的继承关系）。URLClassLoader功能比较强大，它既可以从本地文件系统获取二进制文件来加载类，也可以从远程主机获取二进制文件来加载类。

实际上，在应用程序中可以直接使用URLClassLoader来加载类，URLClassLoader类提供了如下两个构造器：

• URLClassLoader(URL[] urls)：使用默认的父类加载器创建一个ClassLoader对象，该对象将从urls所指定的系列路径来查询并加载类。
• URLClassLoader(URL[] urls, ClassLoader parent)：使用指定的父类加载器创建一个ClassLoader对象，其他功能与前一个构造器相同。

一旦得到了URLClassLoader对象之后，就可以调用该对象的loadClass()方法来加载指定类。下面程序示范了如何直接从文件系统中加载MySQL驱动，并使用该驱动来获取数据库连接。通过这种方式来获取数据库连接，可以无须将MySQL驱动添加到CLASSPATH环境变量中：

查看代码

上面程序中的前两行代码创建了一个URLClassLoader对象，该对象使用默认的父类加载器，该类加载器的类加载路径是当前路径下的mysql-connector-java-3.1.10-bin.jar文件，我们将MySQL驱动复制到该路径下，这样保证该ClassLoader可以正常加载到com.mysql.jdbc.Driver类。

程序使用ClassLoader的loadClass()加载指定类，并调用Class对象的newInstance()方法创建了一个该类的默认实例，也就是得到com.mysql.jdbc.Driver类的对象，当然该对象的实现类实现了java.sql.Driver接口，所以程序将其强制类型转换为Driver。程序的代码通过Driver而不是DriverManager来获取数据库连接，关于Driver接口的用法读者可以自行查阅API文档。

正如前面所看到的，当我们创建URLClassLoader时传入了一个URL数组参数，该ClassLoader就可以从这系列URL指定的资源中加载指定类，这里的URL可以以file:为前缀，表明从本地文件系统加载；可以以http:为前缀，表明从互联网通过HTTP访问来加载；也可以以ftp:为前缀，表明从互联网通过FTP访问来加载，功能非常强大。

原文地址：http://www.cnblogs.com/hzhiping/p/16908248.html