這是一篇繼上一篇繼續介紹多執行緒同步的博客.(你了解多執行緒自旋鎖、互斥鎖、遞回鎖等鎖嗎?)

GNUstep介紹

再介紹其他鎖之前我們先看一個其他的知識點.我們知道在Foundation框架下,蘋果公開的原始碼只有NSObject,而我們想知道的NSString、NSArray、NSRunLoop、NSThread等等都是沒有給原始碼的.只給了NSObject的部分實作,如果我們確實想看這些原始碼的話.通過匯編,打斷點一步一步看,這樣也是可以看到的,但是這樣就有點麻煩,要會匯編語言,而且還要一點一點的除錯才能知道.所以這里給大家介紹另一個方案,叫做:GNUstep.

GNUstep是GNU計劃的專案之一,GNU計劃就是一個軟體計劃,就是希望能夠開源非常非常多的原始碼,希望都是自由的,我們可以認為這個計劃就是做了非常非常多的開源專案.GNUstep就是GNU計劃之一,它將Cocoa的OC庫重新開源實作了一遍.就是雖然蘋果的NSString、NSArray、NSRunLoop、NSThread等等都是沒有開源的,GNUstep就是把它重新實作了一遍并且開源了.

GNUstep原始碼下載地址(建議下載 Base1.26.0版本)

雖然GNUstep不是蘋果官方原始碼,但還是具有一定的參考價值,它里面的實作和蘋果原始碼的實作是非常接近的.請看下面的截圖:

它具有一定的參考價值,對于我們后面理解一些東西有很重要的作用.

接下來我們看看條件鎖

pthread_mutex (條件鎖)

對于mutex的互斥鎖、遞回鎖我們都是很清楚的了,接下來我們直接看看條件鎖.首先看一下我的需求是什么樣,如下圖:

我的業務需求是希望:如果dataMuArr.count==0的時候,我不洗掉,等dataMuArr有資料了我再去洗掉.那這時候,我們就可以用條件鎖,請看下面:

從log輸出,可以看出,條件鎖確實可以解決這種需求.而且我們可以發現pthread_cond_wait在休眠的時候是解鎖了,所以add方法才能繼續執行,被喚醒的時候又加鎖,所以加鎖和解鎖是還是成對出現的.還有個補充點就是:目前是一個執行緒在等待,如果是多個執行緒在等待,我們就用pthread_cond_broadcast(&_cond)即可,broadcast是廣播的意思,所以很容易理解,大家可以試試.

NSLock、NSRecursiveLock、NSCondition詳解

NSLock:它是對pthread_mutex普通鎖的封裝,一看就是oc物件,使用起來更加面向物件,我們看下用法

- (BOOL)tryLock;//嘗試加鎖

- (BOOL)lockBeforeDate:(NSDate*)limit; //在這個時間之前,如果我能等到這把鎖解鎖我就等,否則就不等

- (void)lock; //加鎖

- (void)unlock;//解鎖

主要是上面這四個,我們直接用吧,上面寫得都很清晰:

上面結果很清晰,沒有問題,用法也是非常的簡單.這里還有個注意點,我們可以用我上一個博客的知識點可以查看匯編呼叫程序,你會發現如下

因為這個程序還要找快取,找方法,全是訊息機制那些,知道這些有什么用呢?這個給我們對比執行緒同步的性能方面提供了參考,它的性能相對來說,肯定沒有pthread_mutex效率高,因為它多執行了很多代碼,這個很清晰吧.

如果我們通過打斷點也是能找到NSLock的實作,具體呼叫等等,但是發現很麻煩,這時候我們就用上面說的GNUstep里面查找一下,如下圖:

這里很明顯可以看出是對pthread_mutex普通鎖的一個封裝.

NSRecursiveLock:它是對pthread_mutex遞回鎖的封裝,它基本和上面的NSLock一樣的,幾乎是一樣的,我們直接看一下用法,稍微過一下:

NSCondition:它是對pthread_mutex和cont的封裝,也就是上面的條件鎖,我們也看下用法:

- (void)wait;//等待

