TOMCAT源码分析——生命周期管理(一)

前言

  从server.xml文件解析出来的各个对象都是容器,比如:Server、Service、Connector等。这些容器都具有新建、初始化完成、启动、停止、失败、销毁等状态。tomcat的实现提供了对这些容器的生命周期管理,本文将通过对Tomcat7.0的源码阅读,深入剖析这一过程。

TOMCAT生命周期类接口设计

  我们先阅读图1,从中了解Tomcat涉及生命周期管理的主要类。

图1  Tomcat生命周期类接口设计
这里对图1中涉及的主要类作个简单介绍:

  • Lifecycle:定义了容器生命周期、容器状态转换及容器状态迁移事件的监听器注册和移除等主要接口;
  • LifecycleBase:作为Lifecycle接口的抽象实现类,运用抽象模板模式将所有容器的生命周期及状态转换衔接起来,此外还提供了生成LifecycleEvent事件的接口;
  • LifecycleSupport:提供有关LifecycleEvent事件的监听器注册、移除,并且使用经典的监听器模式,实现事件生成后触打监听器的实现;
  • MBeanRegistration:Java jmx框架提供的注册MBean的接口,引入此接口是为了便于使用JMX提供的管理功能;
  • LifecycleMBeanBase:Tomcat提供的对MBeanRegistration的抽象实现类,运用抽象模板模式将所有容器统一注册到JMX;
    此外,ContainerBase、StandardServer、StandardService、WebappLoader、Connector、StandardContext、StandardEngine、StandardHost、StandardWrapper等容器都继承了LifecycleMBeanBase,因此这些容器都具有了同样的生命周期并可以通过JMX进行管理。

    什么是JMX?

      java管理程序扩展(java management extensions,简称JMX),是一个可以为Java应用程序或系统植入远程管理功能的框架。为便于讲解,我从网络上找了一张JMX的架构,如图2所示。

    图2  JMX架构
    这里对图2中三个分层进行介绍:

  • Probe Level:负责资源的检测(获取信息),包含MBeans,通常也叫做Instrumentation Level。MX管理构件(MBean)分为四种形式,分别是标准管理构件(Standard MBean)、动态管理构件(Dynamic MBean)、开放管理构件(Open Mbean)和模型管理构件(Model MBean)。
  • Agent Level:即MBeanServer,是JMX的核心,负责连接Mbeans和应用程序。
  • Remote Management Level:通过connectors和adaptors来远程操作MBeanServer,常用的控制台,例如JConsole、VisualVM等。

    容器

    TOMCAT容器组成

      StandardServer、StandardService、Connector、StandardContext这些容器,彼此之间都有父子关系,每个容器都可能包含零个或者多个子容器,这些子容器可能存在不同类型或者相同类型的多个,如图3所示。

    图3  Tomcat容器组成

    TOMCAT容器状态

      目前,Tomcat的容器具有以下状态:

  • NEW:容器刚刚创建时,即在LifecycleBase实例构造完成时的状态。
  • INITIALIZED:容器初始化完成时的状态。
  • STARTING_PREP:容器启动前的状态。
  • STARTING:容器启动过程中的状态。
  • STARTED:容器启动完成的状态。
  • STOPPING_PREP:容器停止前的状态。
  • STOPPING:容器停止过程中的状态。
  • STOPPED:容器停止完成的状态。
  • DESTROYED:容器销毁后的状态。
  • FAILED:容器启动、停止过程中出现异常的状态。
  • MUST_STOP:此状态未使用。
  • MUST_DESTROY:此状态未使用。
    这些状态都定义在枚举类LifecycleState中。

    事件与监听

      每个容器由于继承自LifecycleBase,当容器状态发生变化时,都会调用fireLifecycleEvent方法,生成LifecycleEvent,并且交由此容器的事件监听器处理。LifecycleBase的fireLifecycleEvent方法的实现见代码清单1。
    代码清单1

    /**
     * Allow sub classes to fire {@link Lifecycle} events.
     *
     * @param type  Event type
     * @param data  Data associated with event.
     */
    protected void fireLifecycleEvent(String type, Object data) {
        lifecycle.fireLifecycleEvent(type, data);
    }
    

    lifecycle的定义如下:

    /**
     * Used to handle firing lifecycle events.
     * TODO: Consider merging LifecycleSupport into this class.
     */
    private LifecycleSupport lifecycle = new LifecycleSupport(this);
    

    LifecycleSupport的fireLifecycleEvent方法的实现,见代码清单2。
    代码清单2

    /**
     * Notify all lifecycle event listeners that a particular event has
     * occurred for this Container.  The default implementation performs
     * this notification synchronously using the calling thread.
     *
     * @param type Event type
     * @param data Event data
     */
    public void fireLifecycleEvent(String type, Object data) {
    
        LifecycleEvent event = new LifecycleEvent(lifecycle, type, data);
        LifecycleListener interested[] = listeners;
        for (int i = 0; i < interested.length; i++)
            interested[i].lifecycleEvent(event);
    
    }
    

    代码清单2将事件通知给所有监听当前容器的生命周期监听器LifecycleListener,并调用LifecycleListener的lifecycleEvent方法。每个容器都维护这一个监听器缓存,其实现如下:

    /**
     * The set of registered LifecycleListeners for event notifications.
     */
    private LifecycleListener listeners[] = new LifecycleListener[0];
    

    那么listeners中的监听器是何时添加进来的呢?每个容器在新建、初始化、启动,销毁,被添加到父容器的过程中都会调用父类LifecycleBase的addLifecycleListener方法,addLifecycleListener的实现见代码清单3。
    代码清单3

    @Override
    public void addLifecycleListener(LifecycleListener listener) {
        lifecycle.addLifecycleListener(listener);
    }
    

    从代码清单3看到,LifecycleBase的addLifecycleListener方法实际是对LifecycleSupport的addLifecycleListener方法的简单代理,LifecycleSupport的addLifecycleListener方法的实现,见代码清单4。
    代码清单4

    /**
     * Add a lifecycle event listener to this component.
     *
     * @param listener The listener to add
     */
    public void addLifecycleListener(LifecycleListener listener) {
    
      synchronized (listenersLock) {
          LifecycleListener results[] =
            new LifecycleListener[listeners.length + 1];
          for (int i = 0; i < listeners.length; i++)
              results[i] = listeners[i];
          results[listeners.length] = listener;
          listeners = results;
      }
    
    }
    

    在代码清单2中,我们讲过容器会最终调用每个对此容器感兴趣的LifecycleListener的lifecycleEvent方法,那么LifecycleListener的lifecycleEvent方法会做些什么呢?为了简单起见,我们以监听器AprLifecycleListener为例,AprLifecycleListener的lifecycleEvent方法的实现,见代码清单5。
    代码清单5

    /**
     * Primary entry point for startup and shutdown events.
     *
     * @param event The event that has occurred
     */
    public void lifecycleEvent(LifecycleEvent event) {
    
        if (Lifecycle.INIT_EVENT.equals(event.getType())) {
            synchronized (lock) {
                init();
                if (aprAvailable) {
                    try {
                        initializeSSL();
                    } catch (Throwable t) {
                        log.info(sm.getString("aprListener.sslInit"));
                    }
                }
            }
        } else if (Lifecycle.AFTER_STOP_EVENT.equals(event.getType())) {
            synchronized (lock) {
                if (!aprAvailable) {
                    return;
                }
                try {
                    terminateAPR();
                } catch (Throwable t) {
                    log.info(sm.getString("aprListener.aprDestroy"));
                }
            }
        }
    
    }
    

    我会在《TOMCAT源码分析——生命周期管理(二)》一文中继续讲解容器生命周期的其它内容。

