iOS中锁的总结

在多线程中，当多个线程同时访问同一块资源的时候，就容易引起数据错乱和数据安全问题

(1).OSSpinLock

OSSpinLock叫做”自旋锁”，等待锁的线程会处于忙等（busy-wait）状态，一直占用着CPU资源

存在问题：

1. 目前已经不再安全，可能会出现优先级反转问题

2. 如果等待锁的线程优先级较高，它会一直占用着CPU资源，优先级低的线程就无法释放锁

当多个线程优先级不同的时候，同时调用同一方法，当优先级低的线程先调用这个方法的时候，就会进行加锁，优先级高的进来发现已经加锁了，而CPU会对优先级高的分配的时间片多，这时CPU会从优先级低的切换到优先级高的线程执行，而优先级低的线程没执行完，所以没解锁，优先级高的就会一直访问是否解锁，所以就会一直卡着

// 初始化
OSSpinLock lock = OS_SPINLOCK_INIT;
// 加锁
OSSpinLockLock(&lock1);
// 解锁
OSSpinLockUnlock(&lock1);

//还有一种尝试加锁,能加锁就加，不能就直接跳过执行之后代码
bool result = OSSpinLockTry(&lock)

(2).os_unfair_lock

1. os_unfair_lock用于取代不安全的OSSpinLock ，从iOS10开始才支持
2. 从底层调用看，等待os_unfair_lock锁的线程会处于休眠状态，并非忙等
3. 需要导入头文件#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（互斥锁、递归锁）

1. mutex叫做”互斥锁”，等待锁的线程会处于休眠状态
2. 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);
// 销毁相关资源
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– 条件

场景：两条线程有依赖关系，一条线程必须等另外一天线程完成才执行相关操作

// 初始化锁
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的串行队列，也是可以实现线程同步的

dispatch_queue_t queue = dispatch_queue_create("lock_queue", DISPATCH_QUEUE_SERIAL);
dispatch_sync(queue, ^{
       // 任务
    });

(11).dispatch_semaphore

1. semaphore叫做”信号量”

2. 信号量的初始值，可以用来控制线程并发访问的最大数量

3. 信号量的初始值为1，代表同时只允许1条线程访问资源，保证线程同步

// 信号量的初始值
int value = 1;
// 初始化信号量
dispatch_semaphore_t semaphore = dispatch_semaphore_create(value);
// 如果信号量的值<=0，当前线程就会进入休眠等待（知道信号量的值>0）
// 如果信号量的值>0,就减一，然后往下执行代码
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
// 让信号量的值加一
dispatch_semaphore_signal(semaphore);

(12).@synchronized

1. @synchronized是对mutex递归锁的封装

2. 源码查看：objc4中的objc-sync.mm文件

3. @synchronized(obj)内部会生成obj对应的递归锁，然后进行加锁、解锁操作

@synchronized(obj) {
        // 任务
    }

总结

• OSSpinLock不再安全，底层用os_unfair_lock替代
• atomic只能保证setter、getter时线程安全，所以更多的使用nonatomic来修饰
• @synchronized在底层维护了一个哈希链表进行data的存储，使用recursive_mutex_t进行加锁
• NSLock、NSRecursiveLock、NSCondition和NSConditionLock底层都是对pthread_mutex的封装
• NSCondition和NSConditionLock是条件锁，当满足某一个条件时才能进行操作，和信号量dispatch_semaphore类似
• 普通场景下涉及到线程安全，可以用NSLock
• 循环调用时用NSRecursiveLock
• 循环调用且有线程影响时，请注意死锁，如果有死锁问题请使用@synchronized

自旋锁、互斥锁比较

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

1. 预计线程等待锁的时间很短

2. 加锁的代码（临界区）经常被调用，但竞争情况很少发生

3. CPU资源不紧张

4. 多核处理器

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

预计线程等待锁的时间较长

2. 单核处理器

3. 临界区有IO操作

4. 临界区代码复杂或者循环量大

5. 临界区竞争非常激烈

iOS线程同步方案性能比较（性能从高到低排序）

os_unfair_lock > OSSpinLock > dispatch_semaphore > pthread_mutex > dispatch_queue(DISPATCH_QUEUE_SERIAL) > NSLock > NSCondition > pthread_mutex(recursive) > NSRecursiveLock > NSConditionLock > @synchronized