Tomcat7源码解析

Tomcat7 源码阅读学习

    背景
    Tomcat源码目录结构
    Tomcat体系结构
    Tomcat源码解析
          Tomcat的启动流程
          Tomcat一次完整请求的处理流程
          Tomcat的关闭流程
          Tomcat的Connector组件
          Tomcat的运行过程中的线程概况及线程模型
          Tomcat的类加载机制
          Tomcat所涉及的设计模式
   参考资源

一、背景

        Tomcat作为JavaWeb领域的Web容器,目前在我们淘宝也使用的也非常广泛,现在基本上所有线上业务系统都是部署在Tomcat上。为了对平时开发的Web系统有更深入的理解以及出于好奇心对我们写的Web系统是如何跑在Tomcat上的,于是仔细研究了下Tomcat的源码。大家都知道Servlet规范是Java领域中为服务端编程制定的规范,对于我们开发者只是关注了Servlet规范中提供的编程组件(ServletContextListener,Filer,Servlet) 等 ,但是规范中还有一些我们经常使用的接口(ServletContext,ServletRequest,ServletResponse,FilterChain)等都是由Tomcat去实现的,并且我们开发者实现的编程组件只是被Tomcat去回调而已。所以看Tomcat源码实现也有助于我们更好的理解Servlet规范及系统如何在容器中运行(一些开源的MVC框架如Struts2,Webx,SpringMVC本质无非就是这个),顺便整理了一下与大家分享(Tomcat版本7.0.23,JDK版本1.6)。

二、Tomcat源码目录结构


三、Tomcat体系结构

        仔细查看下图(网络上描述Tomcat架构比较清晰的一张图),不难发现其中的Connecotr组件以及与Container组件是Tomcat的核心。一个Server可以有多个Service,而一个Service可以包含了多个Connector组件和一个Engine容器组件,一个Engine可以由多个虚拟主机Host组成,每一个Host下面又可以由多个Web应用Context构成,每一个的Context下面可以包含多个Wrapper(Servlet的包装器)组成。

       Tomcat将Engine,Host,Context,Wrapper统一抽象成Container。一个抽象的Container模块可以包含各种服务。例如,Manager管理器(Session管理),Pipeline管道( 维护管道阀门Value )等。Lifecycle接口统一定义了容器的生命周期,通过事件机制实现各个容器间的内部通讯。而容器的核心接口Container的抽象实现中定义了一个Pipeline,一个Manager,一个Realm以及ClassLoader统一了具体容器的实现规范。连接器(Connector)组件的主要任务是为其所接收到的每一个请求(可以是HTTP协议,也可以AJP协议),委托给具体相关协议的解析类ProtocolHandler,构造出Request 对象和Response 对象。然后将这两个对象传送给容器(Container)进行处理。容器(Container)组件收到来自连接器(Connector)的Request 和Response对象后,负责调用Filter,最后调用Servlet的service 方法(进入我们开发的Web系统中)。

四、Tomcat源码解析

        Servlet规范由一组用 Java编程语言编写的类和接口组成。Servlet规范为服务端开发人员提供了一个标准的 API以及为服务器厂商制定了相关实现规范,开发人员只需要关心Servlet规范中的编程组件(如Filter,Servlet等),其他规范接口由第三方服务器厂商(如Tomcat)去实现,三者的关系如下图,Servlet规范之于Tomcat的关系,也类似于JDBC规范与数据库驱动的关系,本质就是一套接口和一套实现的关系。对于一个Web服务器主要需要做的事情,个人认为基本由以下组件组成: [TCP连接管理] --> [请求处理线程池管理] --> [HTTP协议解析封装] --> [Servlet规范的实现,对编程组件的回调] --> [MVC框架,Web系统业务逻辑]

       Tomcat的源码及功能点因为实在过于庞大,下面的源码解析不可能全部功能模块都涉及到,接下来我们主要会根据Tomcat的启动、请求处理、关闭三个流程来梳理Tomcat的具体实现,尽可能把各个模块的核心组件都展示出来。 基本上每个流程的源码分析我都画了时序图,如果不想看文字的话,可以对着时序图看(如果想看完整的源代码分析也会在附件中上传),最后还会分析下Tomcat的Connector组件及Tomcat运行过程中的线程概况及线程模型及Tomcat的类加载机制及Tomcat所涉及的设计模式。

                                                              Servlet规范和Web应用及Web容器间的关系                                                                                                                           

                                                           Tomcat对Servlet规范的实现

1. Tomcat的启动流程         

Tomcat在启动时的重点功能如下:

·        初始化类加载器:主要初始化Tomcat加载自身类库的StandardClassLoader。

·        解析配置文件:使用Digester组件解析Tomcat的server.xml,初始化各个组件(包含各个web应用,解析对应的web.xml进行初始化)。

·        初始化Tomcat的各级容器Container,当然最后会初始我们Web应用(我们熟悉的Listener,Filter,Servlet等初始化等在这里完成)。

·        初始化连接器Connector:初始化配置的Connector,以指定的协议打开端口,等待请求。

不管是是通过脚本bootstrap.sh启动还是通过Eclipse中启动,Tomcat的启动流程是在org.apache.catalina.startup.Bootstrap类的main方法中开始的,启动时这个类的核心代码如下所示:

Java代码 

1.  public static void main(String args[]) {  

2.      if (daemon == null) {  

3.           daemon = new Bootstrap(); //实例化Bootstrap的一个实例  

4.           try {

5.               // 创建StandardClassLoader类加载器,并设置为main线程的线程上下文类加载器

6.               // 通过StandardClassLoader加载类Cataline并创建Catalina对象 ,并保存到Boosstrap对象中

7.               daemon.init();

8.           } catch (Throwable t) {  

9.          }  

10.     }  

11.     if (command.equals("start")) {  

12.          daemon.setAwait(true);  

13.           daemon.load(args); //执行load,加载资源,调用Catalinaload方法,利用Digester读取及解析server.xml配置文件并且创建StandardServer服务器对象 */

14.           daemon.start(); //启动各个组件,容器开始启动,调用Catalinastart方法

15.     }  

16. }  

从以上的代码中,可以看到在Tomcat启动的时候,执行了三个关键方法即init、load、和start。后面的两个方法都是通过反射调用org.apache.catalina.startup.Catalina的同名方法完成的,所以后面在介绍时将会直接转到Catalina的同名方法。首先分析一下Bootstrap的init方法,在该方法中将会初始化一些全局的系统属性、初始化类加载器、通过反射得到Catalina实例,在这里我们重点看一下初始化类加载器的initClassLoaders()方法

Java代码 

1.  private void initClassLoaders() {  

2.          try {

3.             //创建StandardClassLoader类加载器  

4.              commonLoader = createClassLoader("common"null);  

5.              if( commonLoader == null ) {  

6.                  commonLoader=this.getClass().getClassLoader();  

7.              }  

8.              catalinaLoader = createClassLoader("server", commonLoader);  

9.              sharedLoader = createClassLoader("shared", commonLoader);  

10.         } catch (Throwable t) {  

11.             System.exit(1);  

12.         }  

13. }  

在以上的代码总,我们可以看到初始化了StandardClassLoader类加载器,这个类加载器详细的会在后面关于Tomcat类加载器机制中介绍。

然后我们进入Catalina的load方法:

Java代码 