时间: 2024-10-21 20:01:25

TOMCAT源码分析——生命周期管理(一)的相关文章

TOMCAT源码分析——生命周期管理(二)

前言 我在<TOMCAT源码分析--生命周期管理(一)>一文中介绍了TOMCAT生命周期类接口设计.JMX.容器以及基于容器的事件与监听等内容,本文将接着介绍Tomcat7.0中容器生命周期的管理. 容器生命周期 每个容器都会有自身的生命周期,其中也涉及状态的迁移,以及伴随的事件生成,本节详细介绍Tomcat中的容器生命周期实现.所有容器的转态转换(如新疆.初始化.启动.停止等)都是由外到内,由上到下进行,即先执行父容器的状态转换及相关操作,然后再执行子容器的转态转换,这个过程是层层迭代执行的

TOMCAT源码分析——停止服务

前言 在<TOMCAT源码分析--启动服务>一文中我介绍了Tomcat服务的启动过程分析,本文讲解Tomcat服务是如何停止的. 停止过程分析 我们停止Tomcat的命令如下: sh shutdown.sh 所以,将从shell脚本shutdown.sh开始分析Tomcat的停止过程.shutdown.sh的脚本代码见代码清单10. 代码清单10 os400=false case "`uname`" in OS400*) os400=true;; esac # resolv

