精华内容
下载资源
问答
  • NULL 博文链接:https://yjhexy.iteye.com/blog/668334
  • Tomcat类加载方式

    一、Tomcat类加载方式

    1、jdk定义的类加载

    双亲委派模型
    从Java虚拟机的角度来讲,只存在两种不同的类加载器:一种是启动类加载器(Bootstrap ClassLoader),这个类加载器使用C++语言实现,是虚拟机自身的一部分;另一种就是所有其他的类加载器,这些类加载器都由Java语言实现,独立于虚拟机外部,并且全都继承自抽象类java.lang.ClassLoader。
    从Java开发人员的角度来看, 类加载器还可以划分得更细致一些, 绝大部分Java程序都会使用到以下3种系统提供的类加载器。

    1)启动类加载器(Bootstrap ClassLoader):前面已经介绍过,这个类加载器负责将存放在<JAVA_HOME>\lib目录中的,或者被-Xbootclasspath参数所指定的路径中的,并且是虚拟机识别的(仅按照文件名识别,如rt.jar,名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。

    2)扩展类加载器(Extension ClassLoader):这个加载器由sun.misc.Launcher.ExtClassLoader实现,它负责加载<JAVA_HOME>\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。

    3)应用程序类加载器(Application ClassLoader):这个类加载器由sun.misc.Launcher.AppClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也称它为系统类加载器。它负责加载用户类路径(Class Path)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

    4)我们的应用程序都是由这3种类加载器互相配合进行加载的,如果有必要,还可以加入自己定义的类加载器。这些类加载器之间的关系一般如下图所示。

    在这里插入图片描述
    双亲委托类加载源码参考如下:

    protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    	//首先, 检查请求的类是否已经被加载过了
    	Class c=findLoadedClass(name);
    	if( c== null ){
    		try{
    			if( parent != null ){
    				c = parent.loadClass(name,false);
    			} else {
    				c = findBootstrapClassOrNull(name);
    			}
    		} catch (ClassNotFoundException e) {
    			//如果父类加载器抛出ClassNotFoundException
    			//说明父类加载器无法完成加载请求
    		}
    		if( c == null ) {
    			//在父类加载器无法加载的时候
    			//再调用本身的findClass方法来进行类加载
    			c = findClass(name);
    		}
    	} 
    	if(resolve){
    		resolveClass(c);
    	}
    	return c;
    }
    

    2、Tomcat类加载方式

    打破双亲委派模型
    上文提到过双亲委派模型并不是一个强制性的约束模型,而是Java设计者推荐给开发者的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型,但也有例外。
    Tomcat有自己定义的类加载器,因为一个功能健全的Web容器,要解决如下几个问题:
    **1)部署在同一个Web容器上的两个Web应用程序所使用的Java类库可以实现相互隔离。**这是最基本的需求,两个不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求一个类库在一个服务器中只有一份,服务器应当保证两个应用程序的类库可以互相独立使用。
    **2)部署在同一个Web容器上的两个Web应用程序所使用的Java类库可以互相共享。**这个需求也很常见,例如,用户可能有10个使用Spring组织的应用程序部署在同一台服务器上,如果把10份Spring分别存放在各个应用程序的隔离目录中,将会是很大的资源浪费——这主要倒不是浪费磁盘空间的问题,而是指类库在使用时都要被加载到Web容器的内存,如果类库不能共享,虚拟机的方法区就会很容易出现过度膨胀的风险。
    **3)Web容器需要尽可能地保证自身的安全不受部署的Web应用程序影响。**目前,有许多主流的Java Web容器自身也是使用Java语言来实现的。因此,Web容器本身也有类库依赖的问题,一般来说,基于安全考虑,容器所使用的类库应该与应用程序的类库互相独立。
    **4)支持JSP应用的Web容器,大多数都需要支持HotSwap功能。**我们知道,JSP文件最终要编译成Java Class才能由虚拟机执行,但JSP文件由于其纯文本存储的特性,运行时修改的概率远远大于第三方类库或程序自身的Class文件。而且ASP、PHP和JSP这些网页应用也把修改后无须重启作为一个很大的“优势”来看待,因此“主流”的Web容器都会支持JSP生成类的热替换,当然也有“非主流”的,如运行在生产模式(Production Mode)下的WebLogic服务器默认就不会处理JSP文件的变化。

    在Tomcat目录结构中,有3组目录(“/common/”、“/server/”和“/shared/” tomcat6以后移到lib目录下)可以存放Java类库,另外还可以加上Web应用程序自身的目录“/WEB-INF/”,一共4组,把Java类库放置在这些目录中的含义分别如下:
    ①放置在/common目录中:类库可被Tomcat和所有的Web应用程序共同使用。
    ②放置在/server目录中:类库可被Tomcat使用,对所有的Web应用程序都不可见。
    ③放置在/shared目录中:类库可被所有的Web应用程序共同使用,但对Tomcat自己不可见。
    ④放置在/WebApp/WEB-INF目录中:类库仅仅可以被此Web应用程序使用,对Tomcat和其他Web应用程序都不可见。
    为了支持这套目录结构,并对目录里面的类库进行加载和隔离,Tomcat自定义了多个类加载器,这些类加载器按照经典的双亲委派模型来实现,其关系如下图所示。
    在这里插入图片描述

    前面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容器不可见;
    WebappClassLoaderJasperClassLoader:各个Webapp私有的类加载器,加载路径中的class只对当前Webapp可见;

    二、Springboot启动的嵌入式tomcat类加载

    Springboot启动嵌入式tomcat过程源码(参考我上一篇博文:SprintBoot 1.4.3 启动tomcat源码分析,与Tomcat启动war包的不同)如下:

        @Override
    	public EmbeddedServletContainer getEmbeddedServletContainer(
    			ServletContextInitializer... initializers) {
    		// 实例化一个tomcat
    		Tomcat tomcat = new Tomcat();
    		// 设置tomcat目录
    		File baseDir = (this.baseDirectory != null ? this.baseDirectory
    				: createTempDir("tomcat"));
    		tomcat.setBaseDir(baseDir.getAbsolutePath());
    		// 创建一个连接器
    		Connector connector = new Connector(this.protocol);
    		// service 添加连接器,一个service可以添加多个连接器
    		tomcat.getService().addConnector(connector);
    		// 设置连接器的相关参数
    		customizeConnector(connector);
    		// tomcat设置该连接器
    		tomcat.setConnector(connector);
    		tomcat.getHost().setAutoDeploy(false);
    		// 配置tomcat的engine
    		configureEngine(tomcat.getEngine());
    		for (Connector additionalConnector : this.additionalTomcatConnectors) {
    			tomcat.getService().addConnector(additionalConnector);
    		}
    		// 准备context
    		prepareContext(tomcat.getHost(), initializers);
    		// 创建Container
    		return getTomcatEmbeddedServletContainer(tomcat);
    	}
    

    今天我们进入prepareContext方法继续分析逻辑,就可以看出嵌入式tomcat的类加载方式,看源码:

    protected void prepareContext(Host host, ServletContextInitializer[] initializers) {
    		File docBase = getValidDocumentRoot();
    		docBase = (docBase != null ? docBase : createTempDir("tomcat-docbase"));
    		TomcatEmbeddedContext context = new TomcatEmbeddedContext();
    		context.setName(getContextPath());
    		context.setDisplayName(getDisplayName());
    		context.setPath(getContextPath());
    		context.setDocBase(docBase.getAbsolutePath());
    		context.addLifecycleListener(new FixContextListener());
    		// 设置父类加载器,可以为空
    		context.setParentClassLoader(
    				this.resourceLoader != null ? this.resourceLoader.getClassLoader()
    						: ClassUtils.getDefaultClassLoader());
    		resetDefaultLocaleMapping(context);
    		addLocaleMappings(context);
    		try {
    			context.setUseRelativeRedirects(false);
    		}
    		catch (NoSuchMethodError ex) {
    			// Tomcat is < 8.0.30. Continue
    		}
    		SkipPatternJarScanner.apply(context, this.tldSkip);
    		// 使用WebApp类加载器加载应用信息
    		WebappLoader loader = new WebappLoader(context.getParentClassLoader());
    		// 嵌入式tomcat的webapp类加载器TomcatEmbeddedWebappClassLoader
    		loader.setLoaderClass(TomcatEmbeddedWebappClassLoader.class.getName());
    		loader.setDelegate(true);
    		context.setLoader(loader);
    		if (isRegisterDefaultServlet()) {
    			addDefaultServlet(context);
    		}
    		if (shouldRegisterJspServlet()) {
    			addJspServlet(context);
    			addJasperInitializer(context);
    			context.addLifecycleListener(new StoreMergedWebXmlListener());
    		}
    		ServletContextInitializer[] initializersToUse = mergeInitializers(initializers);
    		configureContext(context, initializersToUse);
    		host.addChild(context);
    		postProcessContext(context);
    	}
    

    我们进入TomcatEmbeddedWebappClassLoader类继续分析:

    **
     * Extension of Tomcat's {@link WebappClassLoader} that does not consider the
     * {@link ClassLoader#getSystemClassLoader() system classloader}. This is required to to
     * ensure that any custom context classloader is always used (as is the case with some
     * executable archives).
     *
     * @author Phillip Webb
     */
    public class TomcatEmbeddedWebappClassLoader extends WebappClassLoader {
    
    	private static final Log logger = LogFactory
    			.getLog(TomcatEmbeddedWebappClassLoader.class);
    
    	public TomcatEmbeddedWebappClassLoader() {
    		super();
    	}
    
    	public TomcatEmbeddedWebappClassLoader(ClassLoader parent) {
    		super(parent);
    	}
    
    	// 类加载过程
    	@Override
    	public synchronized Class<?> loadClass(String name, boolean resolve)
    			throws ClassNotFoundException {
    			Class<?> resultClass = null;
    
    		// 验证当前class缓存,即类是否被加载过
    		resultClass = (resultClass == null ? findLoadedClass0(name) : resultClass);
    		resultClass = (resultClass == null ? findLoadedClass(name) : resultClass);
    		if (resultClass != null) {
    			return resolveIfNecessary(resultClass, resolve);
    		}
    
    		// 校验权限
    		checkPackageAccess(name);
    
    		// 执行具体加载
    		boolean delegateLoad = (this.delegate || filter(name, true));
    
    		if (delegateLoad) {
    			resultClass = (resultClass == null ? loadFromParent(name) : resultClass);
    		}
    		resultClass = (resultClass == null ? findClassIgnoringNotFound(name)
    				: resultClass);
    		if (!delegateLoad) {
    			resultClass = (resultClass == null ? loadFromParent(name) : resultClass);
    		}
    
    		if (resultClass == null) {
    			throw new ClassNotFoundException(name);
    		}
    
    		return resolveIfNecessary(resultClass, resolve);
    	}
    

    SpringBoot嵌入式的Tomcat的启动过程中的类加载只需要WebApp的类加载和Jsper类加载。
    而tomcat启动war要经历所有的类加载过程。

    本文分析若有不对的地方还请给位指正。

    展开全文
  • Tomcat7.0.62 启动类加载日志
  • 类加载  在JVM中并不是一次性把所有的文件都加载到,而是一步一步的,按照需要来加载。  比如JVM启动时,会通过不同的类加载加载不同的。当用户在自己的代码中,需要某些额外的时,再通过加载机制加载到...

    类加载

      在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类加载

      在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.jar

      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包文件,当放置了多份,就可能导致 多个应用间 出现类加载不到的错误。

    展开全文
  • tomcat类加载

    2012-12-11 11:09:48
    DevLoader.zip tomcat 类加载
  • 图解Tomcat类加载机制  说到本篇的tomcat类加载机制,不得不说翻译学习tomcat的初衷。  之前实习的时候学习javaMelody的源码,但是它是一个Maven的项目,与我们自己的web项目整合后无法直接断点调试。后来...

    图解Tomcat类加载机制

      说到本篇的tomcat类加载机制,不得不说翻译学习tomcat的初衷。

      之前实习的时候学习javaMelody的源码,但是它是一个Maven的项目,与我们自己的web项目整合后无法直接断点调试。后来同事指导,说是直接把java类复制到src下就可以了。很纳闷....为什么会优先加载src下的java文件(编译出的class),而不是jar包中的class呢?

      现在了解tomcat的类加载机制,原来一切是这么的简单。

    类加载

      在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类加载

      在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.jar

      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包文件,当放置了多份,就可能导致 多个应用间 出现类加载不到的错误。

    参考

    【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

    分类:  Java
    展开全文
  • 按照我们最初订的计划,今天,我们要开始研究tomcat的几个主要组件(组件太多,无法一一解析,解析几个核心),包括核心的类加载器,连接器和容器,还有生命周期,还有pipeline 和 valve。一个一个来,今天来研究...

    这是我们研究Tomcat的第四篇文章,前三篇文章我们搭建了源码框架,了解了tomcat的大致的设计架构, 还写了一个简单的服务器。按照我们最初订的计划,今天,我们要开始研究tomcat的几个主要组件(组件太多,无法一一解析,解析几个核心),包括核心的类加载器,连接器和容器,还有生命周期,还有pipeline 和 valve。一个一个来,今天来研究类加载器。

    我们分为4个部分来探讨:

       1. 什么是类加载机制?
       2. 什么是双亲委任模型?
       3. 如何破坏双亲委任模型?
       4. Tomcat 的类加载器是怎么设计的?

    我想,在研究tomcat 类加载之前,我们复习一下或者说巩固一下java 默认的类加载器。楼主以前对类加载也是懵懵懂懂,借此机会,也好好复习一下。

    楼主翻开了神书《深入理解Java虚拟机》第二版,p227, 关于类加载器的部分。请看:

    1. 什么是类加载机制?

    代码编译的结果从本地机器码转变成字节码,是存储格式的一小步,却是编程语言发展的一大步。

    Java虚拟机把描述类的数据从Class文件加载进内存,并对数据进行校验,转换解析和初始化,最终形成可以呗虚拟机直接使用的Java类型,这就是虚拟机的类加载机制。

    虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类。实现这动作的代码模块成为“类加载器”。

    类与类加载器的关系

    类加载器虽然只用于实现类的加载动作,但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类,都需要由加载他的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类命名空间。这句话可以表达的更通俗一些:比较两个类是否“相等”,只有在这两个类是由同一个类加载器加载的前提下才有意义,否则,即使这两个类来自同一个Class文件,被同一个虚拟机加载,只要加载他们的类加载器不同,那这个两个类就必定不相等。

    2. 什么是双亲委任模型

    1. 从Java虚拟机的角度来说,只存在两种不同类加载器:一种是启动类加载器(Bootstrap ClassLoader),这个类加载器使用C++语言实现(只限HotSpot),是虚拟机自身的一部分;另一种就是所有其他的类加载器,这些类加载器都由Java语言实现,独立于虚拟机外部,并且全都继承自抽象类java.lang.ClassLoader.

    2. 从Java开发人员的角度来看,类加载还可以划分的更细致一些,绝大部分Java程序员都会使用以下3种系统提供的类加载器:

      • 启动类加载器(Bootstrap ClassLoader):这个类加载器复杂将存放在 JAVA_HOME/lib 目录中的,或者被-Xbootclasspath 参数所指定的路径种的,并且是虚拟机识别的(仅按照文件名识别,如rt.jar,名字不符合的类库即使放在lib目录下也不会重载)。
      • 扩展类加载器(Extension ClassLoader):这个类加载器由sun.misc.Launcher$ExtClassLoader实现,它负责夹杂JAVA_HOME/lib/ext 目录下的,或者被java.ext.dirs 系统变量所指定的路径种的所有类库。开发者可以直接使用扩展类加载器。
      • 应用程序类加载器(Application ClassLoader):这个类加载器由sun.misc.Launcher$AppClassLoader 实现。由于这个类加载器是ClassLoader 种的getSystemClassLoader方法的返回值,所以也成为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库。开发者可以直接使用这个类加载器,如果应用中没有定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

    这些类加载器之间的关系一般如下图所示:

    图中各个类加载器之间的关系成为 类加载器的双亲委派模型(Parents Dlegation Mode)。双亲委派模型要求除了顶层的启动类加载器之外,其余的类加载器都应当由自己的父类加载器加载,这里类加载器之间的父子关系一般不会以继承的关系来实现,而是都使用组合关系来复用父加载器的代码。

    类加载器的双亲委派模型在JDK1.2 期间被引入并被广泛应用于之后的所有Java程序中,但他并不是个强制性的约束模型,而是Java设计者推荐给开发者的一种类加载器实现方式。

    双亲委派模型的工作过程是:如果一个类加载器收到了类加载的请求,他首先不会自己去尝试加载这个类,而是把这个请求委派父类加载器去完成。每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个请求(他的搜索范围中没有找到所需的类)时,子加载器才会尝试自己去加载。

    为什么要这么做呢?

    如果没有使用双亲委派模型,由各个类加载器自行加载的话,如果用户自己编写了一个称为java.lang.Object的类,并放在程序的ClassPath中,那系统将会出现多个不同的Object类, Java类型体系中最基础的行为就无法保证。应用程序也将会变得一片混乱。

    双亲委任模型时如何实现的?

    非常简单:所有的代码都在java.lang.ClassLoader中的loadClass方法之中,代码如下:

    逻辑清晰易懂:先检查是否已经被加载过,若没有加载则调用父加载器的loadClass方法, 如父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败,抛出ClassNotFoundException 异常后,再调用自己的findClass方法进行加载。

    3. 如何破坏双亲委任模型?

    刚刚我们说过,双亲委任模型不是一个强制性的约束模型,而是一个建议型的类加载器实现方式。在Java的世界中大部分的类加载器都遵循者模型,但也有例外,到目前为止,双亲委派模型有过3次大规模的“被破坏”的情况。
    第一次:在双亲委派模型出现之前—–即JDK1.2发布之前。
    第二次:是这个模型自身的缺陷导致的。我们说,双亲委派模型很好的解决了各个类加载器的基础类的统一问题(越基础的类由越上层的加载器进行加载),基础类之所以称为“基础”,是因为它们总是作为被用户代码调用的API, 但没有绝对,如果基础类调用会用户的代码怎么办呢?

    这不是没有可能的。一个典型的例子就是JNDI服务,JNDI现在已经是Java的标准服务,它的代码由启动类加载器去加载(在JDK1.3时就放进去的rt.jar),但它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者(SPI, Service Provider Interface)的代码,但启动类加载器不可能“认识“这些代码啊。因为这些类不在rt.jar中,但是启动类加载器又需要加载。怎么办呢?

    为了解决这个问题,Java设计团队只好引入了一个不太优雅的设计:线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader方法进行设置。如果创建线程时还未设置,它将会从父线程中继承一个,如果在应用程序的全局范围内都没有设置过多的话,那这个类加载器默认即使应用程序类加载器。

    嘿嘿,有了线程上下文加载器,JNDI服务使用这个线程上下文加载器去加载所需要的SPI代码,也就是父类加载器请求子类加载器去完成类加载的动作,这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器,实际上已经违背了双亲委派模型的一般性原则。但这无可奈何,Java中所有涉及SPI的加载动作基本胜都采用这种方式。例如JNDI,JDBC,JCE,JAXB,JBI等。

    第三次:为了实现热插拔,热部署,模块化,意思是添加一个功能或减去一个功能不用重启,只需要把这模块连同类加载器一起换掉就实现了代码的热替换。

    书中还说到:

    Java 程序中基本有一个共识:OSGI对类加载器的使用时值得学习的,弄懂了OSGI的实现,就可以算是掌握了类加载器的精髓。

    牛逼啊!!!

    现在,我们已经基本明白了Java默认的类加载的作用了原理,也知道双亲委派模型。说了这么多,差点把我们的tomcat给忘了,我们的题目是Tomcat 加载器为何违背双亲委派模型?下面就好好说说我们的tomcat的类加载器。

    4. Tomcat 的类加载器是怎么设计的?

    首先,我们来问个问题:

    Tomcat 如果使用默认的类加载机制行不行?

    我们思考一下:Tomcat是个web容器, 那么它要解决什么问题:
    1. 一个web容器可能需要部署两个应用程序,不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求同一个类库在同一个服务器只有一份,因此要保证每个应用程序的类库都是独立的,保证相互隔离。
    2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则,如果服务器有10个应用程序,那么要有10份相同的类库加载进虚拟机,这是扯淡的。
    3. web容器也有自己依赖的类库,不能于应用程序的类库混淆。基于安全考虑,应该让容器的类库和程序的类库隔离开来。
    4. web容器要支持jsp的修改,我们知道,jsp 文件最终也是要编译成class文件才能在虚拟机中运行,但程序运行后修改jsp已经是司空见惯的事情,否则要你何用? 所以,web容器需要支持 jsp 修改后不用重启。

    再看看我们的问题:Tomcat 如果使用默认的类加载机制行不行?
    答案是不行的。为什么?我们看,第一个问题,如果使用默认的类加载器机制,那么是无法加载两个相同类库的不同版本的,默认的累加器是不管你是什么版本的,只在乎你的全限定类名,并且只有一份。第二个问题,默认的类加载器是能够实现的,因为他的职责就是保证唯一性。第三个问题和第一个问题一样。我们再看第四个问题,我们想我们要怎么实现jsp文件的热修改(楼主起的名字),jsp 文件其实也就是class文件,那么如果修改了,但类名还是一样,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重新加载的。那么怎么办呢?我们可以直接卸载掉这jsp文件的类加载器,所以你应该想到了,每个jsp文件对应一个唯一的类加载器,当一个jsp文件修改了,就直接卸载这个jsp类加载器。重新创建类加载器,重新加载jsp文件。

    Tomcat 如何实现自己独特的类加载机制?

    所以,Tomcat 是怎么实现的呢?牛逼的Tomcat团队已经设计好了。我们看看他们的设计图:

    我们看到,前面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的类加载器是如何设计的。顺便复习了一下 Java 默认的类加载器机制,也知道了如何破坏Java的类加载机制。这一次收获不小哦!!! 嘿嘿。

    好了,今天到此为止。下篇 深入理解 Tomcat(五)Tomcat 两大核心组件—-连接器和容器!!!

    good luck!!!

    展开全文
  • TomCat类加载器结构

    千次阅读 2016-10-21 16:23:25
    一个功能健全的类加载器,都要解决以下几个问题: (1)部署在同一服务器上的两个web应用程序所使用的java类库可以实现相互隔离。这是最基本的需求,两个不同的应用程序可能会依赖同一个第三方类库的不同版本,不能...
  • 图解Tomcat类加载机制  说到本篇的tomcat类加载机制,不得不说翻译学习tomcat的初衷。  之前实习的时候学习javaMelody的源码,但是它是一个Maven的项目,与我们自己的web项目整合后无法直接断点调试。后来...
  • 本文首发于微信公众号 【Tomcat那些事儿】,欢迎关注。   Tomcat的用户一定都使用过其应用部署功能,无论是直接拷贝文件到webapps目录,还是修改server.xml以目录的形式部署,或者是增加虚拟主机,指定新的...
  • tomcat学习之四:tomcat类加载机制

    千次阅读 2017-10-27 17:21:13
    tomcat类加载机制继承了java类加载机制中经典的双亲委派模型。所以要了解tomcat类加载机制需要先了解双亲委派模型。  在程序中用到的需要由类加载器将的class文件加载到内存中,然后经由JVM验证、解析、...
  • Tomcat类加载顺序的实现

    千次阅读 2019-09-15 11:38:56
    Tomcat类加载顺序的实现   其实之所以为写这篇文章的原因,主要是前段时间,因为使用第三方的一些库,需要将这些库放到JDK的ext目录,由Java的ExtClassLoader进行加载,第三方库也是用了日志框架,而且使用的是...
  • 类加载机制概念 Java虚拟机把描述的class文件加载到内存,对其进行校验、转换解析、初始化等操作,最终得到可以被虚拟机直接使用的java类型,这就是虚拟机的加载机制。 加载 将class文件读入到内存中,并将其...
  • Tomcat类加载机制

    2019-01-30 23:20:17
    关于Java的类加载机制推荐这...Tomcat类加载机制是违反了双亲委托原则的,对于一些未加载的非基础(Object,String等),各个web应用自己的类加载器(WebAppClassLoader)会优先加载加载不到时再交给commonClassLoa...
  • Tomcat类加载机制以及线程上下文类加载器   tomcat类加载需要解决的问题 tomcat是一个很经典的web服务器,一个服务器就相当于一个Java应用,而在这个Java应用中又有着多个被部署的Web应用,因此,有着如下的几个...
  • tomcat类加载器及jar包冲突问题分析

    千次阅读 2016-12-09 23:04:02
    tomcat类加载器及jar包冲突问题分析 开发过程中遇到过这样一个情况,在本地tomcat下开发调试正常,打包到测试环境的jboss下所有页面都变成空白页。 项目日志和jboss日志没有一点异常信息,费了半天劲把jboss所有日志...
  • TOMCATtomcat 类加载及配置文件

    千次阅读 2014-02-21 16:50:27
    tomcat服务器是一种Servlet/jsp容器,更实质性的说是Servlet容器,因为jsp最终还是被编译成servlet来执行的 1. tomcat web.xml (1)与IIS中的默认文件意思相同 (2)报错文件  如果某文件资源没有找到,服务器要报...
  • 详细说明了tomcat启动过程中 加载资源的顺序
  • tomcat9类加载

    2019-06-10 16:49:37
    我们都知道,tomcat9加载器结构如下图: BoostrapClassLoader:启动类加载器,它是用本地代码实现的装载器,负责将 JDK 中 jre/lib 下的 类库 或者 XBootClassPath指定的类库加载到内存中,开发者无法直接获取...
  • Tomcat类加载器体系结构

    千次阅读 2015-04-25 17:34:26
    Tomcat 等主流Web服务器为了实现下面的基本功能,都实现了不止一个自定义的类加载器: (1).部署在同一个服务器上的两个web应用程序所使用的java类库可以相互隔离。 (2).部署在同一个服务器上的两个web应用程序...
  • 在这篇博文中java动态加载指定的或者jar包反射调用其方法,介绍动态加载指定的,当时我是拿URLClassLoader介绍的,当然可以自定义一个ClassLoader重写对应的方法, 不过这个有现成的比自己重写更强大为何不用...
  • 类加载器如何发生内存泄露,以及Tomcat类加载器有关的源代码,分析了Tomcat的启动流程
  • Tomcat类加载机制

    千次阅读 2016-03-02 15:38:14
    Tomcat类加载 参考 JVM类加载简单介绍 该层次关系称为类加载器的双亲委派模型,上一层即父加载器。 启动类加载器:Bootstrap ClassLoader,负责加载存放在JDK\jre\lib目录下或被-Xbootclasspath参数指定的路径中...
  • 但楼主思前想后,觉得连接器组件不能只是纸上谈兵,需要深入源码,但楼主本能的认为我们应该先分析tomcat的启动过程,以能够和我们上一篇文章深入理解 Tomcat(四)Tomcat 类加载器之为何违背双亲委派模型相衔接。...
  • Tomcat是一个优秀的Servlet容器,本身使用java语言编写。Tomcat是Apache开源软件组织的一个软件项目。Tomcat运行稳定、可靠,而且有着开源的优势,Tomcat已成为目前企业开发JavaWeb应用的最佳Servlet容器选择之一。 ...
  • Tomcat6类加载器定义(class类加载顺序)

    千次阅读 2015-07-01 11:49:29
    Tomcat6类加载器定义(class类加载顺序)
  • 一、Tomcat结构 模块组成结构:Tomcat 的核心组件就 Connector 和 Container,一个Connector+一个Container(Engine)构成一个Service,Service就是对外提供服务的组件,有了Service组件Tomcat就能对外提供服务了,...
  • tomcat 类加载时找不到class文件

    千次阅读 2014-08-05 11:06:27
    问题描述:tomcat启动的时候报错:java.contro
  • 深入剖析Tomcat类加载机制

    万次阅读 2013-09-21 16:17:18
    1JVM类加载机制 JVM的ClassLoader通过Parent属性定义父子关系,可以形成树状结构。其中引导、扩展、系统三个加载器是JVM内置的。 它们的作用分别是: 1)引导类加载器:使用native代码实现,在rt.jar等...
  • 主要给大家介绍了关于tomcat8改了jar加载顺序的踩坑记录,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 433,338
精华内容 173,335
关键字:

tomcat类加载