linux服務(wù)器開發(fā)相關(guān)視頻解析：
c/c++ linux服務(wù)器開發(fā)免費(fèi)學(xué)習(xí)地址：c/c++ linux后臺(tái)服務(wù)器高級(jí)架構(gòu)師
正文：首先看一下問題引出,先看一些經(jīng)典的問題.
多線程的隱患
首先我們利用多線程的話肯定是好處多多,因?yàn)槲覀兛梢酝瑫r(shí)去做一些事情,大大的提高了效率.像我們下載視頻的時(shí)候就可以同時(shí)下載多個(gè)視頻,這樣是節(jié)省了很多時(shí)間,用戶體驗(yàn)也會(huì)更好.但是用得時(shí)候也會(huì)存在一些安全隱患,比如同一塊資源可能會(huì)被多個(gè)線程共享,也就是多個(gè)線程可能會(huì)訪問同一塊資源,這樣會(huì)出現(xiàn)一些數(shù)據(jù)錯(cuò)亂和數(shù)據(jù)安全的問題.下面我們就看一些例子.
存錢取錢案例
比如我現(xiàn)在有1000元,同時(shí)有2個(gè)線程去處理,一個(gè)線程是取錢100元,一個(gè)線程是存錢100元,我制作了一張示意圖如下:
存錢取錢示意圖
我們從上面的圖應(yīng)該很清楚,存100、取100的最終結(jié)果就是還是剩余1000元,但是看我們上面的示意圖,最終結(jié)果要么是900要么是1100,這就與1000的結(jié)果對(duì)不上,所以很明顯用多線程是會(huì)存在隱患,下面我們用代碼演示一下上面的結(jié)果:
賣票案例
這個(gè)和上面的稍微有點(diǎn)差別,因?yàn)樯厦娴氖?個(gè)操作,而賣票呢,它是1個(gè)操作.同樣的比如我現(xiàn)在有1000張票,同時(shí)有2個(gè)線程去處理賣票,一個(gè)線程是一個(gè)線程賣票100張,另一個(gè)線程也是賣票100張,同時(shí)操作的話,也會(huì)出現(xiàn)異常,我制作了一張示意圖如下:
我們同樣的也可以用代碼演示一下效果:
上面的兩個(gè),大家可以試試.接下來針對(duì)上面的問題,我們就引出了今天的主角,線程同步技術(shù)
線程同步技術(shù)
解決方案:使用線程同步技術(shù) (同步,就是協(xié)同步調(diào),按照預(yù)定的先后次序進(jìn)行運(yùn)行),我們先來看下線程同步技術(shù)有哪些方案:線程同步方案最常見的技術(shù)就是:加鎖.大概方案如下(大致這么多方案,當(dāng)然還有其他的)
OSSpinLock (自旋鎖)
os_unfair_lock (互斥鎖)
pthread_mutex (互斥鎖、遞歸鎖)(里面3種類型,目前只說2種對(duì)我們有用的)
dispatch_queue (DISPATCH_QUEUE_SERIAL)
NSLock
NSRecursiveLock
NSCondition
NSConditionLock
@synchronized
以上的這些都是可以做到線程同步方案,我會(huì)一個(gè)一個(gè)介紹,并且介紹它們的優(yōu)缺點(diǎn),性能怎么樣,我們?cè)趺慈ミx擇等等.我們就以上面的例子講解.
【文章福利】需要C/C++ Linux服務(wù)器架構(gòu)師學(xué)習(xí)資料加群812855908（資料包括C/C++，Linux，golang技術(shù)，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協(xié)程，DPDK，ffmpeg等）
OSSpinLock (自旋鎖)
OSSpinLock 叫做 "自旋鎖", 等待鎖的狀態(tài)會(huì)處于忙等( busy-wait )狀態(tài),一直占用著CPU內(nèi)存.頭文件導(dǎo)入<libkern/OSAtomic.h>,而且這個(gè)鎖是過期鎖,iOS10以后就過期了,但是我們還是來看看,因?yàn)槊嬖囍锌赡軙?huì)遇到,用法如下:
初始化鎖:OSSpinLock spinLock = OS_SPINLOCK_INIT;
加鎖: OSSpinLockLock(&_spinLock);
解鎖: OSSpinLockUnlock(&_spinLock);
我們先看賣票:
我是加鎖和解鎖了,為什么上面的代碼還有問題,有發(fā)現(xiàn)原因的嗎?這是因?yàn)镾pinLock是局部變量,所以我們進(jìn)去都是初始化了一把新鎖,這把鎖并沒有被使用過,是達(dá)不到加鎖的目的.所以所有的線程都是用同一把鎖才能達(dá)到加鎖的目的.請(qǐng)看下面代碼:
確實(shí)是剩下85張,沒有問題.原理是這樣,每次執(zhí)行saleTicket都會(huì)進(jìn)入 //加鎖: OSSpinLockLock(&_SpinLock) 這個(gè)代碼,第一次進(jìn)來是正常給_SpinLock加鎖,第二次進(jìn)來的時(shí)候,發(fā)現(xiàn)_SpinLock已經(jīng)被人加了鎖,它會(huì)在這邊等待,等待這把鎖被解鎖,解鎖完了以后然后它再去加鎖,就這樣依次進(jìn)行,就保證了里面的那段代碼同時(shí)只有一個(gè)線程在處理.這就解決了線程同步的問題.
接下來我們就看存錢和取錢的問題.存錢、取錢是2個(gè)操作,我們是用同一把鎖還是2把鎖?思考了這個(gè)問題我們就知道怎么做了,因?yàn)榇驽X和取錢是不能同時(shí)進(jìn)行,所以我們就用同一把鎖即可(2把鎖是有問題的大家可以自己試試),請(qǐng)看下面的代碼,我們驗(yàn)證一下:
自旋鎖"忙等"狀態(tài)是怎么等呢?忙等就是一直忙碌,而且還在等待,類似這樣while(鎖還沒有解開),就會(huì)一直執(zhí)行,占用cpu,直到鎖被放開.而且OSSpinLock是已經(jīng)過期了,而且目前已經(jīng)不再安全,可能會(huì)出現(xiàn)優(yōu)先級(jí)反轉(zhuǎn)的問題.
下面說一下線程的調(diào)度問題
其實(shí)你看上面的圖,如果隨著時(shí)間的推移,操作系統(tǒng)把時(shí)間給thread1一點(diǎn)時(shí)間,再給thread2一點(diǎn)時(shí)間,再給thread3一點(diǎn)時(shí)間,而且這個(gè)時(shí)間周期非常短,就這樣一直非?？斓那袚Q,這樣下來給我們的感覺就是同時(shí)執(zhí)行.這就是實(shí)現(xiàn)多線程的一個(gè)方案.也就是多線程的原理,我們也可以說這是時(shí)間片輪轉(zhuǎn)調(diào)度算法.調(diào)用進(jìn)程或者線程都是用這套算法
還有個(gè)就是線程的優(yōu)先級(jí)問題,比如thread1的優(yōu)先級(jí)比較高,那么操作系統(tǒng)就會(huì)給thread1多一點(diǎn)時(shí)間去執(zhí)行.其他的線程就少一點(diǎn)時(shí)間去執(zhí)行.這樣的話,我們使用自旋鎖就會(huì)存在一個(gè)優(yōu)先級(jí)反轉(zhuǎn)的問題.比如thread1優(yōu)先級(jí)非常高,thread2優(yōu)先級(jí)很低.首先是thread2先進(jìn)去加鎖,thread1再進(jìn)來就會(huì)等thread2解鎖,由于thread1的優(yōu)先級(jí)非常高,CPU就把大量的時(shí)間給了thread1,此時(shí)可能導(dǎo)致thread2沒有時(shí)間執(zhí)行解鎖,thread1就會(huì)一直執(zhí)行等待,有點(diǎn)死鎖的感覺.
這樣大家想一想:如果優(yōu)先級(jí)高的不是忙等,而是休眠,休息就不會(huì)占用CPU,那不就是解決了這個(gè)問題.
os_unfair_lock (互斥鎖)
os_unfair_lock用于取代不安全OSSpinLock,是從iOS10開始支持.
從底層調(diào)用看,等待os_unfair_lock鎖的線程會(huì)處于休眠狀態(tài),并非忙等(后面會(huì)證明一下)
它的用法和OSSpinLock非常像,需要倒入頭文件<os/lock.h>,用法如下:
初始化鎖:os_unfair_lock unfairLock = OS_UNFAIR_LOCK_INIT;
加鎖: os_unfair_lock_lock(&_unfairLock);
解鎖:os_unfair_lock_unlock(&_unfairLock);
下面我們就去看一下用法
存錢和取錢也是一樣的道理,我們可以自己試試.
pthread_mutex (互斥鎖)
像這種pthread開頭的一般都是跨平臺(tái)的Windows、linux等等都是可以用的,mutex叫做"互斥鎖",等待鎖的線程會(huì)處于休眠狀態(tài)
其實(shí)用法都是差不多,我們先來看下怎么用,這個(gè)稍微代碼多一點(diǎn)點(diǎn)
//初始化屬性
pthread_mutexattr_tattr;pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
//初始化鎖
pthread_mutex_init(&_mutex, &attr);(&attr也可以傳NULL,這樣的話,上面的都是默認(rèn)的,上面可以都不用寫)
//加鎖
pthread_mutex_lock(&_mutex);
//解鎖
pthread_mutex_unlock(&_mutex);
//銷毀相關(guān)資源
pthread_mutexattr_destroy(&attr);
pthread_mutex_destroy(&_mutex);
其中PTHREAD_MUTEX_NORMAL是鎖的類型,后面會(huì)細(xì)說,先傳默認(rèn)PTHREAD_MUTEX_NORMAL
先看運(yùn)行結(jié)果:
沒有問題,記得銷毀哈,之前說的2個(gè)鎖,沒有提供銷毀的方法,那我們就不寫,如果提供了,我們還是寫一下的好!
pthread_mutex (遞歸鎖)
我們?cè)倏戳硪环N情況,請(qǐng)看下面的代碼:
上面這些代碼會(huì)出現(xiàn)什么情況?死鎖,會(huì)出現(xiàn)相互等待的情況,只會(huì)輸出第一個(gè)NSLog,遇到這種情況我們?cè)趺唇鉀Q才好呢?2把不同的鎖即可解決問題,就是otherMutexTest里面一把鎖,otherMutexTest2里面另一把鎖就可以解決了,這個(gè)我就不截圖了,我們可以自己試試
再看下面另一種情況:出現(xiàn)遞歸怎么辦?如下圖
遇到上面的這種情況我們又怎么處理,如果就像截圖那樣的話,就會(huì)出現(xiàn)休眠等待.如果我們想執(zhí)行下去,我們就是可以設(shè)置鎖的類型來解決這個(gè)問題:一共3種類型如下
我們只要把鎖的類型換成遞歸鎖,立刻就能解決這個(gè)問題,我們加一個(gè)遞歸停止條件,不然會(huì)一直運(yùn)行
還有一個(gè)注意的,這個(gè)允許重復(fù)加鎖,一定是在同一個(gè)線程,如果是多個(gè)線程的話,就不行.遞歸鎖:允許同一個(gè)線程對(duì)一把鎖重復(fù)加鎖.
自旋鎖、互斥鎖匯編分析
自旋鎖:一直忙等,占用CPU內(nèi)存,一直在執(zhí)行代碼;互斥鎖:不等待,休眠.不執(zhí)行代碼.我們?cè)趺慈プC明這個(gè)問題呢?我們可以從匯編實(shí)現(xiàn)上去證明這個(gè)問題,我們先看OSSpinLock自旋鎖:
首先我們?nèi)绻眠@個(gè)上面的來調(diào)試的話,是看不出來什么效果的,因?yàn)檫@里面都是一大段一大段匯編代碼執(zhí)行的,我們需要一句一句的執(zhí)行匯編指令.就需要敲si,s是step的意思,代碼一行一行的執(zhí)行,如果只用s的話,就是一行oc代碼執(zhí)行,一行oc對(duì)應(yīng)可能一大段匯編,所以我們還需要加i,i是instruction的意思是一行一行匯編指令執(zhí)行,簡稱si. 還有個(gè)是nexti,它也是一行一行匯編指令執(zhí)行,只是nexti它是遇到函數(shù)就會(huì)一下執(zhí)行過去.因?yàn)槲覀円春瘮?shù)實(shí)現(xiàn),所以我們用si.
我們?cè)倏匆幌?我代碼是怎么寫的:
我是創(chuàng)建了10個(gè)線程去執(zhí)行賣票,而且在賣票中間sleep(100),這樣是為了,第一條線程進(jìn)去,我們不管,我們主要看第二條線程在這等待的時(shí)間,到底做了什么事.所以我們主要看第二條的匯編代碼.sleep(100)是為了時(shí)間長點(diǎn),方便我們能看出做什么事.如果時(shí)間太短,直接第二條線程就不等待,那我們就看不到效果,請(qǐng)看下面的結(jié)果
從上面的結(jié)果看,進(jìn)入OSSpinLockLock函數(shù),它會(huì)一直在81aef那里一直循環(huán)執(zhí)行,這是外循環(huán),我們所說的自旋鎖就是這樣,一直循環(huán)執(zhí)行,占用CPU內(nèi)存.一旦有人放開這把鎖就會(huì)條件循環(huán)結(jié)束,不會(huì)再執(zhí)行循環(huán).
接下來我們看看互斥鎖pthread_mutex
查找的方法和上面的一樣,我就截圖最關(guān)鍵的圖即可,請(qǐng)看下面:
執(zhí)行到最后,直接是callsys,調(diào)用系統(tǒng)的方法,是不是類似我之前說的runloop里面的休眠的方法,而且我們知道休眠是任何事情都不會(huì)做,不占用CPU內(nèi)存,所以我們最后看到,我的模擬器立刻又彈出來了,說明確實(shí)是睡眠,不占用任何CPU內(nèi)存.
os_unfair_lock_lock我們可以用上面的方法嘗試,它的結(jié)果也是互斥鎖.
由于鎖內(nèi)容較多,我會(huì)在接下來的博客繼續(xù)介紹
