CC的博客

  • 首页
  • iOS
  • Android
  • React-Native
  • 读书杂谈
  • About
CC
记录美好生活
  1. 首页
  2. 技术编程
  3. iOS
  4. 正文

iOS中常见线程同步方案

2021/07/03

多线程的安全隐患

假设有两个线程在同时访问一个变量(初始值为0)进行加一的操作,线程A和线程B同时对变量加一操作五十次,预期变量值为100,但因为多线程抢夺同一个资源的问题实际变量值为小于等于100的不可预测值。

多次执行以下代码会到的不可预测的值。

    dispatch_group_t group = dispatch_group_create();
    dispatch_queue_t concurrentQueue = dispatch_queue_create("com.example.gcd.queue", DISPATCH_QUEUE_CONCURRENT);
    dispatch_queue_t concurrentQueue1 = dispatch_queue_create("com.example.gcd.queue1", DISPATCH_QUEUE_CONCURRENT);

    __block int a = 0;
    for (int i = 0; i < 50; i++) {
        dispatch_group_async(group,concurrentQueue, ^{
            sleep(1);
            a++;
        });
        dispatch_group_async(group,concurrentQueue1, ^{
            sleep(1);
            a++;
        });
    }
    dispatch_group_notify(group, dispatch_get_main_queue(), ^{
        NSLog(@"a = %d",a);
    });
问题分析:因为多个线程在同时访问一个资源

2615bb529fb7.png

解决方案:使用线程同步方案,常见的方案就是对访问资源的操作进行加锁防护

a0ae6daf177a.png

iOS中的线程同步方案

  • OSSpinLock
  • os_unfair_lock
  • pthread_mutex
  • dispatch_semaphore
  • dispatch_queue(DISPATCH_QUEUE_SERIAL)
  • NSLock
  • NSRecursiveLock
  • NSCondition
  • NSConditionLock
  • @synchronized
OSSpinLock叫做”自旋锁”

等待锁的线程会处于忙等(busy-wait)状态,一直占用着CPU资源
目前已经不再安全,可能会出现优先级反转问题
如果等待锁的线程优先级较高,它会一直占用着CPU资源,优先级低的线程就无法释放锁。

#import <libkern/OSAtomic.h>

    OSSpinLock _lock = OS_SPINLOCK_INIT;
    OSSpinLockLock(&_lock);
    //代码
    OSSpinLockUnlock(&_lock);
os_unfair_lock

os_unfair_lock用于取代不安全的OSSpinLock ,从iOS10开始才支持
从底层调用看,等待os_unfair_lock锁的线程会处于休眠状态,并非忙等。

#import <os/lock.h>

    os_unfair_lock _lock = OS_UNFAIR_LOCK_INIT;
    os_unfair_lock_lock(&_lock);
    //代码
    os_unfair_lock_unlock(&_lock);
pthread_mutex

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

#import <pthread/pthread.h>

    pthread_mutex_t _lock;
    pthread_mutexattr_t attr;
    pthread_mutexattr_init(&attr);
    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_DEFAULT);
    pthread_mutex_init(&_lock, &attr);
    pthread_mutexattr_destroy(&attr);

    pthread_mutex_lock(&_lock);
    //代码
    pthread_mutex_unlock(&_lock);

    pthread_mutex_destroy(&_lock);
mutex递归锁
#import <pthread/pthread.h>

    pthread_mutex_t _lock;
    pthread_mutexattr_t attr;
    pthread_mutexattr_init(&attr);
    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
    pthread_mutex_init(&_lock, &attr);
    pthread_mutexattr_destroy(&attr);

    pthread_mutex_lock(&_lock);
    //代码
    pthread_mutex_unlock(&_lock);

    pthread_mutex_destroy(&_lock);
mutex条件锁
//初始化锁
pthread_mutex_init(&_lock, NULL);
//初始化条件
pthread_cond_t _condition;
pthread_cond_init(&_condition, NULL);
- (void)getMoney {
    pthread_mutex_lock(&_lock);
    if (self.money < 20) {
        pthread_cond_wait(&_condition,&_lock);//等待条件(线程进入休眠并释放锁,被激活后会重新加锁)
    }
    [super getMoney];
    pthread_mutex_unlock(&_lock);
}
- (void)saveMoney {
    pthread_mutex_lock(&_lock);
    [super saveMoney];
//    pthread_cond_broadcast(&_condition);//激活所有等待此条件的线程
    pthread_cond_signal(&_condition);//激活一条等待此条件的线程
    pthread_mutex_unlock(&_lock);
}
NSLock&NSRecursiveLock&NSCondition&NSConditionLock

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

