精华内容
下载资源
问答
  • tomcat的类加载器

    2020-04-21 18:58:13
    Tomcat的类加载机制是违反了双亲委托原则的,对于一些未加载的非基础类(Object,String等),各个web应用自己的类加载器(WebAppClassLoader)会优先加载,加载不到时再交给commonClassLoader走双亲委托。 对于JVM来说:...

    Tomcat的类加载机制是违反了双亲委托原则的,对于一些未加载的非基础类(Object,String等),各个web应用自己的类加载器(WebAppClassLoader)会优先加载,加载不到时再交给commonClassLoader走双亲委托。

    对于JVM来说:

    因此,按照这个过程可以想到,如果同样在CLASSPATH指定的目录中和自己工作目录中存放相同的class,会优先加载CLASSPATH目录中的文件。
    在这里插入图片描述
    Tomcat 如何实现自己独特的类加载机制?
    看图:
    在这里插入图片描述
    我们看到,前面3个类加载和默认的一致,CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器
    它们分别加载/common/、/server/、/shared/*(在tomcat 6之后已经合并到根目录下的lib目录下)和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例,每一个Web应用程序对应一个WebApp类加载器,每一个JSP文件对应一个Jsp类加载器。

    1. commonLoader:Tomcat最基本的类加载器,加载路径中的class可以被Tomcat容器本身以及各个Webapp访问;
      catalinaLoader:Tomcat容器私有的类加载器,加载路径中的class对于Webapp不可见;
      sharedLoader:各个Webapp共享的类加载器,加载路径中的class对于所有Webapp可见,但是对于Tomcat容器不可见;
      WebappClassLoader:各个Webapp私有的类加载器,加载路径中的class只对当前Webapp可见;

    从图中的委派关系中可以看出:

    CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用,从而实现了公有类库的共用,而CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离。

    WebAppClassLoader可以使用SharedClassLoader加载到的类,但各个WebAppClassLoader实例之间相互隔离。

    而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件,它出现的目的就是为了被丢弃:当Web容器检测到JSP文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

    好了,至此,我们已经知道了tomcat为什么要这么设计,以及是如何设计的,那么,tomcat 违背了java 推荐的双亲委派模型了吗?答案是:违背了。 我们前面说过:

    双亲委派模型要求除了顶层的启动类加载器之外,其余的类加载器都应当由自己的父类加载器加载。

    很显然,tomcat 不是这样实现,tomcat 为了实现隔离性,没有遵守这个约定,每个webappClassLoader加载自己的目录下的class文件,不会传递给父类加载器。

    我们扩展出一个问题:如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类,该怎么办?
    看了前面的关于破坏双亲委派模型的内容,我们心里有数了,我们可以使用线程上下文类加载器实现,使用线程上下文加载器,可以让父类加载器请求子类加载器去完成类加载的动作。牛逼吧。

    类加载

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

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

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

    JVM类加载
      JVM类加载采用 父类委托机制,如下图所示:
      在这里插入图片描述
    JVM中包括集中类加载器:

    1 BootStrapClassLoader 引导类加载器

    2 ExtClassLoader 扩展类加载器

    3 AppClassLoader 应用类加载器

    4 CustomClassLoader 用户自定义类加载器

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

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

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

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

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

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

    展开全文
  • TomCat加载器结构

    千次阅读 2016-10-21 16:23:25
    一个功能健全的类加载器,都要解决以下几个问题: (1)部署在同一服务器上的两个web应用程序所使用的java类库可以实现相互隔离。这是最基本的需求,两个不同的应用程序可能会依赖同一个第三方类库的不同版本,不能...

    一个功能健全的类加载器,都要解决以下几个问题:

    (1)部署在同一服务器上的两个web应用程序所使用的java类库可以实现相互隔离。这是最基本的需求,两个不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求一个类库在一个服务器中只有一份,服务器应当可以保证两个应用程序的类库可以相互独立使用。

    (2)部署在同一个服务器上的两个web应用程序所使用的java类库可以相互共享,这个需求也很常见,例如用户可能有10个使用Spring组织的应用程序部署在同一台服务器上,如果把10分Spring分别放在各个应用程序的隔离目录中,将会是很大的资源浪费-----主要到不是浪费磁盘空间的问题,而是指类库在使用时都要被加载到服务器内存,如果类库不能共享,虚拟机的方法区很容易就会出现过度膨胀的危险。

    (3)服务器需要尽可能的保证自身的安全不受部署的web应用程序影响,目前,很多主流的java web服务器自身也是使用java语言来实现的,因此服务器本身也有类库依赖问题,一般来说,基于安全考虑,服务器所使用的类库应该与应用程序的类库互相独立。

    (4)支持JSP应用的web服务器,十有八九都需要支持HotSwap功能,我们知道JSP文件最终要被编译成java Class文件才能被虚拟机执行,但JSp文件由于其纯文本存储的特性,被运行时修改的概率远远大于第三方类库或程序自己的Class文件,而且ASP、PHP、JSP这些网页应用也把修改后无须重启作为一个很大的“优势”来看待,因此“主流”web服务器都会支持JSP生成类的热替换,当然也有“非主流”,如运行在生产模式下的webLogic服务器默认就不会处理JSP文件的变化。

    由于上述存在的问题,在部署web应用时,单独的一个ClassPath就无法满足需求了,所以各种web服务器都不约而同提供了好几个ClassPath路径用户存放第三方类库,这些路径一般都以“lib”或“classess”命名,被放置到不同路径中的类库,具备不同的访问范围和服务对象,通常,每一个目录都会有一个相应的自定义类加载器去加载放置在里面的jav类库,那么Tomcat是如何规划用户的类库结构和类加载器的?

    在Tomcat目录结构中,有三组目录(“/common/*”、“/server/*”、和“/shared/*”)可以存放在java类库中,另外还可以加上web应用程序自身的目录“/WEB-INF/*”,一共四组,把java类库放置在这些目录中的含义分别是:

    (1)放置在/common目录中;类库可被Tomcat和所有的web应用程序共同使用。

    (2)放置在/server目录中:类库可被Tomcat使用,对所有的Web应用程序都不可见。

    (3)放置在/shared目录中:类库可被所有web应用程序共同使用,但对Tomcat自己不可见。

    (4)放置在/WebApp/WEB-INF目录中:类库仅仅可以被此web应用程序使用,对Tomcat和其他web应用程序都不可见。

    为了支持这套目录结构,并对目录里面的类库进行加载和隔离,Tomcat自定义了多个类加载器,这些类加载器按照经典的双亲委派模型来实现。下图是tomcat服务器的类加载结构:


    灰色背景的三个类加载器时JDK默认提供的类加载器。而CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器,它们分载/common/*、/server/*、/shared/*和/WebApp/WEB-INF/*中java类库的逻辑,其中webApp类加载器和JSP类加载器通常会存在多个实例,每一个Web应用程序对应一个WebApp类加载器,每一个JSP文件对应一个JSP类加载器。

    从上图的委派关系可以看出,CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用,而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对象相互隔离。WebAppClassLoader可以使用SharedClassLoader加载到的类,但各个WebAppClassLoader实例之间相互隔离,而JasperLoader的加载范围仅仅是这个Jsp文件所编译出来的那一个Class,它出现的目的就是为了被丢弃:当服务器监测到Jsp文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的Jsp类加载器来实现Jsp文件的HotSwap功能。

    对于Tomcat的6.x版本,只有指定了tomcat/conf/catalina.properties配置文件的server.loader和share.loader项后才会真正建立CatalinaClassLoader和SharedClassLoader的实例,否则会用到这两个类加载器的地方都会用CommonClassLoader的实例来替换,而默认的配置文件中没有设置这两个loader项,所以Tomcat6.x顺理成章的把/common、/server、/shared三个目录默认合并到一起变成一个/lib目录,这个目录里的类库相当于以前/commom目录张类库的作用。这是tomcat设计团队为了简化大多数的部署场景所做的一项改进,如果默认设置不能满足需要,用户可以通过修改配置文件制定server.loader和share.loader的方式重新启用Tomcat5.x的加载器架构。

    2、OSGI灵活的类加载器架构

    OSGI中的每个模块(称为Bundle)与普通的java类库区别并不太大,两者一般都以JAR格式进行封装,并且内部存储的都是Java Package和Class。但是一个Bundle可以声明它所依赖的Java Package(通过Import-Package描述),也可以声明它允许导出发布的Java Package(通过Export-Package描述)。在OSGI中,Bundle之间的依赖关系从传统的上层模块依赖底层模块变成平级模块之间的依赖(至少外观上是如此),而且类库的可见性能得到了非常精确的控制,一个模块里只有被Export过的Package才可能被外界访问,其他的Package和Class将会被隐藏起来,除了更精确的模块划分和可见性控制外,引入OSGI另外一个重要理由是,基于OSGI的程序很可能可以实现模块级的热插拔功能,当程序升级更新或调试除错时,可以只停用,重新安装然后启用程序的其中一部分,这对企业级程序开发来说是一个非常有诱惑力的特性。

    OSGI之所以能有上述诱人的特点,要归功于它灵活的类加载器结构,OSGI的Bundle类加载器之间只有规则,没有固定的委派关系,例如,某个Bundle声明了一个它依赖的Package,如果有其它Bundle声明发布了这个Package后,那么对这个Package的所有类加载动作都会委派给发布它的Bundle类加载器去完成,不涉及某个具体的Package时,各个Bundle加载器都是平级的关系,只有具体使用到某个Package和Class的时候,才会根据Package导入导出定义来构造Bundle间的委派和依赖。

    另外,一个Bundle类加载器为其他Bundle提供服务时,会根据Export-Package列表严格控制访问范围,如果一个类存在于Bundle的类库中但是没有被Export,那么这个Bundle的类加载器能找到这个类,但不会提供给其他Bundle使用,而且OSGI平台也不会把其他Bundle的类加载请求分配给这个Bundle来处理。

    例如,假设存在BundelA、BundleB和BundleC三个模块,并且这三个Bundle定义的依赖关系为:

    BundleA:声明发布了packageA,依赖了java.*的包。

    BundleB:声明依赖了packageA和packageC,同 时也依赖了java.*的包。

    BundleC:声明发布了packageC,依赖了packageA。

    那么这三个Bundle之间的类加载器以及父类加载器之家关系如图:


    上图只是体现了加载器件关系的概念模型,并且只是体现了OSGI中最简单的加载器委派关系,一般来说,在OSGI中,加载一个类可能发生的查找行为和委派关系会比上图复杂的多,类加载时可能进行的查找规则如下:

    以java.*开头的类,委派给父类加载器加载。

    否则,委派列表名单内的类,委派给父类加载器加载。

    否则,Import列表中的类,委派个Export这个类的Bundle的类加载器加载。

    否则,查找当前Bundle的ClassPath,使用自己的类加载器加载。

    否则,查找是否在自己的FragMent Bundle中,如果是则委派给Fragment Bundle的类加载器加载。

    否则,查找Dynamic Import列表的Bundle,委派给对应Bundle的类加载器加载。

    否则,类查找失败。

    从上图看出,在OSGI里面,加载器之间的关系不再是双亲委派模型的树形结构,而是进一步发展成了一种运行时才能确定的网状结构。这种网站结构的类加载器在带来更优秀的灵活性的同时,也可能产生许多新的隐患。


    展开全文
  • Tomcat为什么要重写类加载器 出现的原因 无法实现隔离性:如果使用默认的类加载器机制,那么是无法加载两个相同类库的不同版本的,默认的累加器是不管你是什么版本的,只在乎你的全限定类名,并且只有一份。 ...

    Tomcat为什么要重写类加载器

    出现的原因

    • 无法实现隔离性:如果使用默认的类加载器机制,那么是无法加载两个相同类库的不同版本的,默认的累加器是不管你是什么版本的,只在乎你的全限定类名,并且只有一份。

    • 无法实现热替换:jsp 文件其实也就是class文件,那么如果修改了,但类名还是一样,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重新加载的。

    打破双亲委派机制

    • OSGI是基于Java语言的动态模块化规范,类加载器之间是网状结构,更加灵活,但是也更复杂
    • JNDI服务,使用线程上线文类加载器,父类加载器去使用子类加载器

    Tomcat怎么实现的

    img
    1. tomcat自己定义的类加载器:
    • CommonClassLoader:tomcat最基本的类加载器,加载路径中的class可以被tomcat和各个webapp访问

    • CatalinaClassLoader:tomcat私有的类加载器,webapp不能访问其加载路径下的class,即对webapp不可见

    • SharedClassLoader:各个webapp共享的类加载器,对tomcat不可见

    • WebappClassLoader:webapp私有的类加载器,只对当前webapp可见

    1. 每一个web应用程序对应一个WebappClassLoader,每一个jsp文件对应一个JspClassLoader,所以这两个类加载器有多个实例

    2. 工作原理:

    • a. CommonClassLoader能加载的类都可以被Catalina ClassLoader和SharedClassLoader使用,从而实现了公有类库的共用

    • b. CatalinaClassLoader和Shared ClassLoader自己能加载的类则与对方相互隔离

    • c. WebAppClassLoader可以使用SharedClassLoader加载到的类,但各个WebAppClassLoader实例之间相互隔离,多个WebAppClassLoader是同级关系

    • d. 而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件,它出现的目的就是为了被丢弃:当Web容器检测到JSP文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能

    1. tomcat目录结构,与上面的类加载器对应
    • /common/*

    • /server/*

    • /shared/*

    • /WEB-INF/*

    1. 默认情况下,conf目录下的catalina.properties文件,没有指定server.loader以及shared.loader,所以tomcat没有建立CatalinaClassLoader和SharedClassLoader的实例,这两个都会使用CommonClassLoader来代替。Tomcat6之后,把common、shared、server目录合成了一个lib目录。所以在我们的服务器里看不到common、shared、server目录。

    参考博客:https://www.cnblogs.com/june0816/p/10090428.html

    展开全文
  • Tomcat加载器

    2020-04-21 18:40:34
    Tomcat的类加载机制是违反了双亲委托原则的,对于一些未加载的非基础类(Object,String等),各个web应用自己的类加载器(WebAppClassLoader)会优先加载,加载不到时再交给commonClassLoader走双亲委托。 对于JVM来说:...

    Tomcat的类加载机制是违反了双亲委托原则的,对于一些未加载的非基础类(Object,String等),各个web应用自己的类加载器(WebAppClassLoader)会优先加载,加载不到时再交给commonClassLoader走双亲委托。

    对于JVM来说:

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

    我们看到,前面3个类加载和默认的一致,CommonClassLoader、CatalinaClassLoader、SharedClassLoader和WebappClassLoader则是Tomcat自己定义的类加载器,它们分别加载/common/、/server/、/shared/*(在tomcat 6之后已经合并到根目录下的lib目录下)和/WebApp/WEB-INF/*中的Java类库。其中WebApp类加载器和Jsp类加载器通常会存在多个实例,每一个Web应用程序对应一个WebApp类加载器,每一个JSP文件对应一个Jsp类加载器。
    在这里插入图片描述
    commonLoader:Tomcat最基本的类加载器,加载路径中的class可以被Tomcat容器本身以及各个Webapp访问;
    catalinaLoader:Tomcat容器私有的类加载器,加载路径中的class对于Webapp不可见;
    sharedLoader:各个Webapp共享的类加载器,加载路径中的class对于所有Webapp可见,但是对于Tomcat容器不可见;
    WebappClassLoader:各个Webapp私有的类加载器,加载路径中的class只对当前Webapp可见;
    从图中的委派关系中可以看出:

    CommonClassLoader能加载的类都可以被Catalina
    ClassLoader和SharedClassLoader使用,从而实现了公有类库的共用,而CatalinaClassLoader和Shared
    ClassLoader自己能加载的类则与对方相互隔离。
    WebAppClassLoader可以使用SharedClassLoader加载到的类,但各个WebAppClassLoader实例之间相互隔离。
    而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件,它出现的目的就是为了被丢弃:当Web容器检测到JSP文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

    好了,至此,我们已经知道了tomcat为什么要这么设计,以及是如何设计的,那么,tomcat 违背了java 推荐的双亲委派模型了吗?答案是:违背了。 我们前面说过:

    双亲委派模型要求除了顶层的启动类加载器之外,其余的类加载器都应当由自己的父类加载器加载。

    很显然,tomcat 不是这样实现,tomcat 为了实现隔离性,没有遵守这个约定,每个webappClassLoader加载自己的目录下的class文件,不会传递给父类加载器。

    我们扩展出一个问题:如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类,该怎么办?
    看了前面的关于破坏双亲委派模型的内容,我们心里有数了,我们可以使用线程上下文类加载器实现,使用线程上下文加载器,可以让父类加载器请求子类加载器去完成类加载的动作。

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

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

    1 Bootstrap 引导类加载器

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

    2 System 系统类加载器

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

    加载tomcat使用以及应用通用的一些类,位于CATALINA_HOME/lib下,比如servlet-api.ja
    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启动过程中 加载资源的顺序
  • tomcat加载器

    2012-12-11 11:09:48
    DevLoader.zip tomcat加载器
  • Java类加载机制与Tomcat加载器架构

    万次阅读 热门讨论 2017-02-26 10:58:11
    加载器 虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类...
  • tomcat9类加载器

    2019-06-10 16:49:37
    我们都知道,tomcat9加载器结构如下图: BoostrapClassLoader:启动加载器,它是用本地代码实现的类装载器,负责将 JDK 中 jre/lib 下的 类库 或者 XBootClassPath指定的类库加载到内存中,开发者无法直接获取...
  • Tomcat加载器WebappLoader和WebappClassLoader的工作流程。
  • 一、Tomcat结构 模块组成结构:Tomcat 的核心组件就 Connector 和 Container,一个Connector+一个Container(Engine)构成一个Service,Service就是对外提供服务的组件,有了Service组件Tomcat就能对外提供服务了,...
  • Tomcat启动监听

    千次阅读 2017-11-03 15:40:16
    1.tomcat启动时执行某一方法:import java.util.Timer;import javax.servlet.ServletContextEvent; import javax.servlet.ServletContextListener;public class TestListener implements ServletContextListener { ...
  • 主要介绍了Tomcat加载器的实现方法及实例代码,本文给大家介绍的非常详细,具有一定的参考借鉴价值 ,需要的朋友可以参考下
  • tomcat加载器及jar包冲突问题分析

    千次阅读 2016-12-09 23:04:02
    tomcat加载器及jar包冲突问题分析 开发过程中遇到过这样一个情况,在本地tomcat下开发调试正常,打包到测试环境的jboss下所有页面都变成空白页。 项目日志和jboss日志没有一点异常信息,费了半天劲把jboss所有日志...
  • Tomcat加载方式
  • 项目使用springboot启动一个web项目,在启动阶段看到console中出现了异常“1.10.3-1.4.3\hdf5.jar 系统找不到指定的文件”,虽然这些异常不影响项目的正常运行,但作为一个严谨的技术人员,看到这些异常就像见到...
  • 主要介绍了Eclipse启动Tomcat后无法访问项目解决办法的相关资料,需要的朋友可以参考下
  • 主要给大家介绍了关于tomcat8改了jar加载顺序的踩坑记录,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧
  • 加载器如何发生内存泄露,以及Tomcat与类加载器有关的源代码,分析了Tomcat启动流程
  • 文章引用: ... 2 《深入理解Java虚拟机:JVM高级特性与...主流的Java Web服务器(也就是Web容器),如Tomcat、Jetty、WebLogic、WebSphere或其他笔者没有列举的服务器,都实现了自己定义的类加载器(一般都不止一个)...
  • 按照我们最初订的计划,今天,我们要开始研究tomcat的几个主要组件(组件太多,无法一一解析,解析几个核心),包括核心的类加载器,连接器和容器,还有生命周期,还有pipeline 和 valve。一个一个来,今天来研究类...
  • Tomcat8源码分析系列-类加载器

    千次阅读 2018-04-29 00:45:15
    启动加载器(Bootstrap ClassLoader):加载对象是java的核心类库,把一些的 java 类加载到 jvm 中,它并不是我们熟悉的 ClassLoader,而是 jvm 层面由 C/C++ 实现的类加载器,负责加载 $JAVA_HOME/jre/lib 目录下 ...
  • tomcat过滤异常

    千次阅读 2020-10-14 17:40:20
    tomcat过滤异常
  • 说说tomcat与类加载器

    2019-04-01 15:54:05
    如果我们一个tomcat里面跑了10个SSM架构的项目,怎样节约内存?接下来跟着源码时代老师一起来看一下。 再次认识Tomcat Tomcat是我们从一开始接触Java Web就认识的一个web服务器,它是由Java语言编...
  • 加载机制概念 Java虚拟机把描述类的class文件加载到内存,对其进行校验、转换解析、初始化等操作,最终得到可以被虚拟机直接使用的java类型,这就是虚拟机的加载机制。 加载 将class文件读入到内存中,并将其...
  • Tomcat(Servlet3.0规范的web容器)启动时,会查找ServletContainerInitializer接口实现类,而刚好这个类SpringServletContainerInitializer由spring提供,在配置web服务器时,还会有一个 WebApplicationInitializer...
  • 但楼主思前想后,觉得连接器组件不能只是纸上谈兵,需要深入源码,但楼主本能的认为我们应该先分析tomcat启动过程,以能够和我们上一篇文章深入理解 Tomcat(四)Tomcat加载器之为何违背双亲委派模型相衔接。...
  • NULL 博文链接:https://sunfish.iteye.com/blog/1478036
  • 浅析 Tomcat加载过程

    2019-07-28 02:38:30
    java 类加载器的功能是将 class 加载入内存, tomcat的的应用程序加载过程使 tomcat拥有了在同一个 jvm 中加载管理多个应用的功能. 在介绍 tomcat应用程序加载过程前,我们先简单了解下 java 类加载机制.在Class 类中,...
  • Tomcat(Servlet3.0规范的web容器)启动时,会查找ServletContainerInitializer接口实现类,这个实现类SpringServletContainerInitializer由Spring提供,然后Spring提供的实现类会加载WebApplicationInitializer这个...
  • 之前tomcat启动老是报错,虽然不影响项目的启动运行,但是有强迫症的程序员会心里不爽: 如下: 问题分析 由于本机安装的jdk版本与tomcat中使用的jdk版本不一致导致的。 解决方法 后面我把原先tomcat启动环境用的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 197,637
精华内容 79,054
关键字:

tomcat加载器