正文：首先看一下問題引出,先看一些經典的問題.

多線程的隱患

首先我們利用多線程的話肯定是好處多多,因為我們可以同時去做一些事情,大大的提高了效率.像我們下載視頻的時候就可以同時下載多個視頻,這樣是節省了很多時間,用戶體驗也會更好.但是用得時候也會存在一些安全隱患,比如同一塊資源可能會被多個線程共享,也就是多個線程可能會訪問同一塊資源,這樣會出現一些數據錯亂和數據安全的問題.下面我們就看一些例子.

存錢取錢案例

比如我現在有1000元,同時有2個線程去處理,一個線程是取錢100元,一個線程是存錢100元,我制作了一張示意圖如下:

存錢取錢示意圖

我們從上面的圖應該很清楚,存100、取100的最終結果就是還是剩余1000元,但是看我們上面的示意圖,最終結果要么是900要么是1100,這就與1000的結果對不上,所以很明顯用多線程是會存在隱患,下面我們用代碼演示一下上面的結果:

賣票案例

這個和上面的稍微有點差別,因為上面的是2個操作,而賣票呢,它是1個操作.同樣的比如我現在有1000張票,同時有2個線程去處理賣票,一個線程是一個線程賣票100張,另一個線程也是賣票100張,同時操作的話,也會出現異常,我制作了一張示意圖如下:

我們同樣的也可以用代碼演示一下效果:

上面的兩個,大家可以試試.接下來針對上面的問題,我們就引出了今天的主角,線程同步技術

線程同步技術

解決方案:使用線程同步技術 (同步,就是協同步調,按照預定的先后次序進行運行),我們先來看下線程同步技術有哪些方案:線程同步方案最常見的技術就是:加鎖.大概方案如下(大致這么多方案,當然還有其他的)

OSSpinLock (自旋鎖)

os_unfair_lock (互斥鎖)

pthread_mutex (互斥鎖、遞歸鎖)(里面3種類型,目前只說2種對我們有用的)

dispatch_queue (DISPATCH_QUEUE_SERIAL)

NSLock

NSRecursiveLock

NSCondition

NSConditionLock

@synchronized

以上的這些都是可以做到線程同步方案,我會一個一個介紹,并且介紹它們的優缺點,性能怎么樣,我們怎么去選擇等等.我們就以上面的例子講解.

OSSpinLock (自旋鎖)

OSSpinLock 叫做 "自旋鎖", 等待鎖的狀態會處于忙等( busy-wait )狀態,一直占用著CPU內存.頭文件導入,而且這個鎖是過期鎖,iOS10以后就過期了,但是我們還是來看看,因為面試中可能會遇到,用法如下:

初始化鎖:OSSpinLock spinLock = OS_SPINLOCK_INIT;

加鎖: OSSpinLockLock(&_spinLock);

解鎖: OSSpinLockUnlock(&_spinLock);

我們先看賣票:

我是加鎖和解鎖了,為什么上面的代碼還有問題,有發現原因的嗎?這是因為SpinLock是局部變量,所以我們進去都是初始化了一把新鎖,這把鎖并沒有被使用過,是達不到加鎖的目的.所以所有的線程都是用同一把鎖才能達到加鎖的目的.請看下面代碼:

確實是剩下85張,沒有問題.原理是這樣,每次執行saleTicket都會進入 //加鎖: OSSpinLockLock(&_SpinLock) 這個代碼,第一次進來是正常給_SpinLock加鎖,第二次進來的時候,發現_SpinLock已經被人加了鎖,它會在這邊等待,等待這把鎖被解鎖,解鎖完了以后然后它再去加鎖,就這樣依次進行,就保證了里面的那段代碼同時只有一個線程在處理.這就解決了線程同步的問題.

接下來我們就看存錢和取錢的問題.存錢、取錢是2個操作,我們是用同一把鎖還是2把鎖?思考了這個問題我們就知道怎么做了,因為存錢和取錢是不能同時進行,所以我們就用同一把鎖即可(2把鎖是有問題的大家可以自己試試),請看下面的代碼,我們驗證一下:

自旋鎖"忙等"狀態是怎么等呢?忙等就是一直忙碌,而且還在等待,類似這樣while(鎖還沒有解開),就會一直執行,占用cpu,直到鎖被放開.而且OSSpinLock是已經過期了,而且目前已經不再安全,可能會出現優先級反轉的問題.

下面說一下線程的調度問題

其實你看上面的圖,如果隨著時間的推移,操作系統把時間給thread1一點時間,再給thread2一點時間,再給thread3一點時間,而且這個時間周期非常短,就這樣一直非?？斓那袚Q,這樣下來給我們的感覺就是同時執行.這就是實現多線程的一個方案.也就是多線程的原理,我們也可以說這是時間片輪轉調度算法.調用進程或者線程都是用這套算法

