java的类加载机制

ClassLoader的双亲委派模型：

       所有的类加载器都是有层级结构的，每个类加载器都有一个父类类加载器（通过组合实现，而不是继承），除了启动类加载器（Bootstrap ClassLoader）

 

       当一个类加载器接收到一个类加载请求时，首先将这个请求委派给它的父加载器去加载，所以每个类加载请求最终都会传递到顶层的启动类加载器，如果父加载器无法加载时，子类加载器才会去尝试自己去加载

 

        通过双亲委派模型就实现了类加载器的三个特性：

                委派（delegation）：子类加载器委派给父类加载器加载

                可见性（visibility）：子类加载器可访问父类加载器加载的类，父类不能访问子类加载器加载的类

                唯一性（uniqueness）：可保证每个类只被加载一次

 

Java的类加载器：

         启动类加载器（Bootstrap ClassLoader），是虚拟机自身的一部分

         所有其他的类加载器，独立于虚拟机外部，都继承自抽象类 java.lang.ClassLoader

 

         1、启动类加载器（Bootstrap/Primordial/NULL ClassLoader）：顶层的类加载器，没有父类加载器。负责加载 /lib 目录下的，或则被 -Xbootclasspath 参数所指定路径中的，并被 JVM 识别的（仅按文件名识别，如 rt.jar，名字不符合的类库即使放在 lib 目录也不会被加载）类库加载到虚拟机内存中。所有被 Bootstrap classloader 加载的类，它的 Class.getClassLoader 方法返回的都是 null，所以也称作 NULL ClassLoader。

 

         2、扩展类加载器（Extension CLassLoader）：由 sun.misc.Launcher$ExtClassLoader 实现，负责加载 <JAVA_HOME>/lib/ext 目录下，或被 java.ext.dirs 系统变量所指定的目录下的所有类库

 

         3、应用程序类加载器（Application/System ClassLoader）：由 sun.misc.Launcher$AppClassLoader 实现。它是 ClassLoader.getSystemClassLoader() 方法的默认返回值，所以也称为系统类加载器（System ClassLoader）。它负责加载 classpath 下所指定的类库，如果应用程序没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

 

 

         class.getResource("/") == class.getClassLoader().getResource("")   //当前类所在classpath的根目录

                Class.getResource真正调用ClassLoader.getResource方法之前，会先获取文件的路径（path不以'/'开头时，默认是从此类所在的包下取资源；path以'/'开头时，则是从项目的ClassPath根下获取资源）。

 

                ClassLoader.getResource方法会通过双亲委派机制，先委派双亲去加载类，如果双亲没有加载到，则再由自己加载。

 

线程的上下文类加载器：

         线程上下文类加载器（context class loader）是从 JDK 1.2 开始引入的。类 java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。

 

         如果没有通过 setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文类加载器。Java应用运行的初始线程的上下文类加载器是系统类加载器。如果不做任何的设置，那么线程的上下文类加载器默认就是系统类加载器。

 

Web容器的类加载器：

         Web容器的类加载器的实现方式与一般的Java应用有所不同。不同的Web容器的实现方式也会有所不同。

         以 Apache Tomcat 来说，每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法，其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是：Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。

 

自定义ClassLoader：

对于ClassLoader，其实我们可以随心所欲的自定义它，只要重载findClass()方法就可以。

public class Test {
	public static void main(String[] args) throws Exception {
		DiskClassLoader loader = new DiskClassLoader("D:\\work\\target\\classes");
		Class<?> clazz = loader.loadClass("com.easy.ebook.bean.User");
		System.out.println(clazz);
	}
	
	static class DiskClassLoader extends ClassLoader {
	    private String mFilePath;

	    public DiskClassLoader(String mFilePath) {
	        this.mFilePath = mFilePath;
	    }

	    @Override
	    protected Class<?> findClass(String name) throws ClassNotFoundException {
	        String filepath = this.mFilePath + File.separator + name.replace('.', File.separatorChar) + ".class";
	        System.out.println(filepath);
	        
	        File file = new File(filepath);
	        try {
	            FileInputStream ins = new FileInputStream(file);
	            ByteArrayOutputStream bos = new ByteArrayOutputStream();
	            int len = 0;
	            try {
	                while((len = ins.read()) != -1) {
	                    bos.write(len);
	                }
	            } catch (IOException ioe) {
	                ioe.printStackTrace();
	            }
	            byte[] data = bos.toByteArray();
	            ins.close();
	            bos.close();
	            return defineClass(name, data, 0, data.length);
	        } catch (IOException exp) {
	            exp.printStackTrace();
	        }
	        return super.findClass(name);
	    }
	}
}