JVM,Tomcat与OSGi类加载机制比较

时间:2023-12-16 19:42:26

首先一个思维导图来看下Tomcat的类加载机制和JVM类加载机制的过程

JVM,Tomcat与OSGi类加载机制比较

类加载

  在JVM中并不是一次性把所有的文件都加载到,而是一步一步的,按照需要来加载。

  比如JVM启动时,会通过不同的类加载器加载不同的类。当用户在自己的代码中,需要某些额外的类时,再通过加载机制加载到JVM中,并且存放一段时间,便于频繁使用。

  因此使用哪种类加载器、在什么位置加载类都是JVM中重要的知识。

JVM类加载

  JVM类加载采用 双亲委派机制,如下图所示:

JVM,Tomcat与OSGi类加载机制比较

  JVM中包括集中类加载器:

  1 BootStrapClassLoader 引导类加载器

  2 ExtClassLoader 扩展类加载器

  3 AppClassLoader 应用类加载器

  4 CustomClassLoader 用户自定义类加载器

  他们的区别上面也都有说明。需要注意的是,不同的类加载器加载的类是不同的,因此如果用户加载器1加载的某个类,其他用户并不能够使用。

  当JVM运行过程中,用户需要加载某些类时,会按照下面的步骤(父类委托机制):

  1 用户自己的类加载器,把加载请求传给父加载器,父加载器再传给其父加载器,一直到加载器树的顶层。

  2 最顶层的类加载器首先针对其特定的位置加载,如果加载不到就转交给子类。

  3 如果一直到底层的类加载都没有加载到,那么就会抛出异常ClassNotFoundException。

  因此,按照这个过程可以想到,如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class,会优先加载CLASSPATH目录中的文件。

Tomcat类加载

  在tomcat中类的加载稍有不同,如下图:

JVM,Tomcat与OSGi类加载机制比较

  当tomcat启动时,会创建几种类加载器:

  1 Bootstrap 引导类加载器

  加载JVM启动所需的类,以及标准扩展类(位于jre/lib/ext下)

  2 System 系统类加载器

  加载tomcat启动的类,比如bootstrap.jar,通常在catalina.bat或者catalina.sh中指定。位于CATALINA_HOME/bin下。

JVM,Tomcat与OSGi类加载机制比较

  3 Common 通用类加载器

  加载tomcat使用以及应用通用的一些类,位于CATALINA_HOME/lib下,比如servlet-api.jar

JVM,Tomcat与OSGi类加载机制比较

  4 webapp 应用类加载器

  每个应用在部署后,都会创建一个唯一的类加载器。该类加载器会加载位于 WEB-INF/lib下的jar文件中的class 和 WEB-INF/classes下的class文件。

  当应用需要到某个类时,则会按照下面的顺序进行类加载:

  1 使用bootstrap引导类加载器加载

  2 使用system系统类加载器加载

  3 使用应用类加载器在WEB-INF/classes中加载

  4 使用应用类加载器在WEB-INF/lib中加载

  5 使用common类加载器在CATALINA_HOME/lib中加载

问题扩展

  通过对上面tomcat类加载机制的理解,就不难明白 为什么java文件放在Eclipse中的src文件夹下会优先jar包中的class?

  这是因为Eclipse中的src文件夹中的文件java以及webContent中的JSP都会在tomcat启动时,被编译成class文件放在 WEB-INF/class 中。

  而Eclipse外部引用的jar包,则相当于放在 WEB-INF/lib 中。

  因此肯定是 java文件或者JSP文件编译出的class优先加载。

  通过这样,我们就可以简单的把java文件放置在src文件夹中,通过对该java文件的修改以及调试,便于学习拥有源码java文件、却没有打包成xxx-source的jar包。

  另外呢,开发者也会因为粗心而犯下面的错误。

  在 CATALINA_HOME/lib 以及 WEB-INF/lib 中放置了 不同版本的jar包,此时就会导致某些情况下报加载不到类的错误。

  还有如果多个应用使用同一jar包文件,当放置了多份,就可能导致 多个应用间 出现类加载不到的错误。

OSGi类加载

OSGi:灵活的类加载结构。

OSGi(Open Service Gateway Initiative):是OSGi联盟定制的基于Java语言 的动态模块化规范。

OSGi的模块(Bundle)与普通Java区别:两者区别并不太大,都是以JAR 格式封装,并且内部存储都是Java Package和Class。但是Bundle可以声明依赖 的Java Package,也可以声明它导出发布的Java Package。Bundle从传统上层模块依 赖转变为平级模块依赖。QSGi的Bundle类加载器之间只有规则,没有固定委派关 系。

OSGi类加载器关系:

某个Bundle声明依赖的Package,如果有其他Bundle发布了此Package,则对这个 个package的所有类加载动作会委派它的Bundle了类加载器去完成。

例如:

BundleA:声明发布PackageA,依赖java.*的包;

BundleB:声明依赖PackageA和PackageC,也同时依赖java.*;

BundleC:声明发布PackageC,同时声明依赖PackageA。

则关系图如下:

JVM,Tomcat与OSGi类加载机制比较

OSGi类加载器分析:

可以看出,OSGi类加载器之间不再是双亲委派模型的树形结构,而是进一步发展成 为一种运行时才能确定的网状结构。这种网状类加载器结构拥有更优秀的灵活性, 同时也有许多隐患,由于各模块间依赖关系错综复杂,高并发量下容易发生死锁等 问题。

参考

【1】Tomcat Class Loader:http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html

【2】Tomcat 类加载机制:http://blog.csdn.net/dc_726/article/details/11873343