1.  public void load() {  

2.          //初始化Digester组件,定义了解析规则  

3.          Digester digester = createStartDigester();  

4.          try {  

5.              inputSource.setByteStream(inputStream);  

6.              digester.push(this);  

7.              //通过Digester解析这个文件,在此过程中会初始化各个组件实例及其依赖关系

8.             //最后会把server.xml文件中的内容解析到StandardServer

9.              digester.parse(inputSource);  

10.             inputStream.close();  

11.         } catch (Exception e) {}  

12.         if (getServer() instanceof Lifecycle) {  

13.             try {

14.                // 调用Serverinitialize方法,初始化各个组件  

15.                 getServer().init();  

16.             } catch (LifecycleException e) {  

17.             }  

18.         }  

19. }  

在以上的代码中,关键的任务有两项即使用Digester组件按照给定的规则解析server.xml、调用Server的init方法,而Server的init方法中,会发布事件并调用各个Service的init方法,从而级联完成各个组件的初始化。每个组件的初始化都是比较有意思的,但是我们限于篇幅先关注Tomcat各级容器的初始化及Connector的初始化,这可能是最值得关注的地方。

首先看下StandardService的start方法(), 核心代码如下:

1.  // StandardService的启动  

2.  protected void startInternal() throws LifecycleException {

4.      //启动容器StandardEngine 

5.      if (container != null) {  

6.          synchronized (container) {  

7.              // 启动StandardEngine容器  

8.              container.start();  

9.          }  

10.     }  

12.     //两个connector的启动,HTTP/1.18080AJP/1.38009  

13.     synchronized (connectors) {  

14.         for (Connector connector: connectors) {  

15.             try {  

16.                 if (connector.getState() != LifecycleState.FAILED) {  

17.                     //依次启动Connector[HTTP/1.1-8080]Connector[AJP/1.3-8009]

18.                     //这里会创建请求线程执行器并启动接收线程Acceptor

19.                     connector.start();  

20.                 }  

21.             } catch (Exception e) {  

22.             }  

23.         }  

24.     }  

25. }  

启动Tomcat各级容器的会依次先启动StandardEngine --> StandardHost --> StandardContext(代表一个WebApp应用), 因为我们比较关心我们的Web应用是哪里被初始化回调的,所以就重点看下StandardContext的start()方法,核心代码如下:

Java代码 

1.  //启动WebApp应用 

2.  @Override  

3.  protected synchronized void startInternal() throws LifecycleException {  

4.      boolean ok = true;  

6.      if (getLoader() == null) {  

7.          //创建此WebApp应用的WebApp载入器WebAppLoader,这个应用的WebAppClassLoader类加载器全部是由这个载入器创建

8.          WebappLoader webappLoader = new WebappLoader(getParentClassLoader());  

9.          webappLoader.setDelegate(getDelegate());  

10.         //在这里开始启动WebAppLoader加载器,并且创建此WebAppWebAppClassLoader类加载器,保存到WebAppLoader,最后会被设置到此ContextInstanceManager

11.         setLoader(webappLoader);  

12.     }  

14.     ///线程上下文类加载器切换成当前WebApp的类加载器,Contextloader中获取 

15.     ClassLoader oldCCL = bindThread();  

17.     try {  

18.         if (ok) {  

19.             //触发Context组件的configure_start事件,通知ContextConfig监听器

20.             //开始解析Web应用WEB-INF/web.xml文件配置到WebXml对象,最后把配置信息全部解析到StandardContext

21.             fireLifecycleEvent(Lifecycle.CONFIGURE_START_EVENT, null);  

23.             if (pipeline instanceof Lifecycle) {  

24.                 //启动StandardContext的管道Pipeline

25.                 ((Lifecycle) pipeline).start();  

26.             }  

27.         }  

28.     } finally {  

29.         //线程上下文类加载器切换成之前的StandardClassLoader

30.         unbindThread(oldCCL);  

31.     }  

33.     //线程上下文类加载器切换成当前WebApp的类加载器,Contextloader中获取

34.     oldCCL = bindThread();  

36.     if (ok ) {  

37.         if (getInstanceManager() == null) {  

38.             Map<String, Map<String, String>> injectionMap = buildInjectionMap(  

39.                     getIgnoreAnnotations() ? new NamingResources(): getNamingResources());  

40.             //创建每个应用StandardContext自己的DefaultInstanceManager实例管理器对象

41.             //并且会从WebAppLoader拿到WebAppClassLoader类加载器,之后此WebApp的应用类都由此ClassLoader加载

42.             setInstanceManager(new DefaultInstanceManager(context,  

43.                     injectionMap, thisthis.getClass().getClassLoader()));  

44.         }  

45.     }  

47.     try {  

48.         //StandardContext的上下文参数设置到ServletContext

49.         mergeParameters();  

51.         if (ok) {  

52.             //启动监听器Listener

53.             if (!listenerStart()) {  

54.                 log.error( "Error listenerStart");  

55.                 ok = false;  

56.             }  

57.         }  

59.         try {  

60.             if ((manager != null) && (manager instanceof Lifecycle)) {  

61.                 //启动Session管理器StandardManager

62.                 ((Lifecycle) getManager()).start();  

63.             }  

64.             super.threadStart();  

65.         } catch(Exception e) {  

66.             ok = false;  

67.         }  

69.         if (ok) {  

70.             //启动过滤器Filter

71.             if (!filterStart()) {  

72.                 log.error("Error filterStart");  

73.                 ok = false;  

74.             }  

75.         }  

77.         if (ok) {  

78.             //启动load-on-startupServlet

79.             loadOnStartup(findChildren());  

80.         }  

82.     } finally {  

83.         // WepApp应用启动完成,线程上下文类加载器切换成之前的StandardClassLoader

84.         unbindThread(oldCCL);  

85.     }  

86. }  

Tomcat的各级容器初始化完成后,就开始对Connector的初始化,接着看Connector的initInternal方法,核心代码如下:

Java代码 

1.  public void initInternal() throws LifecycleException{  

2.          //该协议适配器会完成请求的真正处理     

3.          adapter = new CoyoteAdapter(this);  

4.          //对于不同的实现,会有不同的ProtocolHandler实现类, Http11Protocol用来处理HTTP请求  

5.          protocolHandler.setAdapter(adapter);

6.          try {  

7.             // 初始化Http11Protocol协议

8.              protocolHandler.init();  

9.          } catch (Exception e) {  

10.         }  

11. }  

Http11Protocol的init方法中,核心代码如下:

Java代码 

1.  public void init() throws Exception {  

2.          endpoint.setName(getName());

3.          endpoint.setHandler(cHandler);  

4.          try {  

5.              endpoint.init(); //核心代码就是调用JIoEndpoint的初始化方法  

6.          } catch (Exception ex) {  

7.          }  

8.  }  

我们看到最终的初始化方法最终都会调到JIoEndpoint的bind方法,网络初始化和对请求的最初处理都是通过该类及其内部类完成的,后续的内容会详细阐述这个JioEndpoint:

Java代码 

1.  public void bind() throws Exception {

2.          //请求接收线程数,默认为1     

3.          if (acceptorThreadCount == 0) { 

4.              acceptorThreadCount = 1;  

5.          }  

6.          if (serverSocket == null) {  

7.              try {  

8.                  if (address == null) {  

9.                    //创建ServerSocket,绑定指定端口并打开该端口的服务,默认8080端口 

10.                   serverSocket = serverSocketFactory.createSocket(port, backlog);  

11.                 } else {  

12.                     serverSocket = serverSocketFactory.createSocket(port, backlog, address);  

13.                 }  

14.             } catch (BindException orig) {  

15.             }  

16.         }  

17.     }  

在上面的代码中,我们可以看到此时初始化了一个ServerSocket对象,用来监听绑定端口的请求。

紧接着我们看JioEndpoint的start()方法,核心代码如下:

Java代码 

