資源共享

1塊資源可能會被多個線程共享，也就是多個線程可能會訪問同一塊資源

比如多個線程訪問同一個對象、同一個變量、同一個文件

當(dāng)多個線程訪問同一塊資源時，很容易引發(fā)數(shù)據(jù)錯亂和數(shù)據(jù)安全問題

一、解決方案

解決方案：使用線程同步技術(shù)（同步，就是協(xié)同步調(diào)，按預(yù)定的先后次序進行）

常見的線程同步技術(shù)是：加鎖

1、OSSpinLock

OSSpinLock叫做”自旋鎖”，等待鎖的線程會處于忙等（busy-wait）狀態(tài)，一直占用著CPU資源

目前已經(jīng)不再安全，可能會出現(xiàn)優(yōu)先級反轉(zhuǎn)問題

如果等待鎖的線程優(yōu)先級較高，它會一直占用著CPU資源，優(yōu)先級低的線程就無法釋放鎖

需要導(dǎo)入頭文件#import<libkern/OSAtomic.h>

2、os_unfair_lock

os_unfair_lock用于取代不安全的OSSpinLock，從iOS10開始才支持

從底層調(diào)用看，等待os_unfair_lock鎖的線程會處于休眠狀態(tài)，并非忙等

需要導(dǎo)入頭文件#import<os/lock.h>

3、pthread_mutex

mutex叫做”互斥鎖”，等待鎖的線程會處于休眠狀態(tài)

需要導(dǎo)入頭文件#import<pthread.h>

pthread_mutex–普通鎖

pthread_mutex–遞歸鎖

pthread_mutex–條件

4、NSLock

NSLock是對mutex普通鎖的封裝

5、NSRecursiveLock

NSRecursiveLock也是對mutex遞歸鎖的封裝，API跟NSLock基本一致

6、NSCondition

NSCondition是對mutex和cond的封裝

7、NSConditionLock

NSConditionLock是對NSCondition的進一步封裝，可以設(shè)置具體的條件值

8、dispatch_semaphore

semaphore叫做”信號量”

信號量的初始值，可以用來控制線程并發(fā)訪問的最大數(shù)量

信號量的初始值為1，代表同時只允許1條線程訪問資源，保證線程同步

9、dispatch_queue(DISPATCH_QUEUE_SERIAL)

直接使用GCD的串行隊列，也是可以實現(xiàn)線程同步的

10、@synchronized

@synchronized是對mutex遞歸鎖的封裝

源碼查看：objc4中的objc-sync.mm文件(蘋果源碼官方地址)

@synchronized(obj)內(nèi)部會生成obj對應(yīng)的遞歸鎖，然后進行加鎖、解鎖操作

二、iOS線程同步方案性能比較

原則：

普通鎖比遞歸鎖性能好

語言越高級，封裝的邏輯越多，性能也就越差（所有語言都如此）　

實際測試

性能從高到低排序

os_unfair_lock // 缺點：iOS10才支持

OSSpinLock　　// 缺點：可能出現(xiàn)優(yōu)先級反轉(zhuǎn) 已經(jīng)不再安全 蘋果也不推薦使用

dispatch_semaphore // 推薦使用

pthread_mutex　　// 優(yōu)點：跨平臺 互斥鎖（普通鎖） 推薦使用

dispatch_queue(DISPATCH_QUEUE_SERIAL)　// c

NSLock 　　// oc

NSCondition　　 // oc

pthread_mutex(recursive) // 遞歸鎖

NSRecursiveLock　　// oc

NSConditionLock // oc

@synchronized // 遞歸鎖 oc

三、自旋鎖、互斥鎖 選擇

自旋鎖：等待狀態(tài)處于忙等

互斥鎖：等待狀態(tài)處于休眠

1、什么情況使用自旋鎖比較劃算？

預(yù)計線程等待鎖的時間很短

加鎖的代碼（臨界區(qū)）經(jīng)常被調(diào)用，但競爭情況很少發(fā)生

CPU資源不緊張

多核處理器

2、什么情況使用互斥鎖比較劃算？

預(yù)計線程等待鎖的時間較長

單核處理器

臨界區(qū)有IO操作

臨界區(qū)代碼復(fù)雜或者循環(huán)量大

臨界區(qū)競爭非常激烈

四、讀寫鎖

場景：

同一時間，只能有1個線程進行寫的操作

同一時間，允許有多個線程進行讀的操作

同一時間，不允許既有寫的操作，又有讀的操作

上面的場景就是典型的“多讀單寫”，經(jīng)常用于文件等數(shù)據(jù)的讀寫操作，iOS中的實現(xiàn)方案有：

1、讀寫鎖：pthread_rwlock

等待鎖的線程會進入休眠

2、dispatch_barrier_async

這個函數(shù)傳入的并發(fā)隊列必須是自己通過dispatch_queue_cretate創(chuàng)建的

如果傳入的是一個串行或是一個全局的并發(fā)隊列，那這個函數(shù)便等同于dispatch_async函數(shù)的效果

最新評論