JVM内功心法-类加载之类加载器

JVM内功心法-类加载之类加载器

由于类加载器是负责这些和系统运行有关的所有类的加载行为，而针对不同位置的类，JVM提供了三种类加载器：

1.启动类加载器（BootStrap ClassLoader） 最顶层的加载类，主要加载核心类库，也就是我们环境变量下面%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等，还可以通过启动jvm时指定-Xbootclasspath和路径来改变Bootstrap ClassLoader的加载目录。

2.扩展类加载器（Extension ClassLoader） 加载目录%JRE_HOME%\lib\ext目录下的jar包和class`文件。还可以加载-D java.ext.dirs选项指定的目录

3.应用类加载器（Application ClassLoader） 也称为SystemAppClass。 加载当前应用的classpath的所有类(自己写的类)和jar包

class Demo{
    public static void main(String[] args) {
        ClassLoader loader=Demo.class.getClassLoader();
        System.out.println(loader);   //sun.misc.Launcher$AppClassLoader@18b4aac2
        System.out.println(loader.getParent()); //sun.misc.Launcher$ExtClassLoader@cc34f4d
        System.out.println(loader.getParent().getParent()); //null
    }
}
最后一个应该是Bootstrap类加载器，但是这里输出为null，
原因是BootStrapClassLoader是一个使用 C/C++ 编写的类加载器，它已经嵌入到了 JVM 的内核之中。
当 JVM 启动时，BootStrapClassLoader 也会随之启动并加载核心类库。当核心类库加载完成后，
BootStrapClassLoader 会创建 ExtClassLoader 和 AppClassLoader 的实例，
两个 Java 实现的类加载器将会加载自己负责路径下的类库，
这个过程可以在sun.misc.Launcher中看到。

思考1：如何保证加载的类一定是正确的呢？假如我写一个类和类库中的类取一样的名字，到底加载谁的类？

如何保证加载的类一定是正确的： 双亲委派机制：当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过，如果没有再往上。注意这个类似递归的过程，直到到达Bootstrap classLoader之前，都是在检查是否加载过，并不会选择自己去加载。直到BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。【看上图所知：自底向上去检查类是否被加载过，自顶向下尝试加载类】

部分源码如下：

public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
    }

    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
            // 根据类名查找类是否加载过
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                try {
                    // 父类递归尝试加载
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        // parent==null表示到了根加载器，那就由根加载器尝试加载
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                   //抛出类找不到异常
                }
 
                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    c = findClass(name);
                }
            }
            return c;
    }

假如我写一个类和类库中的类取一样的名字，到底加载谁的类： 通过双亲委派模型的优先级的层次关系，向上委派父加载器加载类，避免了类的重复加载，当父加载器已经加载过某一个类，子类加载器就不会重复加载这个类，保证了类的唯一性及安全性，例如你自己写一个java.lang.String的类，这时候往上寻找父类加载，根据类加载机制，在BootStrap ClassLoader已经加载了类库中的java.lang.String，以此防止 Java 核心类被篡改。

4.自定义类加载器（Custom ClassLoader）（经典案例：tomcat的自定义加载器）

思考1：Tomcat是如何实现应用jar包的隔离的？我的tomcat要跑两个程序，而且两个程序用的同一个jar包版本不一样，这时候加载器怎么加载？

我们看到，前面3个类加载和默认的一致，CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器，它们分别加载${TOMCAT_HOME}/lib和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个Jsp类加载器。

commonLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp（web应用）访问；
catalinaLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
sharedLoader：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；
WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；

从图中的委派关系中可以看出：
CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。
WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了实现JSP的HotSwap功能。很显然，Tomcat为了实现隔离性，打破了双亲委派，每个webappClassLoader加载自己的目录下的class文件。