本文分析了Spring的SimpleAsyncTaskExecutor导致线程池提交任务耗时过长的问题。尽管名为"线程池"，但其实它并不复用线程，而是每次执行任务都会创建新线程，这可能导致性能瓶颈。通过查看源码，发现其在并发线程数达到限制时会等待，而非传统的线程池行为。作者提醒在使用接口前要了解其实现，遵循代码规约，明确接口职责。
前两天一个晚上，正当我沉浸在敲代码的快乐中时，听到隔壁的同事传来一声不可置信的惊呼：线程池提交命令怎么可能会执行一秒多？
线程池提交方法执行一秒多？那不对啊，线程池提交应该是一个很快的操作，一般情况下不应该执行一秒多那么长的时间。
看了一下那段代码，好像也没什么问题，就是一个简单的提交任务的代码。
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++) {
最低0.47元/天 解锁文章
131
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
