在多线程中，当多个线程同时访问同一块资源的时候，就容易引起数据错乱和数据安全问题
(1).OSSpinLock
OSSpinLock叫做”自旋锁”，等待锁的线程会处于忙等（busy-wait）状态，一直占用着CPU资源
存在问题：
目前已经不再安全，可能会出现优先级反转问题
如果等待锁的线程优先级较高，它会一直占用着CPU资源，优先级低的线程就无法释放锁
当多个线程优先级不同的时候，同时调用同一方法，当优先级低的线程先调用这个方法的时候，就会进行加锁，优先级高的进来发现已经加锁了，而CPU会对优先级高的分配的时间片多，这时CPU会从优先级低的切换到优先级高的线程执行，而优先级低的线程没执行完，所以没解锁，优先级高的就会一直访问是否解锁，所以就会一直卡着
// 初始化
OSSpinLock lock = OS_SPINLOCK_INIT;
// 加锁
OSSpinLockLock(&lock1);
// 解锁
OSSpinLockUnlock(&lock1);
//还有一种尝试加锁,能加锁就加，不能就直接跳过执行之后代码
bool result = OSSpinLockTry(&lock)
(2).os_unfair_lock
- os_unfair_lock用于取代不安全的OSSpinLock ，从iOS10开始才支持
- 从底层调用看，等待os_unfair_lock锁的线程会处于休眠状态，并非忙等
- 需要导入头文件#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叫做”互斥锁”，等待锁的线程会处于休眠状态
- 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
semaphore叫做”信号量”
信号量的初始值，可以用来控制线程并发访问的最大数量
信号量的初始值为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
@synchronized是对mutex递归锁的封装
源码查看：objc4中的objc-sync.mm文件
@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
自旋锁、互斥锁比较
什么情况使用自旋锁比较划算？
预计线程等待锁的时间很短
加锁的代码（临界区）经常被调用，但竞争情况很少发生
CPU资源不紧张
多核处理器
什么情况使用互斥锁比较划算？
预计线程等待锁的时间较长
单核处理器
临界区有IO操作
临界区代码复杂或者循环量大
临界区竞争非常激烈
iOS线程同步方案性能比较（性能从高到低排序）
os_unfair_lock > OSSpinLock > dispatch_semaphore > pthread_mutex > dispatch_queue(DISPATCH_QUEUE_SERIAL) > NSLock > NSCondition > pthread_mutex(recursive) > NSRecursiveLock > NSConditionLock > @synchronized
