我们谈到tomcat时,第一印象是它是一种servlet容器,这个概念是相当抽象和本质的,我们仍然对tomcat的内幕很陌生。我们知道,tomcat由Connector和Container两大组件构成,Connector在前面的文章已经介绍过了,今天我们就来看看Container是怎么回事。
一、Container基本结构
前文中有讲到,Connector和Container的初始化工作是由Digester解析conf/server.xml来完成的,而在server.xml中已经告诉了我们Container的基本结构。我们先来看看server.xml文件:
<Server port="8005" shutdown="SHUTDOWN"> <Service name="Catalina"> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> <Engine name="Catalina" defaultHost="localhost"> <Realm className="org.apache.catalina.realm.LockOutRealm"> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> </Realm> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" /> </Host> </Engine> </Service> </Server>
通过xml文件,我们可以很清晰的看到,Server下包含了Service(可有多个),Service下包含了Connector和Engine,其实还可以包含Executor(线程池)。Engine正是与Connector处在同一水平的容器,Engine下面有Host,下面给出tomcat模块组成图。
前面在模拟tomcat连接器时,正是将servlet容器的实例作为参数传入到连接器的setContainer()方法中,这样连接器才能调用servlet容器的invoke()方法。
接下来给出一张大众化的Container组件结构图。
通过代码可以知道,tomcat提供了一个Container接口来抽象容器,并且细分了4种类型的容器,分别是Engine、Host、Context和Wrapper,对应不同的概念层次。
· Engine:表示整个Catalina的servlet引擎
· Host:表示一个拥有数个上下文的虚拟主机
· Context:表示一个Web应用,一个context包含一个或多个wrapper
· Wrapper:表示一个独立的servlet
Engine是顶层容器,java程序能够运行是因为有引擎即jvm,很自然的,Engine正是可以配置jvm(jvmRoute="jvm1")。Host是Engine的子容器,Context是Host的子容器,Wrapper是Context的子容器,这4个接口的标准实现分别是StandardEngine、StandardHost、StandardContext、StandardWrapper,她们都在org.apache.catalina.core包类,分析tomcat容器正式主要分析这4个类。下图展示了Container接口及其子接口和实现类的UML类图。
通过上面的两个图,我们知道了Container的结构,那么Container的初始化工作是怎么完成的呢?
二、Container初始化
回到Catalina类中,在load方法中调用了createStartDigester方法。
/** * Create and configure the Digester we will be using for startup. */ protected Digester createStartDigester() { Digester digester = new Digester(); // Initialize the digester // Configure the actions we will be using // 如果遇到”Server“元素起始符;则创建"org.apache.catalina.core.StandardServ // er"的一个实例对象,并压入堆栈;如果"Server"元素的"className"属性存在,那么用 // 这个属性的值所指定的class来创建实例对象,并压入堆栈。 digester.addObjectCreate("Server", "org.apache.catalina.core.StandardServer", "className"); // 从server.xml读取"Server"元素的所有{属性:值}配对,用对应的Setter方法将属性值 // 设置到堆栈顶层元素(Server)。 digester.addSetProperties("Server"); digester.addSetNext("Server", "setServer", "org.apache.catalina.Server"); digester.addObjectCreate("Server/Service", "org.apache.catalina.core.StandardService", "className"); digester.addSetProperties("Server/Service"); digester.addSetNext("Server/Service", "addService", "org.apache.catalina.Service"); digester.addObjectCreate("Server/Service/Listener", null, // MUST be specified in the element "className"); digester.addSetProperties("Server/Service/Listener"); digester.addSetNext("Server/Service/Listener", "addLifecycleListener", "org.apache.catalina.LifecycleListener"); //Executor //Connector // Add RuleSets for nested elements digester.addRuleSet(new NamingRuleSet("Server/GlobalNamingResources/")); digester.addRuleSet(new EngineRuleSet("Server/Service/")); digester.addRuleSet(new HostRuleSet("Server/Service/Engine/")); digester.addRuleSet(new ContextRuleSet("Server/Service/Engine/Host/")); addClusterRuleSet(digester, "Server/Service/Engine/Host/Cluster/"); digester.addRuleSet(new NamingRuleSet("Server/Service/Engine/Host/Context/")); // When the 'engine' is found, set the parentClassLoader. digester.addRule("Server/Service/Engine", new SetParentClassLoaderRule(parentClassLoader)); addClusterRuleSet(digester, "Server/Service/Engine/Cluster/"); return (digester); }
从简化的源码中可以看到,digester对server.xml设置的标签动作有5种调用:
- addObjectCreate:遇到起始标签的元素,初始化一个实例对象入栈
- addSetProperties:遇到某个属性名,使用setter来赋值
- addSetNext:遇到结束标签的元素,调用相应的方法
- addRule:调用rule的begin 、body、end、finish方法来解析xml,入栈和出栈给对象赋值
- addRuleSet:调用addRuleInstances来解析xml标签
从这些规则和xml中可以看到,Calatina的Server对象是StandardServer。StandardService包含了多个Connector(xml中有2个connector)和一个StandardEngine Container。StandardEngine包含了一个Host Container。
三、Context容器加载web服务与热部署
从confg/server.xml中我们可以看到Server的容器的初始化只有Engine和Host,那么Context是什么时候初始化的呢,是怎么加载我们的web application,怎么实现的热部署呢?
先说结论,tomcat的Engine会启动一个线程,该线程每10s会发送一个事件,监听到该事件的部署配置类会自动去扫描webapp文件夹下的war包,将其加载成一个Context,即启动一个web服务。
OK,回过头看conf/server.xml和createStartDigester,添加了HostRuleSet,进入HostRuleSet类中,可以看到这么一行代码:
digester.addRule(prefix + "Host", new LifecycleListenerRule ("org.apache.catalina.startup.HostConfig", "hostConfigClass"));
继续进入LifecycleListenerRule类可以发现,在监听事件中增加了HostConfig类的对象,也就是StandardHost中新增了一个HostConfig监听器。再回过头来进入StandardEngine的starInternal方法super.startInternal(父类ContainerBase)中有这行代码:
threadStart();
进入后发现开启了一个线程,调用ContainerBackgroundProcessor这个的run方法,而这个run方法可以看到,
protected class ContainerBackgroundProcessor implements Runnable { @Override public void run() { // try { while (!threadDone) { try { Thread.sleep(backgroundProcessorDelay * 1000L);//在StandardEngine中构造方法设置默认backgroundProcessorDelay=10,即10s调用一次 } catch (InterruptedException e) { // Ignore } if (!threadDone) { // processChildren(parent, cl); } } } // } }
也就是说该线程每10s会调用一次processChildren,继续跟踪该方法,会看到调用Engine、Host、Context、Wrapper各容器组件及与它们相关的其它组件的backgroundProcess方法。
@Override public void backgroundProcess() { if (loader != null) { try { loader.backgroundProcess(); } catch (Exception e) { log.warn(sm.getString("containerBase.backgroundProcess.loader", loader), e); } } // fireLifecycleEvent(Lifecycle.PERIODIC_EVENT, null); }
这个方法中比较重要的两个
loader.backgroundProcess():调用了载入器的WebappLoader的backgroundProcess方法,进入这个方法可以看到:
public void backgroundProcess() { if (reloadable && modified()) { try { Thread.currentThread().setContextClassLoader (WebappLoader.class.getClassLoader()); if (container instanceof StandardContext) { ((StandardContext) container).reload(); } } finally { if (container.getLoader() != null) { Thread.currentThread().setContextClassLoader (container.getLoader().getClassLoader()); } } } else { closeJARs(false); } }
看判断条件reloadable和modified(),reloadable即为是否开启热部署,而modified()则是当前文件是否有修改的判断,当开启了热部署且有修改就会调用Context的reload方法进行重加载,实现web服务的**热部署**。
fireLifecycleEvent:对容器的监听对象发送Lifecycle.PERIODIC_EVENT事件,调用LifecycleListener的lifecycleEvent。
public void fireLifecycleEvent(String type, Object data) { LifecycleEvent event = new LifecycleEvent(lifecycle, type, data); LifecycleListener interested[] = listeners; for (int i = 0; i < interested.length; i++) interested[i].lifecycleEvent(event); }
好的,前面说到StandardHost通server.xml配置了HostConfig监听器,那么进入HostConfig查看对该事件的响应方法lifecycleEvent
public void lifecycleEvent(LifecycleEvent event) { // Identify the host we are associated with try { host = (Host) event.getLifecycle(); if (host instanceof StandardHost) { setCopyXML(((StandardHost) host).isCopyXML()); setDeployXML(((StandardHost) host).isDeployXML()); setUnpackWARs(((StandardHost) host).isUnpackWARs()); setContextClass(((StandardHost) host).getContextClass()); } } catch (ClassCastException e) { log.error(sm.getString("hostConfig.cce", event.getLifecycle()), e); return; } // 看事件与其对应的方法调用 if (event.getType().equals(Lifecycle.PERIODIC_EVENT)) { check(); } else if (event.getType().equals(Lifecycle.START_EVENT)) { start(); } else if (event.getType().equals(Lifecycle.STOP_EVENT)) { stop(); } }
可以看到Lifecycle.PERIODIC_EVENT事件会调用其check方法。
protected void check() { if (host.getAutoDeploy()) {//这个条件对应这server.xml的Host配置的autoDeploy="true" DeployedApplication[] apps = deployed.values().toArray(new DeployedApplication[0]); for (int i = 0; i < apps.length; i++) { if (!isServiced(apps[i].name)) //资源查找 checkResources(apps[i], false); } if (host.getUndeployOldVersions()) { checkUndeploy(); } //部署 deployApps(); } }
很显然,如果server.xml的Host配置了能够自动部署(StandardHost默认autoDeploy=true),那么会调用deployApps方法。也就是说tomcat每10s会调用一次deployApps,完成**热部署**。当然,启动tomcat时则是START_EVENT,调用start()方法。
public void start() { // ... if (!appBase().isDirectory()) { log.error(sm.getString( "hostConfig.appBase", host.getName(), appBase().getPath())); host.setDeployOnStartup(false); host.setAutoDeploy(false); } if (host.getDeployOnStartup()) deployApps(); }
protected void deployApps() { File appBase = appBase(); File configBase = configBase(); String[] filteredAppPaths = filterAppPaths(appBase.list()); // Deploy XML descriptors from configBase deployDescriptors(configBase, configBase.list()); // Deploy WARs deployWARs(appBase, filteredAppPaths); // Deploy expanded folders deployDirectories(appBase, filteredAppPaths); }
可以看到可以通过xml,war包等直接部署!
protected void deployDescriptor(ContextName cn, File contextXml) { // Context context = null; // Class<?> clazz = Class.forName(host.getConfigClass());//默认值:ContextConfig LifecycleListener listener = (LifecycleListener) clazz.newInstance(); context.addLifecycleListener(listener); // host.addChild(context); // }
而部署的过程,其实就是创建了Context对象,并添加到Host中。
此外从HostConfig部署Contex的方法中可以看到,有3中方式部署war包:
1 在server.xml的Host标签中声明Context标签
2 将war包放入webapps中
3 context.xml配置方式
至此,我们已经知道了Engine、Host、Context的加载了,同时也知道了tomcat是怎么加载我们的web服务,是怎么实现的热部署。那么接下来就剩下最后一个Wrapper的加载了。
很捉急,在server.xml中没有关于Wrapper的初始化加载,那么在哪里呢?
同样回到,上面的deployApps()方法中,在其三种部署方式中都有一节代码
Class<?> clazz = Class.forName(host.getConfigClass());//默认值:ContextConfig LifecycleListener listener = (LifecycleListener) clazz.newInstance(); context.addLifecycleListener(listener);
这段代码的作用是给Context容器添加了ContextConfig监听器。而在Context的startInternal方法中,发送了监听事件:
fireLifecycleEvent(Lifecycle.CONFIGURE_START_EVENT, null);
ContextConfig监听到该事件,调用configureStart方法,在该方法中调用webConfig(),webConfig完成web.xml解析,生成servlet、filter等信息,并配置加载Wrapper。通过对ContextConfig的分析可以知道,Wrapper 代表一个 Servlet,它负责管理一个 Servlet,包括的 Servlet 的装载、初始化、执行以及资源回收。
四、关于StandardContext
StandardContext简单点说就是Servlet容器,是需要我们重点研究的对象,它包含了ApplicationContext (implements ServletContext),查看代码,我们可以发现容器对web.xml中相关元素的加载过程。
//// startInternal() // Set up the context init params mergeParameters(); // Call ServletContainerInitializers ex. SpringServletContainerInitializer for (Map.Entry<ServletContainerInitializer, Set<Class<?>>> entry : initializers.entrySet()) { try { entry.getKey().onStartup(entry.getValue(), getServletContext()); } catch (ServletException e) { log.error(sm.getString("standardContext.sciFail"), e); ok = false; break; } } // Configure and call application event listeners if (ok) { if (!listenerStart()) { log.error( "Error listenerStart"); ok = false; } } try { // Start manager if ((manager != null) && (manager instanceof Lifecycle)) { ((Lifecycle) getManager()).start(); } } catch(Exception e) { log.error("Error manager.start()", e); ok = false; } // Configure and call application filters if (ok) { if (!filterStart()) { log.error("Error filterStart"); ok = false; } } // Load and initialize all "load on startup" servlets if (ok) { if (!loadOnStartup(findChildren())){ log.error("Error loadOnStartup"); ok = false; } }我们常用的spring的ContextLoaderListener就是在此处加载的,注意,在Servlet3.0之前,listener不是按顺序调用的。关于Servlet,强烈建议读一下《Servlet规范》。
好了,从Engine---Host---Contex----Wrapper这个链路上的容器初始化和app加载已经完成。接下来的文章我们来看请求在容器里所走过的代码逻辑。
相关推荐
了解并分析Tomcat源码对于深入理解Java Web应用的部署和执行机制非常有帮助。 源码包"apache-tomcat-9.0.8-src"包含了Tomcat的所有源代码,包括核心组件、模块和服务。它由多个子目录构成,每个目录对应Tomcat的...
- **Servlet生命周期**:如何加载、初始化、服务和销毁Servlet。 - **JSP编译过程**:JSP如何被转换成Servlet并编译。 - **HTTP协议处理**:Tomcat如何接收和响应HTTP请求。 - **连接器(Connector)架构**:不同的...
《Tomcat6源码分析——深入理解Web服务器的运行机制》 Tomcat6作为Apache软件基金会的Jakarta项目的一部分,是一款广泛使用的Java Servlet容器,它实现了Java Servlet和JavaServer Pages(JSP)规范,为开发和部署...
Apache Tomcat 8.5.23 源码分析 Apache Tomcat 是一个开源的、免费的Web服务器和Servlet容器,它实现了Java Servlet和JavaServer Pages(JSP)规范,是开发和部署Java Web应用的重要平台。深入理解Tomcat的源码有助...
"how-tomcat-works-master_howtomcatworks_"是一个关于Tomcat工作原理的源码分析项目,经过整理后可以在IntelliJ IDEA中直接运行,为开发者提供了一手的实践平台。 首先,我们要了解Tomcat的核心组件。Tomcat主要由...
每个Container都有自己的生命周期管理,负责创建、初始化、启动、停止和销毁其子组件。 - **Pipeline与Valve**: Pipeline是容器内部请求处理的流水线,Valve是流水线上的一个个处理环节。Valve可以实现日志记录、...
7. **Container初始化**: - `StandardEngine`、`StandardHost`、`StandardContext`和`StandardWrapper`都属于容器`Container`的不同层次。 - 在`StandardEngine`的`initInternal`方法中,调用`container.init()`...
《Tomcat源码分析1——服务启动与架构详解》 Tomcat,作为一款广泛应用的开源Java Servlet容器,其内部架构和启动流程对于深入理解和优化Web应用程序至关重要。本文将重点解析Tomcat启动时的关键步骤和核心组件,...
### Tomcat源码研究知识点概览 #### 1.1 Catalina.bat脚本解析 - **脚本功能**:`catalina.bat`是Tomcat启动过程中的关键脚本之一,其主要作用在于构建合适的Java命令行参数,进而启动Tomcat服务。此脚本根据环境...
4. **Lifecycle**:在Tomcat中,每个组件都有一个生命周期,包括初始化、启动、停止和销毁等阶段。源码中关于生命周期的管理可以帮助我们理解组件如何正确地启动和关闭。 5. **Logging**:Tomcat使用内置的日志系统...
- `org.apache.catalina.startup.Bootstrap`:Tomcat的启动入口,负责加载服务器配置并初始化Catalina。 - `org.apache.catalina.core.StandardServer`:服务器对象,管理其他服务器组件。 - `org.apache....
【Tomcat源码分析】 Tomcat是一款开源的Java Servlet容器,是Apache软件基金会下的Jakarta项目的一部分。深入理解Tomcat的源码对于开发者来说是非常有价值的,因为它可以帮助我们更好地理解和优化Web应用程序的性能...
### TOMCAT源码分析——启动框架详解 #### 一、前言 TOMCAT作为一款广泛使用的开源Java Servlet容器,其内部实现复杂且强大。本文旨在深入剖析TOMCAT的启动框架及其整体架构,帮助读者更好地理解其工作原理。...
1. **服务器启动流程**:从启动脚本开始,理解如何初始化服务器环境,加载配置文件,创建并启动线程池等。 2. **容器概念**:Tomcat中的Container接口及其实现,如Engine、Host、Context和Wrapper,它们如何组织和...
- **生命周期管理**: 源码中每个组件都有其生命周期,包括初始化、启动、停止和销毁等阶段,这使得Tomcat能够优雅地处理应用的加载和卸载。 3. **请求处理流程** - **接收到请求**: Connector接收HTTP请求,解析...
- 了解`Catalina`的启动流程,包括加载配置、初始化容器等。 - 理解`Connector`如何接收和解析HTTP请求,以及如何构造响应。 - 探究JSP到Servlet的编译过程,包括`Jasper`的工作原理。 - 学习`Context`和`...