Tomcat-正统的类加载器架构

主流的Java Web服务器主要有tomcat,Jetty,WebLogic,WebSphere等,这些服务器都实现了自己定义的加载器(一般都有一个或者多个),因为一个功能齐全的服务器,都需要解决如下问题:

  • 部署在同一个服务器上的两个Web应用程序使用的Java 类库可以实现相互隔离,这是最基本的要求.两个不同应用程序可能会依赖同一个第三方类库的不同版本的,不能要求一个类库在一个服务器中只有一份,服务器应当保证两个应用程序的类库可以互相独立使用
  • 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以互相共享,这个需求也很常见,如果Java类库不能共享使用,虚拟机的方法区很容易出现过度膨胀的风险
  • 服务器需要尽可能保证自身安全不受部署的Web应用程序影响.目前有许多主流的Java Web服务器都使用Java语言开发,因此服务器本身也有类库依赖的问题,一般来说,基于安全的考虑,服务器所使用的类库应该与应用程序使用的类库互相独立
  • 支持JSP的服务器,大部分都需要支持HotSwap功能(热交换功能)

由于上述的种种问题,在部署Web应用的时候如果只使用一个单独的ClassPath是无法满足需求的,所以各种Web服务器都不约而同的提供了多个ClassPath路径供用户存在第三方类库,这些路径一般都以lib,classes命名,被放置到不同路径的类库,具备不同的访问范围

和服务对象.tomcat服务器划分用户类库结构和类加载描述如下:

