一、結果:
關於ThreadPool 中的線程調用算法,其實很簡單,每個線程都有一個自己的工作隊列local queue,此外線程池中還有一個global queue全局工作隊列,首先一個線程被創建出來后,先看看自己的工作隊列有沒有被分配task,如果沒有的話,就去global queue找task,如果還沒有的話,就去別的線程的工作隊列找Task。
第二種情況:在同步方法里調用異步方法,不wait()
如果這個異步方法進入的是global Task 則在線程飢餓的情況下,也會發生死鎖的情況。至於為什么,可以看那篇博文里的解釋,因為global Task的優先級很高,所有新產生的線程都去執行global Task,而global task又需要一個線程去執行local task,所以產生了死鎖。
二、過程
我在寫代碼的時候(.net core)有時候會碰到void方法里,
調用async方法並且Wait,而且我還看到別人這么寫了。
而且我這么寫的時候,編譯器沒有提示任何警告。
但是看了文章:一碼阻塞,萬碼等待:ASP.NET Core 同步方法調用異步方法“死鎖”的真相 了解。
1.同步方法里調用異步方法
同步方法里調用異步方法,一種是wait() 一種是不wait();
private void fun() { funAsync.Wait(); funAsync(); }
這兩種場景都沒有編譯錯誤。首先我們來看一下,在 void里調用 async 方法,
並且要等待async的結果出來之后,才能進行后續的操作。
using System; using System.Threading; using System.Threading.Tasks; namespace ConsoleTool2 { private class Program { private static void Main(string[] args) { Producer(); } private static void Producer() { var result = Process().Result; //或者 //Process().Wait(); } private static async Task<bool> Process() { await Task.Run(() => { Thread.Sleep(1000); }); Console.WriteLine("Ended - " + DateTime.Now.ToLongTimeString()); return true; } } }
這個Producer,這是一個void方法,里面調用了異步方法Process()
,
其中Process()是一個執行1秒的異步方法,調用的方式是Process().Result
或者Process().Wait()
,咱們來運行一遍。
沒有任何問題。看起來,這樣寫完全沒有問題啊,不報錯,運行也是正常的。
接下來,我們修改一下代碼,讓代碼更加接近生產環境的狀態。
using System; using System.Threading; using System.Threading.Tasks; namespace ConsoleTool2 { class Program { private static void Main(string[] args) { while (true) { Task.Run(Producer); Thread.Sleep(200); } } private static void Producer() { var result = Process().Result; } private static async Task<bool> Process() { await Task.Run(() => { Thread.Sleep(1000); }); Console.WriteLine("Ended - " + DateTime.Now.ToLongTimeString()); return true; } } }
在Main函數里加了for循環,並且1秒鍾執行5次Producer()
,使用Task.Run()
,1秒鍾有5個Task產生。相當於生產環境的qps=5。接下來我們再執行下,看看結果:
沒有CPU消耗,但是線程數一直增加,直到突破一台電腦的最大線程數,導致服務器宕機。這明顯出現問題了,線程肯定發生了死鎖,而且還在不斷產生新的線程。
至於為什么只執行了兩次Task,我們可以猜測是因為程序中初始的TreadPool 中只有兩個線程,所以執行了兩次Task,然后就發生了死鎖。
現在我們定義一個Produce2() 這是一個正常的方法,異步函數調用異步函數。
private static async Task Producer2() { await Process(); }
仔細觀察這個圖,我們發現第一秒執行了一個Task,第二秒執行了三個Task,從第三秒開始,就穩定執行了4-5次Task,這里的時間統計不是很精確,
但是可以肯定從某個時間開始,程序達到了預期效果,TreadPool中的線程每秒中都能穩定的完成任務。而且我們還能觀察到,在最開始,
程序是反應很慢的,那個時候線程不夠用,同時應該在申請新的線程,直到后來線程足夠處理這樣的情況了。咱們再看看這個時候的進程信息:
線程數一直穩定在25個,也就是說25個線程就能滿足這個程序的運行了。到此我們可以證明,在同步方法里調用異步方法確實是不安全的,尤其在並發量很高的情況下。
探究原因
我們再深層次討論下為什么同步方法里調用異步方法會卡死,而異步方法調用異步方法則很安全呢?
咱們回到一開始的代碼里,我們加上一個初始化線程數量的代碼,看看這樣是否還是會出現卡死的狀況。由於前面的分析我們知道,這個程序在一秒中並行執行5個Task,每個Task里面也就是Producer 都會執行一個Processer 異步方法,所以粗略估計需要10個線程。於是我們就初始化線程數為10個。
using System; using System.Threading; using System.Threading.Tasks; namespace ConsoleTool2 { private class Program { private static void Main(string\[\] args) { ThreadPool.SetMinThreads(10, 10); while (true) { Task.Run(Producer2); Thread.Sleep(200); } } private static void Producer() { var result = Process().Result; } private static async Task Producer2() { await Process(); } private static async Task<bool\> Process() { await Task.Run(() => { Thread.Sleep(1000); }); Console.WriteLine("Ended - " + DateTime.Now.ToLongTimeString()); return true; } } }
運行一下發現,是沒問題的。說明一開始設置多的線程是有用的,經過實驗發現,只要初始線程小於10個,都會出現死鎖。
而.net core的默認初始線程是肯定小於10個的。那么當初始線程小於10個的時候,發生什么了?發生了大家都聽說過的名詞,線程飢餓。
就是線程不夠用了,這個時候ThreadPool生產新的線程滿足需求。然后我們再關注下,同步方法里調用異步方法並且.Wait()的情況下會發生什么。
private void Producer() { Process().Wait() }
首先有一個線程A ,開始執行Producer , 它執行到了Process 的時候,新產生了一個的線程 B 去執行這個Task。
這個時候 A 會掛起,一直等 B 結束,B被釋放,然后A繼續執行剩下的過程。這樣執行一次Producer 會用到兩個線程,
並且A 一直掛起,一直不工作,一直在等B。這個時候線程A 就會阻塞。
Task Producer() { await Process(); }
這個和上面的區別就是,同時線程A,它執行到Producer的時候,產生了一個新的線程B執行 Process。
但是 A 並沒有等B,而是被ThreadPool拿來做別的事情,等B結束之后,ThreadPool 再拿一個線程出來執行剩下的部分。所以這個過程是沒有線程阻塞的。
再結合線程飢餓的情況,也就是ThreadPool 中發生了線程阻塞+線程飢餓,會發生什么呢?假設一開始只有8個線程,第一秒中會並行執行5個Task Producer,
5個線程被拿來執行這5個Task,然后這個5個線程(A)都在阻塞,並且ThreadPool 被要求再拿5個線程(B)去執行Process,但是線程池只剩下3個線程,
所以ThreadPool 需要再產生2個線程來滿足需求。但是ThreadPool 1秒鍾最多生產2個線程,等這2個線程被生產出來以后,又過去了1秒,這個時候無情又進來5個Task,又需要10個線程了。
別忘了執行第一波Task的一些線程應該釋放了,釋放多少個呢?應該是3個Task占有的線程,因為有2個在等TreadPool生產新線程嘛。
所以釋放了6個線程,5個Task,6個線程,計算一下,就可以知道,只有一個Task可以被完全執行,其他4個都因為沒有新的線程執行Process而阻塞。
於是ThreadPool 又要去產生4個新的線程去滿足4個被阻塞的Task,花了2秒時間,終於生產完了。但是糟糕又來了10個Task,需要20個線程,
而之前釋放的線程已經不足以讓任何一個Task去執行Process了,因為這些不足的線程都被分配到了Producer上,沒有線程再可以去執行Process了(經過上面的分析一個Task需要2個線程A,B,並且A阻塞,直到B執行Process完成)。
所以隨着時間的流逝,要執行的Task越來越多卻沒有一個能執行結束,而線程也在不斷產生,就產生了我們上面所說的情況。
## 我們該怎么辦?經過上面的分析我們知道,在線程飢餓的情況下,使用同步方法調用異步方法並且wait結果,是會出問題的,那么我們應該怎么辦呢?
首先當然是應該避免這種有風險的做法。其次,還有一種方法。經過實驗,我發現,使用專有線程
Task.Run(Producer);
改成
Task.Factory.StartNew(
Producer,
TaskCreationOptions.LongRunning
);
就是TaskCreationOptions.LongRunning 選項,就是開辟一個專用線程,而不是在ThreadPool中拿線程,這樣是不會發生死鎖的。
因為ThreadPool 不管理專用線程,每一個Task進來,都會有專門的線程執行,而Process 則是由ThreadPool 中的線程執行,這樣TheadPool中的線程其實是不存在阻塞的,因此也不存在死鎖。
結語
關於ThreadPool 中的線程調用算法,其實很簡單,每個線程都有一個自己的工作隊列local queue,此外線程池中還有一個global queue全局工作隊列,首先一個線程被創建出來后,先看看自己的工作隊列有沒有被分配task,如果沒有的話,就去global queue找task,如果還沒有的話,就去別的線程的工作隊列找Task。
第二種情況:在同步方法里調用異步方法,不wait()
如果這個異步方法進入的是global Task 則在線程飢餓的情況下,也會發生死鎖的情況。至於為什么,可以看那篇博文里的解釋,因為global Task的優先級很高,所有新產生的線程都去執行global Task,而global task又需要一個線程去執行local task,所以產生了死鎖。