ThreadPoolExecutor几点使用建议

如果正在执行的task是个很耗时的任务,且它没有安乐死的方法.这是用户已经没有耐心在继续等待了,也不想让它继续占用线程池的工作线程;所以想强杀所在线程(强杀无副作用:不会造成死锁资源泄露等),然后再补缺.大家觉得这样的线程池怎么样?

我当时实现的RejectedExecutionHandler，是用定时任务去执行，感觉性能不好。但似乎目前没有现成的更好的办法。

corePoolSize 和 maximumPoolSize的区别， 和大家正常理解的数据库连接池不太一样。
  *  据dbcp pool为例，会有minIdle , maxActive配置。minIdle代表是常驻内存中的threads数量，maxActive代表是工作的最大线程数。
  *  这里的corePoolSize就是连接池的maxActive的概念，它没有minIdle的概念(每个线程可以设置keepAliveTime，超过多少时间多有任务后销毁线程，但不会固定保持一定数量的threads)。
  * 这里的maximumPoolSize，是一种救 急措施的第一层。当threadPoolExecutor的工作threads存在满负荷，并且block queue队列也满了，这时代表接近崩溃边缘。这时允许临时起一批threads，用来处理runnable，处理完后立马退出。

想说的是，这样的功能在cocurrent已经有了。

ThreadPoolExecutor实现了ExecutorService接口，submit()返回一个Future结果。
可以通过Future.cancel(true);进行中断，通过设置Thread.interrupt进行打断。但需要任务支持中断处理。
jdk不建议使用Thread.destory()方法，可能会造成泄漏，一般都是建议使用interrupt处理

建议不错,不过destroy一定是用不了,stop还是个选项.

定时任务去执行这些任务？为何不做成一个阻塞，处于客户端吞吐量的考虑？

根据项目特点来考虑的吧，因为项目的特点是会偶尔有一个很短暂的高峰期(并发量一下猛增)，我只要延时一下，过了高峰期，系统就能处理任务了。

当然实际当时在测试的时候，9m/s(9兆每秒)的处理量也基本没有用到我的RejectedExecutionHandler。当时以这个处理量拷机拷了4－5天，没有死过机。