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()，完成初始化。

image.png

初始化完成之后是start()流程

方式方法大致同init()，这里就不一步步debug了。注意几个核心点即可
- 找到入口
  还是前前面的Bootstrap的main方法，load之后就是
```
 daemon.start();
```
  同样是通过反射执行StandardServer的start方法，也就是Catalina.java中的start方法
  其核心是：
```
getServer().start(); 
```
  后续就和init很类似了
容器启动过程大致就是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的执行细节，这里不继续往下了。