在tomcat目录结构中,有三组目录/common/*,/server/*,/shared/*可以用来存放类库,另外还有Web应用程序自身的目录/WEB-INF/*一共四组,把Java类库放在这些目录的含义和区别如下:

  • 放置在/common/*目录:这些类库可以被tomcat和所有的web应用程序共同使用
  • 放置在/server/*目录:这些类库可以被tomcat使用,所有的web应用程序都不可见
  • 放置在/shared/*目录:这些类库可以被所有的web应用程序共同使用,但是对tomcat自己不可见
  • 放置在/WEB-INF/*目录:这些类库仅仅对当前的web应用程序使用,对tomcat和其他的web应用程序都是不可见的

为了支持上述这样的目录结构,并对目录里面的类库进行加载和隔离,Tomcat定义了多个类加载器来实现,这些类加载器都是按照经典的双亲委派模型来实现的,其关系如图所示:

主要的类加载器有CommonClassLoader,CatalinaClassLoader,SharedClassLoader和WebappClassLoader,它们分别加载/common/*,/server/*,/shared/*和/WEB-INF/*目录下的类库,其中WebApp加载器和JSP类加载器实例通常会存在多个

每一个web应用程序对应一个webapp类加载器,每一个JSP文件对应一个JSP类加载器.

通过上述的关系图可以看出CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用,而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离.WebAppClassLoader可以使用SharedClassLoader

能加载到的类,但是各个WebAppClassLoader实例之间相互隔离,而JasperLoader的加载范围仅仅是这个JSP编译出的那一个Class,它出现的目的就是为了被丢弃:当服务器检测到JSP文件被修改时,会替换掉目前的JasperClassLoader实例,并通过再建一个

新的JSP类加载器来实现JSP文件的HotSwap功能

参考资料:深入理解Java虚拟机

时间: 2024-12-16 07:23:51

Tomcat-正统的类加载器架构的相关文章

Tomcat内核之类加载器工厂

Java虚拟机利用类加载器将类载入内存,以供使用.在此过程中类加载器要做很多的事情,例如读取字节数组.验证.解析.初始化等.而Java提供的URLClassLoader类能方便地将jar.class或网络资源加载到内存.Tomcat中则用一个工厂类ClassLoaderFactory把创建类加载器的细节进行封装,通过它可以很方便地创建自定义的类加载器. 如上图,利用createClassLoader方法并传入资源路径跟父类加载器即可创建一个自定义类加载器,此类加载器负责加载传入的所有资源. Cl

[读书笔记]OSGI-灵活的类加载器架构

以下内容来自周志明的<深入理解Java虚拟机>. 学习JEE规范,去看JBoss源码:学习类加载器,就去看OSGI源码. OSGI,即Open Service Gateway Initiative,是一个基于Java语言的动态模块化规范. 一个模块只有Export过的package才能由外接访问. OSGI可以实现模块级的热插拔功能. OSGI中的加载器之间的关系不再是双亲委派模型的树形结构,而是进一步发展成了一种更为复杂的,运行时才能确定的网状结构.网状结构虽然灵活,但是也会带来隐患. OS

Java基础知识之类加载器

1.类加载器定义 1.1类加载器概述: java类的加载是由虚拟机来完成的,虚拟机把描述类的Class文件加载到内存,并对数据进行校验,解析和初始化,最终形成能被java虚拟机直接使用的java类型,这就是虚拟机的类加载机制.JVM中用来完成上述功能的具体实现就是类加载器.类加载器读取.class字节码文件将其转换成java.lang.Class类的一个实例.每个实例用来表示一个java类.通过该实例的newInstance()方法可以创建出一个该类的对象. 1.2类的生命周期: 类从加载到虚拟

Java 之 类加载器

一.类加载器概述 在开发中会遇到 java.lang.ClassNotFoundException 和 java.lang.NoClassDefError,想要更好解决这类问题,或者在一些特殊的应用场景,比如需要支持类的动态加载或需要对编译后的字节码文件进行加密解密操作,那么需要你自定义类加载器,因此了解类加载器及其加载机制成为了Java开发必备技能之一. 二.四种类加载器 1.引导类加载器(Bootstrap Classloader),又称为根类加载器 它负责加载 Java 的核心库(JAVA

深入理解JVM虚拟机7:JNDI,OSGI,Tomcat类加载器实现

打破双亲委派模型 JNDI JNDI 的理解 JNDI是 Java 命名与文件夹接口(Java Naming and Directory Interface),在J2EE规范中是重要的规范之中的一个,不少专家觉得,没有透彻理解JNDI的意义和作用,就没有真正掌握J2EE特别是EJB的知识. 那么,JNDI究竟起什么作用?//带着问题看文章是最有效的 要了解JNDI的作用,我们能够从“假设不用JNDI我们如何做?用了JNDI后我们又将如何做?”这个问题来探讨. 没有JNDI的做法: 程序猿开发时,

(转)《深入理解java虚拟机》学习笔记8——Tomcat类加载器体系结构

Tomcat 等主流Web服务器为了实现下面的基本功能,都实现了不止一个自定义的类加载器: (1).部署在同一个服务器上的两个web应用程序所使用的java类库可以相互隔离. (2).部署在同一个服务器上的两个web应用程序所使用的java类库可以相互共享. (3).许多Web服务器本身使用java语言实现,因此服务器所使用的类库应与应用程序的类库相互独立. (4).支持JSP应用的Web服务器,需要支持HotSwap功能,因为JSP文件最终是被编译为java的servlet来运行的,当修改JS

Tomcat内核之Tomcat的类加载器

跟其他主流的Java Web服务器一样,Tomcat也拥有不同的自定义类加载器,达到对各种资源库的控制.一般来说,Java Web服务器需要解决以下四个问题: ①   同一个Web服务器里,各个Web项目之间各自使用的Java类库要互相隔离. ②   同一个Web服务器里,各个Web项目之间可以提供共享的Java类库. ③   服务器为了不受Web项目的影响,应该使服务器的类库与应用程序的类库互相独立. ④   对于支持JSP的Web服务器,应该支持热插拔(hotswap)功能. 对于以上几个问

细说tomcat之类加载器

官网:http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.htmlJava类加载与Tomcat类加载器层级关系对比 Java ClassLoader: Bootstrap ClassLoader(加载$JAVA_HOME/jre/lib/目录下核心类库:resources.jar,rt.jar,sunrsasign.jar,jsse.jar,jce.jar,charsets.jar,jfr.jar,以及jre/classes目录下

tomcat 7 中的类加载器学习

tomcat 7自带很多junit测试用例,可以帮助我们窥探源码的秘密.以下使用来测试类加载器的一个测试用例.类加载器也是对象,他们用来将类从类从.class文件加载到虚拟机,这些已经讲了很多,深入jvm中说的很详细,什么双亲委派模型,在书中还以tomcat为例讲解. /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the N