24.0 第24章 类加载机制 24.1 类加载的基本机制和过程
第24章 类加载机制
在前几章中，我们多次提到了类加载器ClassLoader，本章就来详细讨论Java中的类加载机制与ClassLoader。
类加载器ClassLoader就是加载其他类的类，它负责将字节码文件加载到内存，创建Class对象。与之前介绍的反射、注解和动态代理一样，在大部分的应用编程中，我们需要自己实现ClassLoader。
不过，理解类加载的机制和过程，有助于我们更好地理解之前介绍的内容。在反射一章，我们介绍过Class的静态方法Class.forName，理解类加载器有助于我们更好地理解该方法。
ClassLoader一般是系统提供的，不需要自己实现，不过，通过创建自定义的ClassLoader，可以实现一些强大灵活的功能，比如：
1）热部署。在不重启Java程序的情况下，动态替换类的实现，比如Java Web开发中的JSP技术就利用自定义的ClassLoader实现修改JSP代码即生效，OSGI（OpenService Gateway Initiative）框架使用自定义ClassLoader实现动态更新。
2）应用的模块化和相互隔离。不同的ClassLoader可以加载相同的类但互相隔离、互不影响。Web应用服务器如Tomcat利用这一点在一个程序中管理多个Web应用程序，每个Web应用使用自己的ClassLoader，这些Web应用互不干扰。OSGI和Java 9利用这一点实现了一个动态模块化架构，每个模块有自己的ClassLoader，不同模块可以互不干扰。
3）从不同地方灵活加载。系统默认的ClassLoader一般从本地的．class文件或jar文件中加载字节码文件，通过自定义的ClassLoader，我们可以从共享的Web服务器、数据库、缓存服务器等其他地方加载字节码文件。
理解自定义ClassLoader有助于我们理解这些系统程序和框架，如Tomat、JSP、OSGI，在业务需要的时候，也可以借助自定义ClassLoader实现动态灵活的功能。
下面，我们首先来进一步理解Java加载类的过程，理解类ClassLoader和Class.for-Name，介绍一个简单的应用，然后探讨如何实现自定义ClassLoader，演示如何利用它实现热部署。
24.1 类加载的基本机制和过程
运行Java程序，就是执行java这个命令，指定包含main方法的完整类名，以及一个classpath，即类路径。类路径可以有多个，对于直接的class文件，路径是class文件的根目录，对于jar包，路径是jar包的完整名称（包括路径和jar包名）。
Java运行时，会根据类的完全限定名寻找并加载类，寻找的方式基本就是在系统类和指定的类路径中寻找，如果是class文件的根目录，则直接查看是否有对应的子目录及文件；如果是jar文件，则首先在内存中解压文件，然后再查看是否有对应的类。
负责加载类的类就是类加载器，它的输入是完全限定的类名，输出是Class对象。类加载器不是只有一个，一般程序运行时，都会有三个（适用于Java 9之前，Java9引入了模块化，基本概念是类似的，但有一些变化，限于篇幅，就不探讨了）。
1）启动类加载器（Bootstrap ClassLoader）：这个加载器是Java虚拟机实现的一部分，不是Java语言实现的，一般是C++实现的，它负责加载Java的基础类，主要是<JAVA_HOME>/lib/rt.jar，我们日常用的Java类库比如String、ArrayList等都位于该包内。
2）扩展类加载器（Extension ClassLoader）：这个加载器的实现类是sun.misc.Laun-cher$ExtClassLoader，它负责加载Java的一些扩展类，一般是<JAVA_HOME>/lib/ext目录中的jar包。
3）应用程序类加载器（Application ClassLoader）：这个加载器的实现类是sun.misc. Launcher$AppClassLoader，它负责加载应用程序的类，包括自己写的和引入的第三方法类库，即所有在类路径中指定的类。
这三个类加载器有一定的关系，可以认为是父子关系，Application ClassLoader的父亲是Extension ClassLoader, Extension的父亲是Bootstrap ClassLoader。注意不是父子继承关系，而是父子委派关系，子ClassLoader有一个变量parent指向父ClassLoader，在子Class-Loader加载类时，一般会首先通过父ClassLoader加载，具体来说，在加载一个类时，基本过程是：
1）判断是否已经加载过了，加载过了，直接返回Class对象，一个类只会被一个Class-Loader加载一次。
2）如果没有被加载，先让父ClassLoader去加载，如果加载成功，返回得到的Class对象。
3）在父ClassLoader没有加载成功的前提下，自己尝试加载类。
这个过程一般被称为“双亲委派”模型，即优先让父ClassLoader去加载。为什么要先让父ClassLoader去加载呢？这样，可以避免Java类库被覆盖的问题。比如，用户程序也定义了一个类java.lang.String，通过双亲委派，java.lang.String只会被Bootstrap ClassLoader加载，避免自定义的String覆盖Java类库的定义。
需要了解的是，“双亲委派”虽然是一般模型，但也有一些例外，比如：
1）自定义的加载顺序：尽管不被建议，自定义的ClassLoader可以不遵从“双亲委派”这个约定，不过，即使不遵从，以java开头的类也不能被自定义类加载器加载，这是由Java的安全机制保证的，以避免混乱。
2）网状加载顺序：在OSGI框架和Java 9模块化系统中，类加载器之间的关系是一个网，每个模块有一个类加载器，不同模块之间可能有依赖关系，在一个模块加载一个类时，可能是从自己模块加载，也可能是委派给其他模块的类加载器加载。
3）父加载器委派给子加载器加载：典型的例子有JNDI服务（Java Naming andDirectoryInterface），它是Java企业级应用中的一项服务，具体我们就不介绍了。
一个程序运行时，会创建一个Application ClassLoader，在程序中用到ClassLoader的地方，如果没有指定，一般用的都是这个ClassLoader，所以，这个ClassLoader也被称为系统类加载器（System ClassLoader）。下面，我们来具体看下表示类加载器的类ClassLoader。