Java虚拟机把描述类的class文件加载到内存,对其进行校验、转换解析、初始化等操作,最终得到可以被虚拟机直接使用的java类型,这就是虚拟机的加载机制。
主要有五个步骤:
加载
将class文件读入到内存中,并将其放在运行时数据区的方法区内,然后在堆中创建一个java.lang.Class对象,用来封装在方法区的数据结构。
在这个阶段,主要完成如下三件事:
检测线程上下文注入?验证:验证加载后的类格式、语义、字节码、符号引用(判断符号是否存在)
准备(分配内存空间):为类的静态变量在方法去分配内存并赋默认值(0或null)。其中静态常量在这个阶段就赋程序设定的值,比如static final int = 666;
解析:将类的二进制数据中的符号引用转为直接引用
tomcat线程模型?类的初始化:把类加载到系统中,这个阶段才是真正执行java代码。主要工作是为静态变量赋程序设定的初值
关于双亲委派介绍网上资料很多,包括自定义类加载器、线程上下文类加载器等,这里就不做详细赘述了
java中存在很多服务的提供者接口(Service Provider Interface,SPI),这些接口允许第三方为他们提供实现,然后进行载入。常见的SPI有JDBC、JNDI等,接口属于java的核心库,一般存储与rt.jar中,有Bootstrap加载器加载。
spring自定义应用上下文。
如果按照双亲委派的原则,我们该如何去加载到我们所实现的SPI呢,这就涉及到了线程上下文加载器(jdk 1.2开始引入),它是通过破坏双亲委派然后使Bootstrap加载器来反向委托线程上下文类加载器进行加载SPI实现类。
初始化线程的上下文类加载器是系统类加载器(AppClassLoader),我们可以通过java.lang.Thread类中的getContextClassLoader()和setContextClassLoader(ClassLoader cl)方法进行获取或设置
使用jdbc.jar为例来说明上下文类加载器是如何发现并加载实现类的
找到rt.jar中的java.sql.DriverManager类
public class DriverManager {...static {loadInitialDrivers();println("JDBC DriverManager initialized");}/*** 加载并初始化driver*/private static void loadInitialDrivers() {AccessController.doPrivileged(new PrivilegedAction<Void>() {public Void run() {// 加载外部的实现类,如com.mysql.cj.jdbc.DriverServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);try{// 这里执行hasNext()会初进行加载while(driversIterator.hasNext()) {driversIterator.next();}} catch(Throwable t) {// Do nothing}return null;}});
}
在DriveManager类初始化时执行了loadInitialDrivers()方法,然后通过ServiceLoader.load(Driver.class)去加载外部实现的驱动类,配置位置固定为:META-INF/services
接下来我们看下ServiceLoader.load(Driver.class)方法
public static <S> ServiceLoader<S> load(Class<S> service) {// 获取上下文类加载器ClassLoader cl = Thread.currentThread().getContextClassLoader();return ServiceLoader.load(service, cl);}// load方法public static <S> ServiceLoader<S> load(Class<S> service,ClassLoader loader){// 调用静态方法load会实例化一个ServiceLoader对象return new ServiceLoader<>(service, loader);}private ServiceLoader(Class<S> svc, ClassLoader cl) {service = Objects.requireNonNull(svc, "Service interface cannot be null");// 如果没有定义上下文类加载器则使用默认的系统系统加载器loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;reload();}
在ServiceLoader构造中会判断类加载器并保存到变量loader中,我们来看下最终加载实现类的方法:
private S nextService() {if (!hasNextService())throw new NoSuchElementException();String cn = nextName;nextName = null;Class<?> c = null;try {// 使用cn类加载器加载指定的servicec = Class.forName(cn, false, loader);} catch (ClassNotFoundException x) {fail(service,"Provider " + cn + " not found");}if (!service.isAssignableFrom(c)) {fail(service,"Provider " + cn + " not a subtype");}try {// 类型转换S p = service.cast(c.newInstance());providers.put(cn, p);return p;} catch (Throwable x) {fail(service,"Provider " + cn + " could not be instantiated",x);}throw new Error(); // This cannot happen}
可以看到使用类的全限定名+loader加载了实现类com.mysql.cj.jdbc.Driver
加载META-INF/services的过程:
参考《Tomcat架构解析》
Tomcat作为一个容器,需要解决下面几个问题:
Java类库可以实现相互隔离
:因为我们在一个tomcat中会部署多个web应用,他们可能依赖同一个第三方库,不能要求所有类都只有一份,需要保证他们各自的类库要可以独立使用,不相互影响Java类库可以相互共享
:上一个隔离问题的延申,比如我们部署10个Spring应用,那么90%的类库是冗余的,这时我们希望把他们进行类库共享以节约资源不受部署web应用程序的影响
:部署的web有着不确定性,可能那一天就崩溃了,所以,基于安全考虑,容器所使用的类库应该与应用程序的类库相互独立Tomcat类加载架构如下图:
它破坏了双亲委派,每个类加载器作用如下:
Common
:以System为父 类加载器,是位于Tomcat应用服务器顶层的公用类加载器。其路径为common.loader,默认指向$CATALINA_ HOME/ib下的包。Catalina
:以Common为父加载器,是用于加载Tomcat应用服务器的类加载器,其路径为server.loader,默认为空。此时Tomcat使用Common类加载器加载应用服务器。Shared
:以Common为父加载器,是所有Web应用的父加载器,其路径为shared.loader,默认为空。此时Tomcat使用Common类加载器作为Web应用的父加载器。Web应用
:以Shared为父加载器,加载/WEB-INF/classes目录下的未压缩的Class和资源文件以及/WEB-INF/lib目录下的Jar包。如前所述,该类加载器只对当前Web应用可见,对其他Web应用均不可见。JSP
:顾名思义,就是专门加载jsp文件的加载器我们平时的web应用类加载器默认加载顺序为:
1. 先从缓存中加载
2. 如果没有,则从JVM的Bootstrap类加载器加载
3. 如果没有,则从当前类加载器加载(按照WEB-INF/classes、WEB-INF/lib的顺序)
4. 如果没有,则从父类加载器加载,加载顺序是AppClassLoader、Common、Shared
版权声明:本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间:8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态