Java:浅析类加载过程（一）

《深入理解java虚拟机》一文中，把类加载的过程分为5步：加载、验证、准备、解析以及初始化。而第一步“加载”这个过程，虚拟机需要完成3大步骤：
（1）通过一个类的全限定名来获取此类的二进制流。
（2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
（3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

本文重点探讨“加载”的3大步骤中的第一个步骤的其中一部分,那就是：
通过一个类的全限定名获得此类的统一资源定位符（URL）。
为什么要研究这部分内容呢？自己分析了一下，对于开发者来说，只需要关注一下这部分就行了，基本上可以解决我们开发中的所有有关类加载的问题，至于其它的阶段里面的各种问题，正常开发的情况下很少能够碰到。

本文主要内容

主要是分析一下源码，了解一下类加载过程。

1. 基本的类加载器与加载过程。
2. 通过类名找到url，全过程源码分析解析。
3. 浅析：我们重写了第三方包中的类，并把这个类拷贝在我们的工程下，为什么加载到的就是我们重写的类？
4. 开发工具启动工程的时候与命令行启动有什么区别，他们分别做了什么。
5. 常用的使用加载配置文件的方式：class.getResource()与classLoader.getResource()方法的源码解读与正确使用。

注：本文所有的源码都来自于虚拟机hotspot的JDK1.8。

类加载模型：双亲委派模型

在虚拟机中，有3种基本的类加载器：

• 启动类加载器（Bootstrap ClassLoader）:主要负责加载%JAVA_HOME%/lib目录下的jar包。这个类加载器是由C++实现的，代码中无法引用到，但是仍然可以看到它的影子，比如在ClassLoader这个类里面有一个方法就是使用这个类加载去加载的：

private native Class<?> findBootstrapClass(String name);

• 扩展类加载器（Extension ClassLoader）:负责加载%JAVA_HOME%/lib/ext目录下的类库，这个类可以直接引用到，类名是：sun.misc.Launcher.ExtClassLoader
• 应用程序类加载器（Application ClassLoader）:负责加载用户定义的类路径上的类库，也就是系统变量“java.class.path”上面指定的类库。这个类加载是我们最常用的，凡是使用main方法启动的程序都是用的这个类加载器。这个也是我们接下来要探讨的类加载器。类名是：sun.misc.Launcher.AppClassLoader

我们的应用程序一般都是使用上述3种类加载器，当然也会有自定义的一些。类加载对象中有一个属性，叫做parent，也是类加载器。也就是在新建类加载器的时候，需要指定父类加载器。这几种类加载器的关系如下图所示：

每个类加载器都有父类加载器，从ClassLoader的方法里面就能看出来，优先使用父类加载器去加载器，如果没有加载到才会使用自己的。

    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 首先看一下有没有被加载过
            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) {
                   //如果没有找到，再使用自己的去加载。
                    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;
        }
    }

这边实现的话使用了组合，而不是继承。这一点也在平时开发过程中非常关键，如果有时候我们需要使用一些父类的方法的时候，也并不一定必须继承，也可以用一个属性指向父类，反正就是：多用组合少用继承。

从这点来看，我倒觉得明明是单亲啊，为什么要叫做双亲呢，哈哈。可能双亲指的是：每一个应用程序的类加载器都会有扩展类与启动类加载器这两个类加载器。

因此，我们如果重写了JDK本身的一些类，编译本身不会有问题，但是在运行态永远加载不到自己写的类，原因也很简单。
在此简述了一下类加载器模型，当然这也仅仅是JDK本身推荐的方式，并不是强制的。关于类加载机制应用的比较好且值得我们学习就是tomcat与osgi框架了。

类加载类图

稍微先看一下应用程序类加载器的类图，如下：

看下右侧的继承关系即可，重点研究的类是URLClassLoader，就是通过URL去加载一个类。什