Java类加载器

概述

虚拟机设计团队把类加载阶段中的通过一个类的全限定名来获取描述此类的二进制字节流这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为类加载器。

类加载器可以说是Java语言的一项创新，也是Java语言流行的重要原因之一，它最初是为了满足Java Applet的需求而开发出来的。虽然目前Java Applet技术基本上已经”死掉”，但类加载器却在类层次划分、OSGi、热部署、代码加密等领域大放异彩。成为了Java技术体系中一块重要的基石。可谓是失之桑榆，收之东隅。

对于任意一个类，都需要由它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

代码

• 代码

package sto.customerapp.materialquery.entity;

import java.io.IOException;
import java.io.InputStream;
/**
 * 类加载器与instanceof关键字演示
 * @author yanyugang
 */
public class ClassLoadTest {
	public static void main(String[] args) throws Exception {
		// 自定义类加载器
		ClassLoader myLoader = new ClassLoader() {
			@Override
			public Class<?> loadClass(String name) throws ClassNotFoundException {
				byte[] b=null;
				try {
					String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
					InputStream is = getClass().getResourceAsStream(fileName);
					if (is == null) {
						return super.loadClass(name);
					}

					 b = new byte[is.available()];
					is.read(b);

				} catch (IOException e) {
					e.printStackTrace();
				}
				return defineClass(name, b, 0, b.length);
			}
		};
		
		Object object=myLoader.loadClass("sto.customerapp.materialquery.entity.ClassLoadTest").newInstance();
		System.out.println(object.getClass());
		// 虚拟机存在了两个ClassLoadTest类，一个是由系统应用程序类加载器加载器的，另外一个是由我们自定义的类加载器加载的
		System.out.println(object instanceof sto.customerapp.materialquery.entity.ClassLoadTest);
	}

}

• 结果

class sto.customerapp.materialquery.entity.ClassLoadTest
false

双亲委派模型

从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

类加载器分类

• 启动类加载器（Bootstrap ClassLoader）：这个类加载器负责放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库。用户无法直接使用。
• 扩展类加载器(Extension ClassLoader)：这个类加载器由sun.misc.Launcher$AppClassLoader实现。它负责<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。用户可以直接使用。
• 应用程序类加载器(Application ClassLoader)：这个类由sun.misc.Launcher$AppClassLoader实现。是ClassLoader中getSystemClassLoader()方法的返回值。它负责用户路径（ClassPath）所指定的类库。用户可以直接使用。如果用户没有自己定义类加载器，默认使用这个。
• 自定义类加载器（User ClassLoader）

双亲委派模型图

工作过程

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求。它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

• 对应代码

java.lang.ClassLoader.loadClass(String, boolean)

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        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) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }

            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                long t1 = System.nanoTime();
                c = findClass(name);

                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

破坏双亲委派模型

• JDK1.2增加java.lang.ClassLoader.findClass(String)方法
• 引入线程上下文类加载器，通过java.lang.Thread.setContextClassLoader(ClassLoader)方法设置，应用场景JNDI、JDBC、JCE、JAXB和JBI等
• 用户对程序动态性的追求导致的，比如代码热替换（HotSwap）、模块热部署（Hot Deployment）、OSGi规范

---

参考文档：

1. 深入理解Java虚拟机：JVM高级特性与最佳实践（最新第二版）