@protocol NSLocking

- (void)lock;
- (void)unlock;

@end
@interface NSLock : NSObject <NSLocking> {
- (BOOL)tryLock;
- (BOOL)lockBeforeDate:(NSDate *)limit;
@end
@interface NSRecursiveLock : NSObject <NSLocking> {
- (BOOL)tryLock;
- (BOOL)lockBeforeDate:(NSDate *)limit;
@end

NSCondition是对mutex和cond的封装;NSConditionLock是对NSCondition的进一步封装,可以设置具体的条件值

@interface NSCondition : NSObject <NSLocking> {
- (void)wait;
- (BOOL)waitUntilDate:(NSDate *)limit;
- (void)signal;
- (void)broadcast;
@end

@interface NSConditionLock : NSObject <NSLocking> {

- (instancetype)initWithCondition:(NSInteger)condition NS_DESIGNATED_INITIALIZER;

@property (readonly) NSInteger condition;
- (void)lockWhenCondition:(NSInteger)condition;
- (BOOL)tryLock;
- (BOOL)tryLockWhenCondition:(NSInteger)condition;
- (void)unlockWithCondition:(NSInteger)condition;
- (BOOL)lockBeforeDate:(NSDate *)limit;
- (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;

@end
dispatch_semaphore

semaphore叫做”信号量”,信号量可以用来控制线程并发访问的最大数量。
信号量的初始值为1,代表同时只允许1条线程访问资源,保证线程同步。

    dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);//初始化信号量
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);//如果信号量小于等于0,当前线程进行休眠等待(直到信号量大于0);如果信号量大于0,则信号量进行减一,继续执行后面的代码
    dispatch_semaphore_signal(semaphore);//信号量加一
dispatch_queue

直接使用GCD的串行队列,也可以实现线程同步。

dispatch_queue_t queue = dispatch_queue_create("com.example.gcd", DISPATCH_QUEUE_SERIAL);
dispatch_sync(queue, ^{

    });
@synchronized

@synchronized是对mutex递归锁的封装
源码查看:objc4中的objc-sync.mm文件

int objc_sync_enter(id obj)
{
    int result = OBJC_SYNC_SUCCESS;

    if (obj) {
        SyncData* data = id2data(obj, ACQUIRE);
        assert(data);
        data->mutex.lock();
    } else {
        // @synchronized(nil) does nothing
        if (DebugNilSync) {
            _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
        }
        objc_sync_nil();
    }

    return result;
}


// End synchronizing on 'obj'. 
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
int objc_sync_exit(id obj)
{
    int result = OBJC_SYNC_SUCCESS;

    if (obj) {
        SyncData* data = id2data(obj, RELEASE); 
        if (!data) {
            result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
        } else {
            bool okay = data->mutex.tryUnlock();
            if (!okay) {
                result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
            }
        }
    } else {
        // @synchronized(nil) does nothing
    }


    return result;
}

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

@synchronized (self) {
        //代码
}
性能从高到低排序
  • os_unfair_lock
  • OSSpinLock
  • dispatch_semaphore
  • pthread_mutex
  • dispatch_queue(DISPATCH_QUEUE_SERIAL)
  • NSLock
  • NSCondition
  • pthread_mutex(recursive)
  • NSRecursiveLock
  • NSConditionLock
  • @synchronized
自旋锁、互斥锁比较

什么情况使用自旋锁比较划算?
- 预计线程等待锁的时间很短
- 加锁的代码(临界区)经常被调用,但竞争情况很少发生
- CPU资源不紧张
- 多核处理器

什么情况使用互斥锁比较划算?
- 预计线程等待锁的时间较长
- 单核处理器
- 临界区有IO操作
- 临界区代码复杂或者循环量大
- 临界区竞争非常激烈

标签: 暂无
最后更新:2024/07/06

CC

这个人很懒,什么都没留下

点赞
< 上一篇

COPYRIGHT © 2020 CC的博客. ALL RIGHTS RESERVED.

Theme Kratos

豫ICP备2023032048号