线程重复执行问题与线程池

Posted 2023-04-30

参考技术A 一个线程的start，只能start一次，再次调用start方法就会抛出异常。

内部实现这个的原理是：

线程对象内部有一个字段，初始值是0

调用一次start方法之后，这个值会被置成其他值（并没有找到在哪里置其他值）
如果重复掉用这个start，会判断这个值如果不是0了就抛出异常，所以导致一个线程只能被start一次。

使用线程A实现了功能A，这个功能A需要被多次调用，但是这个线程A又不能多次start，导致无法多次调用这个功能A。

于是乎只能多次new线程A的对象，这种虽然可行，但是功能A跑一次就需要一个新的线程A对象，这越积越多，不见得之前用完的线程A对象会被及时回收，这就不可靠。

线程的重复的创建是需要耗费很多的性能的，线程池对这个进行管理，线程池可以重复使用线程，所以可以节约性能。
这里涉及到一个问题，前面有介绍过，一个线程是不可能重复start，换句话说一个线程执行完了以后就不能再被执行了，那么这个线程池是这么重复利用的呢？

这个是线程池的构造方法，上面的几个不同的线程池newScheduledThreadPool、newCachedThreadPool等等其实都是调用的这个构造方法，只不过传递进去的参数不一样，所以会有不一样的效果。

线程池ExecutorService与quartz搭配出现的问题

问题描述：

使用quartz定时推送微信公众号模板消息，一分钟推送一次，定时器里面使用了一个ExecutorService线程池，大小为5个。

批量获取数据之后，全部数据都被分配到n/5的线程池里面等待执行，分配完成之后，系统就默认了这次任务已经执行完毕。

下个一分钟到了的时候，继续获取指定状态的数据，重复上面的入线程池操作。

导致，在之前的任务里面已经分配到线程池中，但是还没有来得及处理的数据，在下一个定时任务开始时重新被放进去了线程池里面。

如此累计，导致最后有的用户多次重复收到了同一条模板消息。

问题定位：

定时任务没有等待ExecutorService所有任务执行完毕之后再结束此次任务，导致的重复累积推送问题。

解决方案：

在定时器方法尾部添加判断线程池状态代码，阻塞任务结束执行。

//等待线程池所有线程执行完毕，再执行下一个定时任务
//shutdown()方法会标记之后，等待所有线程执行完毕后，修改其线程池状态，isTerminated()方法为shutdown真正之后才会返回true

executorService.shutdown();  
while (true) {  
    if (executorService.isTerminated()) {  
        logger.info("SendLimitTemplateTimer end"); 
        break;  
    }  
}