本文轉(zhuǎn)載自：深入理解 iOS 開(kāi)發(fā)中的鎖
作者博客：bestswifter
摘要
本文的目的不是介紹 iOS 中各種鎖如何使用，一方面筆者沒(méi)有大量的實(shí)戰(zhàn)經(jīng)驗(yàn)，另一方面這樣的文章相當(dāng)多，比如 iOS中保證線(xiàn)程安全的幾種方式與性能對(duì)比、iOS 常見(jiàn)知識(shí)點(diǎn)（三）：Lock。本文也不會(huì)詳細(xì)介紹鎖的具體實(shí)現(xiàn)原理，這會(huì)涉及到太多相關(guān)知識(shí)，筆者不敢誤人子弟。
本文要做的就是簡(jiǎn)單的分析 iOS 開(kāi)發(fā)中常見(jiàn)的幾種鎖如何實(shí)現(xiàn)，以及優(yōu)缺點(diǎn)是什么，為什么會(huì)有性能上的差距，最終會(huì)簡(jiǎn)單的介紹鎖的底層實(shí)現(xiàn)原理。水平有限，如果不慎有誤，歡迎交流指正。同時(shí)建議讀者在閱讀本文以前，對(duì) OC 中各種鎖的使用方法先有大概的認(rèn)識(shí)。
在 ibireme 的 不再安全的 OSSpinLock 一文中，有一張圖片簡(jiǎn)單的比較了各種鎖的加解鎖性能:
本文會(huì)按照從上至下(速度由快至慢)的順序分析每個(gè)鎖的實(shí)現(xiàn)原理。需要說(shuō)明的是，加解鎖速度不表示鎖的效率，只表示加解鎖操作在執(zhí)行時(shí)的復(fù)雜程度，下文會(huì)通過(guò)具體的例子來(lái)解釋。
OSSpinLock
上述文章中已經(jīng)介紹了 OSSpinLock 不再安全，主要原因發(fā)生在低優(yōu)先級(jí)線(xiàn)程拿到鎖時(shí)，高優(yōu)先級(jí)線(xiàn)程進(jìn)入忙等(busy-wait)狀態(tài)，消耗大量 CPU 時(shí)間，從而導(dǎo)致低優(yōu)先級(jí)線(xiàn)程拿不到 CPU 時(shí)間，也就無(wú)法完成任務(wù)并釋放鎖。這種問(wèn)題被稱(chēng)為優(yōu)先級(jí)反轉(zhuǎn)。
為什么忙等會(huì)導(dǎo)致低優(yōu)先級(jí)線(xiàn)程拿不到時(shí)間片？這還得從操作系統(tǒng)的線(xiàn)程調(diào)度說(shuō)起。
現(xiàn)代操作系統(tǒng)在管理普通線(xiàn)程時(shí)，通常采用時(shí)間片輪轉(zhuǎn)算法(Round Robin，簡(jiǎn)稱(chēng) RR)。每個(gè)線(xiàn)程會(huì)被分配一段時(shí)間片(quantum)，通常在 10-100 毫秒左右。當(dāng)線(xiàn)程用完屬于自己的時(shí)間片以后，就會(huì)被操作系統(tǒng)掛起，放入等待隊(duì)列中，直到下一次被分配時(shí)間片。
自旋鎖的實(shí)現(xiàn)原理
自旋鎖的目的是為了確保臨界區(qū)只有一個(gè)線(xiàn)程可以訪(fǎng)問(wèn)，它的使用可以用下面這段偽代碼來(lái)描述:
do {
Acquire Lock
Critical section // 臨界區(qū)
Release Lock
Reminder section // 不需要鎖保護(hù)的代碼
}
在 Acquire Lock 這一步，我們申請(qǐng)加鎖，目的是為了保護(hù)臨界區(qū)(Critical Section) 中的代碼不會(huì)被多個(gè)線(xiàn)程執(zhí)行。
自旋鎖的實(shí)現(xiàn)思路很簡(jiǎn)單，理論上來(lái)說(shuō)只要定義一個(gè)全局變量，用來(lái)表示鎖的可用情況即可，偽代碼如下:
bool lock = false; // 一開(kāi)始沒(méi)有鎖上，任何線(xiàn)程都可以申請(qǐng)鎖
do {
while(lock); // 如果 lock 為 true 就一直死循環(huán)，相當(dāng)于申請(qǐng)鎖
lock = true; // 掛上鎖，這樣別的線(xiàn)程就無(wú)法獲得鎖
Critical section // 臨界區(qū)
lock = false; // 相當(dāng)于釋放鎖，這樣別的線(xiàn)程可以進(jìn)入臨界區(qū)
Reminder section // 不需要鎖保護(hù)的代碼
}
注釋寫(xiě)得很清楚，就不再逐行分析了?？上н@段代碼存在一個(gè)問(wèn)題: 如果一開(kāi)始有多個(gè)線(xiàn)程同時(shí)執(zhí)行 while 循環(huán)，他們都不會(huì)在這里卡住，而是繼續(xù)執(zhí)行，這樣就無(wú)法保證鎖的可靠性了。解決思路也很簡(jiǎn)單，只要確保申請(qǐng)鎖的過(guò)程是原子操作即可。
原子操作
狹義上的原子操作表示一條不可打斷的操作，也就是說(shuō)線(xiàn)程在執(zhí)行操作過(guò)程中，不會(huì)被操作系統(tǒng)掛起，而是一定會(huì)執(zhí)行完。在單處理器環(huán)境下，一條匯編指令顯然是原子操作，因?yàn)橹袛嘁惨ㄟ^(guò)指令來(lái)實(shí)現(xiàn)。
然而在多處理器的情況下，能夠被多個(gè)處理器同時(shí)執(zhí)行的操作任然算不上原子操作。因此，真正的原子操作必須由硬件提供支持，比如 x86 平臺(tái)上如果在指令前面加上 “LOCK” 前綴，對(duì)應(yīng)的機(jī)器碼在執(zhí)行時(shí)會(huì)把總線(xiàn)鎖住，使得其他 CPU不能再執(zhí)行相同操作，從而從硬件層面確保了操作的原子性。
這些非常底層的概念無(wú)需完全掌握，我們只要知道上述申請(qǐng)鎖的過(guò)程，可以用一個(gè)原子性操作 test_and_set 來(lái)完成，它用偽代碼可以這樣表示:
bool test_and_set (bool *target) {
bool rv = *target;
*target = TRUE;
return rv;
}
這段代碼的作用是把 target 的值設(shè)置為 1，并返回原來(lái)的值。當(dāng)然，在具體實(shí)現(xiàn)時(shí)，它通過(guò)一個(gè)原子性的指令來(lái)完成。
自旋鎖的總結(jié)
至此，自旋鎖的實(shí)現(xiàn)原理就很清楚了:
bool lock = false; // 一開(kāi)始沒(méi)有鎖上，任何線(xiàn)程都可以申請(qǐng)鎖
do {
while(test_and_set(&lock); // test_and_set 是一個(gè)原子操作
Critical section // 臨界區(qū)
lock = false; // 相當(dāng)于釋放鎖，這樣別的線(xiàn)程可以進(jìn)入臨界區(qū)
Reminder section // 不需要鎖保護(hù)的代碼
}
如果臨界區(qū)的執(zhí)行時(shí)間過(guò)長(zhǎng)，使用自旋鎖不是個(gè)好主意。之前我們介紹過(guò)時(shí)間片輪轉(zhuǎn)算法，線(xiàn)程在多種情況下會(huì)退出自己的時(shí)間片。其中一種是用完了時(shí)間片的時(shí)間，被操作系統(tǒng)強(qiáng)制搶占。除此以外，當(dāng)線(xiàn)程進(jìn)行 I/O 操作，或進(jìn)入睡眠狀態(tài)時(shí)，都會(huì)主動(dòng)讓出時(shí)間片。顯然在 while 循環(huán)中，線(xiàn)程處于忙等狀態(tài)，白白浪費(fèi) CPU 時(shí)間，最終因?yàn)槌瑫r(shí)被操作系統(tǒng)搶占時(shí)間片。如果臨界區(qū)執(zhí)行時(shí)間較長(zhǎng)，比如是文件讀寫(xiě)，這種忙等是毫無(wú)必要的。
信號(hào)量
之前我在 介紹 GCD 底層實(shí)現(xiàn)的文章 中簡(jiǎn)單描述了信號(hào)量 dispatch_semaphore_t 的實(shí)現(xiàn)原理，它最終會(huì)調(diào)用到 sem_wait 方法，這個(gè)方法在 glibc 中被實(shí)現(xiàn)如下:
int sem_wait (sem_t *sem) {
int *futex = (int *) sem;
if (atomic_decrement_if_positive (futex) > 0)
return 0;
int err = lll_futex_wait (futex, 0);
return -1;
)
首先會(huì)把信號(hào)量的值減一，并判斷是否大于零。如果大于零，說(shuō)明不用等待，所以立刻返回。具體的等待操作在 lll_futex_wait 函數(shù)中實(shí)現(xiàn)，lll 是 low level lock 的簡(jiǎn)稱(chēng)。這個(gè)函數(shù)通過(guò)匯編代碼實(shí)現(xiàn)，調(diào)用到 SYS_futex這個(gè)系統(tǒng)調(diào)用，使線(xiàn)程進(jìn)入睡眠狀態(tài)，主動(dòng)讓出時(shí)間片，這個(gè)函數(shù)在互斥鎖的實(shí)現(xiàn)中，也有可能被用到。
主動(dòng)讓出時(shí)間片并不總是代表效率高。讓出時(shí)間片會(huì)導(dǎo)致操作系統(tǒng)切換到另一個(gè)線(xiàn)程，這種上下文切換通常需要 10 微秒左右，而且至少需要兩次切換。如果等待時(shí)間很短，比如只有幾個(gè)微秒，忙等就比線(xiàn)程睡眠更高效。
可以看到，自旋鎖和信號(hào)量的實(shí)現(xiàn)都非常簡(jiǎn)單，這也是兩者的加解鎖耗時(shí)分別排在第一和第二的原因。再次強(qiáng)調(diào)，加解鎖耗時(shí)不能準(zhǔn)確反應(yīng)出鎖的效率(比如時(shí)間片切換就無(wú)法發(fā)生)，它只能從一定程度上衡量鎖的實(shí)現(xiàn)復(fù)雜程度。
pthread_mutex
pthread 表示 POSIX thread，定義了一組跨平臺(tái)的線(xiàn)程相關(guān)的 API，pthread_mutex 表示互斥鎖?；コ怄i的實(shí)現(xiàn)原理與信號(hào)量非常相似，不是使用忙等，而是阻塞線(xiàn)程并睡眠，需要進(jìn)行上下文切換。
互斥鎖的常見(jiàn)用法如下:
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL); // 定義鎖的屬性
pthread_mutex_t mutex;
pthread_mutex_init(&mutex, &attr) // 創(chuàng)建鎖
pthread_mutex_lock(&mutex); // 申請(qǐng)鎖
// 臨界區(qū)
pthread_mutex_unlock(&mutex); // 釋放鎖
對(duì)于 pthread_mutex 來(lái)說(shuō)，它的用法和之前沒(méi)有太大的改變，比較重要的是鎖的類(lèi)型，可以有 PTHREAD_MUTEX_NORMAL、PTHREAD_MUTEX_ERRORCHECK、PTHREAD_MUTEX_RECURSIVE 等等，具體的特性就不做解釋了，網(wǎng)上有很多相關(guān)資料。
一般情況下，一個(gè)線(xiàn)程只能申請(qǐng)一次鎖，也只能在獲得鎖的情況下才能釋放鎖，多次申請(qǐng)鎖或釋放未獲得的鎖都會(huì)導(dǎo)致崩潰。假設(shè)在已經(jīng)獲得鎖的情況下再次申請(qǐng)鎖，線(xiàn)程會(huì)因?yàn)榈却i的釋放而進(jìn)入睡眠狀態(tài)，因此就不可能再釋放鎖，從而導(dǎo)致死鎖。
然而這種情況經(jīng)常會(huì)發(fā)生，比如某個(gè)函數(shù)申請(qǐng)了鎖，在臨界區(qū)內(nèi)又遞歸調(diào)用了自己。辛運(yùn)的是 pthread_mutex支持遞歸鎖，也就是允許一個(gè)線(xiàn)程遞歸的申請(qǐng)鎖，只要把 attr 的類(lèi)型改成 PTHREAD_MUTEX_RECURSIVE 即可。
互斥鎖的實(shí)現(xiàn)
互斥鎖在申請(qǐng)鎖時(shí)，調(diào)用了 pthread_mutex_lock 方法，它在不同的系統(tǒng)上實(shí)現(xiàn)各有不同，有時(shí)候它的內(nèi)部是使用信號(hào)量來(lái)實(shí)現(xiàn)，即使不用信號(hào)量，也會(huì)調(diào)用到 lll_futex_wait 函數(shù)，從而導(dǎo)致線(xiàn)程休眠。
上文說(shuō)到如果臨界區(qū)很短，忙等的效率也許更高，所以在有些版本的實(shí)現(xiàn)中，會(huì)首先嘗試一定次數(shù)(比如 1000 次)的 test_and_test，這樣可以在錯(cuò)誤使用互斥鎖時(shí)提高性能。
另外，由于 pthread_mutex 有多種類(lèi)型，可以支持遞歸鎖等，因此在申請(qǐng)加鎖時(shí)，需要對(duì)鎖的類(lèi)型加以判斷，這也就是為什么它和信號(hào)量的實(shí)現(xiàn)類(lèi)似，但效率略低的原因。
NSLock
NSLock 是 Objective-C 以對(duì)象的形式暴露給開(kāi)發(fā)者的一種鎖，它的實(shí)現(xiàn)非常簡(jiǎn)單，通過(guò)宏，定義了 lock 方法:
#define MLOCK \
- (void) lock\
{\
int err = pthread_mutex_lock(&_mutex);\
// 錯(cuò)誤處理 ……
}
NSLock 只是在內(nèi)部封裝了一個(gè) pthread_mutex，屬性為 PTHREAD_MUTEX_ERRORCHECK，它會(huì)損失一定性能換來(lái)錯(cuò)誤提示。
這里使用宏定義的原因是，OC 內(nèi)部還有其他幾種鎖，他們的 lock 方法都是一模一樣，僅僅是內(nèi)部 pthread_mutex 互斥鎖的類(lèi)型不同。通過(guò)宏定義，可以簡(jiǎn)化方法的定義。
NSLock 比 pthread_mutex 略慢的原因在于它需要經(jīng)過(guò)方法調(diào)用，同時(shí)由于緩存的存在，多次方法調(diào)用不會(huì)對(duì)性能產(chǎn)生太大的影響。
NSCondition
NSCondition 的底層是通過(guò)條件變量(condition variable) pthread_cond_t 來(lái)實(shí)現(xiàn)的。條件變量有點(diǎn)像信號(hào)量，提供了線(xiàn)程阻塞與信號(hào)機(jī)制，因此可以用來(lái)阻塞某個(gè)線(xiàn)程，并等待某個(gè)數(shù)據(jù)就緒，隨后喚醒線(xiàn)程，比如常見(jiàn)的生產(chǎn)者-消費(fèi)者模式。
如何使用條件變量
很多介紹 pthread_cond_t 的文章都會(huì)提到，它需要與互斥鎖配合使用:
void consumer () { // 消費(fèi)者
pthread_mutex_lock(&mutex);
while (data == NULL) {
pthread_cond_wait(&condition_variable_signal, &mutex); // 等待數(shù)據(jù)
}
// --- 有新的數(shù)據(jù)，以下代碼負(fù)責(zé)處理 ↓↓↓↓↓↓
// temp = data;
// --- 有新的數(shù)據(jù)，以上代碼負(fù)責(zé)處理 ↑↑↑↑↑↑
pthread_mutex_unlock(&mutex);
}
void producer () {
pthread_mutex_lock(&mutex);
// 生產(chǎn)數(shù)據(jù)
pthread_cond_signal(&condition_variable_signal); // 發(fā)出信號(hào)給消費(fèi)者，告訴他們有了新的數(shù)據(jù)
pthread_mutex_unlock(&mutex);
}
自然我們會(huì)有疑問(wèn):“如果不用互斥鎖，只用條件變量會(huì)有什么問(wèn)題呢？”。問(wèn)題在于，temp = data; 這段代碼不是線(xiàn)程安全的，也許在你把 data 讀出來(lái)以前，已經(jīng)有別的線(xiàn)程修改了數(shù)據(jù)。因此我們需要保證消費(fèi)者拿到的數(shù)據(jù)是線(xiàn)程安全的。
wait 方法除了會(huì)被 signal 方法喚醒，有時(shí)還會(huì)被虛假喚醒，所以需要這里 while 循環(huán)中的判斷來(lái)做二次確認(rèn)。
為什么要使用條件變量
介紹條件變量的文章非常多，但大多都對(duì)一個(gè)一個(gè)基本問(wèn)題避而不談:“為什么要用條件變量？它僅僅是控制了線(xiàn)程的執(zhí)行順序，用信號(hào)量或者互斥鎖能不能模擬出類(lèi)似效果？”
網(wǎng)上的相關(guān)資料比較少，我簡(jiǎn)單說(shuō)一下個(gè)人看法。信號(hào)量可以一定程度上替代 condition，但是互斥鎖不行。在以上給出的生產(chǎn)者-消費(fèi)者模式的代碼中， pthread_cond_wait 方法的本質(zhì)是鎖的轉(zhuǎn)移，消費(fèi)者放棄鎖，然后生產(chǎn)者獲得鎖，同理，pthread_cond_signal 則是一個(gè)鎖從生產(chǎn)者到消費(fèi)者轉(zhuǎn)移的過(guò)程。
如果使用互斥鎖，我們需要把代碼改成這樣:
void consumer () { // 消費(fèi)者
pthread_mutex_lock(&mutex);
while (data == NULL) {
pthread_mutex_unlock(&mutex);
pthread_mutex_lock(&another_lock) // 相當(dāng)于 wait 另一個(gè)互斥鎖
pthread_mutex_lock(&mutex);
}
pthread_mutex_unlock(&mutex);
}
這樣做存在的問(wèn)題在于，在等待 another_lock 之前， 生產(chǎn)者有可能先執(zhí)行代碼， 從而釋放了 another_lock。也就是說(shuō)，我們無(wú)法保證釋放鎖和等待另一個(gè)鎖這兩個(gè)操作是原子性的，也就無(wú)法保證“先等待、后釋放 another_lock” 這個(gè)順序。
用信號(hào)量則不存在這個(gè)問(wèn)題，因?yàn)樾盘?hào)量的等待和喚醒并不需要滿(mǎn)足先后順序，信號(hào)量只表示有多少個(gè)資源可用，因此不存在上述問(wèn)題。然而與 pthread_cond_wait 保證的原子性鎖轉(zhuǎn)移相比，使用信號(hào)量似乎存在一定風(fēng)險(xiǎn)(暫時(shí)沒(méi)有查到非原子性操作有何不妥)。
不過(guò)，使用 condition 有一個(gè)好處，我們可以調(diào)用 pthread_cond_broadcast 方法通知所有等待中的消費(fèi)者，這是使用信號(hào)量無(wú)法實(shí)現(xiàn)的。
NSCondition 的做法
NSCondition 其實(shí)是封裝了一個(gè)互斥鎖和條件變量， 它把前者的 lock 方法和后者的 wait/signal 統(tǒng)一在 NSCondition 對(duì)象中，暴露給使用者:
- (void) signal {
pthread_cond_signal(&_condition);
}
// 其實(shí)這個(gè)函數(shù)是通過(guò)宏來(lái)定義的，展開(kāi)后就是這樣
- (void) lock {
int err = pthread_mutex_lock(&_mutex);
}
它的加解鎖過(guò)程與 NSLock 幾乎一致，理論上來(lái)說(shuō)耗時(shí)也應(yīng)該一樣(實(shí)際測(cè)試也是如此)。在圖中顯示它耗時(shí)略長(zhǎng)，我猜測(cè)有可能是測(cè)試者在每次加解鎖的前后還附帶了變量的初始化和銷(xiāo)毀操作。
NSRecursiveLock
上文已經(jīng)說(shuō)過(guò)，遞歸鎖也是通過(guò) pthread_mutex_lock 函數(shù)來(lái)實(shí)現(xiàn)，在函數(shù)內(nèi)部會(huì)判斷鎖的類(lèi)型，如果顯示是遞歸鎖，就允許遞歸調(diào)用，僅僅將一個(gè)計(jì)數(shù)器加一，鎖的釋放過(guò)程也是同理。
NSRecursiveLock 與 NSLock 的區(qū)別在于內(nèi)部封裝的 pthread_mutex_t 對(duì)象的類(lèi)型不同，前者的類(lèi)型為 PTHREAD_MUTEX_RECURSIVE。
NSConditionLock
NSConditionLock 借助 NSCondition 來(lái)實(shí)現(xiàn)，它的本質(zhì)就是一個(gè)生產(chǎn)者-消費(fèi)者模型。“條件被滿(mǎn)足”可以理解為生產(chǎn)者提供了新的內(nèi)容。NSConditionLock 的內(nèi)部持有一個(gè) NSCondition 對(duì)象，以及 _condition_value 屬性，在初始化時(shí)就會(huì)對(duì)這個(gè)屬性進(jìn)行賦值:
// 簡(jiǎn)化版代碼
- (id) initWithCondition: (NSInteger)value {
if (nil != (self = [super init])) {
_condition = [NSCondition new]
_condition_value = value;
}
return self;
}
它的 lockWhenCondition 方法其實(shí)就是消費(fèi)者方法:
- (void) lockWhenCondition: (NSInteger)value {
[_condition lock];
while (value != _condition_value) {
[_condition wait];
}
}
對(duì)應(yīng)的 unlockWhenCondition 方法則是生產(chǎn)者，使用了 broadcast 方法通知了所有的消費(fèi)者:
- (void) unlockWithCondition: (NSInteger)value {
_condition_value = value;
[_condition broadcast];
[_condition unlock];
}
@synchronized
這其實(shí)是一個(gè) OC 層面的鎖， 主要是通過(guò)犧牲性能換來(lái)語(yǔ)法上的簡(jiǎn)潔與可讀。
我們知道 @synchronized 后面需要緊跟一個(gè) OC 對(duì)象，它實(shí)際上是把這個(gè)對(duì)象當(dāng)做鎖來(lái)使用。這是通過(guò)一個(gè)哈希表來(lái)實(shí)現(xiàn)的，OC 在底層使用了一個(gè)互斥鎖的數(shù)組(你可以理解為鎖池)，通過(guò)對(duì)對(duì)象去哈希值來(lái)得到對(duì)應(yīng)的互斥鎖。
具體的實(shí)現(xiàn)原理可以參考這篇文章: 關(guān)于 @synchronized，這兒比你想知道的還要多