TOMCAT源码分析——启动服务

前言 熟悉Tomcat的工程师们,肯定都知道Tomcat是如何启动与停止的.对于startup.sh.startup.bat.shutdown.sh.shutdown.bat等脚本或者批处理命令,大家一定知道改如何使用它,但是它们究竟是如何实现的,尤其是shutdown.sh脚本(或者shutdown.bat)究竟是如何和Tomcat进程通信的呢?本文将通过对Tomcat7.0的源码阅读,深入剖析这一过程. 由于在生产环境中,Tomcat一般部署在Linux系统下,所以本文将以startup.s

Tomcat源码分析——server.xml文件的解析

前言 在<Tomcat源码分析--server.xml文件的加载>一文中我们介绍了server.xml的加载,本文基于Tomcat7.0的Java源码,接着对server.xml文件是如何解析的进行分析. 概要 规则 Tomcat将server.xml文件中的所有元素上的属性都抽象为Rule,以Server元素为例,在内存中对应Server实例,Server实例的属性值就来自于Server元素的属性值.通过对规则(Rule)的应用,最终改变Server实例的属性值. Rule是一个抽象类,其中

Tomcat源码分析----初始化与启动

1.前言 1.1 问题思考 在阅读tomcat源码前,我们一般都会有如下几个疑问: web容器和servlet容器的区别是什么: 在springMVC中的web.xml是什么时候加载到tomcat中的: tomcat是怎么加载我们的web服务的: tomcat是怎么实现的热部署: 一个http请求是怎么被tomcat监听到的,会有哪些处理: 为什么请求可以有需要通过nginx的,也可以不需要nginx的直接请求到tomcat上? -- 如果你想知道答案,那么接下来的文章会告诉你. 1.2 基本姿

Tomcat源码分析——类加载体系

前言 Tomcat遵循J2EE规范,实现了Web容器.很多有关web的书籍和文章都离不开对Tomcat的分析,初学者可以从Tomcat的实现对J2EE有更深入的了解.此外,Tomcat还根据Java虚拟机规范实现了经典的双亲委派模式的类加载体系.本文基于Tomcat7.0的Java源码,对其类加载体系进行分析. 概述 首先简单介绍下Java虚拟机规范中提到的主要类加载器: Bootstrap Loader:加载lib目录下或者System.getProperty("sun.boot.class.

Tomcat源码分析——server.xml文件的加载

前言 作为Java程序员,对于tomcat的server.xml想必都不陌生.本文基于Tomcat7.0的Java源码,对server.xml文件是如何加载的进行分析. 源码分析 Bootstrap的load方法用于加载tomcat的server.xml,实际是通过反射调用Catalina的load方法,代码如下: /** * Load daemon. */ private void load(String[] arguments) throws Exception { // Call the

tomcat源码分析-Bootstrap操作Catalina

1.前言 1.1 问题思考 在阅读tomcat源码前,我们一般都会有如下几个疑问: web容器和servlet容器的区别是什么: 在springMVC中的web.xml是什么时候加载到tomcat中的: tomcat是怎么加载我们的web服务的: tomcat是怎么实现的热部署: 一个http请求是怎么被tomcat监听到的,会有哪些处理: 为什么请求可以有需要通过nginx的,也可以不需要nginx的直接请求到tomcat上? -- 如果你想知道答案,那么接下来的文章会告诉你. 1.2 基本姿

Tomcat源码分析----Container初始化与加载

在本章节中,以下几个问题会被回答: - web容器和servlet容器的区别是什么: - 在springMVC中的web.xml是什么时候加载到tomcat中的: - tomcat是怎么加载我们的web服务的: - tomcat是怎么实现的热部署: 1 Container基本结构 从上文中有讲到,Connector和Container的初始化工作是由Digester来解析conf/server.xml来完成的.而在server.xml中已经告诉我们了Container的基本结构.那么我们先来看看