持续集成环境–Tomcat热部署导致线程泄漏,jenkins部署war包到远程服务器的tomcat

Java框架

浏览数:874

2019-6-26

一、问题由来

我们组用jenkins部署了持续集成环境,(jenkins部署war包到远程服务器的tomcat)。

每次提交了代码,jenkins上一键构建,就可以自动拉取最新代码,打war包,热部署到远程环境上的tomcat。

一切都很好,只是一次用jconsole偶然连上去一看,远程环境上的tomcat上,线程数竟多达700多个。。。

二、排查代码

查看线程堆栈,几百个线程中,线程名为“UserService-InformImAndCcm”打头的,多达130+,但是在代码中,只搜到一处线程池配置:

一个qq群里,有人说我们的参数配错了,我一度动摇了,但后来还是觉得不对,我理解的线程池就是:

超过核心线程数后,仍然有task,就丢队列,如果队列满了,就继续开线程,直到达到maximumPoolSize,如果后续队列再满了,则拒绝任务。

也就是说,线程不可能超过maximumPoolSize。

。。。

后来任务一多,忘了。今天又想起来,做个测试,因为我感觉,这事,可能和热部署有关系。

三、本地测试–多次热部署同一应用

1、本地环境配置

很简单,一个war包,两个tomcat自带的war包,用来控制reload应用。

配置好了后,启动tomcat

2、打开jconsole进行监控

主要是监控线程。

3、reload应用一次

打开localhost:9080/manager/html,如果不能访问,请在tomcat下面的conf中的tomcat-users.xml配置:

    <role rolename="manager-gui"/>
    <user username="admin" password="admin" roles="manager-gui"/>

 4、观察jconsole中的线程数是否增加

 5、反复重试前面3-4步

如果不出意外(程序中有线程泄漏)的话,jconsole中的线程图应该是下面这样,一步一个台阶:

 6、查看tomcat下logs中的catalina.log

这里面可能会有些线程泄漏的警告,如下:

四、问题出现的原因

Tomcat热部署的实现机制,暂时没有研究。

不过根据在catalina.log日志中出现的:

26-Dec-2018 13:06:24.920 信息 [http-nio-9081-exec-34] org.apache.catalina.core.StandardContext.reload Reloading Context with name [/CAD_WebService] is completed

在idea中通过如下骚操作:

找到了关联的源码:

进入该Servlet的reload:

protected void reload(PrintWriter writer, ContextName cn,
            StringManager smClient) {

        try {
            Context context = (Context) host.findChild(cn.getName());
            。。。。。。删除无关代码
            context.reload();
        }

    }

这里的context,实现类是org.apache.catalina.core.StandardContext,该类的reload方法:

public synchronized void reload() {

        setPaused(true);

        try {
            stop();
        } catch (LifecycleException e) {
        }
       。。。删除无关代码
        try {
            start();
        } catch (LifecycleException e) {
        }

        setPaused(false);

        if(log.isInfoEnabled())
            log.info(sm.getString("standardContext.reloadingCompleted",
                    getName()));

    }

StandardContext类,未实现自己的stop,因此调用了基类org.apache.catalina.util.LifecycleBase#stop:

public final synchronized void stop() throws LifecycleException {

            stopInternal();  //无关代码已删除
 }