1.  public void startInternal() throws Exception {  

2.      if (!running) {  

4.          if (getExecutor() == null) {  

5.              //创建请求处理线程池ThreadPoolExecutor, 请求接收线程启动前必须把请求处理线程池准备好

6.              createExecutor();  

7.          }  

9.          initializeConnectionLatch();  

11.         //创建并启动Acceptor接收线程

12.         startAcceptorThreads();  

13.     }  

14. }  

从以上的代码,可以看到,如果没有在server.xml中声明Executor的话,将会使用内部的一个容量为200的线程池用来后续的请求处理。并且按照参数acceptorThreadCount的设置,初始化线程来接受请求。而Acceptor就是正在接受请求并会分派给请求处理线程池:

Java代码 

1.  protected class Acceptor implements Runnable {  

2.          public void run() {  

3.              while (running) {  

4.                     // 默认监听8080端口请求,server.xml中的默认配置

5.                     Socket socket =serverSocketFactory.acceptSocket(serverSocket);

6.                      serverSocketFactory.initSocket(socket);  

7.                      // 处理Socket,把客户端请求Socket交给线程池来处理,当前Acceptor线程继续返回接收客户端Socket  

8.                      if (!processSocket(socket)) {  

9.                          //关闭连接  

10.                         try {  

11.                             socket.close();  

12.                         } catch (IOException e) {  

13.                         }  

14.                     }  

15.             }  

16.         }  

17. }  

从这里我们可以看到,Acceptor已经可以接收Socket请求了,并可以调用processSocket方法来对请求进行处理。至此,Tomcat的组件启动初始化完成,等待请求的到来。

Tomcat的启动流程具体序列图如下:


 2. Tomcat一次完整请求的处理流程

Tomcat一次完整请求处理的重点功能如下:

·        接收Socket请求,把请求转发到线程池,由线程池分配一个线程来处理。

·        获取Socket数据包之后,解析HTTP协议,翻译成Tomcat内部的Request和Response对象,再映射相应Container。

·        Request和Response对象进入Tomcat中的Container容器的各级Piepline管道去流式执行,最终会流到StandardWrapperValve这个阀门。

·        在 StandardWrapperValve这个阀门中,把当前请求的Filter及Servlet封装成FilterChain, 最终执行FilterChain, 回调Web应用,完成响应。

JIoEndpoint的Acceptor线程在接收到用户的请求之后,调用processSocket方法。该方法主要是从Executor请求处理线程池中获取一个线程,然后启用一个新线程执行Socket请求,JIoEndpoint的processSocket()方法的核心代码如下:

Java代码 

1.  protected boolean processSocket(Socket socket) {  

2.      try {  

3.          //Socket包装成SocketWrapper

4.          SocketWrapper<Socket> wrapper = new SocketWrapper<Socket>(socket);  

5.          //包装成SocketProcessor交给线程池处理,当前Acceptor线程不处理,以便接收下一个到达的请求

6.          getExecutor().execute(new SocketProcessor(wrapper));  

7.      } catch (RejectedExecutionException x) {  

8.          return false;  

9.      }

10.     return true;  

11. }  

接着请求处理线程池会起一个线程来处理请求来执行SocketProcessor,而SocketProcessor的run()方法中会调用Http11ConnectionHandler的process方法,SocketProcessor的run()方法核心代码如下:

Java代码 

1.   // Tomcat线程池中的请求处理线程

2.   public void run() {  

3.       boolean launch = false;  

4.       synchronized (socket) {  

5.           try {  

6.               SocketState state = SocketState.OPEN;  

7.               if ((state != SocketState.CLOSED)) {  

8.                   if (status == null) {  

9.                      //通过Http11Protocol$Http11ConnectionHandler处理请求,引用外部类对象的成员handler

10.                      state = handler.process(socket, SocketStatus.OPEN);  

11.                  } else {  

12.                      state = handler.process(socket, status);  

13.                  }  

14.              }  

15.              if (state == SocketState.CLOSED) {  

16.                  try {  

17.                     //关闭Socket  

18.                    socket.getSocket().close();  

19.                  } catch (IOException e) {  

20.                  }  

21.              }

22.          }

23.      }  

24.      //清空请求Socket  

25.      socket = null;  

26. }  

在Http11ConnectionHandler中会根据当前请求的协议类型去创建相应的协议处理器,我们这里分析的是HTTP协议,所以会创建Http11Processor去执行process()方法, 拿到Socket数据包后解析生成Tomcat内部的Request对象与Response对象。其中Request对象只是解析Header部分内容,请求参数等做延迟处理,接着就开始调用CoyoteAdapter类进入容器处理, Http11Processor的process方法核心代码如下:

Java代码 

1.  public SocketState process(SocketWrapper<S> socketWrapper)  

2.          throws IOException {  

3.          RequestInfo rp = request.getRequestProcessor();  

4.          //设置SocketWrapper  

5.          setSocketWrapper(socketWrapper);  

7.          //获取Socket中的inputStream设置到inputBuffer,也就是设置到Request  

8.          getInputBuffer().init(socketWrapper, endpoint);  

9.          //获取Socket中的outputStream设置到outputBuffer,也就是设置到Response

10.         getOutputBuffer().init(socketWrapper, endpoint);  

12.         while (!error && keepAlive && !comet && !isAsync() &&  

13.                 !endpoint.isPaused()) {  

14.             try {  

15.                 setRequestLineReadTimeout();  

17.                 //解析HTTP请求的method,requestURI,protocol 

18.                 if (!getInputBuffer().parseRequestLine(keptAlive)) {  

19.                     if (handleIncompleteRequestLineRead()) {  

20.                         break;  

21.                     }  

22.                 }  

24.                 if (endpoint.isPaused()) {  

25.                     response.setStatus(503);  

26.                     error = true;  

27.                 } else {  

28.                     request.setStartTime(System.currentTimeMillis());  

29.                     keptAlive = true;  

31.                     //解析HTTP请求的报头headers  

32.                     if (!getInputBuffer().parseHeaders()) {  

33.                         openSocket = true;  

34.                         readComplete = false;  

35.                         break;  

36.                     }  

37.                 }  

38.             } catch (IOException e) {  

39.             } catch (Throwable t) {  

40.             }  

42.             if (!error) {  

43.                 try {  

44.                     //准备Request,根据已解析的信息做一些过滤 

45.                     prepareRequest();  

46.                 } catch (Throwable t) {  

47.                     ExceptionUtils.handleThrowable(t);  

48.                 }  

49.             }  

50.             if (!error) {  

51.                 try {  

52.                     //调用CoyoteAdapterservice方法,传入org.apache.coyote.Request对象及org.apache.coyote.Response对象

53.                     adapter.service(request, response);  

54.                 } catch (InterruptedIOException e) {  

55.                     error = true;  

56.                 } 

57.            } 

58.        } 

59. }  

紧接着CoyoteAdapter会调用Container容器的Pipeline管道一步一步的对Request,Response对象处理。Tomcat容器主要由4层组成,通过管道的模式将各个层的功能进行了独立,也有利于对各层插入需要的功能。如果需要,只要在server.xml中加入Value元素的配置即可完成扩展功能, CoyoteAdapter的service方法核心代码如下:

Java代码 

1.  public void service(org.apache.coyote.Request req,  

2.                      org.apache.coyote.Response res)  

