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

2018-03-25 本文已影响133人 PPFSaber

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

资源共享

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(转)

条件锁

NSCondition

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

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

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

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

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 多线程基础四、多线程安全——线程锁

资源共享

线程锁

1 自旋锁

2.互斥锁 pthread_mutex

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

条件锁

递归锁NSRecursiveLock

猜你喜欢

热点阅读

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

资源共享

线程锁

1 自旋锁

2.互斥锁 pthread_mutex

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

条件锁

递归锁NSRecursiveLock

猜你喜欢

热点阅读

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