Tomcat源码分析—后台线程管理

Tomcat源码分析—后台线程管理

这篇文章是我在2011年时写的,现转到我自己的博客上

Tomcat后台管理以前也接触过,比如对普通session,持久session,集群session的超时管理,就是后台线程去做的。
在看时序图之前首先看一下后台线程,也就是ContainerBase的内部类ContainerBackgroundProcessor里面的一个重要方法
processChildren(),它是由ContainerBackgroundProcessor#run()每隔一定的时间调用的。

        protected void processChildren(Container container, ClassLoader cl) {
            try {
                if (container.getLoader() != null) {
                    Thread.currentThread().setContextClassLoader
                        (container.getLoader().getClassLoader());
                }
                container.backgroundProcess();
            } catch (Throwable t) {
                log.error("Exception invoking periodic operation: ", t);
            } finally {
                Thread.currentThread().setContextClassLoader(cl);
            }
            Container[] children = container.findChildren();
            for (int i = 0; i < children.length; i++) {
                if (children[i].getBackgroundProcessorDelay() <= 0) {
                    processChildren(children[i], cl);
                }
            }
        }
                                                                                          

实际上它就是调用当前容器的backgroundProcess(),然后再递归执行每个子容器,再调用子容器的backgroundProcess()。

下面来看看ContainerBase#backgroundProcess():

    public void backgroundProcess() {        
        if (!started)
            return;
        if (cluster != null) {
            try {
                cluster.backgroundProcess();
            } catch (Exception e) {
                log.warn(sm.getString("containerBase.backgroundProcess.cluster", cluster), e);                
            }
        }
        if (loader != null) {
            try {
                loader.backgroundProcess();
            } catch (Exception e) {
                log.warn(sm.getString("containerBase.backgroundProcess.loader", loader), e);                
            }
        }
        if (manager != null) {
            try {
                manager.backgroundProcess();
            } catch (Exception e) {
                log.warn(sm.getString("containerBase.backgroundProcess.manager", manager), e);                
            }
        }
        if (realm != null) {
            try {
                realm.backgroundProcess();
            } catch (Exception e) {
                log.warn(sm.getString("containerBase.backgroundProcess.realm", realm), e);                
            }
        }
        Valve current = pipeline.getFirst();
        while (current != null) {
            try {
                current.backgroundProcess();
            } catch (Exception e) {
                log.warn(sm.getString("containerBase.backgroundProcess.valve", current), e);                
            }
            current = current.getNext();
        }
        lifecycle.fireLifecycleEvent(Lifecycle.PERIODIC_EVENT, null);
    }
                                                                                                                                                                                      

这段代码的作用就是调用容器相关联的Cluster,Loader,Manager,Realm的后台方法,再调用和它管理的所有valve,最后触发一个监听事件。这两段代码就是后台管理的核心了。Tomcat对后台管理就是像一个倒着的树一样,一步一步执行下来的。

下面进入正题,看看后台管理调用的时序图:

首先是从CatalinaShutdownHook开始,先调用自己的processChildren(),然后调用第一个容器StandardEngine,引擎会执行和它相关联的Cluster,Loader,Manager,Realm的后台方法,这里只关联了Realm,所以执行Realm的后台方法,这不很简单,一个空方法,所以时序图省略了。然后引擎开始调用它的所有子容器,就是StandardHost,和主机关联的组件没有,所以不执行,valve也是空方法,不要以为这里就完事了,这里会触发一个监听事件,所以会调用到HostConfig,这里可能就会触发重新部署了。
HostConfing首先调用一个checkResources(),这主要是对部署描述文件进行检查,检查他们的时间戳,看看是否改变了,如果改变的话,就将当前的上下文停止掉,并且从自己的部署列表中删除这个上下文。注意,因为这里会有一个重部署的检查工作,所以不会简单的停止启动就完事了,后面还有检查工作。停止完后,再调用自身的deployApps(),这个方法就是启动时候调用的部署方法,里面会调用三种部署应用,这里不是把每个应用都再部署一遍,如果发现某个应用不在自己的列表里,就会执行一次部署工作,这个部署工作就和启动时的部署一模一样了,所以这里就省略了,具体请看《Tomcat源码分析—启动过程》一文。
主机的后台方法执行完了,会回到ContainerBackgroundProcessor,接着执行主机下面的子容器,现在执行的就是StandardContext,它会调用WebappLoader#backgroundProcess(),这个后台方面里会检查当前应用的class和jar是否改动过,这个过程是委托给WebappClassLoader#modified(),这个modified()方法会检查class和jar的时间戳,获取时间戳又会委托FileDirContext#getAttributes(),如果发现有class或者jar改动过了,就简单的重启上下文就可以了,因为部署描述符还是一样的,只是类和jar更新了,所以重启上下文就可以了。
接着上下文会执行ManagerBase#backgroundProcess(),它会调用StandardSession#isValid(),如果session检查自己已经失效就会调用自定义的session属性的Listener,同时将自己从ManagerBase中删除,我们以前所介绍的session管理,其中的后台管理就和这里的步骤完全一样。
上下文执行完了,回到ContainerBackgroundProcessor,此后会继续执行StandardWrapper#backgroundProcess(),StandardWrapper会先调用父类ContainerBase#backgroundProcess(),由于StandardWrapper没有和其他的组件管理,也没有事件监听器,valve的后台方法都是空的,所以返回,此时StandardWrapper会调用这么一段:

if (getServlet() != null && (getServlet() instanceof PeriodicEventListener)) {
    ((PeriodicEventListener) getServlet()).periodicEvent();
}
                                                                                     

谁继承了这个监听器呢?只有JspServlet继承了,这个periodicEvent()会调用checkCompile()方法,默认情况下JSP预编译是没有打开的,如果打开了JSP预编译,在启动后我们又部署了一个新的JSP到应用上,JspServlet就会检查到,然后在后台编译这个JSP。

包装执行完了,后台所有的东西就介绍了,从这里可以看出,Tomcat后台检查实际上比是较繁重的。

3 次阅读

发表评论

电子邮件地址不会被公开。