类加载器(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