? ? ? ? 在多線程開發(fā)中，要注意避免的是多個線程在同一時間對某數(shù)據進行讀或寫所造成的不可預見錯誤。因此在不同線程中需要對公共數(shù)據進行互斥的訪問，最常見的是生產者與消費者問題。

1. 同步塊或者NSLock

? ? ? ? 同步塊或者NSLock實現(xiàn)的效果差不多，都是進行加鎖-操作-解鎖，以此達到互斥訪問的效果。

? ? ? ? 在一個代碼塊中進行加鎖可以實現(xiàn)不同線程對該代碼塊的互斥訪問。在多個代碼塊中使用同一個信號量進行加鎖則不同代碼塊之間也能實現(xiàn)互斥訪問。即加鎖解鎖的本質是對信號量的原子處理。

//生產者-同步代碼塊,括號參數(shù)為自定義信號量 -(void)synchronizeFunc1 {@synchronized (self) {if(count < 1000) {count += 100;NSLog(@"P count is %d", count);}} } //消費者-同步代碼塊 -(void)synchronizeFunc2 {@synchronized (self) {if(count > 0) {count -= 100;NSLog(@"C count is %d", count);}} } //生產者-NSLock，一個NSLock對象就是一個信號量 -(void)synchronizeFunc3 {[nsLock lock];if(count < 1000) {count += 100;NSLog(@"P count is %d", count);}[nsLock unlock]; } //消費者-NSlock -(void)synchronizeFunc4 {[nsLock lock];if(count > 0) {count -= 100;NSLog(@"C count is %d", count);}[nsLock unlock]; }
2. NSConditon

? ? ? ? 很明顯上面兩種操作中，所有的線程都是獨立運行的，線程之間沒有任何通信或者說協(xié)作。如果消費者獲得了lock,但是此時count<0,那么消費者函數(shù)將解鎖并退出，也就是說取錢失敗。如果我們想，取消操作中發(fā)現(xiàn)count<0后，可以進行等待生產者存錢，之后再取錢，這時就需要用到NSCondition了。NSCondition在NSLock的基礎上，多加了wait函數(shù)和signal/broadcast函數(shù)，可以是獲得了信號量但是卻操作條件不足滿的線程釋放信號量進行等待，在條件滿足之后再被喚醒繼續(xù)加鎖執(zhí)行之前的操作。

? ? ? ? 下面有一個測試的例子看wait做了什么

//2個消費者for(int i=0; i<2; i++){NSThread* thread1 = [[NSThread alloc]initWithTarget:self selector:@selector(synchronizeFunc6) object:nil];[thread1 start];}//1個生產者NSThread* thread2 = [[NSThread alloc]initWithTarget:self selector:@selector(synchronizeFunc5) object:nil];[thread2 start];//生產者-NSConditon，一個NSConditon對象就是一個信號量 -(void)synchronizeFunc5 {[condition lock];NSLog(@"P Enter");if(count >= 1000){[condition wait];NSLog(@"P wait");}else {count += 100;NSLog(@"P count is %d", count);[condition broadcast];}[condition unlock];NSLog(@"P conditon"); } //消費者-NSConditon -(void)synchronizeFunc6 {[condition lock];NSLog(@"C Enter");if(count <= 0){[condition wait];NSLog(@"C Wait");}else {count -= 100;NSLog(@"C count is %d", count);[condition broadcast];}[condition unlock];NSLog(@"C condition"); }

程序輸出：

上面先啟動了兩個消費者線程，由于count<0所以都進入了等待。在啟動生產者執(zhí)行了boradcast喚醒之后，兩個消費者線程又分別繼續(xù)執(zhí)行之前的程序，并不會因為count的改變而去執(zhí)行else部分，因為if判斷是在wait之前執(zhí)行的，喚醒后將直接在wait部分繼續(xù)往下執(zhí)行。

這篇博客，講了一些property的atomic相關的東西：

點擊打開鏈接

總結

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

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