3.      throws Exception {  

4.      Request request = (Request) req.getNote(ADAPTER_NOTES);  

5.      Response response = (Response) res.getNote(ADAPTER_NOTES);  

7.      if (request == null) {  

8.          // Tomcat容器中传递的RequestResponse都是这里创建的RequestResponse对象 

9.          //通过Connector创建org.apache.catalina.connector.Request对象

10.         request = connector.createRequest();  

11.         /** 设置org.apache.coyote.Request对象 */  

12.         request.setCoyoteRequest(req);  

14.         //通过Connector创建org.apache.catalina.connector.Response对象

15.         response = connector.createResponse();  

16.         //设置org.apache.coyote.Response对象

17.         response.setCoyoteResponse(res);  

19.         //RequestResponse对象相互关联起来  

20.         request.setResponse(response);  

21.         response.setRequest(request);  

22.     }  

24.     try {  

25.         //解析HTTP协议  

26.         //解析请求的CookiesessionId等信息  

27.         //Connector中映射此请求对应的StandardHostStandardContextStandardWrapper */  

28.         boolean postParseSuccess = postParseRequest(req, request, res, response);  

30.         if (postParseSuccess) {  

31.             //开始调用Tomcat的容器,首先调用StandardEngine容器中管道Pipeline中的第一个Valve,传入connector.Requestconnector.Response

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

33.         }  

35.         //完成此次请求 

36.         request.finishRequest();  

37.         //完成此次响应,并提交响应信息

38.         //如果response已经提交则直接返回,否则提交response  

39.         response.finishResponse();  

40.     } catch (IOException e) {  

41.     } 

43. }  

StandardEngin容器默认配置了StandardEnginValve阀门。它主要做负责选择相应的Host去处理请求,StandardEngineValve的invoke()方法的核心代码如下:

Java代码 

1.  public final void invoke(Request request, Response response)  

2.      throws IOException, ServletException {  

4.      // 得到此请求所对应的StandardHost容器

5.      Host host = request.getHost();  

7.      //调用StandardHost容器中管道Pipeline中的第一个Valve  

8.      host.getPipeline().getFirst().invoke(request, response);  

9.  }  

StandardHost默认情况下配置了ErrorReportValve阀门与StandardHostValue阀门。ErrorReportValve用于处理错误日志。StandardHostValue则选择相应的Context容器,并且把当前Web应用的WebappClassLoader设置为线程上下文类加载器,保证我们的Web应用中拿到的当前线程类加载器为此应用的类加载器, StandardHostValve的invoke()方法的核心代码如下:

Java代码 

1.  public final void invoke(Request request, Response response)  

2.      throws IOException, ServletException {  

4.      //得到此次请求所对应的StandardContext容器 

5.      Context context = request.getContext();  

7.      if( context.getLoader() != null ) {   

8.           //线程上下文类加载器切换成当前WebApp的类加载器,Contextloader中获取

9.           Thread.currentThread().setContextClassLoader(context.getLoader().getClassLoader());  

10.     }  

12.     if (asyncAtStart || context.fireRequestInitEvent(request)) {  

13.         try {  

14.             //调用StandardContext容器中管道Pipeline中的第一个Valve

15.             context.getPipeline().getFirst().invoke(request, response);  

16.         } catch (Throwable t) {  

17.             ExceptionUtils.handleThrowable(t);  

18.         }  

19.     }

20.     //还原StandardClassLoader类加载器为线程上下文类加载器  

21.     Thread.currentThread().setContextClassLoader(StandardHostValve.class.getClassLoader());  

22. }  

StandardContext默认情况下配置了StandardContextValve阀门。对于WEB-INF与META-INF目录禁止访问的控制,之后获取一个此请求的Wrapper容器, StandardContextValve的invoke()方法核核心代码如下:

Java代码 

1.  public final void invoke(Request request, Response response)  

2.       throws IOException, ServletException {

3.       // 对于WEB-INFMETA-INF目录禁止访问的控制

4.       MessageBytes requestPathMB = request.getRequestPathMB();  

5.       if ((requestPathMB.startsWithIgnoreCase("/META-INF/"0))  

6.               || (requestPathMB.equalsIgnoreCase("/META-INF"))  

7.               || (requestPathMB.startsWithIgnoreCase("/WEB-INF/"0))  

8.               || (requestPathMB.equalsIgnoreCase("/WEB-INF"))) {  

9.           response.sendError(HttpServletResponse.SC_NOT_FOUND);  

10.          return;  

11.      }  

12.      //得到此请求所对应的StandardWrapper容器 

13.      Wrapper wrapper = request.getWrapper();  

15.      //调用StandardWrapper容器中管道Pipeline中第一个Valveinvoke()方法

16.      wrapper.getPipeline().getFirst().invoke(request, response);  

17.  }  

StandardWrapper容器默认情况下配置了StandardWrapperValve阀门,主要是找到当前请求的需要拦截的过滤器Filter及初始化当前请求的Servlet对象,最终会封装在FilterChain对象中,责任链方式执行, StandardWrapperValve的invoke()方法的核心代码如下:

Java代码 

1.  public final void invoke(Request request, Response response)  

2.       throws IOException, ServletException {  

4.       //得到StandardWrapper容器  

5.       //每个请求都会对应相应的StandardWrapperStandardWrapperValve对象  

6.       StandardWrapper wrapper = (StandardWrapper) getContainer();  

8.       //得到此请求的StandardContext对象  

9.       Context context = (Context) wrapper.getParent();  

11.      //得到所请求的Servlet对象

12.      Servlet servlet = null;  

14.      try {  

15.          if (!unavailable) {  

16.             //StandardWrapper容器获取一个Servlet对象, Servlet对象的创建及初始化init都在这里执行

17.              servlet = wrapper.allocate();  

18.          }  

19.      } catch (UnavailableException e) {}

21.      //创建ApplicationFilterFactory对象

22.      ApplicationFilterFactory factory = ApplicationFilterFactory.getInstance();  

24.      //创建此次请求的ApplicationFilterChain对象,并设置所请求的Servlet对象

25.      //每个请求都会创建一个ApplicationFilterChain对象,包装了所请求的Servlet对象及一系列拦截的过滤器Filter对象

26.      ApplicationFilterChain filterChain = factory.createFilterChain(request, wrapper, servlet);  

28.      try {  

29.          if ((servlet != null) && (filterChain != null)) {  

30.               //调用ApplicationFilterChaindoFilter方法

31.              //传入org.apache.catalina.connector.RequestFacadeorg.apache.catalina.connector.ResponseFacade对象,开始进行请求处理 

32.              filterChain.doFilter(request.getRequest(),response.getResponse());  

33.          }

34.      } catch (ClientAbortException e) {  

35.          exception(request, response, e);  

36.      } 

38.      try {  

39.          if (servlet != null) {  

40.             //执行完后把Servlet实例回收到Servlet实例池  

41.              wrapper.deallocate(servlet);  

42.          }  

43.      } catch (Throwable e) {  

44.          ExceptionUtils.handleThrowable(e);  

45.      }  

46.  }  

最后就会进入ApplicationFilterChain,这个也是Tomcat管道处理请求的最后节点,在ApplicationFilterChain中会依次调用Web应用的Filter,然后最终调用当前请求映射的Servlet, ApplicationFilterChain的doFilter()方法核心代码如下:

Java代码 

1.  private void internalDoFilter(ServletRequest request,  

2.                                    ServletResponse response)  

3.          throws IOException, ServletException {  

5.          //如果还有过滤器Filter,则执行Filter  

6.          if (pos < n) {  

8.              //得到过滤器Filter  

9.              ApplicationFilterConfig filterConfig = filters[pos++];  

11.             Filter filter = null;  

12.             try {  

13.                 filter = filterConfig.getFilter();  

14.                 //执行过滤器FilterdoFilter(request,response,FilterChain)方法  

15.                filter.doFilter(request, response, this);  

17.            } catch (IOException e) {  

18.                 throw e;  

19.             } 

20.             //执行完FilterdoFilter()方法之后直接返回internalDoFilter方法

21.             return;  

22.         }  

24.         try {  

25.             //过滤器Filter全部执行完,最终调用Servletservice(request,response)方法完成Web应用的业务逻辑 */  

26.            servlet.service(request, response);  

27.         } catch (IOException e) {

28.             throw e;  

29.         } 

30.     }  