還有個就是線程的優先級問題,比如thread1的優先級比較高,那么操作系統就會給thread1多一點時間去執行.其他的線程就少一點時間去執行.這樣的話,我們使用自旋鎖就會存在一個優先級反轉的問題.比如thread1優先級非常高,thread2優先級很低.首先是thread2先進去加鎖,thread1再進來就會等thread2解鎖,由于thread1的優先級非常高,CPU就把大量的時間給了thread1,此時可能導致thread2沒有時間執行解鎖,thread1就會一直執行等待,有點死鎖的感覺.

這樣大家想一想:如果優先級高的不是忙等,而是休眠,休息就不會占用CPU,那不就是解決了這個問題.

os_unfair_lock (互斥鎖)

os_unfair_lock用于取代不安全OSSpinLock,是從iOS10開始支持.

從底層調用看,等待os_unfair_lock鎖的線程會處于休眠狀態,并非忙等(后面會證明一下)

它的用法和OSSpinLock非常像,需要倒入頭文件,用法如下:

初始化鎖:os_unfair_lock unfairLock = OS_UNFAIR_LOCK_INIT;

加鎖: os_unfair_lock_lock(&_unfairLock);

解鎖:os_unfair_lock_unlock(&_unfairLock);

下面我們就去看一下用法

存錢和取錢也是一樣的道理,我們可以自己試試.

pthread_mutex (互斥鎖)

像這種pthread開頭的一般都是跨平臺的Windows、linux等等都是可以用的,mutex叫做"互斥鎖",等待鎖的線程會處于休眠狀態

其實用法都是差不多,我們先來看下怎么用,這個稍微代碼多一點點

//初始化屬性
    pthread_mutexattr_t attr;
    pthread_mutexattr_init(&attr);
    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
    //初始化鎖
    pthread_mutex_init(&_mutex, &attr);(&attr也可以傳NULL,這樣的話,上面的都是默認的,上面可以都不用寫)
    //加鎖
    pthread_mutex_lock(&_mutex);
    //解鎖
    pthread_mutex_unlock(&_mutex);
    //銷毀相關資源
    pthread_mutexattr_destroy(&attr);
    pthread_mutex_destroy(&_mutex);

其中PTHREAD_MUTEX_NORMAL是鎖的類型,后面會細說,先傳默認PTHREAD_MUTEX_NORMAL

先看運行結果:

沒有問題,記得銷毀哈,之前說的2個鎖,沒有提供銷毀的方法,那我們就不寫,如果提供了,我們還是寫一下的好!

pthread_mutex (遞歸鎖)

我們再看另一種情況,請看下面的代碼:

上面這些代碼會出現什么情況?死鎖,會出現相互等待的情況,只會輸出第一個NSLog,遇到這種情況我們怎么解決才好呢?2把不同的鎖即可解決問題,就是otherMutexTest里面一把鎖,otherMutexTest2里面另一把鎖就可以解決了,這個我就不截圖了,我們可以自己試試

再看下面另一種情況:出現遞歸怎么辦?如下圖

遇到上面的這種情況我們又怎么處理,如果就像截圖那樣的話,就會出現休眠等待.如果我們想執行下去,我們就是可以設置鎖的類型來解決這個問題:一共3種類型如下

我們只要把鎖的類型換成遞歸鎖,立刻就能解決這個問題,我們加一個遞歸停止條件,不然會一直運行

還有一個注意的,這個允許重復加鎖,一定是在同一個線程,如果是多個線程的話,就不行.遞歸鎖:允許同一個線程對一把鎖重復加鎖.

自旋鎖、互斥鎖匯編分析

自旋鎖:一直忙等,占用CPU內存,一直在執行代碼;互斥鎖:不等待,休眠.不執行代碼.我們怎么去證明這個問題呢?我們可以從匯編實現上去證明這個問題,我們先看OSSpinLock自旋鎖:

首先我們如果用這個上面的來調試的話,是看不出來什么效果的,因為這里面都是一大段一大段匯編代碼執行的,我們需要一句一句的執行匯編指令.就需要敲si,s是step的意思,代碼一行一行的執行,如果只用s的話,就是一行oc代碼執行,一行oc對應可能一大段匯編,所以我們還需要加i,i是instruction的意思是一行一行匯編指令執行,簡稱si. 還有個是nexti,它也是一行一行匯編指令執行,只是nexti它是遇到函數就會一下執行過去.因為我們要看函數實現,所以我們用si.

我們再看一下,我代碼是怎么寫的:

我是創建了10個線程去執行賣票,而且在賣票中間sleep(100),這樣是為了,第一條線程進去,我們不管,我們主要看第二條線程在這等待的時間,到底做了什么事.所以我們主要看第二條的匯編代碼.sleep(100)是為了時間長點,方便我們能看出做什么事.如果時間太短,直接第二條線程就不等待,那我們就看不到效果,請看下面的結果