在org.apache.catalina.core.StandardContext中,重写了stopInternal:

    protected synchronized void stopInternal()  {

        try {
            // Stop our child containers, if any
            final Container[] children = findChildren();

            for (int i = 0; i < children.length; i++) {
                children[i].stop();
            }
    }

在这里,会查找当前对象(当前对象代表我们要reload的context,即一个应用),这里查找它下面的子container,那就是会查找到各servlet的wrapper。

然后调用这些servlet wrapper的stop。

wrapper的标准实现为:org.apache.catalina.core.StandardWrapper。其stopInternal如下:

protected synchronized void stopInternal() throws LifecycleException {
        // Shut down our servlet instance (if it has been initialized)
        try {
            unload();
        } catch (ServletException e) {
            getServletContext().log(sm.getString
                      ("standardWrapper.unloadException", getName()), e);
        }

    }

这里准备在unload中,关闭servlet。

org.apache.catalina.core.StandardWrapper#unload:


protected volatile Servlet instance = null;

public synchronized void unload() throws ServletException { // Nothing to do if we have never loaded the instance if (!singleThreadModel && (instance == null)) return; unloading = true; // Call the servlet destroy() method try { instance.destroy(); } // Deregister the destroyed instance instance = null; instanceInitialized = false; }

从上看出,这里开始调用servlet的destroy方法了。

spring应用的servlet,想必大家都很熟了,org.springframework.web.servlet.DispatcherServlet。

它的destroy方法由父类org.springframework.web.servlet.FrameworkServlet实现,#destroy:

    public void destroy() {
        getServletContext().log("Destroying Spring FrameworkServlet '" + getServletName() + "'");
        // Only call close() on WebApplicationContext if locally managed...
        if (this.webApplicationContext instanceof ConfigurableApplicationContext && !this.webApplicationContextInjected) {
            ((ConfigurableApplicationContext) this.webApplicationContext).close();
        }
    }

这里,主要是针对spring 容器进行关闭,比如各种bean的close方法等等。

实现在这里,org.springframework.context.support.AbstractApplicationContext#doClose:

protected void doClose() {
        if (this.active.get() && this.closed.compareAndSet(false, true)) {

            LiveBeansView.unregisterApplicationContext(this);

            try {
                // Publish shutdown event.
                publishEvent(new ContextClosedEvent(this));
            }
            catch (Throwable ex) {
                logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", ex);
            }

            // Stop all Lifecycle beans, to avoid delays during individual destruction.
            getLifecycleProcessor().onClose();// Destroy all cached singletons in the context's BeanFactory.
            destroyBeans();

            // Close the state of this context itself.
            closeBeanFactory();

            // Let subclasses do some final clean-up if they wish...
            onClose();

            this.active.set(false);
        }
    }

问题分析到现在,我们可以发现,针对spring bean中的线程池,是没有地方去关闭线程池的。

所以,每次reload,在stop的过程中,线程池都没得到关闭,于是造成了线程泄漏。

五、解决办法

1:网上的解决办法是说:实现一个javax.servlet.ServletContextListener,实现其jcontextDestroyed方法,然后注册到servlet中。

2:我这边觉得,按照上面的分析,直接在关闭bean的时候,关闭线程池也可以:

针对,spring应用,在bean中,如果有线程池实例变量的话,让bean实现org.springframework.beans.factory.DisposableBean接口:

    @Override
    public void destroy() throws Exception {
        logger.info("about to shutdown thread pool");
        pool.shutdownNow();
    }

 不过说实话,上面的两种方案我都试了,不起作用。明天弄个纯净的工程试下吧,目前的project里代码太杂。

2019-02-11日更新:

针对上面的第二种方法,调用线程池的shutdownNow,会循环给池里的线程调用该线程的interrupt方法。

interrupt方法,是否有效果,这个只能取决于具体的线程的run方法实现。

比如看下面我们当时线程的实现就是有问题的:

查看blockingqueue的take方法:

但我们的线程实现里,捕获了异常,继续无限循环。。。(这个是历史代码。。。哎)

所以,正确的做法是,要保证线程在被interrupt后,可以正常结束。

处理方式有几种:

参考https://www.ibm.com/developerworks/cn/java/j-jtp05236.html

1、不捕捉 InterruptedException,将它传播给调用者

2、捕获后重新抛出

3、在runable中,无法抛出时,捕获后,重新设置中断,让调用方可以感知

4、最不建议的方式:吞了异常;或者只打个日志。

 如果大家有什么想法,欢迎和我交流

 

作者:三国梦回