自己开的坑，陆陆续续填坑中，自以为是地觉得基础知识很扎实，一个人接手了公司的一个小项目，结果遇到了多线程并发和阻塞的问题，让人欲哭无泪。特开此文，记录开发中遇到的各种问题以及解决方法，引以为戒。

一、线程池

我所负责的项目是一个高并发的任务调度，所以就很想当然地用到了线程池，线程池的基本原理也不用多说，但是不得不提的一点是线程池的拒绝策略，这个是经常被大家所忽略的，我当初也是直接复制粘贴网上的代码根本没有细看，最后导致的一个问题就是任务没法管理，完全脱离了控制。

我当前的任务管理是用spring的定时器实现的，定时器的作用是每个一段时间就新建几个任务提交给线程池进行处理，这样可以保持任务的并发量维持在一定的量并且不会浪费cpu，但是当这类任务已经完成，不再需要执行时，我关闭定时器，而任务还是在执行之中。其原因在于定时器的触发间隔内，我所提交的任务线程池不一定能够执行完，在旧有的任务没有完成的情况下，又会有新的任务提交进来，这种情况得不到解决，导致线程池被塞满各种来不及执行的任务。而当定时器取消该任务并且不再提交时，线程池中的未执行任务还在排队等候，总有一天能够被cpu翻到牌子得以运行，这也导致了任务数量超出预期效果。

那么为了更好地控制任务，我们需要改变策略

1.在执行任务的时候检查任务数量是否足够，然后再选择执行。

我显然不喜欢这种，强迫症不允许这样浪费

2.调整线程池大小，策略设置为拒绝所有，就是队列满时再提交任务直接拒绝。

rejectedExecutionHandler选择AbortPolicy，其他策略可以自行百度

这样的话同时也限制了其他任务，我不能接受

3.待任务执行完成再提交新的任务

这不得不提到spring自带的定时任务了，在spring4.x.x版本以上，实现了基于注解的定时器，与quartz差不多，提供了三种定时器，cron,fixDelay和fixRate。

cron是基于cron表达式的一种定时器，更灵活当然也更复杂，fixDelay是每隔一段时间执行一次任务，而fixRate顾名思义就是心跳，与fixDelay差不多，但又有很大的不同。

特别需要注意的是这些定时器的触发策略。cron和fixDelay是在上一个定时任务完成之后再触发定时器，也就是说如果前一个定时任务还没有执行完成，不会再创建新的定时任务。只要当前一个任务执行完成之后再来启动自己的定时功能，等到正确的时间进行触发。而fixRate则不同，它是不管上一个任务是否完成，都会在触发器规定的时间内创建一个定时任务，可以说是相当准时。

基于以上，我选择了cron表达式。