SpringBoot中線程池的設置
前言
多線程的設置是編程比較重要的一環，無論是工作編程還是面試，是一個老生常談的話題，多線程一定比單線程跑的快嗎?答案肯定是no，什么時候使用多線程合適，什么場景下使用?線程池的配置又改怎么配置，本文進行一篇總結，歡迎朋友們交流。
1.一些概念介紹:
1.1計算機基礎知識：
計算機主要組件衛CPU、內存、磁盤，三大組件中，CPU的運行速率高于內存的1000倍以上，內存的運行速率高于磁盤1000倍以上。對比運行速率結果為：CPU>內存>磁盤。
1.2上下文切換：
涉及到上下文切換，單核cpu切換是沒意義的，多核cpu的切換才能真正的滿足充分利用資源達到高性能的目的。
1.3線程爭用：
當多個線程執行任務不相同，但是訪問資源又相同的時候，有看呢過會引起數據問題。
1.4并發執行：
可以理解為線程執行任務相同，訪問資源相同的時候觸發的場景。
1.5 自旋鎖:
很形象的一個比喻是：沖奶的時候孩子還在哭，等著媽媽送來奶瓶和換尿布，直到媽媽處理好所有的事情才算結束，要不然就是個一直等待的狀態。
1.6 互斥鎖:
它跟自旋鎖類似，不同的是競選失敗線程會回去睡覺,直到鎖可用來競爭。一直進行循環等。
1.7 樂觀鎖:
很常見的樂觀鎖的例子是在數據庫的數據操作中，直到提交更新的時候才給相關的數據行加鎖。
1.8 悲觀鎖:
悲觀鎖就是如果一個事務操作用了鎖，那只有當這個事務把鎖釋放(把媽媽給釋放)，其他事務才能夠執行與該鎖沖突的操作。
1.9 時間片分配算法:
CPU通過給每個線程分配CPU時間來實現任務運行，這個時間片一般是幾十毫秒。這樣不停地來回切換任務，運行程序，劃分時間片，就叫做:時間片分配算法。
2.線程池配置介紹:
因為線程池的設置肯定是跟著服務器硬件和業務處理走的，所以不通場景下配置是不一樣的。場景假設：
| key值 | 配置值 | 備注 |
|---|---|---|
| tasks(系統每秒任務數) | 每秒的任務數，假設為100~1000 | |
| taskcost(執行任務花的時間) | 每個任務花費時間，假設為0.1s | |
| responsetime （允許響應的最大時間） | 系統允許容忍的最大響應時間，假設為1s |
計算公式：
| 設置key值 | 計算公式 | 備注 |
|---|---|---|
| 核心線程數設置(corePoolSize) | threadcount = tasks/(1/taskcost) =tasks*taskcost = (200~1000)*0.1 = 20~100 個線程 | corePoolSize設置應該大于20 根據8020原則，如果80%的每秒任務數小于200，那么corePoolSize設置為20即可 |
| 隊列數設置(queueCapacity) | 計算可得 queueCapacity = 20/0.1*1 = 200 | 意思是隊列里的線程可以等待1s，超過了的需要新開線程來執行 切記不能設置為Integer.MAX_VALUE，這樣隊列會很大，線程數只會保持在corePoolSize大小，當任務陡增時，不能新開線程來執行，響應時間會隨之陡增 |
| 最大線程數設置(maxPoolSize) | 計算可得 maxPoolSize = (1000-200)/10 = 80 | （最大任務數-隊列容量）/每個線程每秒 |
3.總結:
多線程的使用場景是多個任務執行，但是CPU處理時間不長，占用的時間片不高，那么多線程會很大的提升性能，相反，多線程還沒有單線程快。SpringBoot中比較重要的線程池的概念三個：核心線程數、隊列數、最大線程數。當任務來臨的時候如果corePoolSize 沒有達到那么會創建新的線程執行任務直到corePoolSize 達到設定值的時候開始進入到隊列中，隊列滿了以后開始創建新的線程直到最大線程maxPoolSize 的設置值，全部滿的時候開始執行設置的拒絕策略。
