1. 概述

类加载器是JVM执行类加载机制的前提。

1.1 Classloader的作用：

Classloader是Java的核心组件，所有的Class都是由Classloader进行加载的，Classloader负责通过各种方式将Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，Classloader在整个装载阶段，只能影响到类的加载，而无法通过Classloader去改变类的链接和初始化行为。至于它是否可以运行，则由
Execution Engine决定。

1.2 类的加载分类：显式加载vs隐式加载

class文件的显式加载与隐式加载的方式是指JVM加载class文件到内存的方式。

• 显式加载指的是在代码中通过调用Classloader加载class对象，如直接使用Class. forName(name)或this. getClass().getClassloader().loadClass()加载class对象（调用forName方法）
• 隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的class文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载到内存中。(new的方式)

在日常开发以上两种方式一般会混合使用

1.3 类加载器的必要性：

一般情况下，Java开发人员并不需要在程序中显式地使用类加载器，但是了解类加载器的加载机制却显得至关重要。从以下几个方面说：

• 避免在开发中遇到java.lang.ClassNotFoundException异常或java.lang.NoClassDefFoundError异常时，手足无措。只有了解类加载器的加载机制才能够在出现异常的时候快速地根据错误异常日志定位问题和解决问题
• 需要支持类的动态加载或需要对编译后的字节码文件进行加解密操作时，就需要与类加载器打交道了。
• 开发人员可以在程序中编写自定义类加载器来重新定义类的加载规则，以便实现一些自定义的处理逻辑。

1.4 命名空间

1.4.1 何为类的唯一性？

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在]ava虚拟机中的唯一性。毎一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等

1.4.2 命名空间

• 每个类加载器都有自己的命名空间，命名空间由该加载器及所有的父加载器所加载的类组成
• 在同一命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类
• 在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类

在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本。

1.4.3 类加载机制的基本特征

2. 类的加载器的分类

• 除了顶层的启动类加载器外，其余的类加载器都应当有自己的“父类”加载器
• 不同类加载器看似是继承关系，实际上是包含关系。在下层加载器中，包含着上层加载器的引用。

2.1 启动类加载器(引导类加载器， Bootstrap Classloader)

• 这个类加载使用C/C++语言实现的，嵌套在JVM内部
• 它用来加载Java的核心库( JAVA HOME/jre/lib/rt.jar或sun.boot.class.path路径下的内容)。用于提供JVM自身需要的类
• 并不继承自java.lang.ClassLoader，没有父加载器。
• 出于安全考虑， Bootstrap启动类加载器只加载包名为java、 javax、sun等开头的类
• 加载扩展类和应用程序类加载器，并指定为他们的父类加载器。

使用-XX:+TraceclassLoading参数得到

2.2 扩展类加载器（Extension ClassLoader）

• Java语言编写，由sun.misc. Launcher$ExtClassloader实现
• 继承于ClassLoader类
• 父类加载器为启动类加载器
• 从java.ext,dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加载。

2.3 应用程序类加载器(系统类加载器，AppClassloader)

• java语言编写，由sun.misc. Launchers$AppClassloader实现
• 继承于ClassLoader类
  父类加载器为扩展类加载器
  它负责加载环境变量classpath或系统属性java.class.path指定路
  径下的类库应用程序中的类加载器默认是系统类加载器。
  它是用户自定义类加载器的默认父加载器
  通过Classloader的getSystemClassLoader()方法可以获取到该类加
  载器

2.4 用户自定义类加载器

• 在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的。在必要时，我们还可以自定义类加载器，来定制类的加载方式。
• 体现Java语言强大生命力和巨大魅力的关键因素之一便是，Java开发者可以自定义类加载器来实现类库的动态加载加载源可以是本地的JAR包，也可以是网络上的远程资源。
• 通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现。
• 同时，自定义加载器能够实现应用隔离，例如 Tomcat, Spring等中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C++程序要好太多，想不修改C/C++程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想
• 自定义类加载器通常需要继承于ClassLoader

3. ClassLoader源码解析

类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的
加载过程采用双亲委派机制，这种机制能更好地保证
Java平台的安全。
1 定义
如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去
载这个类，而是把这个请求任务委托给父类加载器
去完成，依次递归，如果父类加载器可以完成类加载任务，就成
功返回。只有父类加载器无法完成此加载任务时，才自己去加载。
2 本质
规定了类加载的顺序是：引导类加载器先加载，若加载不到，由扩
展类加载器加载，若还加载不到，才会由系统类加载
器或自定义的类加载器进行加载。

