iOS中的线程同步方案

前提简述:

常用的线程方案有Pthread,NSThread, GCD,NSOperation。以下是比较:
pthread : 是一套通用的C语言多线程API,适用于Unix \ Linux\ Windows等系统,可跨平台\可移植性,学习难度大。线程生命周期需要程序员管理。

NSThread: 是OC语言,使用更加面向对象,直接操作线程对象,程序员需要管理生命周期。

GCD: 可替代NSThread等线程技术,C语言实现,系统自动管理。

NSOperation: 基于GCD的封装成OC对象,比GCD多了一些更简单实用的功能,使用更加面向对象,系统自动管理线程生命周期

另附上两个案例:

 dispatch_async(dispatch_get_global_queue(0, 0), ^{

        NSLog(@"1");

        [self performSelector:@selector(test) withObject:nil afterDelay:0];

        NSLog(@"3");

    })

-(void)test { NSLog(@"2") ;}

打印结果是:1、3。

原因:performSelector…afterDelay是向runloop中添加了一个timer定时器,子线程中默认是没有启动runloop的,所以不会执行。

-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent*)event {

    NSThread*thread = [[NSThreadalloc]initWithBlock:^{

        NSLog(@"1");

    }];

    [threadstart];

    BOOLisOk =true;

    // isOk 设置为YES时,会导致crash, 因为在子线程runloop未开启,block执行完毕后,Threadj即退出;会提示此信息:performSelector:onThread:withObject:waitUntilDone:modes:]: target thread exited while waiting for the perform'

    // 设置为NO,test不执行。

    [self performSelector:@selector(test) onThread:thread withObject:nil waitUntilDone:isOk];

}

多线程存在安全隐患,同一个数据可能会被多个线程共享,也就是多个线程可能会访问同一块资源,当多个线程访问同一块资源时,很容易引发数据错乱和数据安全问题。这种情况,我们需要使用线程同步技术(同步,就是协同步调,按预定的先后次序进行)解决。常用的方式是加锁。

iOS线程同步方案:

1, OSSpinLock 自旋锁:

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

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

如果等待锁的线程优先级较高,它会一直占用着CPU资源,优先级低的线程就无法释放锁

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

OSSpinLock lock = OS_SPINLOCK_INIT;

OSSpinLockLock(&_moneyLock);

//coding here

 OSSpinLockUnlock(&_moneyLock);

2, os_unfair_lock

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

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

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

os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;

os_unfair_lock_lock(&_ticketLock);

// coding here

os_unfair_lock_unlock(&_ticketLock);

3, pthread_mutex

mutex叫做”互斥锁”,等待锁的线程会处于休眠状态。需要导入头文件#import<pthread.h>

{    // 静态初始化

    pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

    // 初始化属性

    pthread_mutexattr_t attr;

    pthread_mutexattr_init(&attr);

    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_DEFAULT);

//    初始化锁

    pthread_mutex_init(mutex, &attr);

//   销毁属性

    pthread_mutexattr_destroy(&attr);

    // 初始化锁  NULL表示默认属性

    pthread_mutex_init(mutex, NULL);

}

{

     pthread_mutex_lock(&_ticketMutex);

    //coding here...

    pthread_mutex_unlock(&_ticketMutex);

}

- (void)dealloc{

    pthread_mutex_destroy(&mutex);

}

4, pthread_mutex 递归锁

用法和3类似,上述pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE)

5, pthread_mutex – 条件锁

使用方法展示:

 pthread_mutex_t mutex;

 pthread_mutex_init(&mutex, NULL); //NULL表示使用默认属性

  // 初始化条件

 pthread_cond_t condition;

 pthread_cond_init(&condition, NULL);

// 等待条件(进入休眠,释放mutex锁; 被唤醒后,会再次对mutex加锁)

pthread_cond_wait(&condition, &mutex);

//激活一个等待该条件的线程

pthread_cond_signal(&condition);

//激活所有等待该条件的线程

pthread_cond_broadcast(&condition);

- (void) del{

    pthread_mutex_lock(&_mutex);

    pthread_cond_wait(&_cond, &_mutex);

    // coding here

    pthread_mutex_unlock(&_mutex);

}

-(void)append {

    pthread_mutex_lock(&_mutex);

    // coding here

    pthread_cond_signal(&_cond);  // 信号

    pthread_mutex_unlock(&_mutex);

}

- (void)dealloc {

    pthread_mutex_destory(&mutex);

    pthread_cond_destory(&condition);
}

6,NSLock

NSLock是对mutex普通锁的封装, 遵守NSLocking协议

7,NSRecursiveLock

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

8,NSCondition

NSCondition是对mutex和cond的封装,使用演示如下:

NSCondition *condition = [[NSCondition alloc] init];

- (void)del{

    [condition lock];

    [condition wait];  // 等待

    // coding here

    [condition unlock];

}

- (void)add{

    [self.condition lock];

    // coding here

    [self.condition broadcast];

    [self.condition unlock];

}

9, NSConditionLock

NSConditionLock是对NSCondition的进一步封装,可以设置具体的条件值。简列使用如下:

int start = 0; 设置某个启动条件

NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition: start];

[conditionLock lock];

[conditionLock lockWhenCondition: some];

[conditionLock unlockWithCondition:some];

[conditionLock unlock];

10,dispatch_semaphore

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

dispatch_semaphore_t semaphore = dispatch_semaphore_create(x);

//当信号量的值<=0,当前线程就会进入休眠等待(直到信号量的值大于0)

//如果信号量的值>0,就减1,然后执行后面的代码

dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);

dispatch_semaphore_signal(semaphore);

11, dispatch_queue

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

12,@synchronized

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

@synchronized (token) {}

13, atomic用于保证属性setter、getter的原子性操作,相当于在getter和setter内部加了线程同步的锁, 它并不能保证使用属性的过程是线程安全的。

线程同步方案性能比较,性能从高到低排序依次是:

os_unfair_lock > OSSpinLock > dispatch_semaphore > pthread_mutex > pdispatch_queue(DISPATCH_QUEUE_SERIAL) >  NSLock > NSCondition > ppthread_mutex(recursive) > NSRecursiveLock > NSConditionLock > @synchronized

自旋锁、互斥锁比较:

a, 什么情况使用自旋锁比较划算?

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

加锁的代码(临界区)经常被调用,但竞争情况很少发生

CPU资源不紧张

多核处理器

b,什么情况使用互斥锁比较划算?

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

单核处理器

临界区有IO操作

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

临界区竞争非常激烈

推荐阅读更多精彩内容