跟互斥鎖一樣，乙個執行單元要想訪問被自旋鎖保護的共享資源，必須先得到鎖，在訪問完共享資源後，必須釋放鎖。如果在獲取自旋鎖時，沒有任何執行單元保持該鎖，那麼將立即得到鎖；如果在獲取自旋鎖時鎖已經有保持者，那麼獲取鎖操作將自旋在那裡，直到該自旋鎖的保持者釋放了鎖。由此我們可以看出，自旋鎖是一種比較低階的保護資料結構或**片段的原始方式，這種鎖可能存在兩個問題：
死鎖。試圖遞迴地獲得自旋鎖必然會引起死鎖：遞迴程式的持有例項在第二個例項迴圈，以試圖獲得相同自旋鎖時，不會釋放此自旋鎖。在遞迴程式中使用自旋鎖應遵守下列策略：遞迴程式決不能在持有自旋鎖時呼叫它自己，也決不能在遞迴呼叫時試圖獲得相同的自旋鎖。此外如果乙個程序已經將資源鎖定，那麼，即使其它申請這個資源的程序不停地瘋狂「自旋」,也無法獲得資源，從而進入死迴圈。
過多占用cpu資源。如果不加限制，由於申請者一直在迴圈等待，因此自旋鎖在鎖定的時候,如果不成功,不會睡眠,會持續的嘗試,單cpu的時候自旋鎖會讓其它process動不了. 因此，一般自旋鎖實現會有乙個引數限定最多持續嘗試次數. 超出後, 自旋鎖放棄當前time slice. 等下一次機會
由此可見，自旋鎖比較適用於鎖使用者保持鎖時間比較短的情況。正是由於自旋鎖使用者一般保持鎖時間非常短，因此選擇自旋而不是睡眠是非常必要的，自旋鎖的效率遠高於互斥鎖。訊號量和讀寫訊號量適合於保持時間較長的情況，它們會導致呼叫者睡眠，因此只能在程序上下文使用，而自旋鎖適合於保持時間非常短的情況，它可以在任何上下文使用。如果被保護的共享資源只在程序上下文訪問，使用訊號量保護該共享資源非常合適，如果對共享資源的訪問時間非常短，自旋鎖也可以。但是如果被保護的共享資源需要在中斷上下文訪問（包括底半部即中斷處理控制代碼和頂半部即軟中斷），就必須使用自旋鎖。
自旋鎖保持期間是搶占失效的，而訊號量和讀寫訊號量保持期間是可以被搶占的。就保證了對共享資料訪問的順序性，不會出現交叉訪問。自旋鎖只有在核心可搶占或smp（多處理器）的情況下才真正需要，在單cpu且不可搶占的核心下，自旋鎖的所有操作都是空操作。
自旋鎖以及可重入自旋鎖
首先是簡單的自旋鎖 實現 package org.cc.concur public class mylock private boolean islocked false public synchronized void lock throws interruptedexception islock...
java鎖 自旋鎖
什麼是自旋鎖？所謂自旋鎖是指不會引起呼叫者睡眠，若鎖資源被其他執行緒占有，則會迴圈檢查鎖資源的佔有者是否已經釋放鎖。總結下來自旋鎖就是原子操作 自迴圈 如何實現自旋鎖？自旋鎖的原理是通過cas實現，其中cas是比較並交換，本身是使用它的原子性的compareandset方法。cas 操作中包含三個運...
自旋鎖學習
innodb 在實現鎖時採用自旋鎖 自旋鎖與互斥鎖比較類似，它們都是為了解決對某項資源的互斥使用。無論是互斥鎖，還是自旋鎖，在任何時刻，最多只能有乙個保持者，也就說，在任何時刻最多只能有乙個執行單元獲得鎖。但是兩者在排程機制上略有不同。對於互斥鎖，如果資源已經被占用，資源申請者只能進入睡眠狀態。但是...