iOS中的锁

前言

上一话题我理解的GCD最后留下的一个疑问:

如果项目需要在不阻塞线程的情况下,并发地对一个变量进行操作。小伙伴们能想到会造成什么后果吗?要用什么方法对这个问题进行解决呢?

本章就来说一下对这个问题的认识。

一、什么是线程安全

我理解的线程安全很简单,就是多个线程里的队列任务并发同时访问同一个数据。这种情况下,就会造成线程安全。而我们描述的问题其实就是这么一个情况。

二、流行的卖票实验

这个实验非常适合学习掌握多线程下的线程安全。其原理大家应该都有过了解。即开启新线程,对同一个数据源(票票)进行访问操作。我们需要保证卖票的效率的同时,也要保证能够正常卖出票。
要保证卖票的效率,我们最好能够开辟一个新线程,保证主线程不阻塞。所以一开始就要确定使用**异步派发async**。

  1. 异步派发+串行队列进行卖票
// 假设有10张票
self.tickets = 10;

// 创建一个串行队列,并开启两个任务进行卖票
- (void)test1
{
    // 创建串行队列
    dispatch_queue_t squeue = dispatch_queue_create("serial", DISPATCH_QUEUE_SERIAL);
    dispatch_async(squeue, ^{
        
        [self dealTask1];
    });
    dispatch_async(squeue, ^{
        
        [self dealTask1];
    });
}

// 任务
- (void)dealTask1
{
    while (true) {
        [NSThread sleepForTimeInterval:0.5];
        if (self.tickets > 0)
        {
            self.tickets --;
            NSLog(@"剩余票数--%zd张--%@",self.tickets, [NSThread currentThread]);
        } else {
            NSLog(@"卖光了");
            // 逃离任务
            break;
        }
    }
}

上面的案例输出是正常的,票能够正常卖出,且不阻塞主线程。但是因为是串行队列,所以两个任务都是在同一个新线程下进行处理。所以效率可见一斑。

  1. 异步派发+并行队列进行卖票
// 创建并行队列,并开启两个任务进行卖票。
- (void)test2
{
    // 创建并行队列
    dispatch_queue_t cqueue = dispatch_queue_create("concurrent", DISPATCH_QUEUE_CONCURRENT);
    dispatch_async(cqueue, ^{
        
        [self dealTask1];
    });
    dispatch_async(cqueue, ^{
        
        [self dealTask1];
    });
}

输出如下:

2018-03-21 14:53:21.832629+0800 XLLLockTest[13563:292378] 剩余票数--8张--<NSThread: 0x60400027c2c0>{number = 4, name = (null)}
2018-03-21 14:53:21.832696+0800 XLLLockTest[13563:292379] 剩余票数--9张--<NSThread: 0x60400027c6c0>{number = 3, name = (null)}
2018-03-21 14:53:22.336391+0800 XLLLockTest[13563:292379] 剩余票数--6张--<NSThread: 0x60400027c6c0>{number = 3, name = (null)}
2018-03-21 14:53:22.336426+0800 XLLLockTest[13563:292378] 剩余票数--7张--<NSThread: 0x60400027c2c0>{number = 4, name = (null)}
2018-03-21 14:53:22.840266+0800 XLLLockTest[13563:292379] 剩余票数--5张--<NSThread: 0x60400027c6c0>{number = 3, name = (null)}
2018-03-21 14:53:22.840260+0800 XLLLockTest[13563:292378] 剩余票数--5张--<NSThread: 0x60400027c2c0>{number = 4, name = (null)}

根据log来看,卖票出错了。原因就是因为我们开启了并行队列。所以两个任务是在两个线程下同时执行的。而执行任务时操作的是同一个数据源self.sockets。所以会导致线程安全问题。

那我们就会想能不能有方法,在不同线程访问同一个数据源,依然能够保持数据同步呢?

三、锁🔐

是最常用的同步工具。一段代码段(任务)在同一个时间只能允许被一个线程访问,比如一个线程A进入加锁代码之后由于已经加锁,另一个线程B就无法访问,只有等待前一个线程A执行完加锁代码后解锁,B线程才能访问加锁代码。这样保证了多线程并发执行任务的同时,同一变量在不同时间被访问。

  • NSLock 对象锁
    NSLock是最简单的一个互斥锁,在可能在多个线程执行的队列任务前进行加锁,任务执行结束后进行解锁。这样就能够保证这个任务的线程安全。
    需要注意的是,加锁与解锁是相互对应的。如果多加了一层锁,会造成死锁现象。后面的队列因为这个多余的、不能解的锁而一直不会被执行。
- (void)dealTask2
{
    [_lock lock];
    while (true) {
        [NSThread sleepForTimeInterval:0.5];
        if (self.tickets > 0)
        {
            self.tickets --;
            NSLog(@"剩余票数--%zd张--%@",self.tickets, [NSThread currentThread]);
        } else {
            NSLog(@"卖光了");
            // 逃离任务
            break;
        }
    }
    [_lock unlock];
}
  • @synchronized 互互斥锁
    @synchronized也能够保证线程安全,同时也有它的优点:不用显示的去创建锁对象。一般会使用self来加锁,注意这个对象必须是全局唯一的,多个线程同时访问的时候,必须保证@synchronize(OC对象)这个OC对象是相同的。不过@synchronized代码块的性能不敢恭维。
