iOS 线程同步方案学习总结

作者: 西门吹水Jacky | 来源:发表于2020-06-18 16:19 被阅读0次

线程同步目的为了多个线程都能很好的工作，合理的访问系统资源不争不抢、和谐共处。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才出现低版本不支持不推荐。

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

iOS 线程同步方案学习总结

1.@synchronized

2.atomic 原子性

3.OSSpinLock 自旋锁(不再安全)

4.os_unfair_lock

5.pthread_mutex

6. NSLock&NSRecursiveLock&NSCondition&NSConditionLock

7.GCD 信号量semaphore

8.串行队列

性能比较

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读