Tomcat一次完成请求的处理流程具体序列图如下:


 3. Tomcat的关闭流程

       Tomcat的关闭流程和Tomcat启动流程类似,都是之前已经启动的组件依次关闭销毁,篇幅原因不赘述了。

Tomcat的关闭流程具体序列图如下:



 4. Tomcat的Connector组件

     前面也已经经介绍过,Connector组件是Service容器中的一部分。它主要是接收,解析HTTP请求,然后调用本Service下的相关Servlet。由于Tomcat从架构上采用的是一个分层结构,因此根据解析过的HTTP请求,定位到相应Servlet也是一个相对比较复杂的过程,整个Connector实现了从接收Socket到调用Servlet的全过程。先来看一下Connector的功能逻辑:

·        接收Socket

·        从Socket获取数据包,并解析成HttpServletRequest对象

·        从Engine容器开始走调用流程,经过各层Valve,最后调用Servlet完成业务逻辑

·        返回Response,关闭Socket

可以看出,整个Connector组件是Tomcat运行主干,目前Connector支持的协议是HTTP和AJP,本文主要是针对HTTP协议的Connector进行阐述。先来看一下Connector的配置,在server.xml里; 

Xml代码  

1. <Connector port="80" URIEncoding="UTF-8" protocol="HTTP/1.1"   

2.                connectionTimeout="20000"   

3.                redirectPort="7443" />  

熟悉的80端口不必说了。"protocol"这里是指这个Connector支持的协议。针对HTTP协议而言,这个属性可以配置的值有: 

·        HTTP/1.1

·        org.apache.coyote.http11.Http11Protocol –BIO实现

·        org.apache.coyote.http11.Http11NioProtocol –NIO实现

配置"HTTP/1.1"和"org.apache.coyote.http11.Http11Protocol"的效果是一样的,因此Connector的HTTP协议实现缺省是支持BIO的。无论是BIO还是NIO都是实现一个org.apache.coyote.ProtocolHandler接口,因此如果需要定制化,也必须实现这个接口。 接下来再来看看默认状态下HTTP Connector的架构及其消息流。


 可以看见Connector中三大块 

·        Http11Protocol

·        Mapper

·        CoyoteAdapter

Http11Protocol 
       类完全路径org.apache.coyote.http11.Http11Protocol,这是支持HTTP的BIO实现。Http11Protocol包含了JIoEndpoint对象及Http11ConnectionHandler对象。 
Http11ConnectionHandler对象维护了一个Http11Processor对象池,Http11Processor对象会调用CoyoteAdapter完成HTTPr Request的解析和分派。 
JIoEndpoint维护了两个线程,Acceptor请求接收线程及Executor请求处理线程池。Acceptor是接收Socket,然后从 Executor请求处理线程池中找出空闲的线程处理socket,如果 Executor请求处理线程池没有空闲线程,请求会被放入阻塞队列等待有空闲线程。

Mapper 
      类完全路径org.apache.tomcat.util.http.mapper.Mapper,此对象维护了一个从Host到Wrapper的各级容器的快照。它主要是为了,当HTTP Request被解析后,能够将HTTP Request绑定到相应的Host,Context,Wrapper(Servlet),进行业务处理;

CoyoteAdapter 
      类完全路径org.apache.catalina.connector.CoyoteAdapter,此对象负责将http request解析成HttpServletRequest对象,之后绑定相应的容器,然后从Engine开始逐层调用Valve直至该Servlet。比如根据Request中的JSESSIONID绑定服务器端的相应Session。这个JSESSIONID按照优先级或是从Request URL中获取,或是从Cookie中获取,然后再Session池中找到相应匹配的Session对象,然后将其封装到HttpServletRequest对象,所有这些都是在CoyoteAdapter中完成的。看一下将Request解析为HttpServletRequest对象后,开始调用Servlet的代码; 

Java代码  

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

Connector的拿到的容器就是StandardEngine,代码的可读性很强,获取StandardEngine的Pipeline,然后从第一个Valve开始调用逻辑。

Tomcat的Connector组件工作具体序列图入下:



 5. Tomcat运行过程中的线程概况及线程模型

       Tomcat在运行过程中会涉及到很多线程,主要的线程有Tomcat启动时的main主线程(Java进程启动时的那个线程), 子容器启动与关系线程池(用来启动关系子容器),Tomcat后台线程(Tomcat内置的后台线程,比如用来热部署Web应用), 请求接收线程(用来接收请求的线程), 请求处理线程池(用来处理请求的线程)。理解了Tomcat运行过程中的主要线程,有助于我们理解整个系统的线程模型。下面是每个线程的源码及功能的详细分析:

Java代码

1.  (1) main主线程:即从main开始执行的线程,在启动Catalina之后就一直在Server的await方法中等待关闭命令,如果未接收到关闭命令就一直等待下去。main线程会一直阻塞着等待关机命令。  

2.         启动过程:Bootstrap.main>>

3.                           Catalina.start >>

4.                                   Catalina.await() >>

5.                                               StandardServer.await()

