tomcat处理一个请求的过程

首先，tomcat是一个基于组件的服务器，它的构成组件都是可配置的，可以在tomcat目录下conf/server.xml中进行配置。其配置文件结构如下：

<Server>顶层类元素：一个配置文件中只能有一个<Server>元素，可包含多个Service。
    <Service>顶层类元素：本身不是容器，可包含一个Engine，多个Connector。
        <Connector/>连接器类元素：代表通信接口。
        <Engine>容器类元素：为特定的Service组件处理所有客户请求，可包含多个Host。engine为顶层Container
           <Host>容器类元素：为特定的虚拟主机处理所有客户请求，可包含多个Context。
              <Context>容器类元素：为特定的Web应用处理所有客户请求。代表一个应用，包含多个Wrapper（封装了servlet）
              </Context>
           </Host>
        </Engine>
     </Service>
</Server>

tomcat是基于组件的，分层避不可免，对于一个请求的处理，tomcat的链式调用比较长，让我们从接收请求开始说起。

tomcat处理socket请求的IO模型有BIO、NIO、AIO等，后两者IO模型比较复杂，而本文的主要关注点不在这，因此将tomcat配置成BIO模式。

tomcat接收请求的代码在Acceptor类中：

/**
 * The background thread that listens for incoming TCP/IP connections and
 * hands them off to an appropriate processor.
 * JIoEndpoint 的内部类
 */
protected class Acceptor extends AbstractEndpoint.Acceptor {
    @Override
    public void run() {
        // Loop until we receive a shutdown command
        while (running) {
            //if we have reached max connections, wait
            countUpOrAwaitConnection();

            Socket socket = null;
            //阻塞住 监听新的socket请求
            socket = serverSocketFactory.acceptSocket(serverSocket);

            // Configure the socket
            if (running && !paused && setSocketOptions(socket)) {
                // Hand this socket off to an appropriate processor 首先使用processSocket()简单处理socket
                if (!processSocket(socket)) {
                    countDownConnection();
                    // Close socket right away
                    closeSocket(socket);
                }
            } else {
                countDownConnection();
                // Close socket right away
                closeSocket(socket);
            }

        }
    }
}

Acceptor 继承了 AbstractEndpoint.Acceptor ，间接实现了Runnable接口，tomcat在运行时将Acceptor运行在一个后台线程内，单独监听socket请求，此线程的调用栈如下：

processSocket()方法如下：

/**
 * Process a new connection from a new client. Wraps the socket so
 * keep-alive and other attributes can be tracked and then passes the socket
 * to the executor for processing.
 */
protected boolean processSocket(Socket socket) {
    // Process the request from this socket
    SocketWrapper<Socket> wrapper = new SocketWrapper<Socket>(socket);
    wrapper.setKeepAliveLeft(getMaxKeepAliveRequests());
    wrapper.setSecure(isSSLEnabled());
    // During shutdown, executor may be null - avoid NPE
    if (!running) {
        return false;
    }
    getExecutor().execute(new SocketProcessor(wrapper));
    return true;
}

processSocket方法主要工作为将socket请求信息进行封装，然后将一个实现了Runnable接口的并包含socket信息的SocketProcessor对象交给线程池，进行执行，然后Acceptor线程从该方法返回，重新监听端口上的socket请求。

线程池receive到该worker后，取出一个线程处理socket请求，其调用栈如下：

调用栈底部的processor和handler主要处理TCP和HTTP协议的一些细节，CoyoteAdapter实现了对request输入流的编解码工作，并从service中获取顶层Container，将request和response交与容器组件，关键代码如下：

connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);

其中，在每一层容器中对请求的处理都运用了责任链模式，即所谓的Pipeline-Value处理模式，pipeline就像一个管道，表示对请求的链式处理过程，其中包含多个value，每个value代表对请求的一次处理，处理完成之后交给next Value进行处理，每层容器都至少有一个Value，这个Value被成为BaseValue，在pipeline中位于最后一个位置，比如Engine容器的BaseValue为StandardEngineValue。每一层的BaseValue会调用下一层容器的pipeline的第一个Value，由此形成一个长链：

到达pipeline长链最后一个value StandardWrapperValue后，会触发另外一个责任链模式：filterChain责任链，也就是我们平常熟悉的在web项目中配置的filter被调用的位置。

StandardWrapperValue调用filterChain代码如下：

//StandardWrapperValue类

public final void invoke(Request request, Response response){
    ...
    // Create the filter chain for this request
    ApplicationFilterFactory factory =
        ApplicationFilterFactory.getInstance();
    ApplicationFilterChain filterChain =
        factory.createFilterChain(request, wrapper, servlet);
    ...
    //开始调用filterChain
    filterChain.doFilter(request.getRequest(), response.getResponse());
    ...
}

