背景
最近跟着前辈学习了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()，完成初始化。
image.png
初始化完成之后是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的执行细节，这里不继续往下了。
网友评论