探索Android软键盘的疑难杂症
深入探讨Android异步精髓Handler
详解Android主流框架不可或缺的基石
站在源码的肩膀上全解Scroller工作机制

Android多分辨率适配框架（1）— 核心基础
Android多分辨率适配框架（2）— 原理剖析
Android多分辨率适配框架（3）— 使用指南

自定义View系列教程00–推翻自己和过往，重学自定义View
自定义View系列教程01–常用工具介绍
自定义View系列教程02–onMeasure源码详尽分析
自定义View系列教程03–onLayout源码详尽分析
自定义View系列教程04–Draw源码分析及其实践
自定义View系列教程05–示例分析
自定义View系列教程06–详解View的Touch事件处理
自定义View系列教程07–详解ViewGroup分发Touch事件
自定义View系列教程08–滑动冲突的产生及其处理

版权声明

• 本文原创作者：谷哥的小弟
• 作者博客地址：http://blog.csdn.net/lfdfhl

类加载器简介

在Java中类加载器ClassLoader负责加载所有的类，该类被加载至内存后会生成一个与之对应的java.lang.Class实例。当类被装载进JVM以后，当需要再次使用同一个类时就不用再次从内存外读取，而是直接使用JVM中的该类。嗯哼，那么怎么样才算是”同一个”类呢？或者说检验是否是”同一个”类的标准是什么呢？在Java中用类的全限定类名(包名+类名)唯一标识一个类；在JVM中用类的全限定类名(包名+类名)并结合加载它的类加载器共同唯一标识一个类。比如，tokyo.hot包下有个AVer类，该类被ClassLoader1加载进JVM；与此同时该类又被ClassLoader2加载进JVM；那么它们两者在JVM中对应的Class的唯一标识分别为(AVer,tokyo.hot,ClassLoader1)和(AVer,tokyo.hot,ClassLoader2)。这意味着同一个类被两个不同的类加载器加载至JVM时，这两个类彼此独立，互不影响是两个完全不同的Class

嗯哼，那么Java中是不是有个万能的类加载器ClassLoader可以将任何类加载进JVM呢？非也！！！JVM启动时会生成三个类加载器：

• 根类加载器：Bootstrap ClassLoader
• 扩展类加载器：Extension ClassLoader
• 系统类加载器：System ClassLoader

现在，我们来依次学习这三个类加载器

Bootstrap ClassLoader

Bootstrap ClassLoader常被称为根(原始、引导)类加载器，负责加载Java的核心类。至于它具体加载了哪些Java核心类呢？我们来通过一个例子看看

/**
 * 本文作者：谷哥的小弟
 * 博客地址：http://blog.csdn.net/lfdfhl
 */
package cn.com;
import java.net.URL;
import sun.misc.URLClassPath;

public class TestBootstrap {
    public static void main(String[] args) {
        URLClassPath bootstrapClassPath = sun.misc.Launcher.getBootstrapClassPath();
        URL[] urls = bootstrapClassPath.getURLs();
        for (int i = 0; i < urls.length; i++) {
            System.out.println(urls[i].toExternalForm());
        }
    }
}

在编写这段代码时Eclipse可能会报错：Access restriction: The type ‘Launcher’ is not API。该问题可以这么解决：Project -> Properties -> libraries然后remove原来的JRE System Library，然后再Add Library重新添加一次即可。

打印结果如下：

file:/C:/Program Files/Java/jre1.8.0_60/lib/resources.jar
file:/C:/Program Files/Java/jre1.8.0_60/lib/rt.jar
file:/C:/Program Files/Java/jre1.8.0_60/lib/sunrsasign.jar
file:/C:/Program Files/Java/jre1.8.0_60/lib/jsse.jar
file:/C:/Program Files/Java/jre1.8.0_60/lib/jce.jar
file:/C:/Program Files/Java/jre1.8.0_60/lib/charsets.jar
file:/C:/Program Files/Java/jre1.8.0_60/lib/jfr.jar
file:/C:/Program Files/Java/jre1.8.0_60/classes

咦，看到这些，我们还是觉得很陌生。是么？来，我们一起来看看熟悉的

