XB_多线程(安全)

最新推荐文章于 2023-08-10 18:05:41 发布

原创最新推荐文章于 2023-08-10 18:05:41 发布 · 411 阅读

0 ·

CC 4.0 BY-SA版权

iOS 专栏收录该内容

37 篇文章

订阅专栏

1块资源可能会被多个线程共享，也就是多个线程可能会访问同一块资源。比如多个线程访问同一个对象、同一个变量、同一个文件。当多个线程访问同一块资源时，很容易引发数据错乱和数据安全问题。
使用线程同步技术（同步，就是协同步调，按照预定的先后次序进行），常见的线程同步技术是:加锁
线程同步方案：OSSpinLock 、os_unfair_lock 、pthread_mutex 、dispatch_semaphore 、dispatch_queue(DISPATCH_QUEUE_SERIAL) 、NSLock 、NSRecursiveLock 、NSCondition 、NSConditionLock、 @synchronized

OSSpinLock

OSSpinLock叫做”自旋锁”，等待锁的线程会处于忙等（busy-wait）状态，一直占用着CPU资源

目前已经不再安全，可能会出现优先级反转问题

优先级低的线程加锁，刚好这时候优先级高的线程进来了，等待解锁，它会一直占用着CPU资源，优先级低的线程就无法释放锁，有点类似于死锁，下面是思路

优先级低的线程加锁了
OSSpinLock(&lock)

优先级高的线程在这while(1){
等待等待等待。。。，还占用着大量CPU资源，让优先级低的无法处理解锁
}

OSSpinLockUnlock(&lock)

需要导入头文件#import <libkern/OSAtomic.h>

os_unfair_lock

os_unfair_lock用于取代不安全的OSSpinLock ，从iOS10开始才支持

从底层调用看，等待os_unfair_lock锁的线程会处于休眠状态，并非忙等

需要导入头文件#import <os/lock.h>

pthread_mutex

mutex叫做”互斥锁”，等待锁的线程会处于休眠状态

需要导入头文件#import <pthread.h>

用pthread_mutex初始化递归锁，属性传入PTHREAD_MUTEX_RECURSIVE

//这里使用递归锁
- (void)otherTest
{
    pthread_mutex_lock(&_mutex);
    
    NSLog(@"%s", __func__);
       
    pthread_mutex_unlock(&_mutex);
}

递归锁：允许同一个线程对一把锁进行重复加锁！

条件加锁

- (void)__remove
{
    pthread_mutex_lock(&_mutex);
    NSLog(@"__remove - begin");
    
    if (self.data.count == 0) {
        // 等待
        pthread_cond_wait(&_cond, &_mutex);
    }
    
    [self.data removeLastObject];
    NSLog(@"删除了元素");
    
    pthread_mutex_unlock(&_mutex);
}

// 线程2
// 往数组中添加元素
- (void)__add
{
    pthread_mutex_lock(&_mutex);
    
    sleep(1);
    
    [self.data addObject:@"Test"];
    NSLog(@"添加了元素");
    
    // 信号
    pthread_cond_signal(&_cond);
    // 广播
//    pthread_cond_broadcast(&_cond);
    
    pthread_mutex_unlock(&_mutex);
}

类似于生产者消费者，pthread_cond_signal(&_cond)必须与pthread_cond_wait(&_cond, &_mutex)对应。一定要注意，被唤醒之后，会再次加锁！！

NSLock、NSRecursiveLock

NSLock是对mutex普通锁的封装，NSRecursiveLock也是对mutex递归锁的封装，API跟NSLock基本一致

NSCondition

NSCondition是对mutex和cond的封装

NSConditionLock

NSConditionLock是对NSCondition的进一步封装，可以设置具体的条件值

dispatch_semaphore_t

// 如果信号量的值 > 0，就让信号量的值减1，然后继续往下执行代码

// 如果信号量的值 <= 0，就会休眠等待，直到信号量的值变成>0，就让信号量的值减1，然后继续往下执行代码

Synchronized

@synchronized是对mutex递归锁的封装

源码查看：objc4中的objc-sync.mm文件

@synchronized(obj)内部会生成obj对应的递归锁，然后进行加锁、解锁操作

//这里拿[self class]做成了一把锁
- (void)__drawMoney
{
    @synchronized([self class]) {
        [super __drawMoney];
    }
}

- (void)__saveMoney
{
    @synchronized([self class]) { // objc_sync_enter
        [super __saveMoney];
    } // objc_sync_exit
}

性能对比

性能从高到低排序

os_unfair_lock、 OSSpinLock、 dispatch_semaphore 、pthread_mutex、 dispatch_queue(DISPATCH_QUEUE_SERIAL) 、NSLock、 NSCondition、 pthread_mutex(recursive) 、NSRecursiveLock、 NSConditionLock 、@synchronized

自旋锁、互斥锁比较

os_unfair_lock也算是一个互斥锁

什么情况使用自旋锁比较划算？

1>预计线程等待锁的时间很短

2>加锁的代码（临界区）经常被调用，但竞争情况很少发生

3>CPU资源不紧张

4>多核处理器

什么情况使用互斥锁比较划算？

1>预计线程等待锁的时间较长

2>单核处理器

3>临界区有IO操作

4>临界区代码复杂或者循环量大

5>临界区竞争非常激烈

---------------------------------------其他-------------------------------------------

atomic

atomic用于保证属性setter、getter的原子性操作，相当于在getter和setter内部加了线程同步的锁

可以参考源码objc4的objc-accessors.mm

它并不能保证使用属性的过程是线程安全的

- (void)setName:(NSString *)name
{
    // 加锁
    _name = name;
    // 解锁
}

- (NSString *)name
{
 //加锁
    return _name;
 //解锁
}

OS中的读写安全方案

思考如何实现以下场景：

同一时间，只能有1个线程进行写的操作

同一时间，允许有多个线程进行读的操作

同一时间，不允许既有写的操作，又有读的操作

上面的场景就是典型的“多读单写”，经常用于文件等数据的读写操作，iOS中的实现方案有

pthread_rwlock：读写锁

dispatch_barrier_async：异步栅栏调用

pthread_rwlock

等待锁的线程会进入休眠

- (void)read {
    pthread_rwlock_rdlock(&_lock);
    
    sleep(1);
    NSLog(@"%s", __func__);
    
    pthread_rwlock_unlock(&_lock);
}

- (void)write
{
    pthread_rwlock_wrlock(&_lock);
    
    sleep(1);
    NSLog(@"%s", __func__);
    
    pthread_rwlock_unlock(&_lock);
}

dispatch_barrier_async

注意：这个函数传入的并发队列必须是自己通过dispatch_queue_cretate创建的

如果传入的是一个串行或是一个全局的并发队列，那这个函数便等同于dispatch_async函数的效果

  self.queue = dispatch_queue_create("rw_queue", DISPATCH_QUEUE_CONCURRENT);
    
    for (int i = 0; i < 10; i++) {
        dispatch_async(self.queue, ^{
            [self read];
        });
        
        dispatch_async(self.queue, ^{
            [self read];
        });
        
        dispatch_async(self.queue, ^{
            [self read];
        });
        
        dispatch_barrier_async(self.queue, ^{
            [self write];
        });
    }

当到执行栅栏内的代码时，其他读的线程会堵塞，只执行栅栏内任务。