tomcat中的Lifecycle架构

    tomcat中的Lifecycle架构非常简单，但却非常实用。不仅tomcat内部的所有组件使用了Lifecycle，就连我们自己设计的一些系统也会经常用到这个设计。

    先上图，对这个设计有个直观的认识。

    

    估计第一印象是：非常简单，没错，tomcat的Lifecycle就这么简单（这里省略了LifecycleEvent）。

    client本身继承了Lifecycle接口，这个接口中定义了几个关键方法，对LifecycleListener的添加，删除以及查找，另外就是start以及stop方法。他们是非常经典的抽象方法，在大多数组件，服务中间我们都可以用这两个方法来表示他们的一种状态，通常start表示从新建到运行，stop表示从运行到死亡，正是这种抽象，使得他的设计可以表示大多数组件或者服务的生命周期，而且我们可以看到，越高的抽象层次，适用范围就越广。

    Client中有一个类是LifecycleSupport，在StandardServer中是这样定义的：

private LifecycleSupport lifecycle = new LifecycleSupport(this);

    LifecycleSupport是实际对LifecycleListener的添加，删除以及查找的角色（有点像代理模式，但是要注意LifecycleSupport并没有继承Lifecycle，非但没继承，更有趣的是他还是final的），另外，LifecycleSupport还有个重要方法fireLifecycleEvent，它就是具体通知Listener事件的地方，他做的是遍历所有listener并回调一个lifecycleEvent方法。

    LifecycleSupport还持有一组LifecycleListener，这组LifecycleListener是注册进LifecycleSupport中的（通过addLifecycleListener），也就是正在监听Client的所有监听者。注册之后，client发起的事件就可以通过这组LifecycleListener通知所有注册监听的组件。

    在tomcat中，经典的用法是这样的：Engine, Host, Context都是Container，Engine中注册了几个Listener(Host)，Host中注册了几个Listener(Context)，于是当Engine调用fireLifecycleEvent时，遍历了所有的host，并通知host，host接到通知，由于上级容器start了，host也进行start，同时继续fireLifecycleEvent，这样不断反复，就能够将所有的子组件全部启动，这种方式，比显式的写一堆组件的start要来得更加简洁，试想如果你需要启动一堆组件，在一个统一的地方写，或许你需要写200行，而他们仅仅是重复的功能。

    Lifecycle的经典模式就是观察者模式。这里就不细讲了，但是或许你有个疑问，为什么不直接用jdk类库中的Observable和Observer呢？这里有几个有意思的地方，一是如果使用这个方式，就意味着Observable一定是要被继承的，而java中不能多重继承，那只能抛弃一些其他的父类了（所以常说组合优于继承）；二是使用Observable，接口的方法名字就只能随着这个类了，事实上，update这个方法一眼看上去并不知道它想干什么。

    至于LifecycleSupport为什么是final的，我想你一定听说过final的类是不可变的，不可变意味着多线程环境下就不需要加锁了。