iOS 线程同步方案学习总结
线程同步目的为了多个线程都能很好的工作，合理的访问系统资源不争不抢、和谐共处。iOS开发中常用的保持线程同步有以下几种：
1.通过线程加锁
2.串行队列
3.GCD
例子(卖火车票)：
/**
* 初始化火车票数量、卖票窗口、并开始卖票
*/
func initTicketStatus(){
print("mainThread---\(Thread.current)")
let queue1 = DispatchQueue.init(label: "queue1")//窗口1
let queue2 = DispatchQueue.init(label: "queue2")//窗口2
queue1.async {
self.saleTicke()//开始卖票
}
queue2.async {
self.saleTicke()//开始卖票
}
}
/**
* 售卖火车票
*/
func saleTicke(){
while true {
if self.num > 0{
self.num = self.num - 1
print("剩余票数：\(self.num), 窗口：\(Thread.current)")
Thread.sleep(forTimeInterval: 0.2)
}else{
print("所有火车票已卖完")
}
if self.num <= 0{
break
}
}
}
输出：
mainThread---<NSThread: 0x2809e9700>{number = 1, name = main}
剩余票数：49, 窗口：<NSThread: 0x2809acf00>{number = 4, name = (null)}
剩余票数：48, 窗口：<NSThread: 0x2809bab40>{number = 5, name = (null)}
剩余票数：46, 窗口：<NSThread: 0x2809acf00>{number = 4, name = (null)}
剩余票数：47, 窗口：<NSThread: 0x2809bab40>{number = 5, name = (null)}
剩余票数：44, 窗口：<NSThread: 0x2809bab40>{number = 5, name = (null)}
剩余票数：44, 窗口：<NSThread: 0x2809acf00>{number = 4, name = (null)}
.....部分输出
以上输出可以看到数据错乱，解决上面这种资源共享问题，就需要使用线程同步技术。下面学习iOS中不同锁的使用，比较不同锁之间的优缺点。
1.@synchronized
是对 pthread_mutex_t 中递归锁的一个封装，苹果不推荐使用，因为性能差。swift已经废弃了这个，所以用swift的办法写一个
/**
* @synchronized
*/
func synchronized(_ lock: AnyObject, _ action: () -> Void){
objc_sync_enter(lock)
defer { objc_sync_exit(lock) }
action()
}
方法解析：利用objc_sync_enter将对象上锁，defer延迟执行objc_sync_exit解锁，调用时机是出这个方法的作用域，该方法其实还有个抛出常的逻辑，为了看的更清楚点，先去掉了
添加同步方法后的saleTicke：
/**
* 售卖火车票
*/
func saleTicke(){
while true {
synchronized(self) {
if self.num > 0{
self.num = self.num - 1
print("剩余票数：\(self.num), 窗口：\(Thread.current)")
Thread.sleep(forTimeInterval: 0.2)
}else{
print("所有火车票已卖完")
}
}
if self.num <= 0{
break
}
}
}
输出：
mainThread---<NSThread: 0x2830bae40>{number = 1, name = main}
剩余票数：49, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
剩余票数：48, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
剩余票数：47, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
剩余票数：46, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
剩余票数：45, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
剩余票数：44, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
......
所有火车票已卖完
如果纠结Objective-C @synchronized原理实现请转 关于 @synchronized，这儿比你想知道的还要多
synchronized(self)用self作为标记符十分常见，但是很明显会有一个问题:
func methodA(){
DispatchQueue.global().async {
self.synchronized(self) {
//设置属性1
}
}
}
func methodB(){
DispatchQueue.global().async {
self.synchronized(self) {
//设置属性2
}
}
}
如果methodA、methodB没用任何关系，如果此时执行methodA，那么methodB就只能等待其执行完成。
所以这种情况更细的粒度来加锁，使用各自的对象互不影响更为合理。
2.atomic 原子性
用
atomic修饰后，这个属性的setter、getter方法是线程安全的，但是对于整个对象来说不一定是线程安全的
对于NSArray类型@property(atomic)NSArray *array用atomic修饰，数组的添加和删除并不是线程安全的，因为这跟setter、getter没关系呀
详情请转 关于IOS 属性atomic（原子性）的理解
3.OSSpinLock 自旋锁(不再安全)
关于
OSSpinLock不再安全，原因就在于优先级反转问题
个人理解就是A高优先级线程与B普通线程共同使用一个资源C，B先使用C中(此时未解锁)，A准备使用资源C，由于A的优先级高，CPU优先分配时间片给A，A如要使用资源C需等B使用完成解锁才可以使用，此时A就要在B后执行，因OSSpinLock 忙等的机制，就可能造成高优先级一直 running ，占用 cpu时间片。而低优先级任务无法抢占时间片，变成迟迟完不成，不释放锁的情况
4.os_unfair_lock
自旋锁已经不再安全，存在优先级反转问题。苹果在iOS10开始使用os_unfair_lock取代了OSSpinLock。从底层调用来看，自旋锁和os_unfair_lock的区别，前者等待线程处于忙等，而后者等待线程处于休眠状态
//swift 可以直接使用不用导入头文件
var lock = os_unfair_lock()
os_unfair_lock_lock(&lock)//加锁
os_unfair_lock_unlock(&lock)//解锁
添加同步方法后的saleTicke：
/**
* 售卖火车票
*/
func saleTicke(){
while true {
os_unfair_lock_lock(&lock)
if self.num > 0{
self.num = self.num - 1
print("剩余票数：\(self.num), 窗口：\(Thread.current)")
Thread.sleep(forTimeInterval: 0.2)
}else{
print("所有火车票已卖完")
os_unfair_lock_unlock(&lock)
break
}
os_unfair_lock_unlock(&lock)
}
}
输出同上
5.pthread_mutex
互斥锁，等待锁的线程处于休眠状态。
var lock:pthread_mutex_t = pthread_mutex_t.init()
pthread_mutex_init(&lock, nil)
/**
* 售卖火车票
*/
func saleTicke(){
while true {
pthread_mutex_lock(&lock)
if self.num > 0{
self.num = self.num - 1
print("剩余票数：\(self.num), 窗口：\(Thread.current)")
Thread.sleep(forTimeInterval: 0.2)
}else{
print("所有火车票已卖完")
pthread_mutex_unlock(&lock)
break
}
pthread_mutex_unlock(&lock)
}
}
输出同上
6. NSLock&NSRecursiveLock&NSCondition&NSConditionLock
NSLock是对mutex普通锁的封装，不支持递归，如果多次调用会造成死锁。
var lock:NSLock = NSLock.init()
/**
* 售卖火车票
*/
func saleTicke(){
while true {
lock.lock()
if self.num > 0{
self.num = self.num - 1
print("剩余票数：\(self.num), 窗口：\(Thread.current)")
Thread.sleep(forTimeInterval: 0.2)
}else{
print("所有火车票已卖完")
lock.unlock()
break
}
lock.unlock()
}
}
输出同上
NSRecursiveLock
先来看一下
NSLock同一线程多次加锁会造成的死锁效果
var lock:NSLock = NSLock.init()
func deadlock(){
DispatchQueue.global().async {
self.recursiveMethod(count: 5)
}
}
//递归方法
func recursiveMethod(count:Int){
lock.lock()
if count > 0{
print(count)
sleep(2)
recursiveMethod(count: count - 1)
}
lock.unlock()
}
输出：
count = 5
recursiveMethod是递归调用的。所以每次进入这个block时，都会去加一次锁，而从第二次开始，由于锁已经被使用了且没有解锁，所以它需要等待锁被解除，这样就导致了死锁，线程被阻塞住了。调试器只输出5。
在这种情况下，我们就可以使用NSRecursiveLock。它可以允许同一线程多次加锁，而不会造成死锁。递归锁会跟踪它被lock的次数。每次成功的lock都必须平衡调用unlock操作。只有所有达到这种平衡，锁最后才能被释放，以供其它线程使用。
// var lock:NSLock = NSLock.init()
var lock:NSRecursiveLock = NSRecursiveLock.init()
输出：
count = 5
count = 4
count = 3
count = 2
count = 1
NSCondition
NSCondition 的对象实际上作为一个锁和一个线程检查器：锁主要为了当检测条件时保护数据源，执行条件引发的任务；线程检查器主要是根据条件决定是否继续运行线程，即线程是否被阻塞。
condition.lock()：加锁
condition.unlock()：解锁
condition.wait()：让当前线程处于等待状态
condition.signal()：CPU发信号告诉线程不用在等待，可以继续执行
var condition:NSCondition = NSCondition.init()
/**
* 条件锁
*/
func conditionMethod(){
var products:[Int] = []
DispatchQueue.global().async {
self.condition.lock()
if products.count == 0{
print("wait for product")
self.condition.wait()
}
print("remove a product")
self.condition.unlock()
}
DispatchQueue.global().async {
sleep(2)
self.condition.lock()
products.append(1)
print("add a product")
self.condition.signal()
self.condition.unlock()
}
}
输出：
wait for product
add a product
remove a product
NSConditionLock
NSConditionLock是对NSCondition的进一步封装。可以设置具体的条件值，控制线程执行顺序
func threadA(){
DispatchQueue.global().async {
self.conditionLock.lock()//上锁
print("ThreadA：\(Thread.current)")
sleep(2)//耗时任务
self.conditionLock.unlock(withCondition: 1)//解锁时添加获取锁条件为1
}
}
func threadB(){
DispatchQueue.global().async {
self.conditionLock.lock(whenCondition: 1)//用条件1来获取锁并上锁
print("ThreadB：\(Thread.current)")
self.conditionLock.unlock()
}
}
//输出：
ThreadA：<NSThread: 0x283cc2ac0>{number = 3, name = (null)}
ThreadB：<NSThread: 0x283ce5b40>{number = 6, name = (null)}
7.GCD 信号量semaphore
常用API：
let semaphore = DispatchSemaphore.init(value: 1)
//初始化信号量 value根据自己的需求来设
semaphore.wait()
// 如果信号量的值>0，就减1，然后往下执行后面的代码
// 如果信号量的值<=0，当前线程就会进入休眠等待，直到信号量的值>0
semaphore.signal()
// 让信号量的值增加1，信号量值不等于零时，前面的等待的代码会执行
let semaphore = DispatchSemaphore.init(value: 1)
/**
* 售卖火车票
*/
func saleTicke(){
while true {
self.semaphore.wait()
if self.num > 0{
self.num = self.num - 1
print("剩余票数：\(self.num), 窗口：\(Thread.current)")
Thread.sleep(forTimeInterval: 0.2)
}else{
print("所有火车票已卖完")
self.semaphore.signal()
break
}
self.semaphore.signal()
}
}
//输出：
mainThread---<NSThread: 0x2830bae40>{number = 1, name = main}
剩余票数：49, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
剩余票数：48, 窗口：<NSThread: 0x2830eba80>{number = 6, name = (null)}
剩余票数：47, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
剩余票数：46, 窗口：<NSThread: 0x2830eba80>{number = 6, name = (null)}
剩余票数：45, 窗口：<NSThread: 0x2830eba80>{number = 5, name = (null)}
剩余票数：44, 窗口：<NSThread: 0x2830eba80>{number = 6, name = (null)}
......
所有火车票已卖完
关于更多信号量的用法(控制最大并发量、将异步执行任务转换为同步执行任务)请转 信号量semaphore学习总结
8.串行队列
let syncQueue = DispatchQueue.init(label: "syncQueue")
/*使用 OperationQueue 同样也可以，只不过需要把并发数设置为1
let syncQueue = OperationQueue.init()
syncQueue.maxConcurrentOperationCount = 1
*/
/**
* 售卖火车票
*/
func saleTicke(){
syncQueue.sync {
while true {
if self.num > 0{
self.num = self.num - 1
print("剩余票数：\(self.num), 窗口：\(Thread.current)")
Thread.sleep(forTimeInterval: 0.2)
}else{
print("所有火车票已卖完")
break
}
}
}
}
输出：
mainThread---<NSThread: 0x283de9980>{number = 1, name = main}
剩余票数：49, 窗口：<NSThread: 0x283da6600>{number = 4, name = (null)}
剩余票数：48, 窗口：<NSThread: 0x283da6600>{number = 4, name = (null)}
剩余票数：47, 窗口：<NSThread: 0x283da6600>{number = 4, name = (null)}
剩余票数：46, 窗口：<NSThread: 0x283da6600>{number = 4, name = (null)}
剩余票数：45, 窗口：<NSThread: 0x283da6600>{number = 4, name = (null)}
剩余票数：44, 窗口：<NSThread: 0x283da6600>{number = 4, name = (null)}
......
性能比较
不再安全的OSSpinLock中对比了不同锁的性能。
推荐使用dispatch_semaphore和pthread_mutex两个。因为OSSpinLock性能最好但是不安全，os_unfair_lock在iOS10才出现低版本不支持不推荐。
