在併發隊列使用信號量會可能會造成線程優先順序反轉

一、在iOS16 & XCode14上遇到 - 使用信號量造成線程優先順序反轉問題 提醒

經過查詢資料，發現是在XCode14上增加了工具，比如 ：

Thread Performance Checker （XCode14上預設開啟的），這個工具會讓APP在運行的時候，發現有例如線程優先順序反轉和非UI工作在主線程上運行等問題的時候，就會在XCode問題導航欄中提示該卡頓風險警告，可以幫助我們在開發初期就能發現並解決隱含的卡頓風險問題；這個不是崩潰，如果不想要，可以在 “Product -> Scheme - > Edit Scheme 的 Diagnostics 中去掉 Thread Performance Checker勾選”

XCode14還有其他一些新增加的工具類，可參考 iOS卡頓檢測

二、關於線程優先順序反轉

優先順序反轉（Poiority Inversion） 指高優先順序任務需要等待低優先順序任務執行完成才能繼續執行，這種情況下優先順序被反轉了。

舉例：有三個線程分別為：A、B、C。優先順序A > B > C，線程A和B處於掛起狀態，等待某一事件發生，線程C正在運行，此時任務C開始使用共用資源Source。在使用Source時，線程A等待事件到來，線程A轉為就緒態，因為線程A優先順序比線程C高，所以線程A會立即執行。當線程A要使用共用資源Source時，由於共用資源Source正在被線程C使用，因此線程A被掛起，線程C開始運行。如果此時中等優先順序線程B等待事件到來，則線程B轉為就緒態。由於線程B優先順序比線程C高，因此線程B開始運行，直到其運行完畢，線程C才開始運行。直到線程C釋放共用資源Source後，線程A才得以執行。在這種情況下，優先順序發生了翻轉，線程B先於線程A運行。

三、優先順序反轉會造成什麼後果

低優先順序的任務比高優先順序的任務先執行，導致任務的錯亂，邏輯錯亂；

可能造成系統崩潰；

死鎖；優先順序低的線程遲遲得不到調度，具有高優先順序的線程不能執行，死鎖；

四、怎麼避免線程優先順序反轉

如果當前線程因等待某線程上正在進行的 操作如（block1）而受阻，而系統知道block1的所在的目標線程，系統會通過提高相關線程的優先順序來解決優先順序反轉的問題 （如線程A在嘗試獲取共用資源而被掛起的期間內，將線程C的優先順序提升到同線程A的優先順序，等線程C處理結束，降回原優先順序，這樣能防止C被B搶占）。如果不知道block1所在的目標線程，則無法知道應該提高誰的優先順序，也就無法解決反轉的問題，如信號量。

五、使用信號量可能會造成線程優先順序反轉，且無法避免

QoS （Quality of Service），用來指示某任務或者隊列的運行優先順序；

1、記錄了持有者的api都可以自動避免優先順序反轉，系統會通過提高相關線程的優先順序來解決優先順序反轉的問題，如 dispatch_sync, 如果系統不知道持有者所在的線程，則無法知道應該提高誰的優先順序，也就無法解決反轉問題。

2、慎用dispatch_semaphore 做線程同步

dispatch_semaphore 容易造成優先順序反轉，因為api沒有記錄是哪個線程持有了信號量，所以有高優先順序的線程在等待鎖的時候，內核無法知道該提高那個線程的優先順序（QoS）；

3、dispatch_semaphore 不能避免優先順序反轉的原因

在調用dispatch_semaphore_wait() 的時候，系統不知道哪個線程會調用 dispatch_semaphore_signal()方法，系統無法知道owner信息，無法調整優先順序。dispatch_group 和semaphore類似，在調用enter()方法的時候，無法預知誰會leave()，所以系統也不知道owner信息

參考資料：

優先順序反轉

優先順序反轉那些事兒

Diagnosing Performance issues early

dispatch_semaphore 會造成優先順序反轉，慎用！

作者：京東零售 孫巧巧

來源：京東雲開發者社區 轉載請註明來源