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
            }
        }
    }

如果methodAmethodB没用任何关系,如果此时执行methodA,那么methodB就只能等待其执行完成。
所以这种情况更细的粒度来加锁,使用各自的对象互不影响更为合理。

2.atomic 原子性

atomic修饰后,这个属性的settergetter方法是线程安全的,但是对于整个对象来说不一定是线程安全的
对于NSArray类型 @property(atomic)NSArray *arrayatomic 修饰,数组的添加和删除并不是线程安全的,因为这跟settergetter没关系呀
详情请转 关于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_semaphorepthread_mutex两个。因为OSSpinLock性能最好但是不安全,os_unfair_lock在iOS10才出现低版本不支持不推荐。

相关简书:
NSOperation和NSOperationQueue学习总结

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,701评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,649评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 166,037评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,994评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,018评论 6 395
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,796评论 1 308
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,481评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,370评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,868评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,014评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,153评论 1 352
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,832评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,494评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,039评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,156评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,437评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,131评论 2 356