- (void)dealTask3
{
    @synchronized(self) {
        while (true) {
            [NSThread sleepForTimeInterval:0.5];
            if (self.tickets > 0)
            {
                self.tickets --;
                NSLog(@"剩余票数--%zd张--%@",self.tickets, [NSThread currentThread]);
            } else {
                NSLog(@"卖光了");
                // 逃离任务
                break;
            }
        }
    }
}
  • dispatch_semaphore_t 信号量
    信号量对于GCD技术开发的时候,用的还是很频繁的。它的性能也不差。使用的时候,肯定是遵循我下面总结的原则:
  1. 每个队列任务执行的时候,如果发现信号量为1,则-1执行任务。如果信号量为0,则等待执行。
  2. 队列任务执行之后,需要single一下,信号量+1。
  3. 信号量waittime是可以自定义的。如果time设为3秒,则即使信号量不为1,3秒后也会执行该任务。不过一般为了保证线程安全,time都设为DISPATCH_TIME_FOREVER
    所以当信号等待时间设为DISPATCH_TIME_FOREVER之后,如果不遵循前两条原则,极有可能造成死锁。
// 首先将信号量初始为1,保证第一个队列任务能够正常执行
_semaphore = dispatch_semaphore_create(1);

- (void)dealTask4
{
    // dispatch_time_t = dispatch_time(DISPATCH_TIME_NOW, 3);
    // 等待信号量为1,然后执行wait,信号量-1.组织其他线程任务同时执行
    dispatch_semaphore_wait(_semaphore, DISPATCH_TIME_FOREVER);
    while (true) {
        [NSThread sleepForTimeInterval:0.5];
        if (self.tickets > 0)
        {
            self.tickets --;
            NSLog(@"剩余票数--%zd张--%@",self.tickets, [NSThread currentThread]);
        } else {
            NSLog(@"卖光了");
            // 逃离任务
            break;
        }
    }
    // 队列任务执行完成,信号量+1,使下一个任务正常被执行
    dispatch_semaphore_signal(_semaphore);
}
  • pthread_mutex 互斥锁
    性能很好,并且在使用递归的时候,也可以当做递归锁来使用。
    使用前,需导入头文件#import <pthread.h>
// 初始化互斥锁
pthread_mutex_init(&_pthread, NULL);

- (void)dealTask5
{
    // 加锁
    pthread_mutex_lock(&_pthread);
    while (true) {
        [NSThread sleepForTimeInterval:0.5];
        if (self.tickets > 0)
        {
            self.tickets --;
            NSLog(@"剩余票数--%zd张--%@",self.tickets, [NSThread currentThread]);
        } else {
            NSLog(@"卖光了");
            // 逃离任务
            break;
        }
    }
    // 解锁
    pthread_mutex_unlock(&_pthread);
}
  • OSSpinLock 自旋锁
    它是性能最好的锁,但是目前苹果发现了它有bug,并不能完全保证线程安全,已经将其修饰了os_unfair_lock。所以不建议使用。

在此插一句
YYKit开源框架作者也因为得知OSSpinLock自旋锁的漏洞,已经将项目中的自旋锁换上性能差不多的pthread_mutex互斥锁。
文章:不再安全的OSSpinLock

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

// 1. 初始化自旋锁
_spinLock = OS_SPINLOCK_INIT;
- (void)dealTask6
{
    // 加锁
    OSSpinLockLock(&_spinLock);
    while (true) {
        [NSThread sleepForTimeInterval:0.5];
        if (self.tickets > 0)
        {
            self.tickets --;
            NSLog(@"剩余票数--%zd张--%@",self.tickets, [NSThread currentThread]);
        } else {
            NSLog(@"卖光了");
            // 逃离任务
            break;
        }
    }
    // 解锁
    OSSpinLockUnlock(&_spinLock);
}

其次还有诸如NSRecursiveLock递归锁NSCondition,NSConditionLock条件锁等等。用的比较少,也没过多了解。

四、总结

iOS保证线程安全的锁有很多,根据自己需要选择合适的锁,以上介绍的几个一般的项目足够用了。网上有好多人对各个锁进行了性能测试,我这边截取一下在YYKit作者文章下看到的性能排行图,供大家参考。

线程锁性能排行榜

这是Demo,包含对上一章同步异步+串行并行的探索代码
参考文章:https://www.jianshu.com/p/35dd92bcfe8c
写得不好,但都是一步一步走下来得到的结果。对于初级的认识还是很有帮助的。如果有发现不对的地方,希望一定要指正出来,共同进步。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,163评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,301评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,089评论 0 352
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,093评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,110评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,079评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,005评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,840评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,278评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,497评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,667评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,394评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,980评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,628评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,649评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,548评论 2 352

推荐阅读更多精彩内容

  • 锁是一种同步机制,用于多线程环境中对资源访问的限制iOS中常见锁的性能对比图(摘自:ibireme): iOS锁的...
    LiLS阅读 1,514评论 0 6
  • 在平时的开发中经常使用到多线程,在使用多线程的过程中,难免会遇到资源竞争的问题,那我们怎么来避免出现这种问题那? ...
    IAMCJ阅读 3,096评论 2 25
  • 本文不介绍各种锁的高级用法,只是整理锁相关的知识点,帮助理解。 锁的作用 防止在多线程(多任务)的情况下对共享资源...
    HelloiWorld阅读 2,890评论 0 8
  • 在多线程操作过程中,往往一个数据同时被多个线程读写,在这种情况下,如果没有相应的机制对数据进行保护,就很可能会发...
    没技术的BUG开发攻城狮阅读 375评论 0 0
  • 自从张小龙们创造了微信,你是否发现自己的生活逐渐落入“企鹅帝国”设计的“圈”套中?从前,你每天早上醒来要做三件事—...
    B〇SS33阅读 412评论 0 1