双亲委派机制优势
避免类的重复加载，确保一个类的全局唯一性
Java类随着它的类加载器一起具备了一种带有优先级的层次关系，
通过这种层级关可以避免类的重复加载，当父亲
已经加载了该类时，就没有必要子ClassLoader再加载一次
保护程序安全，防止核心API被随意纂改

2 代码支持
双亲委派机制在
java.lang,Classloader,loadClass( String, boolean)
接口中体现。该接口的逻辑如下：
(1)先在当前加载器的缓存中查找有无目标类，如果有，直接返回。
(2)判断当前加载器的父加載器是否为空，如果不为空，
则调用 parent.loadclass(nane, false)接口进行加载。
(3)反之，如果当前加载器的父类加载器为空，则调用
findbootstrapclassornul(name)接口，让引导类加载器进行
加载。
(4)如果通过以上3条路径都没能成功加载，则调用
findclass(name)接口进行加载。该接口最终会调用
java.1ang.Classloader接口的 definedClass系列
的 native接口加载目标Java类。
双亲委派的模型就隐藏在这第2和第3步中。
3.举例
假设当前加载的是java.lang. objecti这个类，很显然，该
类属于JDK中核心得不能再核心的一个类，因此一定只能由
引导类加载器进行加载。当JVM准备加载javalang.Object时，
JVM默认会使用系统类加载器去加载，按照上面
的理转，在第1步从系统类的缓存中背定查找不到该类，于
是进入第2步由于从系统类加载器的父加载器是扩展类加载器，
于是扩展类加载器继续从第一步开始重复。由于扩展类加
载器的缓存中也一定查找不到这类，因此进入第二步。扩展类
的父加载器是null,因此系统调用 findClass( String),最终通
过引导类加载器进行加载。

4 思考
如果在自定义的类加载器中重写
java.lang.Classloader.loadClass( string)或java.lang.Classloader.loadClass( String, boolean)
方法，抹去其中的双亲委派机制，仅保留上面这4步中的第1步与第4步，
那么是不是就能够加载核心类库了呢？
这也不行！因为JDK还为核心类库提供了一层保护机制。不管是自定
义的类加载器，还是系统类加载器抑或扩展类加载
器，最终都必须调用
java.ang.Classloader. definedClass( String,byte],int,int,Protectiondomain)方法，
而该方法会执行 predefinedClass()接口，该接口中提供了对JDK核心类库
的保护。

5 双亲委托模式的弊端
检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较
清晰，使各个Classloaderl的职责非常明确，但是
同时会带来一个问题，即顶层的classloader无法访问底层的classl
oader所加载的类。
通常情况下，启动类加载器中的类为系统核心类，包括一些重要
的系统接口，而在应用类加载器中，为应用类。按照这
种模式，应用类访问系统类自然是没有问题，但是系统类访问应用
类就会出现问题。比如在系统类中提供了一个接口，
该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用
于创建该接口的实例，而接口和工厂方法都在启动类
加载器中。这时，就会出现该工厂方法无法创建由应用类加载器
加载的应用实例的问题。
结论
由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要
使用双亲委派模型，只是建议采用这种方式而己
比如在 Tomcat中，类加载器所采用的加载机制就和传统的双系委
派模型有一定区别，当缺省的类加载器接收到一个类的
加载任务时，首先会由它自行加载，当它加载失败时，オ会将类的
加载任务委派给它的超类加载器去执行，这同时也是
Servlet规范推荐的一种做法

破坏双亲委派机制1
双亲委派模型并不是一个具有强制性约束的模型，而是Java设
计者推荐给开发者们的类加载器实现方式。
在Java的世界中大部分的类加载器都遵循这个模型，但也有例外
的情况，直到Java模块化出现为止，双亲委派模型主要
出现过3次较大规模“被破坏”的情况。
第一次破坏双亲委派机制
双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前
一即JDK1.2面世以前的“远古”时代。
由于双亲委派模型在JDK1.2之后才被引入，但是类加载器的概念
和抽象类java.lang.Classloaderl则在Java的第一个版本中
就已经存在，面对己经存在的用户自定义类加载器的代码，
Java设计者们引入双亲委派模型时不得不做出一些妥协，为了
兼容这些已有代码，无法再以技术手段避免lloadClass()被子
类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中
添加一个新的 protected方法 findclass(),并引导用户编写
的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中
编写代码。上节我们已经分析过loadclass()方法，双亲委派的
具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果
父类加载失败，会自动调用自己的 findclass()方法来完成加载，
这样既不影响用户按照自己的意愿去加载类，又可以保证新写出
来的类加载器是符合双亲委派规则的。

