欧美肉大捧一进一出免费视频,国产在线精品免费av

關(guān)于線程池配置不合理引發(fā)的故障，公司內(nèi)部有較多記錄，下面舉一些例子：
Case1：2018年XX頁面展示接口大量調(diào)用降級。
事故描述：XX頁面展示接口產(chǎn)生大量調(diào)用降級，數(shù)量級在幾十到上百。
事故原因：該服務(wù)展示接口內(nèi)部邏輯使用線程池做并行計算，由于沒有預(yù)估好調(diào)用的流量，導(dǎo)致最大核心數(shù)設(shè)置偏小，大量拋出
RejectedExecutionException ，觸發(fā)接口降級條件，示意圖如下：

圖14 線程數(shù)核心設(shè)置過小引發(fā)RejectExecutionException
Case2：2018年XX業(yè)務(wù)服務(wù)不可用S2級故障。
事故描述：XX業(yè)務(wù)提供的服務(wù)執(zhí)行時間過長，作為上游服務(wù)整體超時，大量下游服務(wù)調(diào)用失敗。
事故原因：該服務(wù)處理請求內(nèi)部邏輯使用線程池做資源隔離，由于隊列設(shè)置過長，最大線程數(shù)設(shè)置失效，導(dǎo)致請求數(shù)量增加時，大量任務(wù)堆積在隊列中，任務(wù)執(zhí)行時間過長，最終導(dǎo)致下游服務(wù)的大量調(diào)用超時失敗。示意圖如下：

圖15 線程池隊列長度設(shè)置過長、corePoolSize設(shè)置過小導(dǎo)致任務(wù)執(zhí)行速度低
業(yè)務(wù)中要使用線程池，而使用不當(dāng)又會導(dǎo)致故障，那么我們怎樣才能更好地使用線程池呢？針對這個問題，我們下面延展幾個方向：
1. 能否不用線程池?
回到最初的問題，業(yè)務(wù)使用線程池是為了獲取并發(fā)性，對于獲取并發(fā)性，是否可以有什么其他的方案呢替代？我們嘗試進行了一些其他方案的調(diào)研：

綜合考慮，這些新的方案都能在某種情況下提升并行任務(wù)的性能，然而本次重點解決的問題是如何更簡易、更安全地獲得的并發(fā)性。另外， Actor模型的應(yīng)用實際上甚少，只在Scala中使用廣泛，協(xié)程框架在Java中維護的也不成熟。這三者現(xiàn)階段都不是足夠的易用，也并不能解決業(yè)務(wù)上現(xiàn)階段的問題。
2. 追求參數(shù)設(shè)置合理性？
有沒有一種計算公式，能夠讓開發(fā)同學(xué)很簡易地計算出某種場景中的線程池應(yīng)該是什么參數(shù)呢？
帶著這樣的疑問，我們調(diào)研了業(yè)界的一些線程池參數(shù)配置方案：

調(diào)研了以上業(yè)界方案后，我們并沒有得出通用的線程池計算方式。并發(fā)任務(wù)的執(zhí)行情況和任務(wù)類型相關(guān) ， IO密集型和CPU密集型的任務(wù)運行起來的情況差異非常大，但這種占比是較難合理預(yù)估的，這導(dǎo)致很難有一個簡單有效的通用公式幫我們直接計算出結(jié)果。
3. 線程池參數(shù)動態(tài)化？
盡管經(jīng)過謹慎的評估，仍然不能夠保證一次計算出來合適的參數(shù) ，那么我們是否可以將修改線程池參數(shù)的成本降下來，這樣至少可以發(fā)生故障的時候可以快速調(diào)整從而縮短故障恢復(fù)的時間呢？基于這個思考，我們是否可以將線程池的參數(shù)從代碼中遷移到分布式配置中心上，實現(xiàn)線程池參數(shù)可動態(tài)配置和即時生效，線程池參數(shù)動態(tài)化前后的參數(shù)修改流程對比如下：