1：原子操作 - OSAtomic系列函數

iOS平臺下的原子操作函數都以OSAtomic開頭，使用時需要包含頭文件<libkern/OSBase.h>。不同線程如果通過原子操作函數對同一變量進行操作，可以保證一個線程的操作不會影響到其他線程內對此變量的操作，因為這些操作都是原子式的。因為原子操作只能對內置類型進行操作，所以原子操作能夠同步的線程只能位于同一個進程的地址空間內。

2：鎖 - NSLock系列對象 iOS平臺下的鎖對象為NSLock對象，進入鎖通過調用lock函數，解鎖調用unlock函數（因為iOS中大部分的線程同步類都繼承自NSLocking協議，所以其加鎖/解鎖的操作基本都為lock/unlock函數），同一個NSLock對象成功調用lock函數后，在其顯式unlock之前任何線程都不能再對此NSLock對象加鎖，以達到互斥訪問的目的。除了lock函數，對NSLock加鎖的函數還包括tryLock以及lockBeforeDate函數，lock函數在成功加鎖之間會一直阻塞，而tryLock會嘗試加鎖，如果不成功，不會阻塞，而是直接返回NO，lockBeforeDate則是阻塞到傳入的NSDate日期為止。

除了NSLock，iOS還提供了NSRecursive、NSConditionLock類型的鎖類型。NSRecursive與NSLock最大的區別就是NSRecursive是可重入的，也就是說一個線程可以對一個NSRecursive對象多次調用lock，只要解鎖時調用相同次數的unlock函數便可。NSConditionLock是一種帶有條件的鎖對象，除了基本的lock與unlock函數，還提供了lockWithCondition以及unlockWithCondition，這兩個函數接收整型類型的數據作為參數，只有當一個unlockWithCondition對象被調用時，對應的lockWithCondition才會正常返回。這種機制在需幾多個線程順序化的完成某個任務時比較有用，例程如下：

[plain] view plaincopy

//線程A

id condLock = [[NSConditionLock alloc] initWithCondition:NO_DATA];

while(true)

{

[condLock lock]; /* Add data to the queue. */ [condLock unlockWithCondition:HAS_DATA]; 復制代碼

}

[plain] view plaincopy

//線程B

while (true)

{

[condLock lockWhenCondition:HAS_DATA]; /* Remove data from the queue. */ [condLock unlockWithCondition:(isEmpty ? NO_DATA : HAS_DATA)]; // Process the data locally. 復制代碼

}

除了顯示的生成NSLock系列對象，還可以通過將代碼放到@synchronized內來達到同步的目的，一段放入其內的代碼，不同的線程是不能重入的例如：

[plain] view plaincopy

• (void)myMethod:(id)anObj

{

@synchronized(anObj) { //此處代碼在同一時刻只能有一個線程執行. } 復制代碼

}

NSLock系列對象都是可以具名的，也就是說，這些對象可以用于不同進程內部的線程的同步。

3：事件 - NSCondtion

NSConditon類型提供了wait與signal函數，分別代表了等待事件的操作以及觸發事件的操作。除了wait函數，NSCondition還提供了waitUntilDate函數，其功能與NSLock中的lockBeforeDate大致相同，簡要來說就是提供了一個帶超時的wait函數。

雖然NSCondition與Windows環境下Event類型所完成的功能大致類似，但對一個熟悉Event類型的開發人員來說，NSConditon的行為會有點奇怪：

第一點：因為遵循NSLocking協議，所以NSCondition在觸發與等待過程的前后要分別調用lock與unlock函數，前面提到過，當一個遵循NSLocking協議的對象調用lock后，其他的對此對象的lock調用都會阻塞。那么，如果兩個線程A和B，A要觸發事件，B接收事件，B線程在調用lock后，通過調用wait函數進入等待事件觸發的狀態，那么，A線程豈不是再也沒有機會對這個事件進行觸發了（因為此對象已經被B線程lock）？秘密就在于wait函數的調用，其實，在wait函數內部悄悄的調用了unlock函數，也就是說在調用wati函數后，這個NSCondition對象就處于了無鎖的狀態，這樣A線程就可以對此對象加鎖并觸發該NSCondition對象。當一個事件被其他線程觸發時，在wait函數內部得到此事件被觸發的通知，然后對此事件重新調用lock函數，然后函數返回，而在函數外部，看起來好像接收事件的線程從來沒有放開NSCondition對象的所有權，B線程直接由阻塞狀態進入了觸發狀態。

第二點：當有多個線程進入阻塞狀態，等待同一個AutoReset的Event對象被觸發時，在Windows環境下喚醒哪一個線程是沒有固定的順序的，也就是說操作系統對喚醒哪一個線程不會提供任何的保證。而在iOS平臺上，經過筆者測試，其被觸發的順序與，并且只與調用wait函數的順序相關，與其他（比如線程優先級）條件沒有關系。這一點在開發時需要進行額外的考慮。

第三點：wait函數并不是完全可信的。這一點比較讓人蛋疼，也就是說wait返回后，并不代表對應的事件一定被觸發了，因此，為了保證線程之間的同步關系，使用NSCondtion時往往需要加入一個額外的變量來對非正常的wait返回進行規避。具體示例代碼如下：

[plain] view plaincopy

//等待事件觸發的線程

[cocoaCondition lock];

while (timeToDoWork <= 0)

[cocoaCondition wait]; 復制代碼

timeToDoWork--;

// Do real work here.

[cocoaCondition unlock];

//出發事件的線程

[cocoaCondition lock];

timeToDoWork++;

[cocoaCondition signal];

[cocoaCondition unlock];

這個timeToDoWork就是那個額外需要的變量，在NSCondition的使用中，這個變量是必不可少的。

NSConditon對象也是具名的，也就是說，其可于不同進程內部的線程同步。

相較于Windows平臺下提供的豐富的線程同步機制，iOS下的線程同步機制稍顯單薄，但也正是這種簡潔簡化了其使用。

總結

以上是生活随笔為你收集整理的iOS多线程编程：线程同步总结 NSCondtion的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。