執行緒安全與鎖的優化

互斥鎖：

從 實現原理上來講，Mutex屬於sleep-waiting型別的鎖。例如在一個雙核的機器上有兩個執行緒(執行緒A和執行緒B)，它們分別執行在Core0和 Core1上。假設執行緒A想要通過pthread_mutex_lock操作去得到一個臨界區的鎖，而此時這個鎖正被執行緒B所持有，那麼線程A就會被阻塞 (blocking)，Core0 會在此時進行上下文切換(Context Switch)將執行緒A置於等待佇列中，此時Core0就可以執行其他的任務(例如另一個執行緒C)而不必進行忙等待。而Spin lock則不然，它屬於busy-waiting型別的鎖，如果執行緒A是使用pthread_spin_lock操作去請求鎖，那麼執行緒A就會一直在 Core0上進行忙等待並不停的進行鎖請求，直到得到這個鎖為止。
適用場景

自旋鎖

自旋鎖與互斥鎖有點類似，只是自旋鎖不會引起呼叫者立即睡眠，如果自旋鎖已經被別的執行單元保持，呼叫者不放棄處理器的執行時間， 進行忙迴圈(自旋)， 看是否該自旋鎖的保持者已經釋放了鎖，”自旋”一詞就是因此而得名。(JDK1.6以後預設開啟了自旋鎖

有些不足之處：
1、自旋鎖一直佔用CPU，他在未獲得鎖的情況下，一直執行－－自旋，所以佔用著CPU，如果不能在很短的時 間內獲得鎖，這無疑會使CPU效率降低。
2、在用自旋鎖時有可能造成死鎖，當遞迴呼叫時有可能造成死鎖，呼叫有些其他函式也可能造成死鎖，如 copy_to_user()、copy_from_user()、kmalloc()等。
因此我們要慎重使用自旋鎖，自旋鎖只有在核心可搶佔式或SMP的情況下才真正需要，在單CPU且不可搶佔式的核心下，自旋鎖的操作為空操作。自旋鎖適用於鎖使用者保持鎖時間比較短的情況下。
適用場景
如果是多核處理器

自適應的自旋鎖

JDK1.6中引入了自適應的自旋鎖。 自適應意味著自旋的時間不再是固定的， 而是由前一次在同一個鎖上的自旋時間以及鎖擁有者的狀態來決定。如果在同一個鎖物件上, 自旋等待剛好成功獲得鎖， 並且在持有鎖的執行緒在執行中， 那麼虛擬機器就會認為這次自旋也是很有可能獲得鎖， 進而它將允許自旋等待相對更長的時間。

不足與使用場景與自旋鎖相同。