线程池出问题怎么办（线程池使用的10个坑）

日常开发中，为了更好管理线程资源，减少创建线程和销毁线程的资源损耗，我们会使用线程池来执行一些异步任务。但是线程池使用不当，就可能会引发生产事故。今天跟大家聊聊线程池的10个坑。大家看完肯定会有帮助的~

1. 线程池默认使用无界队列，任务过多导致OOM
2. 线程创建过多，导致OOM
3. 共享线程池，次要逻辑拖垮主要逻辑
4. 线程池拒绝策略的坑
5. Spring内部线程池的坑
6. 使用线程池时，没有自定义命名
7. 线程池参数设置不合理
8. 线程池异常处理的坑
9. 使用完线程池忘记关闭
10. ThreadLocal与线程池搭配，线程复用，导致信息错乱。

JDK开发者提供了线程池的实现类，我们基于Executors组件，就可以快速创建一个线程池。日常工作中，一些小伙伴为了开发效率，反手就用Executors新建个线程池。写出类似以下的代码：

/** * 公众号；捡田螺的小男孩 */ public class NewFixedTest { public static void main(String[] args) { ExecutorService executor = Executors.newFixedThreadPool(10); for (int i = 0; i < Integer.MAX_VALUE; i ) { executor.execute(() -> { try { Thread.sleep(10000); } catch (InterruptedException e) { //do nothing } }); } } } 复制代码

使用newFixedThreadPool创建的线程池，是会有坑的，它默认是无界的阻塞队列，如果任务过多，会导致OOM问题。 运行一下以上代码，出现了OOM。

Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371) at com.example.dto.NewFixedTest.main(NewFixedTest.java:14) 复制代码

这是因为newFixedThreadPool使用了无界的阻塞队列的LinkedBlockingQueue，如果线程获取一个任务后，任务的执行时间比较长(比如，上面demo代码设置了10秒)，会导致队列的任务越积越多，导致机器内存使用不停飙升， 最终出现OOM。

看下newFixedThreadPool的相关源码，是可以看到一个无界的阻塞队列的，如下：

//阻塞队列是LinkedBlockingQueue，并且是使用的是无参构造函数 public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()); } //无参构造函数，默认最大容量是Integer.MAX_VALUE，相当于无界的阻塞队列的了 public LinkedBlockingQueue() { this(Integer.MAX_VALUE); } 复制代码

因此，工作中，建议大家自定义线程池，并使用指定长度的阻塞队列。

有些小伙伴说，既然Executors组件创建出的线程池newFixedThreadPool，使用的是无界队列，可能会导致OOM。那么，Executors组件还可以创建别的线程池，如newCachedThreadPool，我们用它也不行嘛？

我们可以看下newCachedThreadPool的构造函数：

public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>()); } 复制代码

它的最大线程数是Integer.MAX_VALUE。大家应该意识到使用它，可能会引发什么问题了吧。没错，如果创建了大量的线程也有可能引发OOM！

笔者在以前公司，遇到这么一个OOM问题：一个第三方提供的包，是直接使用new Thread实现多线程的。在某个夜深人静的夜晚，我们的监控系统报警了。。。这个相关的业务请求瞬间特别多，监控系统告警OOM了。

所以我们使用线程池的时候，还要当心线程创建过多，导致OOM问题。大家尽量不要使用newCachedThreadPool，并且如果自定义线程池时，要注意一下最大线程数。

3. 共享线程池，次要逻辑拖垮主要逻辑

要避免所有的业务逻辑共享一个线程池。比如你用线程池A来做登录异步通知，又用线程池A来做对账。如下图：

如果对账任务checkBillService响应时间过慢，会占据大量的线程池资源，可能直接导致没有足够的线程资源去执行loginNotifyService的任务，最后影响登录。就这样，因为一个次要服务，影响到重要的登录接口，显然这是绝对不允许的。因此，我们不能将所有的业务一锅炖，都共享一个线程池，因为这样做，风险太高了，犹如所有鸡蛋放到一个篮子里。应当做线程池隔离！

4. 线程池拒绝策略的坑，使用不当导致阻塞

我们知道线程池主要有四种拒绝策略，如下：

• AbortPolicy: 丢弃任务并抛出RejectedExecutionException异常。(默认拒绝策略)
• DiscardPolicy：丢弃任务，但是不抛出异常。
• DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务。
• CallerRunsPolicy：由调用方线程处理该任务。

如果线程池拒绝策略设置不合理，就容易有坑。我们把拒绝策略设置为DiscardPolicy或DiscardOldestPolicy并且在被拒绝的任务，Future对象调用get()方法,那么调用线程会一直被阻塞。

我们来看个demo：

/** * 关注公众号：捡田螺的小男孩 */ public class DiscardThreadPoolTest { public static void main(String[] args) throws ExecutionException, InterruptedException { // 一个核心线程，队列最大为1，最大线程数也是1.拒绝策略是DiscardPolicy ThreadPoolExecutor executorService = new ThreadPoolExecutor(1, 1, 1L, TimeUnit.MINUTES, new ArrayBlockingQueue<>(1), new ThreadPoolExecutor.DiscardPolicy()); Future f1 = executorService.submit(()-> { System.out.println("提交任务1"); try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } }); Future f2 = executorService.submit(()->{ System.out.println("提交任务2"); }); Future f3 = executorService.submit(()->{ System.out.println("提交任务3"); }); System.out.println("任务1完成 " f1.get());// 等待任务1执行完毕 System.out.println("任务2完成" f2.get());// 等待任务2执行完毕 System.out.println("任务3完成" f3.get());// 等待任务3执行完毕 executorService.shutdown();// 关闭线程池，阻塞直到所有任务执行完毕 } } 复制代码

运行结果：一直在运行中。。。

这是因为DiscardPolicy拒绝策略，是什么都没做，源码如下：

public static class DiscardPolicy implements RejectedExecutionHandler { /** * Creates a {@code DiscardPolicy}. */ public DiscardPolicy() { } /** * Does nothing, which has the effect of discarding task r. */ public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { } } 复制代码

我们再来看看线程池 submit 的方法：

public Future<?> submit(Runnable task) { if (task == null) throw new NullPointerException(); //把Runnable任务包装为Future对象 RunnableFuture<Void> ftask = newTaskFor(task, null); //执行任务 execute(ftask); //返回Future对象 return ftask; } public FutureTask(Runnable runnable, V result) { this.callable = Executors.callable(runnable, result); this.state = NEW; //Future的初始化状态是New } 复制代码

我们再来看看Future的get() 方法

//状态大于COMPLETING，才会返回，要不然都会阻塞等待 public V get() throws InterruptedException, ExecutionException { int s = state; if (s <= COMPLETING) s = awaitDone(false, 0L); return report(s); } FutureTask的状态枚举 private static final int NEW = 0; private static final int COMPLETING = 1; private static final int NORMAL = 2; private static final int EXCEPTIONAL = 3; private static final int CANCELLED = 4; private static final int INTERRUPTING = 5; private static final int INTERRUPTED = 6; 复制代码

阻塞的真相水落石出啦，FutureTask的状态大于COMPLETING才会返回，要不然都会一直阻塞等待。又因为拒绝策略啥没做，没有修改FutureTask的状态，因此FutureTask的状态一直是NEW，所以它不会返回，会一直等待。

这个问题，可以使用别的拒绝策略，比如CallerRunsPolicy，它让主线程去执行拒绝的任务，会更新FutureTask状态。如果确实想用DiscardPolicy，则需要重写DiscardPolicy的拒绝策略。

温馨提示，日常开发中，使用 Future.get() 时，尽量使用带超时时间的，因为它是阻塞的。

future.get(1, TimeUnit.SECONDS); 复制代码

难道使用别的拒绝策略，就万无一失了嘛？ 不是的，如果使用CallerRunsPolicy拒绝策略，它表示拒绝的任务给调用方线程用，如果这是主线程，那会不会可能也导致主线程阻塞呢？总结起来，大家日常开发的时候，多一份心眼吧，多一点思考吧。

5. Spring内部线程池的坑

工作中，个别开发者，为了快速开发，喜欢直接用spring的@Async，来执行异步任务。

@Async public void testAsync() throws InterruptedException { System.out.println("处理异步任务"); TimeUnit.SECONDS.sleep(new Random().nextInt(100)); } 复制代码

Spring内部线程池，其实是SimpleAsyncTaskExecutor，这玩意有点坑，它不会复用线程的，它的设计初衷就是执行大量的短时间的任务。有兴趣的小伙伴，可以去看看它的源码：

/** * {@link TaskExecutor} implementation that fires up a new Thread for each task, * executing it asynchronously. * * <p>Supports limiting concurrent threads through the "concurrencyLimit" * bean property. By default, the number of concurrent threads is unlimited. * * <p><b>NOTE: This implementation does not reuse threads!</b> Consider a * thread-pooling TaskExecutor implementation instead, in particular for * executing a large number of short-lived tasks. * * @author Juergen Hoeller * @since 2.0 * @see #setConcurrencyLimit * @see SyncTaskExecutor * @see org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor * @see org.springframework.scheduling.commonj.WorkManagerTaskExecutor */ @SuppressWarnings("serial") public class SimpleAsyncTaskExecutor extends CustomizableThreadCreator implements AsyncListenableTaskExecutor, Serializable { ...... } 复制代码

也就是说来了一个请求，就会新建一个线程！大家使用spring的@Async时，要避开这个坑，自己再定义一个线程池。正例如下：

@Bean(name = "threadPoolTaskExecutor") public Executor threadPoolTaskExecutor() { ThreadPoolTaskExecutor executor=new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(10); executor.setThreadNamePrefix("tianluo-%d"); // 其他参数设置 return new ThreadPoolTaskExecutor(); } 复制代码

6. 使用线程池时，没有自定义命名

使用线程池时，如果没有给线程池一个有意义的名称，将不好排查回溯问题。这不算一个坑吧，只能说给以后排查埋坑，哈哈。我还是单独把它放出来算一个点，因为个人觉得这个还是比较重要的。反例如下：

/** * 关注公众号：捡田螺的小男孩 */ public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20)); executorOne.execute(()->{ System.out.println("关注公众号：捡田螺的小男孩"); throw new NullPointerException(); }); } } 复制代码

运行结果：

关注公众号：捡田螺的小男孩 Exception in thread "pool-1-thread-1" java.lang.NullPointerException at com.example.dto.ThreadTest.lambda$main$0(ThreadTest.java:17) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) 复制代码

可以发现，默认打印的线程池名字是pool-1-thread-1，如果排查问题起来，并不友好。因此建议大家给自己线程池自定义个容易识别的名字。其实用CustomizableThreadFactory即可，正例如下：

public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20),new CustomizableThreadFactory("Tianluo-Thread-pool")); executorOne.execute(()->{ System.out.println("关注公众号：捡田螺的小男孩"); throw new NullPointerException(); }); } } 复制代码