7.  (2子容器启动与关闭线程:ContainerBase的protected ThreadPoolExecutor startStopExecutor容器线程池执行器[处理子容器的启动和停止]在ContainerBase.initInternal()方法中进行初始化       作用:在ContainerBase.startInternal()方法中启动子容器,在ContainerBase.stopInternal()方法中停止子容器,即处理子容器的启动和停止事件。  

8.         子容器线程池创建过程:StandardService.initInternal>>

9.                                        ContainerBase.initInternal >> 

10.                                                      new ThreadPoolExecutor()  

11.        启动过程:StandardService.startInternal>>

12.                               ContainerBase.startInternal >>

13.                                                startStopExecutor.submit(new StartChild(Child)或StopChild(Child))>>

14.                                                                                                        execute(ftask) >>           

15.                                                                                                                     addIfUnderCorePoolSize(command)             

16.        addIfUnderCorePoolSize内容如下:  

17. private boolean addIfUnderCorePoolSize(Runnable firstTask) {  

18.         Thread t = null;  

19.         final ReentrantLock mainLock = this.mainLock;  

20.         mainLock.lock();  

21.         try {  

22.             if (poolSize < corePoolSize && runState == RUNNING)  

23.                 t = addThread(firstTask);  

24.         } finally {  

25.             mainLock.unlock();  

26.         }  

27.         if (t == null)  

28.             return false;  

29.         t.start(); // StartChild.call()被调用,调用子容器的child.start()启动子容器   

30.         return true;  

31. }  

32. private Thread addThread(Runnable firstTask) {  

33.         Worker w = new Worker(firstTask);  

34.         Thread t = threadFactory.newThread(w); //创建一个线程

35.         if (t != null) {  

36.             w.thread = t;  

37.             workers.add(w);  

38.             int nt = ++poolSize;  

39.             if (nt > largestPoolSize)  

40.                 largestPoolSize = nt;  

41.         }  

42.         return t;  

43.     }

45. (3容器的后台处理线程:ContainerBackgroundProcessor是ContainerBase的一个内部类 

46.         启动过程:StandardService.startInternal>>

47.                                     ContainerBase.startInternal >> 

48.                                                    ContainerBase.threadStart()  

49.    ContainerBase.startInternal(){  

50.         for(int i=0 ;i < children.length;i++){  

51.           startStopExecutor.submit(new StartChild(children[i]); //起新线程启动子容器  

52.         }  

53.         threadStart(); // 在启动容器的最后调用threadStart方法  

54.     }   

55. protected void threadStart() {  

56.         if (thread != null)  

57.             return;  

58.         // backgroundProcessorDelay默认为-1,即不产生后台线程,但StandardEngine的构造  

59.         // 函数中设置backgroundProcessorDelay = 10,即默认只有Engine产生后台线程,  

60.         // 其它子容器共享Engine的后台线程

61.         if (backgroundProcessorDelay <= 0)   

62.             return;  

63.         threadDone = false;  

64.         String threadName = "ContainerBackgroundProcessor[" + toString() + "]";  

65.         thread = new Thread(new ContainerBackgroundProcessor(), threadName);  

66.         thread.setDaemon(true);  

67.         thread.start(); // 启动容器后台线程

68. }

70. (4请求接收线程:即运行Acceptor的线程,启动Connector的时候产生  

71.         启动过程:StandardService.startInternal>>

72.                             Connector.startInternal() >>

73.                                            protocolHandler.start() >>

74.                                                      AbstractProtocol.start() >>

75.                                                                        endpoint.start() >>

76.                                                                                  AbstractEndpoint.Start() >>

77.                                                                                               JioEndpoint.startInternal() >>

78.                                                                                                              JIoEndpoint.startAcceptorThreads()  

79.     startAcceptorThreads内容如下:  

80.     protected final void startAcceptorThreads() {  

81.         int count = getAcceptorThreadCount(); // 默认只有一个接收线程Acceptor

82.         acceptors = new Acceptor[count];  

83.         for (int i = 0; i < count; i++) {  

84.             acceptors[i] = createAcceptor(); // org.apache.tomcat.util.net. JIoEndpoint.Acceptor

85.             Thread t = new Thread(acceptors[i], getName() + "-Acceptor-" + i);  //创建请求接收线程

86.             t.setPriority(getAcceptorThreadPriority());  

87.             t.setDaemon(getDaemon());  

88.             t.start(); // 启动请求接收线程来接收请求

89.         }  

90.     }  

91. 这样在Acceptor的run()中就可以接收请求了。

92.
(5请求处理线程:即运行SocketProcessor的线程,从请求处理线程池中产生,org.apache.tomcat.util.net. AbstractEndpoint的成员变量private Executor executor用来处理请求,org.apache.tomcat.util.net.JioEndpoint(继承了AbstractEndpoint)在方法startInternal()中调用createExecutor()来创建executor为线程池对象ThreadPoolExecutor  

93.         请求处理线程池创建过程:StandardService.startInternal>>

94.                                            Connector.startInternal >>

95.                                                          protocolHandler.start >>

96.                                                                   AbstractProtocol.start >>

97.                                                                                 endpoint.start >>             

98.                                                                                       AbstractEndpoint.Start >>

99.                                                                                               JIoEndpoint.startInternal >>  

100.                                                                                                            JIoEndpoint.createExecutor>> 

101.                                                                                                                           new ThreadPoolExecutor()  

102.      public void createExecutor() {  

103.          internalExecutor = true;  

104.          TaskQueue taskqueue = new TaskQueue();  

105.          // 线程池线程产生的的工厂为java.util.concurrent.ThreadFactory.TaskThreadFactory

106.          TaskThreadFactory tf = new TaskThreadFactory(getName() + "-exec-", daemon, getThreadPriority());  

107.          executor = new ThreadPoolExecutor(getMinSpareThreads(), getMaxThreads(), 60, TimeUnit.SECONDS,taskqueue, tf);  

108.          taskqueue.setParent( (ThreadPoolExecutor) executor);  

109.      }  

110.          启动过程:Acceptor.run()>> // 请求接收线程接收到请求后

111.                             processSocket(socket)>>  

112.                                   getExecutor().execute(new SocketProcessor(wrapper))>> // 交给请求处理线程处理

113.                                                                   ThreadPoolExecutor.execute (command,0,TimeUnit.MILLISECONDS)>>  

114.                                                                                                                 super.execute(command) >>  

115.                                                                                                                            addIfUnderCorePoolSize(command)  

116.  addIfUnderCorePoolSize内容如下:  

117.  private boolean addIfUnderCorePoolSize(Runnable firstTask) {  

118.          Thread t = null;  

119.          final ReentrantLock mainLock = this.mainLock;  

120.          mainLock.lock();  

121.          try {  

122.              if (poolSize < corePoolSize && runState == RUNNING)  

123.                  t = addThread(firstTask);  

124.          } finally {  

125.              mainLock.unlock();  

126.          }  

127.          if (t == null)  

128.              return false;  

129.          t.start();  // SocketProcessor.run运行

130.          return true;  

131.  }  

132.  private Thread addThread(Runnable firstTask) {  

133.          Worker w = new Worker(firstTask);  

134.          Thread t = threadFactory.newThread(w); //创建一个线程

135.          if (t != null) {  

136.              w.thread = t;  

137.              workers.add(w);  

138.              int nt = ++poolSize;  

139.              if (nt > largestPoolSize)  

140.                  largestPoolSize = nt;  

141.          }  

142.          return t;  

143.  }  

144.  至此SocketProcessor.run运行起来了,这个线程负责处理请求。 

 Tomcat运行过程中的线程概况具体序列图入下:


       大家都知道Java中的IO模型分阻塞式的IO模型(BIO)及非阻塞式的IO模型(NIO),Tomcat中的对请求接收网络IO模块中也同样实现了基于上述两种IO的线程模型,具体的实现如下,

 Tomcat基于阻塞式IO(BIO)的线程模型序列图如下:


Tomcat基于非阻塞式IO(NIO)的线程模型序列图如下:

6. Tomcat的类加载机制

   主流的JavaWeb服务器如(Tomcat,Jetty,WebLogic)都实现了自己定义的类加载器(一般不止一个),因为Web服务器一般要解决如下几个问题:

          1、部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离。

          2、部署在同一个服务器上的两个应用程序所使用的Java类库可以相互共享。

          3、服务器需要尽可能地保证自身的安全不受部署的Web应用程序的影响

         为了解决这几个问题Tomcat实现了如下类加载器的层级结构:


Tomcat7运行时类的加载说明:

1)Bootstrap Class Loader是JVM的内核由C实现的,加载了JVM的核心包rt.jar。rt.jar中的所有类执行其class的getClassLoader()方法都将返回null,例如Integer.class.getClassLoader()。


2)Extension Class Loader主要加载了JVM扩展包中相关的jar包。例如运行下列代码将System.out.println(ZipPath.class.getClassLoader());将得到如下的运行结果:sun.misc.Launcher$ExtClassLoader。


3)System Class Loader加载CLASSPATH相关的类,例如在Tomcat的Bootstrap的main方法中执行System.out.println(Bootstrap.class.getClassLoader());则将得到:sun.misc.Launcher$AppClassLoader。


4)Common Class Loader,Tomcat7中的CATALINA_HOME/lib下的jar包。注意Tomcat在启动文件中将启动时配置了-classpath "%CATALINA_HOME%\lib\catalina.jar"因此catalina.jar中的类虽然指定使用类加载器Common Class Loader,但是按JVM的委托加载原则System.out.println(Bootstrap.class.getClassLoader());得到的类加载器是:sun.misc.Launcher$AppClassLoader。


5)Webapp Class Loader, 主要负责加载Context容器中的所有的类。实际上该加载器提供了参数delegateLoad供用户设定是否使用parent-first加载。默认该值为false,默认用parent-last加载。出于安全性的考虑对于核心类WebappClassLoader是不允许加载的。包括:java.,javax.servlet.jsp.jstl,javax.servlet.,javax.el。


