一、问题由来
我们组用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、最不建议的方式：吞了异常；或者只打个日志。
如果大家有什么想法，欢迎和我交流