7. 线程池参数设置不合理

线程池最容易出坑的地方，就是线程参数设置不合理。比如核心线程设置多少合理，最大线程池设置多少合理等等。当然，这块不是乱设置的，需要结合具体业务。

比如线程池如何调优，如何确认最佳线程数？

最佳线程数目 = （（线程等待时间 线程CPU时间）/线程CPU时间 ）* CPU数目 复制代码

我们的服务器CPU核数为8核，一个任务线程cpu耗时为20ms，线程等待（网络IO、磁盘IO）耗时80ms，那最佳线程数目：( 80 20 )/20 * 8 = 40。也就是设置 40个线程数最佳。

有兴趣的小伙伴，也可以看这篇文章哈： 线程池到底设置多少线程比较合适？

对于线程池参数，如果小伙伴还有疑惑的话，可以看我之前这篇文章哈：Java线程池解析

8. 线程池异常处理的坑

我们来看段代码：

/** * 关注公众号：捡田螺的小男孩 */ public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20),new CustomizableThreadFactory("Tianluo-Thread-pool")); for (int i = 0; i < 5; i ) { executorOne.submit(()->{ System.out.println("current thread name" Thread.currentThread().getName()); Object object = null; System.out.print("result## " object.toString()); }); } } } 复制代码

按道理，运行这块代码应该抛空指针异常才是的，对吧。但是，运行结果却是这样的;

