类加载器（ClassLoader）是通过一个类的全限定名来获取定义此类的二进制字节流。

在类加载的第一阶段“加载”过程中，需要通过一个类的全限定名来获取定义此类的二进制字节流，完成这个动作的代码块就是类加载器。

类的唯一性

类加载器虽然只用于实现类的加载动作，但是对于任意一个类，都需要由加载它的类加载器和这个类本身共同确立其在Java虚拟机中的唯一性。

通俗的说，JVM中两个类是否“相等”，首先就必须是同一个类加载器加载的，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要类加载器不同，那么这两个类必定是不相等的。

双亲委派模型

从Java虚拟机角度来说，只存在两种不同的类加载器：

• 启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现（HotSpot虚拟机中），是虚拟机自身的一部分；
• 其他的类加载器，这些类加载器都有Java语言实现，独立于虚拟机外部，并且全部继承自java.lang.ClassLoader。

从开发者的角度，类加载器可以细分为：

• 启动（Bootstrap）类加载器：负责将Java_Home/lib下面的类库加载到内存中（比如rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
• 标准扩展（Extension）类加载器：是由Sun的ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将Java_Home/lib/ext或者由系统变量java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。
• 应用程序（Application）类加载器：是由Sun的AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统（System）加载器。

破坏双亲委派模型

Tomcat、SPI、JNDI等都违反了双亲委托。

Tomcat类加载

Tomcat作为一个web容器，需要保证web容器之间的互不影响。

容器之间隔离性：

• 保证每个应用的类库都是独立的，保证相互隔离；
• 部署在不同web容器中相同的类库相同的版本可以共享；
• 基于安全考虑，应该让容器的类库和程序的类库隔离开来。

Tomcat为了上面的隔离性问题，没有遵守双亲委派这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。

Tomcat的类加载过程：

1. 在本地缓存中查找是否已经加载过该类；
2. 委托Appication类加载器尝试加载该类（为了防止一些基础类会被web中的类覆盖）；
3. 委托WebApp应用的类加载器将自行加载(违反了双亲委托机制)，如果加载到则返回；
4. 委托父类Common类加载器（违反了双亲委托机制）去加载。

SPI

双亲委派存在的问题？SPI为什么出现？

在实际开发场景中，存在一些组件或扩展的实现由应用来具体实现的。可以理解为，系统类提供了通用的接口，具体实现需要应用来实现并且加载。

SPI(Service Provider Interface)是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。

JDBC违背了双亲委派模型？

在JDBC4.0之前，连接数据库的时候，通常会用Class.forName("com.mysql.jdbc.Driver")加载数据库相关的驱动，然后再进行获取连接等的操作。
而JDBC4.0之后不需要Class.forName来加载驱动，直接获取连接即可，这里使用了Java的SPI扩展机制来实现。

OSGI

OSGi（Open Service Gateway Initiative）是Java动态化模块化系统的一系列规范。

bundle是开发、部署 OSGi 应用的基本单元，可以认识一个功能模块，最重要的是每个bundle都有单独的类加载器(这也是解决多版本冲突的重点)。

为什么需要动态化模块？
版本化：bundle可以版本化，多版本能够共存而不会影响系统功能；
热插拔：bundle能够进行即时的更新，服务可以根据需要动态增加或者删除；

OSGI可以通过仅暴露服务，不同bundle可以依赖各自版本的jar包来解决java多版本冲突的问题。

在Java9中提供了模块化特性。

阿里有一款未开源的Pandora中间件，同样利用了模块化思想。