类加载器

类加载器

• 启动类加载器（Bootstrap ClassLoader）：此加载器采用C++编写，一般开发中是看不到的。 负责将存放在lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机中。

• 扩展类加载器
  （Extendsion ClassLoader）：用来进行扩展类的加载，一般对应的是jrelibext目录中的类;

• 应用程序类加载器
  （AppClassLoader）：(默认)加载classpath指定的类，是最常使用的是一种加载器。

双亲委派模型

除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。

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

这种加载模式保证了由上到下的安全性，首先加载类库的类和扩展类，然后才是开发人员写的类。如果你想自己写个String类，都没机会加载的，这样就避免了一些风险。

双亲委派模型的实现：

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;
    }
}

破坏双亲委派模型

1.向前兼容带来的破坏

为了向前兼容，JDK1.2之后的Java.lang.ClassLoader添加了一个新的protected方法findClass()。在此之前，用户去继承java.lang.ClassLoader的唯一目的就是为了重写loadClass()方法。

2.自身缺陷导致被破坏

如果基础类又要调用回用户的代码，该怎么办？

如JNDI服务，它的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者(SPI)的代码，但是启动类加载器不可能认识这些代码啊。所以Java设计团队引入了线程上下文类加载器。

Thread.currentThread().setContextClassLoader(currentClassLoader);

如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作。

3.动态性带来的破坏

代码热替换、模块热部署。就像计算机外设一样，接上鼠标、U盘，不用重启机器就能立即使用，需要升级就换个，不用停机也不用重启。

Java模块化标准–OSGi
OSGi实现模块化部署的关键则是它自定义的类加载器机制的实现。每一个程序模块(Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。

Tomcat类加载器

在Tomcat目录结构中，有3组目录（”/common/“、”/server/“和”/shared/*”）可以存放
Java类库，另外还可以加上Web应用程序自身的目录“/WEB-INF/*”，一共4组，把Java类库
放置在这些目录中的含义分别如下：

• 放置在/common目录中：类库可被Tomcat和所有的Web应用程序共同使用。
• 放置在/server目录中：类库可被Tomcat使用，对所有的Web应用程序都不可见。
• 放置在/shared目录中：类库可被所有的Web应用程序共同使用，但对Tomcat自己不可
  见。
• 放置在/WebApp/WEB-INF目录中：类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见。

JSP类加载器 -> WebApp类加载器 -> Shared类加载器 -> Common类加载器

JasperLoader的加载范围仅仅是这个JSP文件所
编译出来的那一个Class，它出现的目的就是为了被丢弃：当服务器检测到JSP文件被修改
时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

思考几个问题：
- web容器是如何加载类的：如Tomcat,Jetty,Resin….
- JDBC和JNDI连接数据库的区别
- Class.forName() 和 ClassLoader.loadClass()的区别