current thread nameTianluo-Thread-pool1 current thread nameTianluo-Thread-pool2 current thread nameTianluo-Thread-pool3 current thread nameTianluo-Thread-pool4 current thread nameTianluo-Thread-pool5 复制代码

这是因为使用submit提交任务，不会把异常直接这样抛出来。大家有兴趣的话，可以去看看源码。可以改为execute方法执行，当然最好就是try...catch捕获，如下：

/** * 关注公众号：捡田螺的小男孩 */ public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20),new CustomizableThreadFactory("Tianluo-Thread-pool")); for (int i = 0; i < 5; i ) { executorOne.submit(()->{ System.out.println("current thread name" Thread.currentThread().getName()); try { Object object = null; System.out.print("result## " object.toString()); }catch (Exception e){ System.out.println("异常了" e); } }); } } } 复制代码

其实，我们还可以为工作者线程设置UncaughtExceptionHandler，在uncaughtException方法中处理异常。大家知道这个坑就好啦。

9. 线程池使用完毕后，忘记关闭

如果线程池使用完，忘记关闭的话，有可能会导致内存泄露问题。所以，大家使用完线程池后，记得关闭一下。同时，线程池最好也设计成单例模式，给它一个好的命名，以方便排查问题。

public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20), new CustomizableThreadFactory("Tianluo-Thread-pool")); executorOne.execute(() -> { System.out.println("关注公众号：捡田螺的小男孩"); }); //关闭线程池 executorOne.shutdown(); } } 复制代码

