在多線程中，當多個線程同時訪問同一塊資源的時候，就容易引起數(shù)據(jù)錯亂和數(shù)據(jù)安全問題
(1).OSSpinLock
OSSpinLock叫做”自旋鎖”，等待鎖的線程會處于忙等（busy-wait）狀態(tài)，一直占用著CPU資源
存在問題：
目前已經(jīng)不再安全，可能會出現(xiàn)優(yōu)先級反轉(zhuǎn)問題
如果等待鎖的線程優(yōu)先級較高，它會一直占用著CPU資源，優(yōu)先級低的線程就無法釋放鎖
當多個線程優(yōu)先級不同的時候，同時調(diào)用同一方法，當優(yōu)先級低的線程先調(diào)用這個方法的時候，就會進行加鎖，優(yōu)先級高的進來發(fā)現(xiàn)已經(jīng)加鎖了，而CPU會對優(yōu)先級高的分配的時間片多，這時CPU會從優(yōu)先級低的切換到優(yōu)先級高的線程執(zhí)行，而優(yōu)先級低的線程沒執(zhí)行完，所以沒解鎖，優(yōu)先級高的就會一直訪問是否解鎖，所以就會一直卡著
// 初始化
OSSpinLock lock = OS_SPINLOCK_INIT;
// 加鎖
OSSpinLockLock(&lock1);
// 解鎖
OSSpinLockUnlock(&lock1);
//還有一種嘗試加鎖,能加鎖就加，不能就直接跳過執(zhí)行之后代碼
bool result = OSSpinLockTry(&lock)
(2).os_unfair_lock
- os_unfair_lock用于取代不安全的OSSpinLock ，從iOS10開始才支持
- 從底層調(diào)用看，等待os_unfair_lock鎖的線程會處于休眠狀態(tài)，并非忙等
- 需要導入頭文件#import <os/lock.h>
//初始化
os_unfair_loc lock = OS_UNFAIR_LOCK_INIT;
// 嘗試加鎖
os_unfair_lock_trylock(&lock)
// 加鎖
os_unfair_lock_lock(&lock);
// 解鎖
os_unfair_lock_unlock(&lock);
(3).pthread_mutex（互斥鎖、遞歸鎖）
- mutex叫做”互斥鎖”，等待鎖的線程會處于休眠狀態(tài)
- n需要導入頭文件#import <pthread.h>
/*
鎖的屬性的設置
Mutex type attributes
*/
#define PTHREAD_MUTEX_NORMAL 0
#define PTHREAD_MUTEX_ERRORCHECK 1
#define PTHREAD_MUTEX_RECURSIVE 2 // 遞歸鎖，允許同一個線程對一把鎖進行重復加鎖
#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
// 初始化屬性
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_DEFAULT);
// 初始化鎖
pthread_mutex_t mutex
pthread_mutex_init(mutex, &attr);
// 加鎖
pthread_mutex_lock(&mutex);
// 解鎖
pthread_mutex_unlock(&mutex);
// 銷毀相關(guān)資源
pthread_mutexattr_destroy(&attr);
pthread_mutex_destroy(&mutex);
(4).pthread_mutex– 遞歸鎖
和上面的一樣，只不過更換一下鎖的屬性的枚舉值
// 初始化屬性
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
// 初始化鎖
pthread_mutex_t mutex
pthread_mutex_init(mutex, &attr);
(5).pthread_mutex– 條件
場景：兩條線程有依賴關(guān)系，一條線程必須等另外一天線程完成才執(zhí)行相關(guān)操作
// 初始化鎖
pthread_mutex_t mutex;
// NULL代表使用默認屬性
pthread_mutex_init(&_mutex, NULL);
// 初始化條件
pthread_cond_t cond;
pthread_cond_init(&_cond, NULL);
// 等待條件（符合條件，進入休眠，放開鎖；被喚醒后會再次加鎖）
pthread_cond_wait(&_cond, &_mutex);
// 激活一個等待該條件的線程
pthread_cond_signal(&_cond);
// 激活所有等待該條件的線程
pthread_cond_broadcast(&_cond);
// 銷毀資源
pthread_mutex_destroy(&_mutex);
pthread_cond_destroy(&_cond);
(6).NSLock
NSLock是對pthread_mutex_t普通鎖的封裝
@interface NSLock : NSObject <NSLocking> {
//嘗試加鎖，能加就加
- (BOOL)tryLock;
//在limit之前一直等待加鎖，如果limit之前不能加鎖，則返回false，否則返回true
- (BOOL)lockBeforeDate:(NSDate *)limit;
}
@protocol NSLocking
- (void)lock;
- (void)unlock;
@end
//初始化
NSLock *lock = [[NSLock alloc] init];
(7).NSRecursiveLock
NSRecursiveLock也是對mutex遞歸鎖的封裝，API跟NSLock基本一致
(8).NSCondition
NSCondition是對mutex和cond的封裝
@interface NSCondition : NSObject <NSLocking> {
- (void)wait;
- (BOOL)waitUntilDate:(NSDate *)limit;
- (void)signal;
- (void)broadcast;
}
@protocol NSLocking
- (void)lock;
- (void)unlock;
@end
(9).NSConditionLock
NSConditionLock是對NSCondition的進一步封裝，可以設置具體的條件值
@interface NSConditionLock : NSObject <NSLocking> {
- (instancetype)initWithCondition:(NSInteger)condition NS_DESIGNATED_INITIALIZER;
@property (readonly) NSInteger condition;
- (void)lockWhenCondition:(NSInteger)condition;
- (BOOL)tryLock;
- (BOOL)tryLockWhenCondition:(NSInteger)condition;
- (void)unlockWithCondition:(NSInteger)condition;
- (BOOL)lockBeforeDate:(NSDate *)limit;
- (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;
}
(10).dispatch_queue
直接使用GCD的串行隊列，也是可以實現(xiàn)線程同步的
dispatch_queue_t queue = dispatch_queue_create("lock_queue", DISPATCH_QUEUE_SERIAL);
dispatch_sync(queue, ^{
// 任務
});
(11).dispatch_semaphore
semaphore叫做”信號量”
信號量的初始值，可以用來控制線程并發(fā)訪問的最大數(shù)量
信號量的初始值為1，代表同時只允許1條線程訪問資源，保證線程同步
// 信號量的初始值
int value = 1;
// 初始化信號量
dispatch_semaphore_t semaphore = dispatch_semaphore_create(value);
// 如果信號量的值<=0，當前線程就會進入休眠等待（知道信號量的值>0）
// 如果信號量的值>0,就減一，然后往下執(zhí)行代碼
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
// 讓信號量的值加一
dispatch_semaphore_signal(semaphore);
(12).@synchronized
@synchronized是對mutex遞歸鎖的封裝
源碼查看：objc4中的objc-sync.mm文件
@synchronized(obj)內(nèi)部會生成obj對應的遞歸鎖，然后進行加鎖、解鎖操作
@synchronized(obj) {
// 任務
}
總結(jié)
- OSSpinLock不再安全，底層用os_unfair_lock替代
- atomic只能保證setter、getter時線程安全，所以更多的使用nonatomic來修飾
- @synchronized在底層維護了一個哈希鏈表進行data的存儲，使用recursive_mutex_t進行加鎖
- NSLock、NSRecursiveLock、NSCondition和NSConditionLock底層都是對pthread_mutex的封裝
- NSCondition和NSConditionLock是條件鎖，當滿足某一個條件時才能進行操作，和信號量dispatch_semaphore類似
- 普通場景下涉及到線程安全，可以用NSLock
- 循環(huán)調(diào)用時用NSRecursiveLock
- 循環(huán)調(diào)用且有線程影響時，請注意死鎖，如果有死鎖問題請使用@synchronized
自旋鎖、互斥鎖比較
什么情況使用自旋鎖比較劃算？
預計線程等待鎖的時間很短
加鎖的代碼（臨界區(qū)）經(jīng)常被調(diào)用，但競爭情況很少發(fā)生
CPU資源不緊張
多核處理器
什么情況使用互斥鎖比較劃算？
預計線程等待鎖的時間較長
單核處理器
臨界區(qū)有IO操作
臨界區(qū)代碼復雜或者循環(huán)量大
臨界區(qū)競爭非常激烈
iOS線程同步方案性能比較（性能從高到低排序）
os_unfair_lock > OSSpinLock > dispatch_semaphore > pthread_mutex > dispatch_queue(DISPATCH_QUEUE_SERIAL) > NSLock > NSCondition > pthread_mutex(recursive) > NSRecursiveLock > NSConditionLock > @synchronized