Tomcat类加载器的相关类图 


Tomcat类加载器的相关源代码分析

(一) ClassLoader的load方法

Java代码  

1. protected Class<?> loadClass(String name, boolean resolve)  

2.         throws ClassNotFoundException  

3.     {  

4.         synchronized (getClassLoadingLock(name)) {  

5.             // First, check if the class has already been loaded  

6.             Class c = findLoadedClass(name);

7.             if (c == null) {  

8.                 try {  

9.                     if (parent != null) {  

10.                        c = parent.loadClass(name, false);  

11.                    } else {  

12.                        c = findBootstrapClassOrNull(name);  

13.                    }  

14.                }   

15.                if (c == null) {  

16.                    // If still not found, then invoke findClass in order  

17.                    // to find the class.  

18.                    long t1 = System.nanoTime();  

19.                    c = findClass(name);  

20.                }  

21.            }  

22.            if (resolve) {  

23.                resolveClass(c);  

24.            }  

25.            return c;  

26.        }  

27.    }  

1)在该方法中,首先检查是否已经加载了该类,这里有个问题JVM如何判断一个类是否被加载过的?这里涉及到了类的命名空间问题。在JAVA中判断一个类是否相同不仅看类名是否相同,还要看其类加载器是否相同。同一个类可以被不同的类加载器所加载,并且认为是不同的。该问题可以分解下面两个方面看。

  a) 单一加载原则:在加载器链中,一个类只会被链中的某一个加载器加载一次。而不会被重复加载。实现类的共享,Tomcat多个应用,如果需要共享一些jar包,那么只需要交给                   commonClassLoader加载,那么所有的应用就可以共享这些类。

  b) 可见性原则:父加载器加载的类,子加载器是可以访问的。而自加载器所加载的类,父加载器无法访问。不同加载器链之间其是相互不可见,无法访问的。实现隔离,Tomcat就是应         用该特性,为每一个Context容器创建一个WebappClassLoader类加载器对象,从而实现了应用间的相互隔离。应用间的类是不可见的所以无法相互访问。

2) 如果步骤一中无缓存,查看该类父加载器,如果存在那么委托给付加载器。如果没有父加载器那么认为BootstrapClassLoader是其父加载器,委托进行加载。

3)如果父加载器无法加载则抛出ClassNotFoundException,调用抽象方法findClass方法。

4)此处的resolveClass方法指的是上文类加载过程中连接的第三步操作。resolve该类的形式引用等等。

(二)类URLClassLoader的findClass方法

Java代码  

1. protected Class<?> findClass(final String name)  

2.          throws ClassNotFoundException  

3.     {  

4.         try {  

5.             return AccessController.doPrivileged(  

6.                 new PrivilegedExceptionAction<Class>() {  

7.                     public Class run() throws ClassNotFoundException {  

8.                         String path = name.replace('.''/').concat(".class");  

9.                         Resource res = ucp.getResource(path, false);  

10.                        if (res != null) {  

11.                            try {  

12.                                return defineClass(name, res);  

13.                            } catch (IOException e) {  

14.                                throw new ClassNotFoundException(name, e);  

15.                            }  

16.                        } else {  

17.                            throw new ClassNotFoundException(name);  

18.                        }  

19.                    }  

20.                }, acc);  

21.        } catch (java.security.PrivilegedActionException pae) {  

22.            throw (ClassNotFoundException) pae.getException();  

23.        }  

24.    }  

  该方法的核心是加载获取Java类字节码文件的字节流,然后调用父类的defineClass方法完成类的构造过程。defineClass是由JVM实现的,不允许被覆写,因此用户类文件就必须遵循     JVM的文件规范才能被正确的解析。

(三)WebappClassLoader重写了ClassLoader的loadClass方法

Java代码  

1. @Override  

2. public synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {  

3.         Class<?> clazz = null;  

5.         // (0) 当前对象缓存中检查是否已经加载该类  

6.         clazz = findLoadedClass0(name);  

8.         // (0.1) 检查JVM的缓存,是否已经加载过该类  

9.         clazz = findLoadedClass(name);  

11.        // (0.2) 防止加载一些系统相关的类  

12.        try {  

13.            clazz = system.loadClass(name);  

14.            if (clazz != null) {  

15.                if (resolve)  

16.                    resolveClass(clazz);  

17.                return (clazz);  

18.            }  

19.        } catch (ClassNotFoundException e) {}  

21.        boolean delegateLoad = delegate || filter(name);  

23.        // (1) 如果配置了parent-first模式,那么委托给父加载器  

24.        if (delegateLoad) {  

25.            ClassLoader loader = parent;  

26.            if (loader == null) loader = system;  

27.            try {  

28.                clazz = Class.forName(name, false, loader);  

29.                if (clazz != null) {  

30.                    if (resolve) resolveClass(clazz);  

31.                    return (clazz);  

32.                }  

33.            } catch (ClassNotFoundException e) {}  

34.        }  

36.        // (2) WebApp中去加载类,主要是WebApp下的/classes目录与/lib目录  

37.        try {  

38.            clazz = findClass(name);  

39.            if (clazz != null) {  

40.                if (resolve)  

41.                    resolveClass(clazz);  

42.                return (clazz);  

43.            }  

44.        } catch (ClassNotFoundException e) {}  

46.        // (3) 如果在当前WebApp中无法加载到,委托给StandardClassLoader$catalina_home/lib中去加载

47.        if (!delegateLoad) {  

48.            ClassLoader loader = parent;  

49.            if (loader == null)  

50.                loader = system;  

51.            try {  

52.                clazz = Class.forName(name, false, loader);  

53.                if (clazz != null) {  

54.                    if (resolve)  

55.                        resolveClass(clazz);  

56.                    return (clazz);  

57.                }  

58.            } catch (ClassNotFoundException e) {}  

59.        }  

61.        throw new ClassNotFoundException(name);  

62.    }  

(四)WebappClassLoader的findClass()方法>>findClassInternal()方法>>findResourceInternal()方法

Java代码 

1.      //WebappClassLoaderclasspath中加载类或资源文件 

