Thread & ExecutorService & ThreadPoolExecutor 总览
ExecutorService
允许已经提交的任务（尚未开始执行和已经开始执行的）继续执行 shutdownNowvcD4NCjxwPsnQzrS/qsq81rTQ0LXEyM7O8bK71NnWtNDQo6zNrMqxs6LK1NbV1rnV/dTa1rTQ0LXEyM7O8TwvcD4NCjxwPs7ewtvKx3NodXRkb3duILu5ysdzaHV0ZG93bk5vd6Oswb249rXE1rTQ0La8u+HX6Na50MK1xMjOzvHM4b27PC9wPg0KPHA+0ru49kV4ZWN1dG9yU2VydmljZdK7tal0ZXJtaW5hdGlvbqOsse3D98O709DV/dTa1rTQ0LXEyM7O8aOsw7vT0LXItP3WtNDQtcTIzs7xo6zSsrK7u+HT0NDCtcTIzs7xv8nS1LG7zOG9u6GjPC9wPg0KPHA+yOe5+9K7uPZFeGVjdXRvclNlcnZpY2Wyu9TZyrnTw6Os06a4w7X308NzaHV0ZG93bre9t6jAtLvYytXXytS0oaM8L3A+DQo8cD5zdWJtaXS3vbeoo6jI/bj21tjU2Le9t6ijqTwvcD4NCjxwcmUgY2xhc3M9"brush:">
返回的Future对象可以用来取消任务和等待任务执行完成
invokeAny和invokeAll方法
用户批量执行任务，
invokeAny：会阻塞当前线程，直到某个任务完成。并返回这个任务相关的Future对象
invokeAll：会阻塞当前线程，直到所有任务完成。
两阶段shutdown
先执行shutdown方法 调用awaitTermination方法 再调用shutdownNow方法
void shutdownAndAwaitTermination(ExecutorService pool) {
pool.shutdown(); // Disable new tasks from being submitted
// Wait a while for existing tasks to terminate
if (!pool.awaitTermination(60, TimeUnit.SECONDS)) {
pool.shutdownNow(); // Cancel currently executing tasks
// Wait a while for tasks to respond to being cancelled
if (!pool.awaitTermination(60, TimeUnit.SECONDS))
System.err.println(&Pool did not terminate&);
} catch (InterruptedException ie) {
// (Re-)Cancel if current thread also interrupted
pool.shutdownNow();
// Preserve interrupt status
Thread.currentThread().interrupt();
isShutdown和isTerminated分别对应于两个状态：关闭状态，终结状态
interrupt方法
如果执行a.interrupt方法后，如果a线程（注意是a线程，不是调用线程）抛出了InterruptedException异常，那么a的中断状态会被清除。如果不是抛出InterruptedException异常，那么a的中断状态都会被设置。 interrupted方法
执行a.interrupted方法会返回a线程的中断状态，同时会清除a线程的中断状态 isInterrupted方法
执行a.interrupted方法会返回a线程的中断状态，不会清除a线程的中断状态
ThreadPoolExecutor
core pool size 及 max pool size
一个新的任务提交哪些情况下回创建新的线程：
1. 已创建的的线程数小于corePoolSize（即便有线程是空闲的）
2. 已创建的线程数大于corePoolSize小于maxPoolSize，同时任务队列已经满的情况下，也会创建新的线程
可以动态改变这两个的值：setCorePoolSize
以及 setMaximumPoolSize
如果corePoolSize==maxinumPoolSize，那么则创建了一个固定大小的线程池
keep alive time
如果已创建的线程大于了corePoolSize，并且如果有线程的空闲时间大于了keepAliveTime，那么这些线程会被kill掉直到剩下corePoolSize个线程。
可以动态设置：setKeepAliveTime方法
默认情况下keep-alive策略只会针对已创建线程数大于corePoolSize的情况下
可以通过执行allowCoreThreadTimeOut(boolean)让keep-alive策略应用在已创建线程数小于corePoolSize的情况下。
BlockingQueue
如果已创建线程数小于corePoolSize，那么会创建新的线程来执行当前提交的任务，而不是进入阻塞队列 如果已创建线程数大于等于corePoolSize,会尝试先进入阻塞队列，如果进入失败（其实就是队列已满），则会在maxPoolSize条件下创建新的线程来执行当前提交的任务。如果不满足maxPoolSize条件，那么就会执行 拒绝执行策略（默认的拒绝执行策略见下）
通常有三种入队列策略
直接传递给线程（Direct handoffs）
比如：SychronousQueue
感觉可以理解为这个入队列会总是失败，就相当于没有这个队列一样。这样就能在maxPoolSize条件下尽可能快的创建（或选择空闲的线程）来执行新提交的任务。
如果提交的任务有互相的依赖性，可以考虑使用这种队列。
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue());
无界队列（Unbounded Queue）
比如：LinkedBlockingQueue
可以理解为如果有任务需要入队列，那么总会入队成功。
因此按照创建新线程的条件，理论上不会有超过corePoolSize个数的线程。也就是说理论上线程数最多为corePoolSize，因此maxPoolSize的设置也就显得没有意义了。
如果提交的任务互相间没有依赖性，可以考虑使用这种队列
有界队列（Bounded Queue）
比如：ArrayBlockingQueue
如果使用有限个maxPoolSize,那么使用这种队列可以防止资源的耗尽。
使用长队列和小的线程池，可以降低CPU使用率，降低资源的消耗，以及降低线程上下文切换的消耗，但是会导致低吞吐量。如果任务频繁的阻塞，系统可能会创建比允许的线程数多的线程。
使用短队列和大的线程池，可以提高CPU使用率，但也有可能导致吞吐量下降。
拒绝执行策略（我自己的叫法，实际上就是 RejectedExceptionHandler ）
ThreadPoolExecutor.AbortPolicy
抛出RejectedExecutionException异常
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
throw new RejectedExecutionException(&Task & + r.toString() +
& rejected from & +
e.toString());
ThreadPoolExecutor.CallerRunsPolicy
在调用线程上执行（哪个线程提交的任务就哪个线程执行）
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
if (!e.isShutdown()) {
ThreadPoolExecutor.DiscardPolicy
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
ThreadPoolExecutor.DiscardOldestPolicy
放弃当前队列中第一个任务
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
if (!e.isShutdown()) {
e.getQueue().poll();
e.execute(r);
Finalization
一个在程序中不再被引用的线程池如果同时没有剩余的线程，那么这个线程池会被自动的shutdown.
因此如果你想即便在忘记执行shutdown方法的时候仍能正常关闭线程池，那么建议设置一个有限的keepAliveTime（针对大于线程数大于corePoolSize的那些线程），同时也执行下 allowCoreThreadTimeOut(boolean) .
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'在android中使用ExecutorService类：
Future&Boolean& future = executorService
.submit(new Callable&Boolean&() {
public Boolean call() throws Exception {
Thread.sleep(3000);//执行这个操作的时候会明显发现UI线程被阻塞了
if (future.get()) {
} catch (Exception e) {
e.printStackTrace();
executorService.shutdown();
难道这个线程池所提供的线程是跑在UI线程的？但是打印出来的Thread.name并不是主线程，但是为什么在这里面执行耗时操作也会阻塞UI线程呢？
<dd style="float:cursor:" title="声誉值：
该问题被发起重新开启投票
投票剩余时间：
之前被关闭原因：
该问题被发起删除投票
投票剩余时间：
距离悬赏到期还有：
参与关闭投票者：
关闭原因：
该问题已经被锁定
锁定原因：（）
保护原因：避免来自新用户不合宜或无意义的致谢、跟帖答案。
该问题已成功删除，仅对您可见，其他人不能够查看。
问题不是ExecutorService执行时阻塞UI线程，而是你在这里用了future.get()，它可能会阻塞线程。建议你了解一下Feture模式。
德问是一个专业的编程问答社区，请
后再提交答案
关注该问题的人
共被浏览 (3583) 次您要找的是不是:
Its nodes are configured to perform multithreaded processing of the tasks using the
ExecutorService interface.
其中节点被配置成使用 ExecutorService接口来进行多线程处理。
As great as the ExecutorService interface is, certain tasks need to be done in a scheduled fashion, such as executing a given task at determined intervals or at a specific time.
尽管 ExecutorService 接口非常有用，但某些任务仍需要以计划方式执行，比如以确定的时间间隔或在特定时间执行给定的任务。
For example, rather than calling execute() once for each task, the ExecutorService could take a collection of tasks and return a List of Futures representing the future results of each of those tasks.
例如，无需每执行一项任务就调用一次 execute()，ExecutorService 可以接受一组任务并返回一个表示每项任务的未来结果的未来列表。
$firstVoiceSent
- 来自原声例句
请问您想要如何调整此模块？
感谢您的反馈，我们会尽快进行适当修改！
请问您想要如何调整此模块？
感谢您的反馈，我们会尽快进行适当修改！Java ExecutorService生命周期 - Java教程 - 编程入门网
Java ExecutorService生命周期
ExecutorService接口继承了Executor接口，定义了一些生命周期的方法
public interface
ExecutorService extends Executor {
void shutdown();
List&Runnable& shutdownNow();
boolean isShutdown();
boolean isTerminated();
boolean awaitTermination(long timeout, TimeUnit unit)
throws InterruptedE
本文，我们逐一分析里面的每个方法。
首先，我们需要创建一个任务代码，这段任务代码 主要是随机生成含有10个字符的字符串
* 随机生成10个字符的字符串
* @author dream-victor
public class Task1 implements Callable&String& {
public String call() throws Exception {
String base = &abcdefghijklmnopqrstuvwxyz&;
Random random = new Random();
StringBuffer sb = new StringBuffer();
for (int i = 0; i & 10; i++) {
int number = random.nextInt(base.length());
sb.append(base.charAt(number));
return sb.toString();
然后，我们还需要一个长任务，这里我们默认是沉睡10秒
* 长时间任务
* @author dream-victor
public class LongTask implements Callable&String& {
public String call() throws Exception {
TimeUnit.SECONDS.sleep(10);
return &success&;
OK，所有前期准备完毕，下面我们就来分析一下ExecutorService接口中和生命周期有关的这些方 法：
1、shutdown方法：这个方法会平滑地关闭ExecutorService，当我们调用这个方法时， ExecutorService停止接受任何新的任务且等待已经提交的任务执行完成(已经提交的任务会分两类：一类是已 经在执行的，另一类是还没有开始执行的)，当所有已经提交的任务执行完毕后将会关闭ExecutorService。这 里我们先不举例在下面举例。
2、awaitTermination方法：这个方法有两个参数，一个是timeout即超 时时间，另一个是unit即时间单位。这个方法会使线程等待timeout时长，当超过timeout时间后，会监测 ExecutorService是否已经关闭，若关闭则返回true，否则返回false。一般情况下会和shutdown方法组合使用 。例如：
ExecutorService service = Executors.newFixedThreadPool(4);
service.submit(new Task1());
service.submit(new Task1());
service.submit(new LongTask());
service.submit(new Task1());
service.shutdown();
while (!service.awaitTermination(1, TimeUnit.SECONDS)) {
System.out.println(&线程池没有关闭&);
System.out.println(&线程池已经关闭&);
这段代码中，我们在第三次提交了一个长任务，这个任务 将执行10秒沉睡，紧跟着执行了一次shutdown()方法，假设：这时ExecutorService被立即关闭，下面调用 service.awaitTermination(1, TimeUnit.SECONDS)方法时应该返回true，程序执行结果应该只会打印出：& 线程池已经关闭&。但是，真实的运行结果如下：
线程池没有关闭
线程池没有关闭
线程池没有关闭
线程池没有关闭
线程池没有关闭
线程池没有关闭
线程池没有关闭
线程池没有关闭
线程池没有关闭
线程池已经关闭
这说明我们假设错误，service.awaitTermination(1, TimeUnit.SECONDS)每隔一秒 监测一次ExecutorService的关闭情况，而长任务正好需要执行10秒，因此会在前9秒监测时ExecutorService 为未关闭状态，而在第10秒时已经关闭，因此第10秒时输出：线程池已经关闭。这也验证了shutdown方法关闭 ExecutorService的条件。}