美文网首页
iOS 多线程基础 四、多线程安全——线程锁

iOS 多线程基础 四、多线程安全——线程锁

作者: PPFSaber | 来源:发表于2018-03-25 20:07 被阅读133次

    多线程是一把双刃剑,他即可以提高我们的运行效率,但是当资源共享多个线程同时存取同一块资源的时候,可能会造成引发数据错乱和数据安全问题。

    资源共享

    • 1块资源可能会被多个线程共享,也就是多个线程可能会访问同一块资源。
      比如多个线程访问同一个对象、同一个变量、同一个文件

    • 当多个线程访问同一块资源的时候,很容易引发数据的错乱和数据安全问题

    例如 :变量a 为 100 两个线程访问变量a 然后都同时都加1然后写入,本来按照逻辑a应该是 102,但是当 两个线程同时访问a来进行操作的时候得到的结果成了101。这就会引发数据错乱。

    线程锁

    为了避免出现数据错乱这种情况,我们需要用到工具线程锁。
    线程锁有以下几个基本类型

    1.自旋锁: atomic 即OSSpinLock 在ios中已经不是线程安全的了,如果共享数据已经有其他线程加锁了,线程会以死循环的方式等待锁,一旦被访问的资源被解锁,则等待资源的线程会立即执行。(效率最高,如果一直等不到锁会较占用cpu资源)

    2.信号锁:dispatch_semaphore是gcd中通过信号量来实现共享数据的数据安全。(效率第二)

    3.互斥锁:pthread_mutex ,nslock ,synchronized都是互斥锁。如果共享数据已经有其他线程加锁了,线程会进入休眠状态等待锁。一旦被访问的资源被解锁,则等待资源的线程会被唤醒。(synchronized效率最低)

    4.递归锁:pthread_mutex(recursive)与NSRecursiveLock , 多次调用不会阻塞已获取该锁的线程。

    5.条件锁:nsconditionlock 满足一定的条件的加锁和解锁,可以实现依赖关系。nscondition条件锁,也是通过信号量来解锁,主要用来实现生产者消费者模式。

    1 自旋锁

    在多线程要操作一个字符串时,为了保证只有一个线程在赋值或者取值的时候我们会考虑加锁。

    实现原理 当属性加锁之后另外的线程则忙等(进入死循环等待属性解锁),一旦解锁立即读取资源,因此效率高,但是耗费CPU资源。

    • atomic属性内部的锁称为 自旋锁

    `
    @property(atomic,copy)NSString *name;

    `

    atomic应该怎么在setter和getter中实现呢,原理是仅需要给self加锁,重写setter,getter:

    @synthesize name = _name; 
    - (void)setName:(NSString *)name
     { 
         @synchronized(self) 
            { 
                  _name = [name copy]; 
             } 
    } 
    - (NSString *)name 
    { 
           @synchronized(self) 
           {
                return _name;
            } 
    }
    

    不过这么写,也不能保证线程安全。如果线程A调用了getter,同时线程B调用了setter,那么A线程getter得到的值,可能是B在set之前的原始值,也可能是B set的值。同时这个属性的值,也可能是B set的值。所以不建议用自旋锁

    2.互斥锁 pthread_mutex

    互斥锁的意思是某一时刻只允许一个线程访问某一资源。为了保证这一点,每个想要访问共享资源的线程,需要首先获得一个共享资源的互斥锁,一旦某个线程对共享资源完成了访问,就释放掉这个互斥锁,这样别的线程就有机会获取互斥锁,然后访问该共享资源了。

    由于 pthread_mutex 有多种类型,可以支持递归锁等,因此在申请加锁时,需要对锁的类型加以判断,这也就是为什么它和信号量的实现类似,但效率略低的原因。

    互斥锁的实现原理与信号量非常相似,不是使用忙等,而是阻塞线程并睡眠,需要进行上下文切换

    • pthread_mutex
      pthread表示的是POSIX thread,定义的是一组跨平台线程相关的API。
      pthread_mutex互斥锁是一个非递归锁,如果同一线程重复调用加锁会造成死锁。
      用法比较简单
    static pthread_mutex_t pmutexLock; 
    
    pthread_mutex_init(&pLock, NULL);
    
     //1.线程2 
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{ 
    NSLog(@"线程2 befor lock"); 
    pthread_mutex_lock(&pLock); 
    NSLog(@"线程2");
     pthread_mutex_unlock(&pLock); 
    }); 
    
    //2.线程1 
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
     NSLog(@"线程1 before lock"); 
    pthread_mutex_lock(&pLock); 
    sleep(3); 
    NSLog(@"线程1");
     pthread_mutex_unlock(&pLock); 
    });
    
    

    pthread_mutex(recursive) 递归锁,比较安全,同一线程有且仅有一次加锁,重复加锁不会死锁。无论加锁几次,只需解锁一次。

    //参数isRecu 是否是递归锁
    - (void)pthreadMutexWithRECURSIVE:(BOOL)isRecu
    {
        pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
        
     //设置锁的属性为递归
        if (isRecu)
        {
            pthread_mutexattr_t attr;
            pthread_mutexattr_init(&attr);
            pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
            pthread_mutex_init(&mutex, &attr);
            pthread_mutexattr_destroy(&attr);
        }
    
        pthread_mutex_lock(&mutex);
        
        NSLog(@"真是麻烦,看老子一会把你封装了");
        
        while (YES) {
            [NSThread sleepForTimeInterval:0.2];
            
            
            //互斥锁 -- 保证锁内的代码,同一时间,只有一条线程执行!
            //互斥锁 的范围 应该尽量小,范围大了 效率就差!!
            //1.判断是否有票
            //参数:任意OC对象都OK!一般用self!全局对象
            //局部变量,每一个线程单独拥有的,因此没法加锁!!!
            if (self.tickets > 0) {
                //2.如果有就卖一张
                self.tickets--;
                NSLog(@"剩下%d张票  %@",self.tickets,[NSThread currentThread]);
            }else{
                //3.如果没有了,提示用户
                NSLog(@"卖完了! %@",[NSThread currentThread]);
                break;
            }
            
            
        }
        
        pthread_mutex_unlock(&mutex);
        
        pthread_mutex_destroy(&mutex);
        
    }
    
    • @synchronized
      这其实是一个 OC 层面的锁, 主要是通过牺牲性能换来语法上的简洁与可读。
      我们知道 @synchronized 后面需要紧跟一个 OC 对象,它实际上是把这个对象当做锁来使用。你调用 sychronized 的每个对象,Objective-C runtime 都会为其分配一个递归锁并存储在哈希表中。OC 在底层使用了一个互斥锁的数组(你可以理解为锁池),通过对对象地址哈希值来得到对应的互斥锁。
    若是在self对象上频繁加锁,那么程序可能要等另一段与此无关的代码执行完毕,才能继续执行当前代码,这样做其实并没有必要。
    - (void)setName:(NSString *)name
     { 
         //互斥锁
         @synchronized(self) 
            { 
                  _name = [name copy]; 
             } 
    } 
    
    • NSLock
      NSLock只是在内部封装了一个pthread_mutex,属性为PTHREAD_MUTEX_ERRORCHECK,它会损失一定性能换来错误提示。这里使用宏定义的原因是,OC 内部还有其他几种锁,他们的 lock 方法都是一模一样,仅仅是内部pthread_mutex互斥锁的类型不同。
      通过宏定义,可以简化方法的定义。
      NSLock比pthread_mutex略慢的原因在于它需要经过方法调用,同时由于缓存的存在,多次方法调用不会对性能产生太大的影响。
    
    - (NSLock *)mutexLock
    {//创建线程锁锁
      if(!_mutexLock)
    {
    _mutexLock = [[NSLock alloc] init]; 
    }
    return _mutexLock;
    }
    - (void)action
    /设置票的数量为5 
    _tickets = 5;   
    
    //线程1 
    dispatch_async(self.concurrentQueue, ^{
    
     [self saleTickets]; 
    
    }); 
    //线程2 
    dispatch_async(self.concurrentQueue, ^{
     [self saleTickets]; 
    }); 
    
    }
    - (void)saleTickets
    {
    while (YES) {
            [NSThread sleepForTimeInterval:0.2];
            
             //加锁
            [self.mutexLock lock];
            //互斥锁 -- 保证锁内的代码,同一时间,只有一条线程执行!
            //互斥锁 的范围 应该尽量小,范围大了 效率就差!!
            //1.判断是否有票
            //参数:任意OC对象都OK!一般用self!全局对象
            //局部变量,每一个线程单独拥有的,因此没法加锁!!!
            if (self.tickets > 0) {
                //2.如果有就卖一张
                self.tickets--;
                NSLog(@"剩下%d张票  %@",self.tickets,[NSThread currentThread]);
            }else{
                //3.如果没有了,提示用户
                NSLog(@"卖完了! %@",[NSThread currentThread]);
                break;
     //解锁
            [self.mutexLock unlock];
            }
    }
    
    • 自旋锁和互斥锁

    • 相同点:

      都能保证同一时间只有一个线程访问共享资源。都能保证线程安全。

    • 不同点:

      互斥锁:如果共享数据已经有其他线程加锁了,线程会进入休眠状态等待锁。一旦被访问的资源被解锁,则等待资源的线程会被唤醒。
      自旋锁:如果共享数据已经有其他线程加锁了,线程会以死循环的方式等待锁,一旦被访问的资源被解锁,则等待资源的线程会立即执行。

    • 自旋锁的效率高于互斥锁。

    信号量 dispatch_semaphore是gcd中通过信号量来实现共享数据的数据安全。

    不是使用忙等,而是阻塞线程并睡眠,需要进行上下文切换。

    缺点
    在时间较短的操作,没有自旋锁高效,会有上下文切换的成本。
    优点
    效率高。
    

    由于信号量用的比较少,这里就不再多讲。想进一步了解的同学大家可以参考 这篇文章 iOS - dispatch_semaphore 和 NSCondition(转)

    条件锁

    1. NSCondition

    NSCondition 其实是封装了一个互斥锁和条件变量。NSCondition 的底层是通过条件变量(condition variable) pthread_cond_t 来实现的。条件变量有点像信号量,提供了线程阻塞与信号机制,因此可以用来阻塞某个线程,并等待某个数据就绪,随后唤醒线程。它仅仅是控制了线程的执行顺序。

    互斥锁提供线程安全,条件变量提供线程阻塞与信号机制。
    

    它的基本用法和NSLock一样,这里说一下NSCondition的特殊用法。
    NSCondition提供更高级的用法,方法如下:

      - (void)wait; //阻塞当前线程 直到等待唤醒 
      - (BOOL)waitUntilDate:(NSDate *)limit; //阻塞当前线程到一定时间 之后自动唤醒
      - (void)signal; //唤醒一条阻塞线程 - (void)broadcast; //唤醒所有阻塞线程
    
    1. NSConditionLock

    借助 NSCondition 来实现,它的本质就是一个生产者-消费者模型。“条件被满足”可以理解为生产者提供了新的内容。NSConditionLock 的内部持有一个 NSCondition 对象,以及 _condition_value 属性,在初始化时就会对这个属性进行赋值:

    // 简化版代码 
    - (id) initWithCondition: (NSInteger)value { 
    if (nil != (self = [super init])) 
    { 
    _condition = [NSCondition new] ;
    _condition_value = value; 
    } 
    return self; 
    }
    
    

    它的 lockWhenCondition 方法其实就是消费者方法:

    - (void) lockWhenCondition: (NSInteger)value {
        [_condition lock];
        while (value != _condition_value) {
            [_condition wait];
        }
    }
    

    对应的 unlockWhenCondition 方法则是生产者,使用了 broadcast 方法通知了所有的消费者:

    - (void) unlockWithCondition: (NSInteger)value {
        _condition_value = value;
        [_condition broadcast];
        [_condition unlock];
    }
    
    //调用方法
    NSConditionLock *theLock = [[NSConditionLock alloc] init];
     //线程1 
    dispatch_async(self.concurrentQueue, ^{ 
    for (int i=0;i<=3;i++) { 
    [theLock lock]; 
    NSLog(@"thread1:%d",i); 
    sleep(1); 
    [theLock unlockWithCondition:i];
     } 
    }); 
    //线程2
     dispatch_async(self.concurrentQueue, ^{ 
    [theLock lockWhenCondition:2]; 
    NSLog(@"thread2");
     [theLock unlock];
     });
    
    
    

    递归锁NSRecursiveLock

    上文已经说过,递归锁也是通过 pthread_mutex_lock
    函数来实现,在函数内部会判断锁的类型,如果显示是递归锁,就允许递归调用,仅仅将一个计数器加一,锁的释放过程也是同理。
    NSRecursiveLock
    与 NSLock
    的区别在于内部封装的 pthread_mutex_t
    对象的类型不同,前者的类型为 PTHREAD_MUTEX_RECURSIVE

    // 实例类person 
    Person *person = [[Person alloc] init]; 
    // 创建锁对象
    NSRecursiveLock *theLock = [[NSRecursiveLock alloc] init]; 
    // 创建递归方法
     static void (^testCode)(int); testCode = ^(int value) { 
    
        [theLock tryLock]; 
    
    if (value > 0) {
          [person personA]; 
           [NSThread sleepForTimeInterval:1]; 
           testCode(value - 1);
       } 
           [theLock unlock]; 
    }; 
    
    //线程A dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ 
          testCode(5); 
    }); 
    //线程B dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ 
           [theLock lock];
           [person personB]; 
           [theLock unlock]; 
    });
    
    
    
    各种锁的性能参考图

    1、总的来看,推荐dispatch_semaphore 或者 pthread_mutex作为实际项目的首选方案;
    2、对于耗时较大又易冲突的读操作,可以使用读写锁代替pthread_mutex;
    3、如果确认仅有set/get的访问操作,可以选用原子操作属性;
    4、对于性能要求苛刻,可以考虑使用OSSpinLock,需要确保加锁片段的耗时足够小;
    5、条件锁基本上使用面向对象的NSCondition和NSConditionLock即可;
    6、@synchronized则适用于低频场景如初始化或者紧急修复使用;

    参考资料
    iOS-多线程-锁
    iOS中的5种锁

    相关文章

      网友评论

          本文标题:iOS 多线程基础 四、多线程安全——线程锁

          本文链接:https://www.haomeiwen.com/subject/vujkcftx.html