ThreadPoolTaskScheduler动态添加、移除定时任务

最近遇到一个需求，定时任务的业务逻辑不会改变，但需要动态添加、移除定时任务，而且定时执行时间有可能随时改变，这可怎么实现呢？

首先，配置定时任务线程池；

第二步，建立任务，里面包含了定时任务需要实现的业务逻辑；

第三步，应用定时任务，包括添加、移除；

最后，运行入口程序，打开浏览器进行测试； 通过浏览器分别执行了localhost:8080/index/insert/1000/10、localhost:8080/index/insert/2000/20，也就是添加了两个任务，任务1000每10s执行一次，任务2000每20s执行一次；

执行 http://localhost:8080/index/remove/1000 ，把1000的任务移除掉，再看执行结果，只剩下任务2000，ok，动态添加、移除定时任务编码完成。

当然，这里为了测试，把管理任务的队列直接放到了Controller里，实际应用时应保持全局唯一。

最后总结

通过这个需求，我们又用到了一个类ThreadPoolTaskScheduler，它有别于ThreadPoolTaskExecutor类，有兴趣有时间的可以查看源码。

动态添加、移除定时任务的 *** 作流程，大致可以分为以下四个步骤：

1.建立一个定时任务线程池；

2.为定时任务线程池建立一个队列，来管理这些任务；

3.根据唯一标识，往定时任务线程池和队列里分别添加这个任务；

4.根据唯一标识，从定时任务线程池里取消一个任务，并从队列里移除这个任务。

只要您遵循几条简单的准则，线程池可以成为构建服务器应用程序的极其有效的方法：

不要对那些同步等待其它任务结果的任务排队。这可能会导致上面所描述的那种形式的死锁，在那种死锁中，所有线程都被一些任务所占用，这些任务依次等待排队任务的结果，而这些任务又无法执行，因为所有的线程都很忙。

在为时间可能很长的 *** 作使用合用的线程时要小心。如果程序必须等待诸如 I/O 完成这样的某个资源，那么请指定最长的等待时间，以及随后是失效还是将任务重新排队以便稍后执行。这样做保证了：通过将某个线程释放给某个可能成功完成的任务，从而将最终取得某些进展。

理解任务

要有效地调整线程池大小，您需要理解正在排队的任务以及它们正在做什么。它们是 CPU 限制的（CPU-bound）吗？它们是 I/O 限制的（I/O-bound）吗？您的答案将影响您如何调整应用程序。如果您有不同的任务类，这些类有着截然不同的特征，那么为不同任务类设置多个工作队列可能会有意义，这样可以相应地调整每个池。

调整池的大小

调整线程池的大小基本上就是避免两类错误：线程太少或线程太多。幸运的是，对于大多数应用程序来说，太多和太少之间的余地相当宽。

请回忆：在应用程序中使用线程有两个主要优点，尽管在等待诸如 I/O 的慢 *** 作，但允许继续进行处理，并且可以利用多处理器。在运行于具有 N 个处理器机器上的计算限制的应用程序中，在线程数目接近 N 时添加额外的线程可能会改善总处理能力，而在线程数目超过 N 时添加额外的线程将不起作用。事实上，太多的线程甚至会降低性能，因为它会导致额外的环境切换开销。

线程池的最佳大小取决于可用处理器的数目以及工作队列中的任务的性质。若在一个具有 N 个处理器的系统上只有一个工作队列，其中全部是计算性质的任务，在线程池具有 N 或 N+1 个线程时一般会获得最大的 CPU 利用率。

对于那些可能需要等待 I/O 完成的任务（例如，从套接字读取 HTTP 请求的任务），需要让池的大小超过可用处理器的数目，因为并不是所有线程都一直在工作。通过使用概要分析，您可以估计某个典型请求的等待时间（WT）与服务时间（ST）之间的比例。如果我们将这一比例称之为 WT/ST，那么对于一个具有 N 个处理器的系统，需要设置大约 N*(1+WT/ST) 个线程来保持处理器得到充分利用。

处理器利用率不是调整线程池大小过程中的唯一考虑事项。随着线程池的增长，您可能会碰到调度程序、可用内存方面的限制，或者其它系统资源方面的限制，例如套接字、打开的文件句柄或数据库连接等的数目。

---