亚洲欧美激情在线,丝袜捆绑调教丨vk,视频在线观看免费

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