第二次破坏双亲委派机制：线程上下文类加载器
双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，
双亲委派很好地解决了各个类加载器协作时基础类
型的一致性问题（越基础的类由越上层的加载器进行加载），
基础类型之所以被称为“基础”，是因为它们总是作为被
用户代码继承、调用的API存在，但程序设计往往没有绝对不变的
完美规则，如果有基础类型又要调用回用户的代码
那该怎么办？
这并非是不可能出现的事情，一个典型的例子使是JNDI服务，
JNDI现在己经是Java的标准服务，它的代码由启动类加
载器来完成加载(在JDK1.3时加入到 rt jar的)，肯定属于Java中
很基础的类型了。但JNDI存在的目的就是对资源进行查找和集
中管理，它需要调用由其他厂商实现并部署在应用程序
的classpath下的JNDI服务提供者接口
(Service Provider Interface,SPI)
的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些
代码的，那该怎么办？(SPT:在Java平台中，通常把核心类rt,jar中
提供外部服务、可由应用层自行实现的接口称为SPT)
为了解決这个困境，]ava的设计团队只好引入了一个不太优雅
的设计：线程上下文类加载器（ Thread Context
C1 assloader)。这个类加载器可以通过java.lang. Thread类的
setcontextclassloader()方法进行设置，如果创建线程时还未
设置，它将会从父线程中继承一个，如果在应用程序的全局
范围内都没有设置过的话，那这个类加载器默认就是应用程序类
加载器。
有了线程上下文类加载器，程序就可以做一些“舞弊”的事情
了。JNDI服务使用这个线程上下文类加载器去加载所需的
SPI服务代码，这是一种父类加载器去请求子类加载器完成
类加载的行为，这种行为实际上是打通了双系委派模型的层次
结构来逆向使用类加载器，已经违背了双亲委派模型的一
般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基
本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和
JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能
根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的
实现方式，在JDK6时，JDK提供了一种相对合理的解决方案。

默认上下文加载器就是应用类加载器，这样以上下文
加载器为中介，使得启动类加载器中的代码也可以访问
应用类加载器中的类

第三次破坏双亲委派机制：
双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追
求而导致的。如：代码替換( Hot Swap)、
模块热部署( Hot Deployment)等
IBM公司主导的JSR-291(即 OSGI R4.2)实现模块化热部署
的关键是它自定义的类加载器机制的实现，每一个程序模
块(OSGi中称为 Bundle)都有一个自己的类加载器，当需要
更換一个 Bundle时，就把Bundle连同类加载器一起换掉以实
现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型
推荐的树状结构，而是进一步发展为更加复杂的网状结构
当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：
1)将以java.*开头的类，委派给父类加载器加载
2)否则，将委派列表名单内的类，委派给父类加载器加载。
3)否则，将 Import列表中的类，委派给 Export这个类的
Bundle的类加载器加较。
4)否则，查找当前 Bundle的ClassPath,使用自己的类加载器加载。
5)否则，查找类是否在自己的 Fragment Bundle中，如果在，
则委派给 Fragment Bundle的类加载器加载。
6)否则，查找 Dynamic Import列表的 Bundle,委派给对应
Bundle的类加载器加载。
7)否则，类查找失败。
说明：只有开头两点仍然符合双亲委派模型的原则，其余
的类查找都是在平级的类加载器中进行的
小结
这里，我们使用了“被破坏”这个词来形容上述不符合双亲委
派模型原则的行为，但这里“被破坏”并不一定是带有贬义的。
只要有明确的目的和充分的理由，突破旧有原则无疑是一种创新。

正如：OSGi中的类加载器的设计不符合传统的双亲委派的类
加载器架构，且业界对其为了实现热部署而带来
的额外的高复杂度还存在不少争议，但对这方面有了解的技术
人员基本还是能达成一个共识，认为
OSGi中对类加载器的运用是值得学习的，完全弄懂了OSGi的
实现，就算是掌握了类加载器的精梓。