多線程之旅(10)_QueueUserWorkItem和UnsafeQueueUserWorkItem的區別「建議收藏」

這是個比較冷門的點，是我在寫多線程之旅(2)_創建一個屬于自己的精簡線程池_線程調度策略——附C#源碼這篇文章時，發現在做線程隊列時，官方選用的是Unsafequeueuserworkitem，而不是常見的QueueUserWorkItem，所以后續我就對這兩個方法調查一番，發現資料也不多，總結一下。

一、官方定義

首先看一下官方的定義：

來源：

https://docs.microsoft.com/zh-cn/dotnet/api/system.threading.threadpool.queueuserworkitem?view=netframework-4.8

https://docs.microsoft.com/zh-cn/dotnet/api/system.threading.threadpool.unsafequeueuserworkitem?view=netframework-4.8

（1）QueueUserWorkItem(WaitCallback, Object)

將方法排入隊列以便執行，并指定包含該方法所用數據的對象。此方法在有線程池線程變得可用時執行。

參數：

WaitCallback，它表示要執行的方法。

Object，包含方法所用數據的對象。

（2）UnsafeQueueUserWorkItem(WaitCallback, Object)

將指定的委托排隊到線程池，但不會將調用堆棧傳播到輔助線程。

參數：

WaitCallback，表示當線程池中的線程選擇工作項時調用的委托。

Object，在接受線程池服務時傳遞給委托的對象。

二、解析

看著上面的官方解釋，一如既往的迷，不用擔心是之上問題，或許是因為翻譯問題使得很難理解。

下面我用一篇文章（http://www.csframework.com/archive/2/arc-2-20110727-1759.htm）中的一段描述來解釋這個問題：

threadpool類有一個UnsafeQueueUserWorkItem方法。該方法與平時調用的QueueUserWorkItem方法非常相似。下面先簡單介 紹一下這兩個方法的區別：

當有線程試圖訪問一個受限資源（如打開一個文件）時，clr將執行一個代碼訪問安全（code access security， cas）檢查。也就是說，clr將檢查調用線程的調用堆棧中的所有程序集是否都有訪問資源的許可權限。如果有一些程序集沒有所需 的許可權限，clr將拋出一個securityexception異常。假設正在執行代碼的線程所在的程序集沒有打開文件的許可權限，那么在線程試圖打開文件時，clr將拋出一個securityexception異常。

為讓線程繼續運行，線程可以在線程池的隊列加入一個工作項，讓線程池中的線程來執行打開文件的代碼。當然這必須在擁 有合適許可權限的程序集中進行。這種“工作區”智取安全權限的現象可以允許懷惡意的代碼對受限資源進行嚴重破壞。為阻止這 種獲得安全權限的方式，QueueUserWorkItem方法內部遍歷調用線程的堆棧，并捕獲所有被授予的安全權限。然后，當線程池中的線程開始執行時，這些權限再與線程結合。因此，線程池中的線程以調用QueueUserWorkItem方法的線程相同的權限集來完成運行。

（看著是有些繞，簡單說呢，QueueUserWorkItem作為一種安全的線程池機制，其內部有一個功能，就是能遍歷調用線程池中線程的‘堆?！?，獲取堆棧中程序集所具有的安全權限。當堆棧對該線程調用時，這個線程的就繼承了調用他的堆棧內容所具有的權限。這樣就避免了權限較小的堆棧通過調用權限較大的線程，來獲取非法數據。

就好比堆棧里的內容沒有打開文件的權限，但是線程池中的線程可以打開文件，那么堆棧通過調用線程池里的線程來打開文件，從而獲取打開文件的權限。）

OK，我們再來了解一下UnsafeQueueUserWorkItem

遍歷線程的堆棧并捕獲所有的安全權限與性能緊密相關。如果希望改進受計算限制的異步操作的排隊性能，可以調用 UnsafeQueueUserWorkItem方法。該方法只將工作項加入到線程池的隊列中，而不遍歷調用線程的堆棧。最后結果是這個方法比 QueueUserWorkItem方法執行得快，但它在應用程序中打開了一個潛在的安全漏洞。僅當可以確認線程池中的線程執行的代碼不觸及受限資源時，或確信接觸這部分資源不會出現問題時，我們才可以調用unsafequeueuserwork-item方法。同樣，還需注意調用該方 法需要使securitypermission的controlpolicy標記和controlevidence標記開啟，可阻止未信任的代碼偶然或故意提升它的許可權 限。

（有了上面的鋪墊，UnsafeQueueUserWorkItem就很好理解了，為了追求效率，UnsafeQueueUserWorkItem對堆棧里的內容信任，不再去遍歷堆棧信息，讀取權限，而是直接執行。）

三、其他

還有一篇文章（https://www.cnblogs.com/JeffreyZhao/archive/2009/07/22/thread-pool-1-the-goal-and-the-clr-thread-pool.html）中的一段話，提到了兩者的關聯，貼上來

我們在編寫程序的時候，可以使用ThreadPool類的兩個靜態方法：QueueUserWorkItem和UnsafeUserQueueWorkItem向CLR線程池中添加任務（一個WorkCallback委托對象），這兩個方法的區別，在于前者會收集調用方的ExecutionContext，也就是保留了的當前線程的執行信息（如認證或語言文化等），使任務最終會在“創建”時刻的環境中執行2——后者就不會。因此，如果比較兩個方法的絕對性能，Unsafe方法會略勝一籌。但是平時還是建議使用QueueUserWorkItem方法，因為保留執行上下文會避免很多麻煩事情，且這點性能損耗其實算不上什么。

這段話表述不是很清楚，但大概意思也表明了QueueUserWorkItem方法在處理線程時會做更多的信息評判，更加安全。而相比之下UnsafeQueueUserWorkItem的執行效率更高。