JVM -- 类加载器

类加载器(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下的文件

二、 双亲委派机制

双亲委派机制主要是为了解决：

1. 同一个类被多次加载或者一个类应该被谁加载的问题；
2. 保证类加载的安全性：避免恶意代码替换JDK中的核心类库。

启动类加载器、扩展类加载器、应用类加载器的关系如下：

[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类中实现双线委派方式原理：

双亲委派的核心代码：

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

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