2.      protected ResourceEntry findResourceInternal(String name, String path) {  

3.          if (!started) {  

4.              log.info(sm.getString("webappClassLoader.stopped", name));  

5.              return null;  

6.          }  

7.          ResourceEntry entry = resourceEntries.get(name);  

8.          if (entry != null)  

9.              return entry;  

11.         int contentLength = -1;  

12.         InputStream binaryStream = null;  

14.         int jarFilesLength = jarFiles.length;  

15.         int repositoriesLength = repositories.length;  

17.         int i;  

18.         Resource resource = null;  

19.         boolean fileNeedConvert = false;  

21.        //首先从/WEB-INF/classes路径中加载类

22.         for (i = 0; (entry == null) && (i < repositoriesLength); i++) {  

23.             try {  

24.                 String fullPath = repositories[i] + path;  

25.                 //获取资源的绝对路径 

26.                 Object lookupResult = resources.lookup(fullPath);  

27.                 if (lookupResult instanceof Resource) {  

28.                     resource = (Resource) lookupResult;  

29.                 }  

31.                 ResourceAttributes attributes =  

32.                     (ResourceAttributes) resources.getAttributes(fullPath);  

33.                 contentLength = (int) attributes.getContentLength();  

34.                 String canonicalPath = attributes.getCanonicalPath();  

35.                 if (canonicalPath != null) {  

36.                     entry = findResourceInternal(new File(canonicalPath), "");  

37.                 } else {  

38.                     //获取类或文件的ResourceEntry  

39.                     entry = findResourceInternal(files[i], path);  

40.                 }  

41.                 entry.lastModified = attributes.getLastModified();  

43.                 if (resource != null) {  

44.                     try {  

45.                         //得到类或资源的输入流InputStream  

46.                         binaryStream = resource.streamContent();  

47.                     } catch (IOException e) {  

48.                         return null;  

49.                     }  

50.                     if (needConvert) {  

51.                         if (path.endsWith(".properties")) {  

52.                             fileNeedConvert = true;  

53.                         }  

54.                     }  

55.                 }  

56.             } catch (NamingException e) {  

57.             }  

58.         }  

60.        //然后再从/WEB-INF/lib路径中加载类

61.         if ((entry == null) && (notFoundResources.containsKey(name)))  

62.             return null;  

63.         JarEntry jarEntry = null;  

64.         synchronized (jarFiles) {  

65.             try {  

66.                 for (i = 0; (entry == null) && (i < jarFilesLength); i++) {  

67.                     //获取JarFile下的JarEntry 

68.                     jarEntry = jarFiles[i].getJarEntry(path);  

70.                     if (jarEntry != null) {  

71.                         entry = new ResourceEntry();  

72.                         try {  

73.                             //设置类或文件的URL  

74.                             entry.codeBase = getURL(jarRealFiles[i], false);  

75.                             String jarFakeUrl = getURI(jarRealFiles[i]).toString();  

76.                             jarFakeUrl = "jar:" + jarFakeUrl + "!/" + path;  

77.                             //设置URL  

78.                             entry.source = new URL(jarFakeUrl);  

79.                             entry.lastModified = jarRealFiles[i].lastModified();  

80.                         } catch (MalformedURLException e) {  

81.                             return null;  

82.                         }  

83.                         contentLength = (int) jarEntry.getSize();  

84.                         try {  

85.                             entry.manifest = jarFiles[i].getManifest();  

86.                             //JarFile中根据JarEntry获取jar包中类的输入流InputStream  

87.                             binaryStream = jarFiles[i].getInputStream(jarEntry);  

88.                         } catch (IOException e) {  

89.                             return null;  

90.                         }  

91.                     }  

92.                 }  

94.                 if (binaryStream != null) {  

95.                     byte[] binaryContent = new byte[contentLength];  

96.                     int pos = 0;  

97.                     try {  

98.                         while (true) {  

99.                             //从输入流InputStream中读取类或文件的二进制流  

100.                              int n = binaryStream.read(binaryContent, pos, binaryContent.length - pos); 

101.                              if (n <= 0)  

102.                                  break;  

103.                              pos += n;  

104.                          }  

105.                      } catch (IOException e) {  

106.                          return null;  

107.                      }  

108.                      //设置二进制设置到ResourceEntry 

109.                      entry.binaryContent = binaryContent;  

110.                  }  

111.              } 

112.          }  

113.          synchronized (resourceEntries) {

114.              ResourceEntry entry2 = resourceEntries.get(name);

115.              if (entry2 == null) {  

116.                  //向本地资源缓存这注册ResourceEntry

117.                  resourceEntries.put(name, entry);  

118.              } else {  

119.                  entry = entry2;  

120.              }  

121.          }  

122.          return entry;  

123.      }  

(五)Web应用中经常使用到的线程上下文类加载器的在Tomcat中的设置实现

 在Web应用中我们经常用到线程上下文类加载器,拿到的肯定是当前WebApp的WebAppClassLoader, 如下

Java代码  

1.  ClassLoader classLoader= Thread.currentThread().getContextClassLoader();

我们用到的线程上下文类加载器其实是在StandardHostValve的invoke()方法中被设置的

Java代码 

1.  public final void invoke(Request request, Response response)  

2.      throws IOException, ServletException {  

4.      //得到此次请求所对应的StandardContext容器  

5.      Context context = request.getContext();  

7.      if( context.getLoader() != null ) {  

8.              //线程上下文类加载器切换成当前WebApp的类加载器,Contextloader中获取  

9.              Thread.currentThread().setContextClassLoader(context.getLoader().getClassLoader());  

10.     }  

12.     if (asyncAtStart || context.fireRequestInitEvent(request)) {  

13.         try {  

14.             //调用StandardContext容器中管道Pipeline中的第一个Valve,直到调用Servlet  

15.             context.getPipeline().getFirst().invoke(request, response);  

16.         } catch (Throwable t) {  

17.             ExceptionUtils.handleThrowable(t);  

18.             request.setAttribute(RequestDispatcher.ERROR_EXCEPTION, t);  

19.             throwable(request, response, t);  

20.         }  

21.     }  

22.     if (!Globals.IS_SECURITY_ENABLED) {  

23.         //还原StandardClassLoader类加载器为线程上下文类加载器 

24.         Thread.currentThread().setContextClassLoader(StandardHostValve.class.getClassLoader();  

25.     }  

26. }  

7、Tomcat所涉及的设计模式

         Tomcat虽然代码比较庞大,但是整体还是设计的比较优雅,特别是很多组件化的设计思路,其中涉及到的一些常用的设计模式值得我们学习及借鉴:

责任链模式
        Tomcat中有两个地方比较明显的使用了责任链模式,一、Tomcat中的ApplicationFilterChain实现了Filter拦截和实际Servlet的请求,是典型的责任链模式。其他开源框架中类似的设计还有Struts2中的DefaultActionInvocation实现Interceptor拦截和Action的调用。Spring AOP中ReflectiveMethodInvocation实现MethodInceptor方法拦截和target的调用。二、Tomcat中的Pipeline-Valve模式也是责任链模式的一种变种,从Engine到Host再到Context一直到Wrapper都是通过一个链来传递请求。

观察者模式
        Tomcat通过LifecycleListener对组件生命周期组件Lifecycle进行监听就是典型的观察者模式,各个组件在其生命期中会有各种各样行为,而这些行为都会触发相应的事件,Tomcat就是通过侦听这些事件达到对这些行为进行扩展的目的。在看组件的init和start过程中会看到大量如:lifecycle.fireLifecycleEvent(AFTER_START_EVENT,null);这样的代码,这就是对某一类型事件的触发,如果你想在其中加入自己的行为,就只用注册相应类型的事件即可。

门面模式
      门面设计模式在 Tomcat 中有多处使用,在 Request 和 Response 对象封装中(RequestFacade,ResponseFacade)、ApplicationContext 到ApplicationContextFacade等都用到了这种设计模式。这种设计模式主要用在一个大的系统中有多个子系统组成时,这多个子系统肯定要涉及到相互通信,但是每个子系统又不能将自己的内部数据过多的暴露给其它系统,不然就没有必要划分子系统了。每个子系统都会设计一个门面,把别的系统感兴趣的数据封装起来,通过这个门面来进行访问。

模板方法模式

  模板方法模式是我们平时开发当中常用的一种模式,把通用的骨架抽象到父类中,子类去实现特地的某些步骤。Tomcat及Servlet规范API中也大量的使用了这种模式,比如Tomcat中的ContainerBase中对于生命周期的一些方法init,start,stop和Servlet规范API中的GenericServlet中的service抽象骨架模板方法均使用了模板方法模式。


参考资源
Tomcat官网:http://tomcat.apache.org/
<How Tomcat Wroks>:Tomcat5的架构分析
Tomcat源码分析:http://zddava.iteye.com/blog/305944

Tomat的源码环境搭建:http://mabusyao.iteye.com/blog/1198557

<Servlet2.5规范>:JSR制定的规Servlet范

 

阅读更多
个人分类: Tomcat7源码解析
想对作者说点什么? 我来说一句
相关热词

没有更多推荐了,返回首页

关闭
关闭
关闭