多线程的安全隐患
多条线程操作同一个资源，会造成资源的不同步，造成数据的不准确。
采用线程同步技术来规避资源的同步，常用的技术就是加锁
锁
锁保证当前情况下只能有一个线程操作该资源，操作完解锁，后面线程进来继续加锁解锁。
iOS 中线程同步的方案有
-
OSSpinLock(自旋锁)
等待锁的线程会处于忙等（busy-wait）状态，一直占用着CPU资源,
目前已经不安全了，会出现线程优先级反转的问题。
优先级反转：
thread1优先级高，thread2低，当执行任务时，比如thread2加锁，执行thread1会在锁处忙等，等待thread2解锁，但是thread1的优先级比较高，CPU会分配给thread1的时间调度比较多，导致thread2一直无法放开锁，造成类似于死锁的现象
#import
/**
自旋锁
*/
@property (nonatomic, assign) OSSpinLock lock;
- (void)use {
//初始化
self.lock = OS_SPINLOCK_INIT;
//加锁
OSSpinLockLock(&_lock);
//解锁
OSSpinLockUnlock(&_lock);
}
-
os_unfair_lock
os_unfair_lock 用于取代不安全的OSSpinLock，从iOS10 开始支持，从底层来看，等待os_unfair_lock锁的线程会处于休眠状态，也不是忙等状态。
#import
@property (nonatomic, assign) os_unfair_lock lock;
- (void)use {
//初始化
self.lock = OS_UNFAIR_LOCK_INIT;
//加锁
os_unfair_lock_lock(&_lock);
//解锁
os_unfair_lock_unlock(&_lock);
}
-
pthread_mutex
pthread是跨平台的锁 ,互斥锁，等待所得线程会处于休眠状态。
初始化的时候创建属性可以选择锁类型：
PTHREAD_MUTEX_NORMAL //普通锁
PTHREAD_MUTEX_RECURSIVE //递归锁，用于递归调用的时候避免产生死锁情况。
#import
@property (nonatomic, assign) pthread_mutex_t lock;
- (void)use {
//初始化
[self __initLock:&_lock];
//加锁
pthread_mutex_lock(&_lock);
//解锁
pthread_mutex_unlock(&_lock);
//销毁
pthread_mutex_destroy(&_lock);
}
- (void) __initLock:(pthread_mutex_t *)lock {
//PTHREAD_MUTEX_INITIALIZER是个结构体，语法不允许这么创建
// self.ticketLock = PTHREAD_MUTEX_INITIALIZER;
pthread_mutexattr_t att;
pthread_mutexattr_init(&att);
pthread_mutexattr_settype(&att, PTHREAD_MUTEX_NORMAL);
pthread_mutex_init(lock, &att);
// pthread_mutex_init(lock, NULL); //也可以穿NULL，采用默认
//销毁属性
pthread_mutexattr_destroy(&att);
}
还有一种（pthread_mutex-条件）用法，改方法可以实现线程之间相互以依赖的问题，比如线程1加锁之后，需要依赖线程2执行完之后才能够进行。此时使用pthread_cond_t 可以给pthread_mutex_lock添加条件，来进行多线程之间的控制。
-
NSLock
NSLock是对mutex普通锁的封装。
- (BOOL)tryLock; //尝试加锁，未加锁-->加锁，加锁-->继续执行
- (BOOL)lockBeforeDate:(NSDate *)limit;
//时间段内加锁，limit时间之前阻塞线程，等到锁断开之后或者未加锁状态下加锁成功返回YES,否则加锁失败 返回NO。
-
NSRecursiveLock
递归锁，也是对mute递归锁的封装。
pthread_mutexattr_settype(&att, PTHREAD_MUTEX_RECURSIVE);
-
NSCondition
条件锁，也是对mute和pthread_cond_t的封装。可以调用wait 方法，等待条件成立再执行锁一下的内容。signle方法唤醒线程锁。
-
NSConditionLock
是对NSCondition进一步封装，可以设定具体的条件值，首先初始化一个条件值，
当执行[self.conditionLock lockWhenCondition:1];只有条件值对应上才能加锁成功，否则一直等待锁得状态。
[self.conditionLock unlockWithCondition:2];解锁并且将条件值赋值为2
-
dispatch_semaphore
dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);
信号量的值>0的时候执行，<=0等待
dispatch_semaphore_signal(self.semaphore);
信号量的值+1
-
dispatch_queue(DISPATCH_QUEUE_SERIAL)
GCD的串行队列，也可以实现锁的概念。
-
@synchronized
@synchronized是对mutex递归锁得封装
源码在objc4/sync.mm 内部.
@synchronized(self){
//lock content
}
@synchronized需要传入一个对象，这个对象（不一定就是self）就是这把锁，相同对象持有相同锁，不同对象持有不同锁，关键字在左大括号加锁，大括号结束解锁。底层就是对mutex递归锁的封装。
不同锁的优劣
锁大致分为2种
- OSSpinLock（自旋锁），加锁状态的时候线程处于忙等状态，占用CPU资源。
-
pthread_mutex（互斥锁），跨平台，加锁状态的时候线程处于休眠状态，不会占用CPU资源。
各个锁性能比较
面试题
- 什么情况使用自旋锁比较划算
- 预计线程等待锁的时间很短
- 加锁的代码（临界区）会经常调用，但竞争情况很少发生。
- CPU资源不紧张
- 多核处理器
- 什么情况使用互斥锁比较划算
- 预计线程等待锁的时间比较长
- 单核处理器，可以休眠
- 临界区有IO（文件读取）操作
- 临界区代码比较复杂，或者循环量大
- 竞争非常激烈