10. ThreadLocal与线程池搭配，线程复用，导致信息错乱。

使用ThreadLocal缓存信息，如果配合线程池一起，有可能出现信息错乱的情况。先看下一下例子：

private static final ThreadLocal<Integer> currentUser = ThreadLocal.withInitial(() -> null); @GetMapping("wrong") public Map wrong(@RequestParam("userId") Integer userId) { //设置用户信息之前先查询一次ThreadLocal中的用户信息 String before = Thread.currentThread().getName() ":" currentUser.get(); //设置用户信息到ThreadLocal currentUser.set(userId); //设置用户信息之后再查询一次ThreadLocal中的用户信息 String after = Thread.currentThread().getName() ":" currentUser.get(); //汇总输出两次查询结果 Map result = new HashMap(); result.put("before", before); result.put("after", after); return result; } 复制代码

按理说，每次获取的before应该都是null，但是呢，程序运行在 Tomcat 中，执行程序的线程是Tomcat的工作线程，而Tomcat的工作线程是基于线程池的。

线程池会重用固定的几个线程，一旦线程重用，那么很可能首次从 ThreadLocal 获取的值是之前其他用户的请求遗留的值。这时，ThreadLocal 中的用户信息就是其他用户的信息。

把tomcat的工作线程设置为1

server.tomcat.max-threads=1 复制代码

用户1，请求过来，会有以下结果，符合预期：

用户2请求过来，会有以下结果，「不符合预期」：

因此，使用类似 ThreadLocal 工具来存放一些数据时，需要特别注意在代码运行完后，显式地去清空设置的数据，正例如下：

@GetMapping("right") public Map right(@RequestParam("userId") Integer userId) { String before = Thread.currentThread().getName() ":" currentUser.get(); currentUser.set(userId); try { String after = Thread.currentThread().getName() ":" currentUser.get(); Map result = new HashMap(); result.put("before", before); result.put("after", after); return result; } finally { //在finally代码块中删除ThreadLocal中的数据，确保数据不串 currentUser.remove(); } }

前两天一个晚上，正当我沉浸在敲代码的快乐中时，听到隔壁的同事传来一声不可置信的惊呼：线程池提交命令怎么可能会执行一秒多？

线程池提交方法执行一秒多？那不对啊，线程池提交应该是一个很快的操作，一般情况下不应该执行一秒多那么长的时间。

看了一下那段代码，好像也没什么问题，就是一个简单的提交任务的代码。

复制代码executor.execute( () -> { // 具体的任务代码 // 这里有个for循环 });

虽然执行的Job里面有一个for循环，可能比较耗时，但是execute提交任务的时候，并不会去真正去执行Job，所以应该不是这个原因引起的。

分析

看到这个情况，我们首先想到的是线程池提交任务时候的一个处理过程：

线程池原理图

然后逐个分析一下有可能耗时一秒多的操作：

创建线程耗时？

根据上面的图，我们可以知道，如果核心线程数量设置过大，就可能会不断创建新的核心线程去执行任务。同理，如果核心线程池和任务队列都满了，会创建非核心线程去执行任务。

创建线程是比较耗时的，而且Java线程池在这里创建线程的时候还上了锁。

复制代码final ReentrantLock mainLock = this.mainLock; mainLock.lock();

我们写个简单的程序，可以模拟出来线程池耗时的操作，下面这段代码创建2w个线程，在我的电脑里大概会耗时6k多毫秒。

复制代码long before = System.currentTimeMillis(); for (int i = 0; i < 20000; i ) { // doSomething里面睡眠一秒 new Thread(() -> doSomething()).start(); } long after = System.currentTimeMillis(); // 下面这行在我的电脑里输出6139 System.out.println(after - before);

但是看了一下我们的监控，线程数量一直比较健康，应该不是这个原因。再说那个地方新线程也不太可能达到这个量级。

入任务队列耗时？

线程池的任务队列是一个同步队列。所以入队列操作是同步的。

常用的几个同步队列：

1. LinkedBlockingQueue
2. 链式阻塞队列，底层数据结构是链表，默认大小是Integer.MAX_VALUE，也可以指定大小。
3. ArrayBlockingQueue
4. 数组阻塞队列，底层数据结构是数组，需要指定队列的大小。
5. SynchronousQueue
6. 同步队列，内部容量为0，每个put操作必须等待一个take操作，反之亦然。
7. DelayQueue
8. 延迟队列，该队列中的元素只有当其指定的延迟时间到了，才能够从队列中获取到该元素 。

所以使用特殊的同步队列还是有可能导致execute方法阻塞一秒多的，比如SynchronousQueue。如果配合一个特殊的“拒绝策略”，是有可能造成这个现象的，我们将在下面给出例子。

拒绝策略？

线程数量达到最大线程数就会采用拒绝处理策略，四种拒绝处理的策略为 ：

1. ThreadPoolExecutor.AbortPolicy：默认拒绝处理策略，丢弃任务并抛出异常。
2. ThreadPoolExecutor.DiscardPolicy：丢弃新来的任务，但是不抛出异常。
3. ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列头部（最旧的）的任务，然后重新尝试执行程序（如果再次失败，重复此过程）。
4. ThreadPoolExecutor.CallerRunsPolicy：由调用线程处理该任务。

可以看到，前面三种拒绝处理策略都是会“丢弃”任务，而最后一种不会。最后一种拒绝策略配合上面的SynchronousQueue，就有可能造成我们遇到的情况。示例代码：

复制代码Executor executor = new ThreadPoolExecutor(2,2, 2, TimeUnit.MILLISECONDS,new SynchronousQueue<>(), new ThreadPoolExecutor.CallerRunsPolicy()); for (int i = 0; i < 3; i ) { long before = System.currentTimeMillis(); executor.execute( () -> { // doSomething里面睡眠一秒 doSomething(); }); long after = System.currentTimeMillis(); // 下面这段代码，第三行会输出1001 System.out.println(after - before); }

SimpleAsyncTaskExecutor

所以我们遇到的问题会是上面的种种原因导致的吗？带着这些猜测，我们去找到了定义executor的代码。

复制代码SimpleAsyncTaskExecutor executor = new SimpleAsyncTaskExecutor(); executor.setConcurrencyLimit(20);

设置最大并发数量是20好像没什么问题，等等，这个SimpleAsyncTaskExecutor是个什么鬼？

好像是Spring提供的一个线程池吧……（声音逐渐不自信）

em…看了一下包的定义，org.springframework.core.task，确实是Spring提供的。至于是不是线程池，先看看类图：

实现的是Executor接口，但是继承树里为什么没有ThreadPoolExecutor？我们猜测可能是Spring自己实现了一个线程池？虽然应该没什么必要。

源码

带着疑问，我们继续看了一下这个类的源码。主要看execute方法，发现每次执行之前，都要先调用一个beforeAccess方法，这个方法里面有这样一段很奇怪的代码

beforeAccess

while循环去检查，如果当前并发线程数量大于等于设置的最大值，就等待。

找到原因了，这应该就是罪魁祸首。可是为什么Spring要这么设计呢？

我们在SimpleAsyncTaskExecutor类的注释上面找到了作者的留言：

复制代码 * <p><b>NOTE: This implementation does not reuse threads!</b> Consider a * thread-pooling TaskExecutor implementation instead, in particular for * executing a large number of short-lived tasks.

大概意思就是：这个实现并不复用线程，如果你要复用线程请去使用线程池的实现。这个是用来执行很多耗时很短的任务的。

至此，真相大白。

反思使用接口前先了解一下

造成这个问题的根本原因是，我们以为SimpleAsyncTaskExecutor是一个“线程池”，而其实它不是！！！

我们在使用开源项目的时候，往往直接就用了，不会去仔细看看它的源码，也可能没有考虑清楚它的应用环境。等到程序出问题了才发现，已经晚了。

所以使用接口之前最好先了解一下，至少要看看官方文档或者接口文档/注释。

哪怕是真的出问题了，看源码也不失为一种排查问题的方式，因为代码都是死的，它不会骗人。

代码规约

阿里有这么一个代码规约：不建议我们直接使用Executors类中的线程池，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学需要更加明确线程池的运行规则，规避资源耗尽的风险。

以前我还不太理解，心想使用Executors类可以提高可读性，JDK提供了这样的工具类，不用白不用。直到遇到这个问题，才明白这条规约的良苦用心。

如果我们使用规范的方式去使用线程池，而不是用一个所谓的Spring提供的“线程池”，就不会遇到这个问题了。

明确接口职责

再来想一想为什么同事会把它当成一个线程池？因为它的类名、方法名都太像一个线程池了。它实现了Executor接口的execute方法，才导致我们误以为它是一个线程池。

所以回归到Executor这个接口上来，它的职责究竟是什么？我们可以在JDK的execute方法上看到这个注释：

复制代码/** * Executes the given command at some time in the future. The command * may execute in a new thread, in a pooled thread, or in the calling * thread, at the discretion of the {@code Executor} implementation. */

大意就是，在将来某个时间执行传入的命令，这个命令可能会在一个新的线程里面执行，可能会在线程池里，也可能在调用这个方法的线程中，具体怎么执行是由实现类去决定的。

所以这才是Executor这个类的职责，它的职责并不是提供一个线程池的接口，而是提供一个“将来执行命令”的接口。

所以，真正能代表线程池意义的，是ThreadPoolExecutor类，而不是Executor接口。

在我们写代码的时候，也要定义清楚接口的职责哟。这样别人用你的接口或者阅读源码的时候，才不会疑惑。

,