Tomcat源码和架构深入分析
背景
最近跟着前辈学习了Tomcat源码。记录一下分析过程和tomcat的架构设计思想。
环境准备
idea
java sdk
tomcat源码下载:https://github.com/apache/tomcat.git
git下载失败可以换码云:https://gitee.com/mirrors/tomcat
源码目录结构
├── bin 启动和关闭tomcat的脚本
├── conf 服务器的各种配置文件
├── java 源码目录
├── modules jdbc包
├── res ?
├── test 单元测试
└── webapps 应用程序目录
idea配置源码调试环境
1 idea配置
- 下载源码后用idea打开,设置源码目录为java
- image.png
- 配置启动类,jre我用的13,大家选择自己安装的版本即可
- image.png
-
idea项目根目录添加pom.xml,工程设置添加maven依赖
主要是依赖的一些第三方库,我这里给一个我的pom.xml的依赖配置供参考
如果不知道maven的pom文件怎么写,建议去参考一下其他教程,这里不扩展了。<dependencies> <dependency> <groupId>ant</groupId> <artifactId>ant</artifactId> <version>1.7.0</version> </dependency> <dependency> <groupId>ant</groupId> <artifactId>ant-apache-log4j</artifactId> <version>1.6.5</version> </dependency> <dependency> <groupId>ant</groupId> <artifactId>ant-commons-logging</artifactId> <version>1.6.5</version> </dependency> <dependency> <groupId>wsdl4j</groupId> <artifactId>wsdl4j</artifactId> <version>1.6.2</version> </dependency> <dependency> <groupId>javax.xml.rpc</groupId> <artifactId>javax.xml.rpc-api</artifactId> <version>1.1</version> </dependency> <dependency> <groupId>org.eclipse.jdt.core.compiler</groupId> <artifactId>ecj</artifactId> <version>4.6.1</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> <dependency> <groupId>org.easymock</groupId> <artifactId>easymock</artifactId> <version>RELEASE</version> <scope>test</scope> </dependency> </dependencies>
-
现在开始运行,发现还有一些错误
是一些源码无关的测试,example代码引起的,继续解决 -
错误提示: trailers.ResponseTrailers不存在
解决方式: webapps/examples/WEB_INF/classes/trailers 目录下找到该类,复制一份到test。 -
错误提示:CookieFilter不存在
解决方式和上面类似,全局搜索到CookieFilter,拷贝到test/util,报错找不到的位置 -
错误提示:java.lang.ClassNotFoundException: listeners.ContextListener
解决方法,暴力一点,直接删除, 删除 webapps 下的 examples 文件夹!程序再次运行不报此错误,对的,就是整个目录删掉。 -
这个时候已经可以运行了,但是启动后,浏览器输入127.0.0.1:8080,会报服务器错误500
解决方式: org.apache.catalina.startup.ContextConfig 文件的 configureStart() 方法,添加初始化 JSP 解析器的代码
context.addServletContainerInitializer(new JasperInitializer(), null);
添加位置:
- image.png
至此,源码调试环境配置完成
2 为什么启动类是org.apache.catalina.startup.Bootstrap
前面应该看到我们配置启动类位置:org.apache.catalina.startup.Bootstrap,找到入口这个很关键,后续看源码也是从这个入口出发。如何找到这个入口呢?
- 工程下找到 /bin/start.sh
--> 可以发现最终执行的 catalina.sh start
找到 catalina.sh start 逻辑
eval $_NOHUP "\"$_RUNJAVA\"" "\"$LOGGING_CONFIG\"" $LOGGING_MANAGER $JAVA_OPTS $CATALINA_OPTS \
-D$ENDORSED_PROP="\"$JAVA_ENDORSED_DIRS\"" \
-classpath "\"$CLASSPATH\"" \
-Dcatalina.base="\"$CATALINA_BASE\"" \
-Dcatalina.home="\"$CATALINA_HOME\"" \
-Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
org.apache.catalina.startup.Bootstrap "$@" start \
>> "$CATALINA_OUT" 2>&1 "&"
核心是:org.apache.catalina.startup.Bootstrap
源码找到:Bootstrap 其中的main方法,就是启动入口。这里有个入参"start",其实没有这个参数,tomcat启动也会设置默认入参数 start
Tomcat 架构
tomcat是一个web应用服务器,核心是两部分:
-
Http服务,其实是一个Connector(Coyote)
image.png -
Servlet容器(Catalina)
源码中设计的Coyote和Catalina两个关键字分别对应这里的两个模块,后续不再解释了。
核心代码解读
下面进入核心代码的阅读
LifeCycle
-
为了统一管理,抽象出LifeCycle接口
-
源码中作者自己用字符画了一张生命周期的示意图,牛逼!!!
- image.png
-
LifeCycle主要的构成
- 生命周期接口:init(),start(),stop(), destroy()
- 事件名:BEFORE_INIT_EVENT等等
- 其他接口:
- public void addLifecycleListener(LifecycleListener listener);
-
public LifecycleState getState();
通过idea的Structure工具,能比较清晰的看出类结构
image.png
如果需要查看类层级图,mac idea下的快捷键是
ctrl + h
网上有教程说在 idea->navigate->call hierachy中,奈何我这个idea版本上一直灰显,还好找到了快捷键。层级图基本和项目的架构对应,容器啊,service这些,这里不深究了,只要知道基本整个容器和服务都继承了LifeCycle即可,继续往下。
image.png
启动流程分析:初始化init()
- 前面已经分析过了,启动入口在Bootstrap的main方法中
main方法中有个默认的启动参数是“start”
顺着这个逻辑我们先直接到关键代码行
else if (command.equals("start")) {
daemon.setAwait(true);
daemon.load(args);
daemon.start();
if (null == daemon.getServer()) {
System.exit(1);
}
- 其中daemon.load(args);就是我们要关心的核心代码
- 跳转到load
private void load(String[] arguments)
throws Exception {
// Call the load() method
String methodName = "load";
Object param[];
Class<?> paramTypes[];
if (arguments==null || arguments.length==0) {
paramTypes = null;
param = null;
} else {
paramTypes = new Class[1];
paramTypes[0] = arguments.getClass();
param = new Object[1];
param[0] = arguments;
}
// 通过反射获取方法并且执行
// catalinaDaemon的config file来自 conf/server.xml
Method method =
catalinaDaemon.getClass().getMethod(methodName, paramTypes);
if (log.isDebugEnabled())
log.debug("Calling startup class " + method);
method.invoke(catalinaDaemon, param);
}
然后进入Catalina.java找到这个load()方法
其中初始化的核心代码是:
getServer().init();
这里的getServer用debug模式看到是StandardServer,其继承关系如下:
其init()方法的逻辑在LifecycleBase中
@Override
public final synchronized void init() throws LifecycleException {
if (!state.equals(LifecycleState.NEW)) {
invalidTransition(Lifecycle.BEFORE_INIT_EVENT);
}
try {
setStateInternal(LifecycleState.INITIALIZING, null, false);
initInternal();
setStateInternal(LifecycleState.INITIALIZED, null, false);
} catch (Throwable t) {
handleSubClassException(t, "lifecycleBase.initFail", toString());
}
}
其中initInternal();用的是设计模式的“模版模式”,即基类中定义流程,然后具体的实现类中实现initInternal();从StanderServer的initInternal中出发,我们大致可以看到如下图所示的实例化过程。
就是依次调用子类的initInternal(),完成初始化。
初始化完成之后是start()流程
-
方式方法大致同init(),这里就不一步步debug了。注意几个核心点即可
- 找到入口
还是前前面的Bootstrap的main方法,load之后就是
同样是通过反射执行StandardServer的start方法,也就是Catalina.java中的start方法daemon.start();
其核心是:
后续就和init很类似了getServer().start();
- 找到入口
-
容器启动过程大致就是init(),start(),启动之后如何处理http请求呢。接下俩看servlet请求处理的过程。
Servlet请求链路源码
前置知识:
- 前面start过程中,默认启动的是nio,selector多路复用channel
- acceptor线程用来注册selector,poller线程检查selector线程中哪些channel中有数据
-
所以核心处理的入口在Poller这个线程中。关联的类是NioEndpoint.java就从这个类开始分析。
前面已经配置好了调试环境,点击页面这个按钮,可以出发一条请求,但是因为前面删掉了一些文件,所以虽然可以构建请求,但是最后的返回有错误,只是不影响我们阅读源码流程
image.png
NioEndpoint
- start()过程模版方法调用的执行方法是startInternal() ,其核心代码在最后
注册Poller和启动Acceptor
// Start poller threads
pollers = new Poller[getPollerThreadCount()];
for (int i=0; i<pollers.length; i++) {
pollers[i] = new Poller();
Thread pollerThread = new Thread(pollers[i], getName() + "-ClientPoller-"+i);
pollerThread.setPriority(threadPriority);
pollerThread.setDaemon(true);
pollerThread.start();
}
startAcceptorThreads();
- 其中Poller继承自Runnable,说明是一个线程程序,实现逻辑在run方法
Poller初始化:注册一个nioselector
public Poller() throws IOException {
this.selector = Selector.open();
}
run中 while(True)的大循环中等待selector中事件就绪,然后开始处理
while (true) {
boolean hasEvents = false;
try {
if (!close) {
hasEvents = events();
if (wakeupCounter.getAndSet(-1) > 0) {
//if we are here, means we have other stuff to do
//有请求需要处理了
keyCount = selector.selectNow();
} else {
keyCount = selector.select(selectorTimeout);
}
wakeupCounter.set(0);
}
// ***省略若干
// keyCount>0 开始处理
Iterator<SelectionKey> iterator =
keyCount > 0 ? selector.selectedKeys().iterator() : null;
}
while (iterator != null && iterator.hasNext()) {
SelectionKey sk = iterator.next();
NioSocketWrapper attachment = (NioSocketWrapper)sk.attachment();
// Attachment may be null if another thread has called
// cancelledKey()
if (attachment == null) {
iterator.remove();
} else {
// 先删除后处理
iterator.remove();
processKey(sk, attachment); // 处理的核心
}
}//while
然后看processKey(),其中两个逻辑分支,分别是读和写,
if (sk.isReadable() || sk.isWritable() )
处理逻辑是processSocket()
其核心是
SocketProcessorBase<S> sc = processorCache.pop();
if (sc == null) {
// 创建线程,处理socketWrapper
sc = createSocketProcessor(socketWrapper, event);
} else {
sc.reset(socketWrapper, event);
}
// *** 省略若干
executor.execute(sc);
可以知道sc是一个线程,交给线程池executor去执行
既然sc是线程,那么找到核心的run方法。
@Override
public final void run() {
synchronized (socketWrapper) {
if (socketWrapper.isClosed()) {
return;
}
doRun();
}
}
这里和前面一样,是模版方法,debug发现真实执行的是
Endpoint中的doRun方法。
@Override
protected void doRun() {
NioChannel socket = socketWrapper.getSocket();
SelectionKey key = socket.getIOChannel().keyFor(socket.getPoller().getSelector());
try {
// *** 省略若干,判断握手状态,handshake == 0就是握手没有问题
if (handshake == 0) {
SocketState state = SocketState.OPEN;
// Process the request from this socket
if (event == null) {
state = getHandler().process(socketWrapper, SocketEvent.OPEN_READ);
} else {
// process执行处理
state = getHandler().process(socketWrapper, event);
}
// *** 省略若干代码
}
}
}
走进process方法在AbstractProtocol.java,其中的process方法
其中核心是找到一个能处理的processor
// ** 省略若干
Processor processor = connections.get(socket);
// *** 省略若干,创建过还没有被销毁的
if (processor == null) {
processor = recycledProcessors.pop();
}
// ** 省略若干,还为空,就创建新的
if (processor == null) {
processor = getProtocol().createProcessor();
register(processor);
}
// ** 省略若干代码
do {
// 找到了之后开始处理,processor默认是Http11Processor
state = processor.process(wrapper, status);
// ** 省略若干代码
}while ( state == SocketState.UPGRADING);
找到process方法,核心代码如下,这里又是模版模式
if (state == SocketState.OPEN) {
state = service(socketWrapper);
}
在具体的Http11Processor中,又service方法的实现。
这里是一个核心方法,代码很多,这里不贴了,描述一下这里的功能:
- 解析http报文
- 封装request和response
- response是初始化结构,还没有response数据
- getAdapter将数据转换成servlet容器可用的数据格式(这里获取的Adapter是CoyoteAdapter)
getAdapter().service(request, response);
然后进入CoyoteAdapter的service方法
public void service(org.apache.coyote.Request req, org.apache.coyote.Response res)
throws Exception {
// *** 省略若干
}
可以看到入参是两个coyote包下的Request和Response,就是原生request,response适配后的request和response
其中核心处理方法是:
// 找到能够处理请求的servlet
postParseSuccess = postParseRequest(req, request, res, response);
if (postParseSuccess) {
//check valves if we support async
request.setAsyncSupported(
connector.getService().getContainer().getPipeline().isAsyncSupported());
// Calling the container
connector.getService().getContainer().getPipeline().getFirst().invoke(
request, response);
}
这里用到了Mapper机制,封装了Host,Context,wrapper(servlet)之前的数据和关系
上述方法进入之后
上述的invoke方法debug模式下跳转到
StandardEngineValue中的invoke方法。
然后跳转到
AbstractAccessLogValve的invoke方法
然后跳转到
ErrorReportValue中的invoke方法
然后跳转到
StanderHostValve的invoke方法
这里是 找到一个合适的Context处理request 如果没有找到合适的Context就会报错
(这里吐槽一下,找到这个真实的处理方法跳转次数也太多了,以目前的境界还不能理解这种设计的好处)
找到context之后
if (!response.isErrorReportRequired()) {
context.getPipeline().getFirst().invoke(request, response);
}
又是一组context,有种预感,又要一层层往下拨开,找到真正的invoke
在StandardContextValve中
接下来又是一个invoke嵌套的过程,
StandardWrapperValve找到的invoke中,才真正初始化一个
// ** 省略若干代码
servlet = wrapper.allocate();
// ** 省略若干代码
// 创建一个链
ApplicationFilterChain filterChain =
ApplicationFilterFactory.createFilterChain(request, wrapper, servlet);
// ** 省略若干代码
filterChain.doFilter(request.getRequest(),
response.getResponse());
跳转进入之后找到执行方法internalDoFilter()
其中核心执行逻辑 servlet.service(request, response);
这里就是servlet请求真实被执行的地方。
我们调试的这个例子,就会进入:
JspServlet.java中的service方法,继续往下看,还有很多servlet的执行细节,这里不继续往下了。