- (BOOL)waitUntilDate:(NSDate*)limit;//在這個時間之前,如果我能等到這把鎖解鎖我就等,否則就不等

- (void)signal;//信號

- (void)broadcast;//廣播

- (void)lock; //加鎖

- (void)unlock;//解鎖

我直接演示一下用法即可,你可以用條件鎖,也可以普通鎖.我就把前面那個演示一下:

NSConditionLock詳解

NSConditionLock:它是對NSCondition的進一步封裝,可以設定具體的條件值,以前的鎖都是等待什么,這個是可以設定具體的值

這時候如果我們把初始化條件置為其他的話,程式就會一直休眠,不會有任何列印.用這個鎖,我們就可以達到控制多執行緒的執行順序,無論多少個,我們都能控制.這個也是很明確,就不細說了

dispatch_queue (DISPATCH_QUEUE_SERIAL)

直接使用GCD的串行佇列,也是可以實作執行緒同步的.我們不能想到執行緒同步,就想到鎖,我們要知道執行緒同步的本質是什么,就是多條執行緒搶占同一個資源,所以串行佇列也是可以解決執行緒同步的問題.比如我們就拿賣票來說.

dispatch_semaphore_t詳解

dispatch_semaphore_t叫做"信號量"

信號量的初始值,可以用來控制執行緒并發訪問的最大數量.如果我們最大數量設定1,那就是能達到執行緒同步的目的,現在我們先去看一下怎么使用

dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER):如果信號量的值是>0,就讓信號量的值減1,然后繼續往下執行代碼...直到當信號量的值是0的時候,這時候就會休眠等待.首先看你傳的時間,如果是now就立即執行,這里傳的DISPATCH_TIME_FOREVER就不受時間這個條件限制了,直到當信號量的值>0才會喚起休眠,繼續執行.

dispatch_semaphore_signal(self.semaphore):就是讓信號量的值+1,只要變成1就會喚起之前的等待,就這樣重復執行.

所以我們之前的代碼,我們只要把信號量的值設定為1就可以做到執行緒同步,這里大家可以自己嘗試.

@synchronized詳解

相信很多都見過這個關鍵字

@synchronized它是對pthread_mutex遞回鎖的一個封裝,我們參考一下GNUstep去參考一下原始碼.

它是在寫法上最簡單的,這里我們先看一下怎么使用:

寫法非常簡單,也是能解決執行緒同步. 這里的 @synchronized (self) 里面的self跟每個鎖是一一對應的,我們可以理解就是self是key,這個鎖就是value,就是存在字典中(可以由GNUstep去參考得知).所以如果是同一鎖,@synchronized (self)這里的self物件必須是同一個物件.

說了這么多,上面的都是常用的方案.,當然還有其他方案,

執行緒同步總結:

1.同步方案性能優化對比:

這里是整理了一個由高到低的排序,也是測出來的,供大家參考:

os_unfair_lock (只支持iOS10以后)

OSSpinLock (不建議使用,iOS10以后棄用)

dispatch_semaphore_t

pthread_mutex

dispatch_queue (DISPATCH_QUEUE_SERIAL)

NSLock

NSCondition

pthread_mutex (recursive)

NSRecursiveLock

NSConditionLock

@synchronized

所以推薦使用dispatch_semaphore_t和pthread_mutex ,初始化代碼多的話,可以定義成宏.

2.自旋鎖和互斥鎖的對比

(雖然自旋鎖現在已經不用了,因為只有一個還是廢棄的,但是有時候面試喜歡問,所以這里我們還是說下)

一、什么時候用自旋鎖比較劃算?

預計執行緒的等待時間較短;加鎖的代碼(臨界區)經常被呼叫,但競爭情況很少發生;CPU資源不緊張;多核處理器

二、什么時候用互斥鎖比較劃算?

預計執行緒等待時間較長;單核處理器;臨界區由IO操作;臨界區代碼復雜或者回圈量大.

接下來我會繼續努力撰寫其他博客,您的支持就是我最大的動力!

如果覺得我寫得對您有所幫助，請點贊關注我，我會持續更新😄

感謝支持🙏🙏🙏!

我是GDCoder,我們下期見!