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中的核心类库。

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

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

相关推荐
JavaNice哥20 分钟前
1初识别jvm
jvm
涛粒子20 分钟前
JVM垃圾回收详解
jvm
YUJIANYUE23 分钟前
PHP将指定文件夹下多csv文件[即多表]导入到sqlite单文件
jvm·sqlite·php
逊嘘32 分钟前
【Java语言】抽象类与接口
java·开发语言·jvm
鱼跃鹰飞10 小时前
大厂面试真题-简单说说线程池接到新任务之后的操作流程
java·jvm·面试
王佑辉11 小时前
【jvm】Major GC
jvm
阿维的博客日记11 小时前
jvm学习笔记-轻量级锁内存模型
jvm·cas·轻量级锁
曹申阳14 小时前
2. JVM的架构模型和生命周期
jvm·架构
琪露诺大湿15 小时前
JavaEE-多线程初阶(4)
java·开发语言·jvm·java-ee·基础·1024程序员节·原神
王佑辉18 小时前
【jvm】Full GC
jvm