iOS 锁 Lock 线程同步 多线程安全隐患

多线程的安全隐患

多条线程操作同一个资源，会造成资源的不同步，造成数据的不准确。
采用线程同步技术来规避资源的同步，常用的技术就是加锁

锁

锁保证当前情况下只能有一个线程操作该资源，操作完解锁，后面线程进来继续加锁解锁。
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资源。

  
  
  

  各个锁性能比较

面试题

1. 什么情况使用自旋锁比较划算

• 预计线程等待锁的时间很短
• 加锁的代码（临界区）会经常调用，但竞争情况很少发生。
• CPU资源不紧张
• 多核处理器

2. 什么情况使用互斥锁比较划算

• 预计线程等待锁的时间比较长
• 单核处理器，可以休眠
• 临界区有IO（文件读取）操作
• 临界区代码比较复杂，或者循环量大
• 竞争非常激烈