首先我们需要了解两个重要的知识点:一个是tomcat容器的总体结构, 一个是lifecycle接口
tomcat容器的结构示意图如下:
它是一种层层包裹的结构类型,最外层是Server
然后Service里面有三大组件: Connector(处理外部网络请求), Executor(线程池)和Engine(tomcat容器)
然后Engine又是层层包裹结构: 最外层Engine=>Host>Context=>Wrapper(Servlet)。当Tomcat启动的时候,这些组件也要跟着一起启动,并且当Tomcat关闭的时候,这些组件也要同时关闭,并且要进行必要的清理操作
Lifecycle接口是所有tomcat组件的最顶层的接口,负责管理所有组件的生命周期。
它是通过观察者模式和模板方法来实现的,具体后面会讲
Lifecycle接口的最大的作用:统一各个组件的状态,因为我们看到tomcat组件是嵌套关系,如果外层组件已经启动,而内层组件却启动失败,那么这种状态就是有问题的,我们需要一种有效的触发机制,保证:从父级到子级的整个链条都能准确传导,动作保持一致,也就是:
当Tomcat启动的时候,这些组件也要跟着一起启动,并且当Tomcat关闭的时候,这些组件也要同时关闭,并且要进行必要的清理操作
然后我们从tomcat源码开始分析它的启动过程:
tomcat的启动类是org.apache.catalina.startup.Bootstrap,
Bootstrap的main方法主要是完成catalina对象的初始化和启动。
public void init() throws Exception {
initClassLoaders();
Thread.currentThread().setContextClassLoader(catalinaLoader);
SecurityClassLoad.securityClassLoad(catalinaLoader);
// Load our startup class and call its process() method
if (log.isDebugEnabled()) {
log.debug("Loading startup class");
}
// 通过反射加载Catalina类并进行实例化
Class<?> startupClass = catalinaLoader.loadClass("org.apache.catalina.startup.Catalina");
Object startupInstance = startupClass.getConstructor().newInstance();
// Set the shared extensions class loader
if (log.isDebugEnabled()) {
log.debug("Setting startup class properties");
}
String methodName = "setParentClassLoader";
Class<?> paramTypes[] = new Class[1];
paramTypes[0] = Class.forName("java.lang.ClassLoader");
Object paramValues[] = new Object[1];
paramValues[0] = sharedLoader;
Method method =
startupInstance.getClass().getMethod(methodName, paramTypes);
method.invoke(startupInstance, paramValues);
// 完成catalina对象的初始化
catalinaDaemon = startupInstance;
}
从init方法的代码段可以看到init方法完成了catalina对象的初始化,然后回到bootStrap的main方法: 这里就开始启动catalina了:
上面就是通过反射启动了catalina。
然后我们看看catalina启动start方法又干了什么:
org.apache.catalina.startup.Catalina 类名
注意:getServer().start()方法就是获取tomcat server,并且将它启动。
然后下面就重点的重点了,前面提到Lifecycle是tomcat所有组件的最顶层接口,那么也就是说
tomcat组件中的:StandardServer, StandardService,ContainerBase,StandardEngine StandardContext 等组件全部都会实现Lifecycle接口,可以说Lifecycle是所有tomcat组件的大总管:管理了这些组件从初始化,创建,销毁的所有生命周期,以及对这些组件的监听、事件发布、消息传递以及状态的更新。
然后继续回到源码:
getServer方法返回的Server实际继承了Lifecycle接口,换句话说Server也是接口,
那么我们进去看看Server接口的实现类是什么?
可以看到Server的唯一实现类是StandardServer。
然后我们继续从上面的getServer().start()方法往下走,发现会跳到Lifecycle的start方法。
然后这个start方法的实现类是LifecycleBase
注意了:LifecycleBase是Lifecycle的实现类,而且是一个抽象类,这是整个Tomcat组件中影响最重要的一个类,因为这里定义了通用的模板方法设计,而且会被组件反复调用
然后我们看看LifecycleBase的start方法:
这个里面最重要的方法是startInternal方法,然后点进去看看:
然后startInternal方法又会跳回到Lifecycle接口,注意到startInternal方法是一个抽象方法,这是典型的模板方法设计模式, 也就是他的子类必须重写该方法,此时我们应该选择哪一个实现类呢?因为实现类下面有很多选项。前面的getServer已经提到上面执行的实际是StandardServer的start方法,所以这里应该选择StandardServer作为startInternal方法的实现类。
这里可以看到:startInternal方法会遍历service集合,然后执行service的start方法。
那么Service又是什么类型?
Service是一个继承了Lifecycle的子接口,而StardardService是Service的唯一实现类
然后仍然回到上面StandardServer中startInternal方法中的 service的start方法。这里会跟前面一样:先进入到LifecycleBase的start方法,然后接着进入到LifecycleBase的start方法:
LifecycleBase的start方法仍然重点看startInternal方法
startInternal方法是实现类选择StandardService,因为上面方法的执行源头是service.start,而service实际就是StandardService.
从上面可以看到:组件的start方法=》 Lifecycle的start方法=》LifecycleBase的start方法=》 实现类(组件)的 startInternal方法
这一段逻辑会反复被调用,这就是典型的模板方法设计。
然后进入StandardService的startInternal方法,这里我们重点看它做的两件事:
1. 启动servlet容器(容器的最外层:Engine)
2. 启动线程池
我们重点看看servlet容器部分,也就是engine,Engine是servlet的顶层容器
Engine是一个接口,它的继承关系如下:
Engine=> Container=>Lifecycle
而StandardEngine是Engine的唯一实现类,
所以可以推断上面的engine.start方法必然还是和前面一样的套路:=》 Lifecycle的start方法=》LifecycleBase的start方法=》 StandardEngine的 startInternal方法
所以我们跳过这些重复的模板方法,直接进入StandardEngine的 startInternal方法:
然后这里又会执行它父级ContainerBase的startInternal方法:
这里重点看一下findChildren方法:
从这里我们可以推断findChildren是找到Engine底下所有的嵌套容器:包括Host,Context, Wrapper等,因为Children是一个HashMap,key是容器名,而它的value就是容器实例。
然后回到前面的代码段,继续跟着findChildren方法,可以发现:这里会遍历四层嵌套容器,并通过线程池启动他们的start方法
// Start our child containers, if any
Container children[] = findChildren();
List<Future<Void>> results = new ArrayList<>();
for (Container child : children) {
// 遍历四层嵌套容器,并通过线程池启动他们的start方法
results.add(startStopExecutor.submit(new StartChild(child)));
}
我们可以看到StartChild是一个Callable函数式接口的实现类,构造器参数就是Container实例,并重写了call方法,在该方法里面执行container容器的start方法。
而从Container的层级关系可以看到:Container包括了Host,Context, Wrapper这些嵌套容器
所以上面的那个for循环最终也会启动Wrapper的start方法,Wrapper也就是Servlet容器
而StardardWrapper就是Wrapper的实现类,从上图可以看到:它确实就是定义了一个servlet容器
但是Wrapper是由它父级容器Context启动的,所以从加载的因果关系来看:我们应该先看看Context的实现类StandardContext的start方法:
而它的start方法必然还是和前面一样的套路:=》 Lifecycle的start方法=》LifecycleBase的start方法=》 StandardContext的 startInternal方法
所以我们跳过这些重复的模板方法,直接进入StandardContext的 startInternal方法:
这个方法代码很长,我们重点进入下面代码段的loadOnStartup方法
进入到loadOnStartup方法后,最重要的方法来了: wrapper.load方法,这个方法就是加载servlet容器
可以看到:上面的wrapper.load方法实际执行的是它的实现类StandardWrapper的load方法,最终我们定位到了初始化servlet的代码: initServlet
而initServlet方法会调用servlet的init方法
至此tomcat源码从启动流程到跟踪servlet初始化的整个分析过程已经全部完成。