ApplicationFilterFactory.getInstance()方法如下：

/**
 * Return the factory instance.
 */
//ApplicationFilterFactory类
public static ApplicationFilterFactory getInstance() {
    if (factory == null) {
        factory = new ApplicationFilterFactory();
    }
    return factory;
}

看到这个单例方法我有点蒙，这不明摆着存在竞态条件么，完全线程不安全的单例工厂 - - ，源码为tomcat7.0，难道这样没问题？

createFilterChain创建filterChain的代码如下：

//ApplicationFilterChain类

public ApplicationFilterChain createFilterChain
        (ServletRequest request, Wrapper wrapper, Servlet servlet) {
     ApplicationFilterChain filterChain = null;
     ...
     filterChain = new ApplicationFilterChain();
     ...
     filterChain.setServlet(servlet);
     ...
     // Acquire the filter mappings for this Context
     StandardContext context = (StandardContext) wrapper.getParent();
     FilterMap filterMaps[] = context.findFilterMaps();

     // If there are no filter mappings, we are done
     if ((filterMaps == null) || (filterMaps.length == 0))
         return (filterChain);

     // Acquire the information we will need to match filter mappings
    String servletName = wrapper.getName();

    // Add the relevant path-mapped filters to this filter chain 根据请求url找到对应的filter指针，添加进来
    for (int i = 0; i < filterMaps.length; i++) {
        if (!matchDispatcher(filterMaps[i] ,dispatcher)) {
            continue;
        }
        if (!matchFiltersURL(filterMaps[i], requestPath))
            continue;
        ApplicationFilterConfig filterConfig = (ApplicationFilterConfig)
            context.findFilterConfig(filterMaps[i].getFilterName());
        if (filterConfig == null) {
            // FIXME - log configuration problem
            continue;
        }
        ...
        filterChain.addFilter(filterConfig);
    }

    // Add filters that match on servlet name second
    //如果配置了根据servlet名称过滤，则再寻找一遍filter
    for (int i = 0; i < filterMaps.length; i++) {
        if (!matchDispatcher(filterMaps[i] ,dispatcher)) {
            continue;
        }
        if (!matchFiltersServlet(filterMaps[i], servletName))
            continue;
        ApplicationFilterConfig filterConfig = (ApplicationFilterConfig)
            context.findFilterConfig(filterMaps[i].getFilterName());
        if (filterConfig == null) {
            // FIXME - log configuration problem
            continue;
        }
        ...
        //addFilter时会对filter指针排重
        filterChain.addFilter(filterConfig);
    }

    // Return the completed filter chain
    return (filterChain);
}

创建filterChain代码比较简单，首先创建一个FilterChain对象，然后把url对应的servlet放进去，相当于pipeline-value模式中的最后一个BaseValue。之后从ServletContext中拿出所有的filter，然后根据url和servlet name找到符合条件的filter，根据顺序组装到filterChain中。

可能看到这里有些人会想，为什么要为每次请求都创建一个新的FilterChain对象呢，这显得有些不合常理，因为对于tomcat的大部分组件、filter、servlet都是单例的，而且频繁new操作有些消耗资源吧。确实是这样的，但这里将FilterChain做成prototype是有原因的，因为对于每个url，对应的filter个数都是不固定的，filterchain需要保存每个请求所对应的一个filter数组，以及调用到的filter的position，以便继续向下调用filter。这里的filter不能像pipeline-value模式那样组装起来，而是依靠filterChain来决定每个url的调用顺序。

创建完filterchain后，StandardWrapperValue就开始调用filterChain的doFilter方法了：

//ApplicationFilterChain类
public void doFilter(ServletRequest request, ServletResponse response){
...
    internalDoFilter(request,response);
...
}

private void internalDoFilter(ServletRequest request, 
                                  ServletResponse response){
    ...
    // Call the next filter if there is one
    if (pos < n) {
        ApplicationFilterConfig filterConfig = filters[pos++];
        Filter filter = null;
        filter = filterConfig.getFilter();
        filter.doFilter(request, response, this);
        return;
    }

    ...

    // We fell off the end of the chain -- call the servlet instance
    servlet.service(request, response);
    ...
}

pos为filterchain对象内的一个变量，用来标记当前调用的filter的位置，filter.doFilter(request, response, this)，这句代码即调用咱们的filter了，记不记得咱们自己写filter时，如果不直接close outputstream，都会在doFilter最后写一句：filterChain.doFilter(req,res)来回调filterChain,让它继续调用接下来的filter。

在pos == n （filter数组长度）时，也就是filter调用完了，servlet.service(request, response)这一句便是调用我们的servlet了。我们的servlet在处理完请求后，再一步一步按原路返回，将处理结果通过socket写回客户端。

至此，一个请求就被tomcat处理完了。