Lock Convoy（鎖封護）
[1]Lock Convoy是在多線程併發環境下由於鎖的使用而引起的性能退化問題。當多個相同優先級的線程頻繁地爭搶同一個鎖時可能會引起lock convoy問題，一般而言，lock convoy並不會像deadlock或livelock那樣造成應用邏輯停止不前，相反地，遭受lock convoy的系統或應用程序仍然往前運行，但是，由於線程們頻繁地爭搶鎖而導致過多的線程環境切換，從而使得系統的運行效率大爲降低，而且，若存在同等優先級下不參與鎖爭搶的線程，則它們可以獲得相對較多的處理器資源，從而造成系統調度的不公平性。
Lock Convoy描述的是這樣一種情況，假設有ABC三個線程在同一個時間片內多次取鎖，在不考慮優先級的情況下（假設調度規則爲平均時間），則可能發生當A執行1/3的時間片後被調度進程中斷，轉而執行B，B也執行了1/3的時間片後被調度進程中斷，執行C。這樣三個線程總是沒執行完時間片就被打斷。（在現代操作系統中，只要一個線程獲取了一個時間片，那麼在時間片內它就不能被重新執行），導致線程頻繁切換，而降低系統的執行效率。
除了引起調度粒度變小以外，lock convoy的另一個問題是造成調度器的時間分配不公平。假設另有一個線程X也是在同等的優先級上運行，但沒有參與鎖競爭。於是，在每一輪的鎖競爭過程中，線程X都有機會被分配一次完整的時間片，於是，這些競爭的線程在一輪中獲得1/3時間片，而非競爭的線程可以獲得完整的時間片。當然，你可以說這種不公平是由於它們搶鎖而引起的，但從時間分配比例而言，參與競爭與不參與競爭的線程是不公平的。下圖說明了線程X和A、B、C之間的執行時間差異。
由以上描述可以看出，Lock convoy的存在條件是，參與競爭的線程頻繁地獲取鎖，鎖被一個線程釋放以後其所有權便落到了另一個線程的手裏。在操作系統中，相同優先級的線程按照FIFO的順序被調度和執行，競爭同一個鎖的線程也按照FIFO的順序被依次成功地獲取到鎖。這些條件在現代操作系統中都能被滿足，包括Windows。
一種合理的緩解lock convoy的方案，要求在每個線程獲取鎖的時候先嚐試（try），如果嘗試多次仍不成功，再阻塞。
Priority inversion（優先級反轉）
高優先級任務需要等待低優先級任務釋放資源，而低優先級任務又正在等待中等優先級任務的現象，叫做優先級反轉。
（注意： 此時高優先級任務和中等優先級任務之間沒有任何共享資源但執行順序卻發生了倒置，這種情況才稱爲優先級反轉；而高優先級任務因爲等待低優先級任務釋放資源而阻塞的情況則不稱爲優先級反轉。）
圖片含義：當低優先級在運行時被高優先級打斷，但高優先級所使用的資源被低優先級所佔用而阻塞，此時中優先級打斷低優先級任務，低優先級任務發生了阻塞，而此時高優先級和中優先級沒有任何資源共享，卻發生了優先級反轉。
兩種經典的防止反轉的方法：
1. （Priority inheritance，優先級繼承）：繼承現有被阻塞任務的最高優先級作爲其優先級，任務退出臨界區，恢復初始優先級。 在上述例子中當高優先級任務需要等待低優先級任務釋放資源而阻塞時，就將低優先級任務的優先級升爲高優先級任務的優先級，當它退出臨界區後就將其優先級恢復爲初始優先級。
2. （Priority ceilings，設置優先級上限）：設置優先級上限是指將申請（佔有）某資源的任務的優先級提升到可能訪問該資源的所有任務中最高優先級任務的優先級。如上面的例子，如果給低優先級線程擡高到最高優先級，那麼中級優先級程序就不會被調度，不會發生優先級反轉。