tomcat源码分析-http请求在Container中的执行路线


声明:本文转载自https://my.oschina.net/javahongxi/blog/1555897,转载目的在于传递更多信息,仅供学习交流之用。如有侵权行为,请联系我,我会及时删除。

    在CoyoteAdapter的service方法中,主要干了2件事:

    1. org.apache.coyote.Request -> org.apache.catalina.connector.Request extends HttpServletRequest

        org.apache.coyote.Response -> org.apache.catalina.connector. Response extends HttpServletResponse

        Context和Wrapper定位

    2. 将请求交给StandardEngineValue处理

 

public void service(org.apache.coyote.Request req,                          org.apache.coyote.Response res) {      //      postParseSuccess = postParseRequest(req, request, res, response);      //      connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);      //  }

postParseRequest方法的代码片段

  

connector.getMapper().map(serverName, decodedURI, version,                                        request.getMappingData());  request.setContext((Context) request.getMappingData().context);  request.setWrapper((Wrapper) request.getMappingData().wrapper);

request通过URI的信息找到属于自己的Context和Wrapper。而这个Mapper保存了所有的容器信息,不记得的同学可以回到Connector的startInternal方法中,最有一行代码是mapperListener.start()。在MapperListener的start()方法中,

  

public void startInternal() throws LifecycleException {        setState(LifecycleState.STARTING);      findDefaultHost();        Engine engine = (Engine) connector.getService().getContainer();      addListeners(engine);        Container[] conHosts = engine.findChildren();      for (Container conHost : conHosts) {          Host host = (Host) conHost;          if (!LifecycleState.NEW.equals(host.getState())) {              registerHost(host);          }      }  }

在容器初始化和变化时都会触发监听事件,从而将所有容器信息保存在Mapper中。之所以叫Mapper,因为它的主要作用就是定位Wrapper,而我们在web.xml里也配了filter/servlet-mapping。

 

    另外,由上面的代码可知,在随后的请求路线中,Engine可有Connector获取,Context和Wrapper可直接由Request获取,Host也可由Request获取。

public Host getHost() { return ((Host) mappingData.host); }

 

    上面的代码中还涉及到了两个很重要的概念--Pipeline和Value,我们不妨先一睹Container的调用链和时序图。




 
     对于每个引入的http请求,连接器都会调用与其关联的servlet容器所绑定的一系列阀门(Value)的invoke方法,基础阀门(StandardXxValue)都在尾端,然后会逐步调用子容器的阀门。为什么必须要有一个Host容器呢?

    在tomcat的实际部署中,若一个Context实例使用ContextConfig对象进行设置,就必须使用一个Host对象,原因如下:

    使用ContextConfig对象需要知道应用程序web.xml文件的位置,在其webConfig()方法中会解析web.xml文件

 

// Parse context level web.xml          InputSource contextWebXml = getContextWebXmlSource();          parseWebXml(contextWebXml, webXml, false);

 

在getContextWebXmlSource方法里

// servletContext即core包下的ApplicationContext  url = servletContext.getResource(Constants.ApplicationWebXml);

 

在getResource方法里

String hostName = context.getParent().getName();

 因此,除非你自己实现一个ContextConfig类,否则,你必须使用一个Host容器。

 

    管道(Pipeline)包含该servlet容器将要调用的任务。一个阀(Value)表示一个具体的执行任务。在servlet容器的管道中,有一个基础阀,但是,可以添加任意数量的阀。阀的数量指的是额外添加的阀数量,即不包括基础阀。有意思的是,可以通过server.xml来动态添加阀。

    管道和阀的工作机制类似于servlet编程中的过滤器链和过滤器,tomcat的设计者采用的是链表数据结构来实现的链条机制,引入了一个类叫ValueContext。值得注意的是,基础阀总是最后执行。

    请求最终会被引导到StandardWrapper,本人也是首先从Wrapper这一层来入手Container的,直接看StandardWrapperValue的invoke方法

 

@Override  public final void invoke(Request request, Response response) {      //        requestCount++;      StandardWrapper wrapper = (StandardWrapper) getContainer();      Servlet servlet = null;      Context context = (Context) wrapper.getParent();        //        // Allocate a servlet instance to process this request      try {         if (!unavailable) {            servlet = wrapper.allocate();         }      } catch (Exception e) {}        //        // Create the filter chain for this request      ApplicationFilterFactory factory =              ApplicationFilterFactory.getInstance();      ApplicationFilterChain filterChain =              factory.createFilterChain(request, wrapper, servlet);        //        // Call the filter chain for this request      // NOTE: This also calls the servlet's service() method      //      filterChain.doFilter(request.getRequest(), response.getResponse());      //        // Release the filter chain (if any) for this request      if (filterChain != null) filterChain.release();        // Deallocate the allocated servlet instance      if (servlet != null) wrapper.deallocate(servlet);    // If this servlet has been marked permanently unavailable,          // unload it and release this instance          try {              if ((servlet != null) &&                  (wrapper.getAvailable() == Long.MAX_VALUE)) {                  wrapper.unload();              }          } catch (Throwable e) { }        //  }

 

上面代码中最重要的三处逻辑就是servlet实例的获取与卸载和filter链调用。我们先看卸载servlet实例的代码

@Override      public void deallocate(Servlet servlet) throws ServletException {            // If not SingleThreadModel, no action is required          if (!singleThreadModel) {              countAllocated.decrementAndGet();              return;          }            // Unlock and free this instance          synchronized (instancePool) {              countAllocated.decrementAndGet();              instancePool.push(servlet);              instancePool.notify();          }        }

 

我们不考虑SingleThreadModel模型,因为较新版本的tomcat已经不用这种模型了(只有很老的版本才用),显然,通过上面的代码可以知道,基本上什么都不用做,而Single Thread Model常用的是池化模型(maxInstances=20)。下面给出加载servlet实例的代码

@Override  public Servlet allocate() throws ServletException {        boolean newInstance = false;            // If not SingleThreadedModel, return the same instance every time          if (!singleThreadModel) {              // Load and initialize our instance if necessary              if (instance == null || !instanceInitialized) {                  synchronized (this) {                      if (instance == null) {                          try {                              if (log.isDebugEnabled()) {                                  log.debug("Allocating non-STM instance");                              }                                // Note: We don't know if the Servlet implements                              // SingleThreadModel until we have loaded it.                              instance = loadServlet();                              newInstance = true;                              if (!singleThreadModel) {                                  // For non-STM, increment here to prevent a race                                  // condition with unload. Bug 43683, test case                                  // #3                                  countAllocated.incrementAndGet();                              }                          } catch (ServletException e) {                              throw e;                          } catch (Throwable e) {                              ExceptionUtils.handleThrowable(e);                              throw new ServletException(sm.getString("standardWrapper.allocate"), e);                          }                      }                      if (!instanceInitialized) {                          initServlet(instance);                      }                  }              }                if (singleThreadModel) {                  if (newInstance) {                      // Have to do this outside of the sync above to prevent a                      // possible deadlock                      synchronized (instancePool) {                          instancePool.push(instance);                          nInstances++;                      }                  }              } else {                  if (log.isTraceEnabled()) {                      log.trace("  Returning non-STM instance");                  }                  // For new instances, count will have been incremented at the                  // time of creation                  if (!newInstance) {                      countAllocated.incrementAndGet();                  }                  return instance;              }          }            synchronized (instancePool) {              while (countAllocated.get() >= nInstances) {                  // Allocate a new instance if possible, or else wait                  if (nInstances < maxInstances) {                      try {                          instancePool.push(loadServlet());                          nInstances++;                      } catch (ServletException e) {                          throw e;                      } catch (Throwable e) {                          ExceptionUtils.handleThrowable(e);                          throw new ServletException(sm.getString("standardWrapper.allocate"), e);                      }                  } else {                      try {                          instancePool.wait();                      } catch (InterruptedException e) {                          // Ignore                      }                  }              }              if (log.isTraceEnabled()) {                  log.trace("  Returning allocated STM instance");              }              countAllocated.incrementAndGet();              return instancePool.pop();          }  }

 我们看到了:If not SingleThreadedModel, return the same instance every time

最后,我们来看看filterChain的执行,

@Override      public void doFilter(ServletRequest request, ServletResponse response)          throws IOException, ServletException {        internalDoFilter(request,response);  }    private void internalDoFilter(ServletRequest request,                                     ServletResponse response)          throws IOException, ServletException {        // Call the next filter if there is one      if (pos < n) {          filter.doFilter(request, response, this);      }         // We fell off the end of the chain -- call the servlet instance       servlet.service(request, response);  }

 

显然,在调用web.xml里配的某个servlet时,都会先依次调用在web.xml里配的filter,这可谓是责任链设计模式的一种经典实现,方法的最后会调用servlet.service(request, response)。

 

一个Servlet到底有多少个实例呢,我们来看看官方的说明,在Servlet规范中,对于Servlet单例与多例定义如下:

 

“Deployment Descriptor”, controls how the servlet container provides instances of the servlet.For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration. However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance.

 

上面规范提到,

如果一个Servlet没有被部署在分布式的环境中,一般web.xml中声明的一个Servlet只对应一个实例。

而如果一个Servlet实现了SingleThreadModel接口,就会被初始化多个实例,默认20个

补充以下,一个Servlet在web.xml声明两次,会产生两个实例。

   

    好了,现在你可以把前文中Connector执行过程和本文的Container执行过程结合起来了。我始终相信,深入一点,你会更快乐。

本文发表于2017年10月25日 12:34
(c)注:本文转载自https://my.oschina.net/javahongxi/blog/1555897,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如有侵权行为,请联系我们,我们会及时删除.

阅读 1957 讨论 0 喜欢 0

抢先体验

扫码体验
趣味小程序
文字表情生成器

闪念胶囊

你要过得好哇,这样我才能恨你啊,你要是过得不好,我都不知道该恨你还是拥抱你啊。

直抵黄龙府,与诸君痛饮尔。

那时陪伴我的人啊,你们如今在何方。

不出意外的话,我们再也不会见了,祝你前程似锦。

这世界真好,吃野东西也要留出这条命来看看

快捷链接
网站地图
提交友链
Copyright © 2016 - 2021 Cion.
All Rights Reserved.
京ICP备2021004668号-1