linux下tomcat shutdown后 java进程依旧存在 -- 阿里MetaQ篇

此篇文章描述的症状和上一篇文章一致（即执行tomcat ./shutdown.sh 后，虽然tomcat服务不能正常访问了，但是ps -ef | grep java 后，发现tomcat对应的java进程未随web容器关闭而销毁，进而存在僵尸java进程），但是处理的过程不一致，所有又单开了一篇blog来写。

我在另外一个项目中使用到了阿里的MetaQ消息中间件，然后shutdown tomcat 发现java进程依旧存在，沿用上一篇文章的思路，我最开始以为是本地代码中scheduledExecutorService没有及时关闭，但check code后发现scheduledExecutorService 已经进行了shutdown处理。于是只能从jstack dump跟踪，./jps   查询到对应的pid，然后 ./jstack  pid，发现存在如下一个非守护线程的dump：

"notify-remoting-ScanAllConnection-1-thread-1" prio=10 tid=0x00007f6124956000 nid=0x2cda waiting on condition [0x00007f6149544000]   java.lang.Thread.State: TIMED_WAITING (parking)        at sun.misc.Unsafe.park(Native Method)        - parking to wait for  <0x00000000f04a5958> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)        at java.lang.Thread.run(Thread.java:722)

上述dump对应的代码是Gecko中，com.taobao.gecko.service.impl.BaseRemotingController类，发现此类中存在一个ScheduledExecutorService scanAllConnectionExecutor，然后我窃以为是此处未shutdown，但，非也，阿里coder的代码不会出现如此低劣的漏洞的，遵循问题定位原则：出现bug时先确保不是自己的代码出现问题，我又看了一遍项目中涉及到metaq的代码，惊奇的发现，虽然一再强调MessageSessionFactory、MessageProducer、MessageConsumer 应该是单例复用形式存在，项目中我是采用spring来托管singleton的，然后，在创建MessageProducer时，却没有使用已经singleton的MessageSessionFactory，而是又重新new 出一个 MessageSessionFactory 实例，而且shutdown时只shutdown spring托管的实例，重新new 出来的对象并未对其进行shutdown。正是该原因，导致Gecko中的scanAllConnectionExecutor一直处于timed_waiting 状态，进而导致jvm无法正常退出。

此次bug定位耗时近一天，最开始我甚至以为是Gecko的bug，但事实证明，出问题往往是自己！引此为戒 ：)