线程池三大核心参数的含义线程池核心线程数制定策略-电子发烧友网

1 前言

说到线程池八股文背的很熟的肯定知道无非就这几个考点：

（1）线程池三大核心参数 corePoolSize、maximumPoolSize、workQueue 的含义

（2）线程池核心线程数制定策略

（3）建议通过 ThreadPoolExecutor 的构造函数来声明，避免使用 Executors 创建线程池

以上考点作为线程池面试几乎必问的内容，大部分人应该都是如数家珍，张口就来，但是懂了面试八股文真的就不一定在实际运用中真的就会把线程池用好 。且看下面这次真实生产事故还原

2 事故还原

某次一位研发同事写出了下面类似的代码：

Listitems=getFromDb();
List>completableFutures=items.stream().map(item->CompletableFuture.supplyAsync(()->{
AppMapStationDatadata=mapper.copy(item);
//发起价格信息查询的RPC调用
data.setPriceInfo(priceApi.getPriceInfoById(item.getId()))
returndata;
},apiExecutor)).collect(Collectors.toList());

result=completableFutures.stream().map(e->{
returne.get();
}).filter(Objects::nonNull).collect(Collectors.toList());

上面的代码中，代码首先从数据库里面查出来一堆对象，然后对每一个对象进行模型转换，由于要获取每个对象的价格信息发起了一次RPC调用，由于RPC服务没有提供批量接口，所以代码里面用了线程池并发请求，以求得接口尽可能快的返回数据。

使用的是CompletableFuture 而且自定义了线程池，线程池指定了10个核心线程，20个最大线程，这段代码在上线后的一段时间确实没有任何问题，但是在灰度放量用户量多起来之后发现接口经常超时告警。

请问为什么上面的代码在用户量稍微大一点的时候就运行缓慢了呢？

实际代码问题出现在了这个get方法中，这个get方法没有指定超时时间，当getPriceInfoById这个接口响应变慢的时候，这个主线程的代码get又没有指定超时时间，这时候问题就来了。

由于某次业务查询查到了非常多的数据，每条数据就是个模型转换任务，这个任务就会在队列排队，get方法没有指定超时时间的情况下，其最终耗时就取决于整个线程池中执行最慢的那一个任务，所以当从DB中查出来的数据量越来越大的时候这个转换任务的最大耗时就会逐渐增加，进而引发接口超时。

所以这里改进上述问题需要做到两个点：

1、数据库中查出来的数据集合必须分页

2、get方法必须设置超时时间

此外需要知道get方法设置超时时间的计算方式也需要留意，考虑下面这种场景

提交两个任务 A 和 B 到线程池，A 任务耗时 3 秒，B 任务耗时 4 秒，Future 以 2 秒为超时时间获取任务结果

代码如下：

ExecutorServiceexecutorService=Executors.newFixedThreadPool(2);

CallabletaskA=()->{
sleep(3);
return"A";
};
CallabletaskB=()->{
sleep(4);
return"B";
};

List>futures=Stream.of(taskA,taskB)
.map(executorService::submit)
.collect(Collectors.toList());

for(Futurefuture:futures){
try{
Strings=future.get(2,TimeUnit.SECONDS);
System.out.println(s);
}catch(Exceptione){
continue;
}
}

实际运行情况是第一个任务会超时但是第二个不会 ，看起来是不是还有点不可思议，耗时时间长的任务B反而没超时。原因就在于 Future.get(long timeout, TimeUnit unit) ，调用 get 时才开始计时，而非任务加入线程池的时间

从图上就可以看出来，在获取B的任务执行结果的时候B任务已经执行了两秒，所以在等待两秒的情况下可以获取到结果

3 线程池不当使用举例

（1）不区分业务一把梭哈，全用一个线程池

曾经有一个项目，对接多个租户，每个租户都有各自的任务需要执行，代码中不区分租户的将所有租户的任务全部丢到一个线程池中执行，结果一个租户的任务提交过多导致线程池执行缓慢，但是由于线程池是同一个，影响了所有租户接口的响应时间。如果说上面说的这个场景用一个线程池产生了租户互相影响的问题还不够严重，那么下面的这种场景就问题更大了。

曾经有一段这样的场景，因为共用线程池直接导致线程池任务永远完成不了，请看下面的这种情况：

首先向线程池中提交了一个任务，然后在这个任务的内部实现中又往同一个线程池中再次提交了一个任务，相当于父子任务在同一个线程池中执行，这时候极有可出现线程死锁也就是循环等待的情况

如上图所示，父任务全部处于执行状态，这时候子任务想要执行需要等父任务执行完成，但是父任务都执行不完，因为还有个子任务没完成，即父任务等待子任务执行完成，而子任务等待父任务释放线程池资源，这也就造成了 "死锁"

所以综上所述，在代码中应该避免各种任务都往一个线程池中投放，对每个线程池指定好线程名称，做好分类比较合适，这里在日常开发中比较推荐使用Guava的工具类，来指定线程名称前缀，这样使用jstack分析线程问题也方便排查。

ThreadFactorythreadFactory=newThreadFactoryBuilder()
.setNameFormat(threadNamePrefix+"-%d")
.setDaemon(true).build();
ExecutorServicethreadPool=newThreadPoolExecutor(
corePoolSize,
maximumPoolSize,
keepAliveTime,
TimeUnit.MINUTES,
workQueue,
threadFactory);

（2）@Async注解不自己定义线程池

@Async用在方法上标识这是一个异步方法，如果不自己指定线程池这个方法将直接新建一个线程执行，可以翻看spring实现源码知道这个点

@Async的实现其实非常简单就是利用AOP，容器启动的时候会扫描所有被打上@Async注解的方法，并代理这些方法的执行，在执行这个方法的时候，生成Callable任务丢到线程池中执行（核心代码位于org.springframework.aop.interceptor.AsyncExecutionInterceptor）

@Override
@Nullable
publicObjectinvoke(finalMethodInvocationinvocation)throwsThrowable{
ClasstargetClass=(invocation.getThis()!=null?AopUtils.getTargetClass(invocation.getThis()):null);
MethodspecificMethod=ClassUtils.getMostSpecificMethod(invocation.getMethod(),targetClass);
finalMethoduserDeclaredMethod=BridgeMethodResolver.findBridgedMethod(specificMethod);

AsyncTaskExecutorexecutor=determineAsyncExecutor(userDeclaredMethod);
if(executor==null){
thrownewIllegalStateException(
"NoexecutorspecifiedandnodefaultexecutorsetonAsyncExecutionInterceptoreither");
}
//将方法调用封装成Callable实例丢入线程池中执行
Callable