请打开rt.jar后再打开java.lang，嗯哼，是不是看到我们熟悉的东西了String.class、Thread.class、Integer.class、Object等等。这些Java核心类正是由Bootstrap ClassLoader加载的。

Extension ClassLoader

Extention ClassLoader被称为扩展类加载器，它负责加载JRE的扩展目录(%JAVA_HOME%/jre/lib/ext)中JAR包的类。所以，可将我们自己开发好的JAR包放入该路径下从而为java扩展核心类以外的功能。

System ClassLoader

System ClassLoader被称为系统(应用)类加载器，它负责在JVM启动时加载CLASSPATH所指定的JAR包和类路径。我们可通过ClassLoader的静态方法getSystemClassLoader()获取系统类加载器。一般情况下，我们编写的java类都是由这个类加载器加载。

类加载器的工作机制

刚才我们已经介绍了这三种类加载器，我们现在通过代码的形式来再次认识它们：

/**
 * 本文作者：谷哥的小弟
 * 博客地址：http://blog.csdn.net/lfdfhl
 */
package cn.com;

import java.io.IOException;
import java.net.URL;
import java.util.Enumeration;

public class TestClassLoader {
    public static void main(String[] args) throws IOException {
        // 获取系统类加载器
        ClassLoader classLoader = ClassLoader.getSystemClassLoader();
        System.out.println("系统类加载器SystemClassLoader="+classLoader);
        Enumeration<URL> urlEnumeration = classLoader.getResources("");
        while (urlEnumeration.hasMoreElements()) {
            URL nextElement = urlEnumeration.nextElement();
            System.out.println("系统类加载器SystemClassLoader的加载路径="+nextElement);
        }
        //获取扩展类加载器
        ClassLoader extLoader = classLoader.getParent();
        System.out.println("扩展类加载器ExtClassLoader=" + extLoader);
        String property = System.getProperty("java.ext.dirs");
        System.out.println("扩展类加载器ExtClassLoader的加载路径=" + property);
        //获取扩展类加载器的父类
        ClassLoader bootstrapClassLoader=extLoader.getParent();
        if(bootstrapClassLoader==null){
            System.out.println("扩展类加载器的父类=null");
        }
    }
}

输出如下：

系统类加载器SystemClassLoader=sun.misc.Launcher$AppClassLoader@4e0e2f2a
系统类加载器SystemClassLoader的加载路径=file:/D:/Workspace/TestClassLoader01/bin/
扩展类加载器ExtClassLoader=sun.misc.Launcher$ExtClassLoader@5c647e05
扩展类加载器ExtClassLoader的加载路径=C:\Program Files\Java\jre1.8.0_60\lib\ext;C:\WINDOWS\Sun\Java\lib\ext
扩展类加载器的父类=null

在这我们可以看出来：

• 系统类加载器的加载路径是当前程序运行的路径

• 扩展类加载器的加载路径是C:\Program Files\Java\jre1.8.0_60\lib\ext

• 系统类加载器的父类是扩展类加载器

• 扩展类加载器的getParent()返回值为null，并不是我们预计的根类加载器。这是因为根类加载器Bootstrap ClassLoader没有继承java.lang.ClassLoader抽象类。当然，实际上扩展类加载器的父类加载器就是根加载器，只不过根加载器不是Java实现的而是由JVM自身实现的。

在明白了这些之后，我们再来看类加载器中的父类委托机制。

当一个类加载器收到了类加载的请求时它不会自己去尝试加载这个类，而是把该请求委派给父加载器去完成。这样一层一层地往上传递，最终所有的加载请求都被传到最顶层的根类加载器中。只有当父加载器无法完成这个加载请求时，父加载器再将该请求交给子加载器去尝试加载。

这么做有什么好处呢？
当一个类加载器负责加载某个Class时，该Class所依赖和应该的其它Class也将由该类加载器载入。我们知道java.lang.Object是所有类的父类，因此无论哪个类加载都要加载这个类，于是关于加载Object的所有的请求都汇聚到了顶层的根类加载器中，因此Object类会由根类加载器来加载。所以在一次Object类后，就不用再次加载该类了。如果不采用该父类委托模式而由各个类加载器自行加载的话，系统中就会出现多个Object类，不仅效率低下而且混乱不堪也不能保证加载的对象是同一个。