《深入理解Java虚拟机》读书笔记（六）--虚拟机类加载机制（下）
一、类加载器与类
通过一个类的全限定名来获取描述此类的二进制字节流，实现这个动作的代码模块称为“类加载器”。用户可以使用自定义的类加载器，以此自己决定如何去获取所需要的类。
在虚拟机中，对于任何一个类的唯一性是由加载它的类加载器和这个类的全限定名共同确定的，每一个类加载器都有一个独立的类命名空间。这里需要注意的是，对于相同全限定名的类，如果类加载器不同，会影响到类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也会影响使用instanceof关键字做对象所属关系判定等情况。
另外，对于synchronized(更多相关synchronized的信息可参考Java并发编程(九)：深入JVM 核心全面理解 Synchronized)，如果使用xxx.class作为锁对象，那么在不同的类加载器情况下，也会有不同的表现。
站在Java虚拟机的角度来讲，只存在两种不同的类加载器：
- 启动类加载器（Bootstrap ClassLoader）:这个类加载器使用C 实现，是虚拟机自身的一部分
- 所有其他的类加载器：这些类加载器都由Java实现，独立于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader
站在Java开发人员的角度来看，类加载器大致可以按照以下划分：
- 启动类加载器（Bootstrap ClassLoader）:由C 实现，没有父加载器，负责加载<JAVA_HOME>lib目录或-Xbootclasspath参数指定路径中的类库。仅按照文件名识别，比如rt.jar，名字不符合的类库，即使放在对应目录中也不会被加载。
- 扩展类加载器（Extension ClassLoader）：由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>libext目录或java.ext.dirs系统变量指定路径中的所有类库，开发者可以直使用扩展类加载器。
- 应用程序类加载器（Application ClassLoader）：由sun.misc.Launcher$AppClassLoader实现。由于它是ClassLoader中的getSystemClassLoader()方法的返回值，所以也被称为系统类加载器。它负责加载用户类路径（classpath）上所指定的类库，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
- 自定义类加载器（User ClassLoader）：可继承抽象类ClassLoader实现，按照自己的意愿加载字节码文件。
二、双亲委派
双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委派给父类加载器去完成，每一层的类加载器都是如此，因此所有的加载请求都应该传到启动类加载器（Bootstrap ClassLoader）中，之后当父类反馈自己无法完成这个加载请求（在它的搜索范围中没有找到所需的类）时，子加载器才会尝试去自己加载。这里类加载器的父子关系一般不会以继承的关系实现，而是使用组合关系来复用父加载器的代码。
类加载器双亲委派模型（网图）
双亲委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的一种类加载器实现方式。它最大的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如对于类java.lang.Object，它存放在rt.jar中，无论哪一个类加载器要加载这个类，最终都会委派给最顶端的启动类加载器进行加载，保持了Object类在环境中的唯一性。如果用户自己编写了一个java.lang.Object的类，并放在程序的classpath中，那系统中将会出现多个不同的Object类，应用程序将会变得一片混乱。
注：事实上，即使自定义了自己的类加载器，强行用defineClass()方法去加载一个以“java.lang”开头的类也不会成功，虚拟机会抛出Prohibited package name:java.lang异常。
三、破坏双亲委派模型
3.1 ClassLoader的历史原因
双亲委派模型在JDK1.2之后才被引入，而类加载器和抽象类java.lang.ClassLoader则在JDK1.0就已经存在，面对已经存在的用户自定义类加载器的实现代码，Java设计者不得不做出一些妥协。为了向前兼容，JDK1.2之后的java.lang.ClassLoader添加了一个新的protected方法findClass()。在此之前，用户继承ClassLoader的唯一目的就是为了重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法的唯一逻辑就是调用自己的loadClass()，所以此时的用户要实现自己的类加载逻辑，除了重写loadClass()方法之外，别无选择。
而双亲委派的逻辑就是在loadClass()方法中实现的，如果不想破坏双亲委派模型，那么提倡不要去覆盖loadClass()方法，而应当覆盖findClass()方法。在ClassLoader的loadClass方法的逻辑里，如果父类加载失败，则会调用自己的findClass()方法来完成加载，以保证符合双亲委派模型。
3.2 JNDI和ThreadContextClassLoader
JNDI（Java Naming and Directory Interface，Java命名和目录接口），它的核心代码由启动类加载器加载，但是它需要调用由独立厂商实现并部署在应用程序的classpath下的JNDI接口提供者（SPI）的实现，但是启动类加载器不能加载这些类。
以SPI举例，对于某些功能，比如日志、JDBC等等，Java本身只提供了接口，由用户自己实现或选择第三方提供的实现类，这样遵循了可插拔的特性。为了支持这点，Java提供了一种服务发现机制：为一些接口寻找具体的实现类。当作为服务提供者实现了某个服务接口之后，需要在jar包的META-INF/services/目录下创建一个以服务接口全限定名命名的文件，将接口实现类全限定名配置在该文件中。JDK提供了一个根据此规则寻找服务实现者的工具：ServiceLoader。使用ServiceLoader可以找到指定接口的实现类，进而完成服务实现者的加载。
这其中出现的问题就是ServiceLoader是由启动类加载器加载，而服务实现者并不在其能加载的文件允许范围内，于是便出现了冲突。为了解决这个问题，Java设计团队引入了一个不太优雅却又十分强大的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可通过Thread类的setContextClassLoader方法进行设置，如果创建线程时没有设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那默认就是应用程序类加载器（ApplicationClassLoader）。启动类加载器知道自己不能加载服务实现者，便可以从当前线程获取ThreadContextClassLoader，使用这个TCCL来加载服务实现者，以此便打通了双亲委派模型的层次结构来逆向使用类加载器。Java中所有涉及SPI的动作基本都采用这种方式。
3.3 OSGI模块化热部署
在OSGI中，每一个程序模块（Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGI环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构。
注：对于支持同时部署多个应用的servlet容器来说，也有类似打破双亲委派模型的结构，将在后面类加载及执行子系统中做进一步阐述。
所属专题
- 《深入理解Java虚拟机》读书笔记，架构君整理通俗易懂
