类加载器(ClassLoader)是Java虚拟机提供给应用程序去实现访问接口和类字节码数据的技术。类加载器只负责加载过程中的字节码获取并加载到内存的这一过程。
一、 类加载器的分类
类加载器的详细信息可以使用Arthas通过classloader命令查看：
1.启动类加载器(Bootstrap ClassLoader)
由Hotspot虚拟机提供的，使用C++编写的类加载器，默认加载Java安装目录/jre/lib下的类文件。针对用户自定义的jar包如果想被启动类加载器加载的话，可以使用如下参数进行加载：
-Xbootclasspath/a:jar包目录/jar包名
加载java中最核心的类。
2. 扩展类加载器(Extension Class Loader)
使用JAVA编写，由JDK提供，源码位于sun.misc.Launcher，是一个静态内部类，继承自URLClassLoader。默认加载java安装目录的/jre/lib/ext下的文件，使用如下参数使用扩展类加载器进行加载：
-Djava.ext.dirs=jar包目录 进行扩展,这种方 式会覆盖掉原始目录，可以用;(windows):(macos/linux) 追加上原始目录
3. 应用类加载器(App CLass Loader)
使用JAVA编写，由JDK提供，源码位于sun.misc.Launcher，是一个静态内部类，继承自URLClassLoader。加载的是位于classpath下的文件
二、 双亲委派机制
双亲委派机制主要是为了解决：
- 同一个类被多次加载或者一个类应该被谁加载的问题；
- 保证类加载的安全性：避免恶意代码替换JDK中的核心类库。
启动类加载器、扩展类加载器、应用类加载器的关系如下：
java
[arthas@106672]$ classloader -t
+-BootstrapClassLoader
+-sun.misc.Launcher$ExtClassLoader@79acc872
+-com.taobao.arthas.agent.ArthasClassloader@7b94591c
+-sun.misc.Launcher$AppClassLoader@18b4aac2应用程序类加载器的父类是扩展类加载器。而扩展类加载器的parent为null，但是在逻辑上，扩展类加载器依然会把启动类加载器当作夫类加载器处理。
启动类加载器使用C++编写，没有父类加载器。
逻辑：当一个类去加载某个类的时候，会自底向上查找是否加载过，如果加载过就直接返回，如果到底一直没有加载过，再由顶向下委派进行加载。
三、 打破双亲委派机制
打破的原因：一个Tomcat可以部署多个Web应用，如果两个应用中出现了相同限定名的类，比如Servlet类，Tomcat要保证这两个类都能加载并且它们应该是不同的类。
ClassLoader类中实现双线委派方式原理：
双亲委派的核心代码：
java
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
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 states
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
1. 自定义类加载器
自定义类加载器，重写loadClass()，不再使用双亲委派机制，而使用自己实现的loadClass()。
其中自定义类加载器的父加载器为：应用类加载器(getSystemClassLoader())
问题：两个自定义类加载器加载相同限定名的类，是否会冲突？
不会，只有同一个类加载器且加载相同限定名的才会被认定为同一个类。
2. 线程上下文类加载器
以DriverManager为例：
核心逻辑就是：启动类加载器加载DriverManager，在初始化DriverManager时会通过SPI机制加载mysql驱动，SPI机制利用了线程上下文来加载并创建对象，实现原本应该由启动类加载器交由应用类加载器去加载的过程，打破双亲委派机制。
依赖于SPI机制：rt.jar核心包是有Bootstrap类加载器加载的，其内包含SPI核心接口类，由于SPI中的类经常需要调用外部实现类的方法，而jdbc.jar包含外部实现类（jdbc.jar存在于classpath路径）无法通过Bootstrap类加载器加载，因此只能委派线程上下文加载器的加载方式破坏了"双亲委派模型"，它在执行过程中抛弃双亲委派加载链模式，使程序可以逆向使用类加载器，当然这也使得Java类加载器变得更加灵活。为了进一步证实这种场景，不妨看看DriverManager类的源码，DriverManager是Java核心rt.jar包中的类，该类用来管理不同数据库的实现驱动即Driver，它们都实现了Java核心包中的java.sql.Driver接口，如mysql驱动包中的com.mysql.jdbc.Driver
java
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public void run() {
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();
}
}实现延迟服务提供者查找
DriverManager.loadInitialDrivers -> ServiceLoader.load -> reload ->lookupIterator = new LazyInterator(service, loader);
加载meta-inf，初始化驱动
loadedDrivers.iterator() -> driversIterator.hasNext() -> hasNextService ->
ClassLoader.getSystemResources(fullName);
这样ServiceLoader会帮我们处理一切，并最终通过load()方法加载
3. Osgi框架的类加载器
历史上，OSGi模块化框架。它存在同级之间的类加载器的委托加载（如下图的加载器1和2）。OSGi还使用类加载器实现了热部署的功能。热部署指的是在服务不停止的情况下，动态地更新字节码文件到内存中。JDK9之后不再使用OSGi，现在可以使用arthas解决热部署问题。
由于这种机制使用已经不多，所以不再过多讨论OSGI