1 前言

說到線程池八股文背的很熟的肯定知道無非就這幾個考點：

（1）線程池三大核心參數(shù) corePoolSize、maximumPoolSize、workQueue 的含義

（2）線程池核心線程數(shù)制定策略

（3）建議通過 ThreadPoolExecutor 的構造函數(shù)來聲明，避免使用 Executors 創(chuàng)建線程池

以上考點作為線程池面試幾乎必問的內(nèi)容，大部分人應該都是如數(shù)家珍，張口就來，但是懂了面試八股文真的就不一定在實際運用中真的就會把線程池用好 。且看下面這次真實生產(chǎn)事故還原

2 事故還原

某次一位研發(fā)同事寫出了下面類似的代碼：

Listitems=getFromDb();
List>completableFutures=items.stream().map(item->CompletableFuture.supplyAsync(()->{
AppMapStationDatadata=mapper.copy(item);
//發(fā)起價格信息查詢的RPC調(diào)用
data.setPriceInfo(priceApi.getPriceInfoById(item.getId()))
returndata;
},apiExecutor)).collect(Collectors.toList());

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

上面的代碼中，代碼首先從數(shù)據(jù)庫里面查出來一堆對象，然后對每一個對象進行模型轉(zhuǎn)換，由于要獲取每個對象的價格信息發(fā)起了一次RPC調(diào)用，由于RPC服務沒有提供批量接口，所以代碼里面用了線程池并發(fā)請求，以求得接口盡可能快的返回數(shù)據(jù)。

使用的是CompletableFuture 而且自定義了線程池，線程池指定了10個核心線程，20個最大線程，這段代碼在上線后的一段時間確實沒有任何問題，但是在灰度放量用戶量多起來之后發(fā)現(xiàn)接口經(jīng)常超時告警。

請問為什么上面的代碼在用戶量稍微大一點的時候就運行緩慢了呢？

實際代碼問題出現(xiàn)在了這個get方法中，這個get方法沒有指定超時時間，當getPriceInfoById這個接口響應變慢的時候，這個主線程的代碼get又沒有指定超時時間，這時候問題就來了。

由于某次業(yè)務查詢查到了非常多的數(shù)據(jù)，每條數(shù)據(jù)就是個模型轉(zhuǎn)換任務，這個任務就會在隊列排隊，get方法沒有指定超時時間的情況下，其最終耗時就取決于整個線程池中執(zhí)行最慢的那一個任務，所以當從DB中查出來的數(shù)據(jù)量越來越大的時候這個轉(zhuǎn)換任務的最大耗時就會逐漸增加，進而引發(fā)接口超時。

所以這里改進上述問題需要做到兩個點：

1、數(shù)據(jù)庫中查出來的數(shù)據(jù)集合必須分頁

2、get方法必須設置超時時間

此外需要知道get方法設置超時時間的計算方式也需要留意，考慮下面這種場景

提交兩個任務 A 和 B 到線程池，A 任務耗時 3 秒，B 任務耗時 4 秒，F(xiàn)uture 以 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) ，調(diào)用 get 時才開始計時，而非任務加入線程池的時間

從圖上就可以看出來，在獲取B的任務執(zhí)行結果的時候B任務已經(jīng)執(zhí)行了兩秒，所以在等待兩秒的情況下可以獲取到結果

3 線程池不當使用舉例

（1）不區(qū)分業(yè)務一把梭哈，全用一個線程池

曾經(jīng)有一個項目，對接多個租戶，每個租戶都有各自的任務需要執(zhí)行，代碼中不區(qū)分租戶的將所有租戶的任務全部丟到一個線程池中執(zhí)行，結果一個租戶的任務提交過多導致線程池執(zhí)行緩慢，但是由于線程池是同一個，影響了所有租戶接口的響應時間。如果說上面說的這個場景用一個線程池產(chǎn)生了租戶互相影響的問題還不夠嚴重，那么下面的這種場景就問題更大了。

曾經(jīng)有一段這樣的場景，因為共用線程池直接導致線程池任務永遠完成不了，請看下面的這種情況：

首先向線程池中提交了一個任務，然后在這個任務的內(nèi)部實現(xiàn)中又往同一個線程池中再次提交了一個任務，相當于父子任務在同一個線程池中執(zhí)行，這時候極有可出現(xiàn)線程死鎖也就是循環(huán)等待的情況

如上圖所示，父任務全部處于執(zhí)行狀態(tài)，這時候子任務想要執(zhí)行需要等父任務執(zhí)行完成，但是父任務都執(zhí)行不完，因為還有個子任務沒完成，即父任務等待子任務執(zhí)行完成，而子任務等待父任務釋放線程池資源，這也就造成了 "死鎖"

所以綜上所述，在代碼中應該避免各種任務都往一個線程池中投放，對每個線程池指定好線程名稱，做好分類比較合適，這里在日常開發(fā)中比較推薦使用Guava的工具類，來指定線程名稱前綴，這樣使用jstack分析線程問題也方便排查。

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

（2）@Async注解不自己定義線程池

@Async用在方法上標識這是一個異步方法，如果不自己指定線程池這個方法將直接新建一個線程執(zhí)行，可以翻看spring實現(xiàn)源碼知道這個點

@Async的實現(xiàn)其實非常簡單就是利用AOP，容器啟動的時候會掃描所有被打上@Async注解的方法，并代理這些方法的執(zhí)行，在執(zhí)行這個方法的時候，生成Callable任務丟到線程池中執(zhí)行（核心代碼位于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");
}
//將方法調(diào)用封裝成Callable實例丟入線程池中執(zhí)行
Callable