IOS多线程 之 线程安全，线程同步，读写安全详解

什么是线程不安全和线程安全？

  • 线程不安全：
    是指不提供加锁机制保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据。如下图：


    image.png

  • 线程安全：
    指多个线程在执行同一段代码的时候采用加锁机制，使每次的执行结果和单线程执行的结果都是一样的，不存在执行程序时出现意外结果。如下图：


    image.png

如何解决线程不安全？

使用线程同步技术（同步，就是协同步调，按预定的先后次序进行）
常见的线程同步技术是：加锁

举例：

假设售票系统有15张票，A，B，C同时来买票，如果是线程不安全，那么可能售票系统可能出现15-1去同时执行的情况，最终结果是A，B，C都买完后剩下13张票，而不是12张。

/**
 卖1张票
 */
- (void)saleTicket
{
    int oldTicketsCount = self.ticketsCount;
    sleep(.2);
    oldTicketsCount--;
    self.ticketsCount = oldTicketsCount;
    
    NSLog(@"还剩%d张票 - %@", oldTicketsCount, [NSThread currentThread]);
}

/**
 卖票演示
 */
- (void)ticketTest
{
    self.ticketsCount = 15;
    
    dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
    
    dispatch_async(queue, ^{
        [self saleTicket];
    });
    
    dispatch_async(queue, ^{
        [self saleTicket];
    });
    
    dispatch_async(queue, ^{
        [self saleTicket];
    });
}

打印结果为：

2020-03-26 15:29:49.638680+0800 Interview03-安全隐患[12657:281738] 还剩14张票 - <NSThread: 0x600001cd03c0>{number = 9, name = (null)}
2020-03-26 15:29:49.638694+0800 Interview03-安全隐患[12657:281709] 还剩14张票 - <NSThread: 0x600001c9db00>{number = 7, name = (null)}
2020-03-26 15:29:49.638800+0800 Interview03-安全隐患[12657:281458] 还剩13张票 - <NSThread: 0x600001cbaf40>{number = 3, name = (null)}

要解决以上线程不安全的问题，就需要给每个线程加同一把锁。

锁又分为自旋锁、互斥锁、递归锁、读写锁

  • 自旋锁：
    自旋锁是一种特殊的互斥锁，当资源被加锁后，其它线程想要再次加锁，此时该线程不会被阻塞睡眠而是陷入循环等待状态（不能再做其它事情），循环检查资源持有者是否已经释放了资源，这样做的好处是减少了线程从睡眠到唤醒的资源消耗，但会一直占用CPU资源。适用于资源的锁被持有的时间短，而不希望在线程的唤醒上花费太多资源的情况。

  • 互斥锁：
    一个线程获得资源的使用权后就会将改资源加锁，使用完后会将其解锁，所以在使用过程中有其它线程想要获取该资源的锁，那么它就会被阻塞陷入睡眠状态，直到该资源被解锁才会别唤醒，如果被阻塞的资源不止一个，那么它们都会被唤醒，但是获得资源使用权的是第一个被唤醒的线程，其它线程又陷入沉睡。

  • 递归锁：
    同一个线程可以多次获得该资源锁，别的线程必须等待该线程释放所有次数的锁才能获得。

  • 读写锁:
    读写锁拥有读状态加锁、写状态加锁、不加锁三种状态。只有一个线程可以占有写状态的锁，但可以多个线程同时占有读状态锁，这也是它可以实现高并发的原因。当其处于写状态锁下，任何想要尝试获得锁的线程都会被阻塞，直到写状态锁被释放；如果是处于读状态锁下，允许其它线程获得它的读状态锁，但是不允许获得它的写状态锁，当读写锁感知到有线程想要获得写状态锁时，便会阻塞其后所有想要获得读状态锁的线程。所以读写锁非常适合资源的读操作远多于写操作的情况。

有以下10种加锁方案：

注意：在不同的线程中加锁，必须是同一把锁。

  1. OSSpinLock：需导入头文件#import <libkern/OSAtomic.h>，是自旋锁。
    目前已经不再安全，可能会出现优先级反转问题。(如果等待锁的线程的优先级较高，它会一直占用CPU资源，优先级低的线程就无法释放锁)

    //初始化锁
OSSpinLock lock = OS_SPINLOCK_INIT;
//加锁
OSSpinLockLock(&lock);
//解锁
OSSpinLockUnlock(&lock);

  2. os_unfair_lock：需导入头文件#import <os/lock.h>，是互斥锁。
    用于取代不安全的OSSpinLock，从IOS10开始才支持，从底层调用看，等待os_unfair_lock锁的线程会处于休眠状态，并非忙等。

    //初始化锁
os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
//加锁
os_unfair_lock_lock(&lock);
//解锁
os_unfair_lock_unlock(&lock);

  3. pthread_mutex_t：需导入头文件#import <pthread.h>，是互斥锁。

    //申明mutex锁
pthread_mutex_t mutex;
//声明mutex锁的属性
pthread_mutexattr_t attr;
//初始化属性attr
pthread_mutexattr_init(&attr);
//设置锁属性的类型
/* 参数说明
  *
  * 第一个参数pthread_mutexattr_t：mutex锁属性attr对象的地址
  * 第二个参数：锁的类型
              #define PTHREAD_MUTEX_NORMAL          0 //默认锁，也就是”互斥锁“
              #define PTHREAD_MUTEX_ERRORCHECK      1 //错误锁
              #define PTHREAD_MUTEX_RECURSIVE       2 //递归锁
              #define PTHREAD_MUTEX_DEFAULT         PTHREAD_MUTEX_NORMAL
 */
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
//初始化锁
/* 参数说明
  *
  * 第一个参数pthread_mutex_t：mutex锁对象的地址
  * 第二个参数pthread_mutexattr_t：mutex锁属性attr对象的地址。该参数可以传NULL，为默认属性PTHREAD_MUTEX_DEFAULT，”互斥锁“
 */
pthread_mutex_init(&mutex, &attr);
//销毁mutex锁的属性
pthread_mutexattr_destroy(&attr);
//加锁
pthread_mutex_lock(&mutex);
//解锁
pthread_mutex_unlock(&mutex);
//销毁锁
pthread_mutexattr_destroy(&mutex);

    扩展：
    pthread_cond_t条件锁：配合pthread_mutex_t实现

    //初始化条件锁
pthread_cond_t cond;
pthread_cond_init(&cond, NULL);
//条件等待，当线程调用该函数，然后阻塞当前线程进入休眠并解锁。
pthread_cond_wait(&cond, &mutex);
//条件唤醒，当线程中调用该函数，等到该调用线程解锁后，然后h就唤醒前面休眠的线程，并给唤醒线程加锁。
//唤醒一个等待该条件的线程
pthread_cond_signal(&cond);
//唤醒所有等待该条件的线程
pthread_cond_broadcast(&cond);
//销毁条件
pthread_cond_destroy(&cond);

  4. NSLock：对pthread_mutex_t的锁封装。

    //初始化锁
NSLock *lock = [[NSLock alloc] init];
//加锁
[lock lock];
//解锁
[lock unlock];

  5. NSRecursiveLock:：对pthread_mutex_t的的递归锁封装。

    //初始化锁
NSRecursiveLock *recursiveLock = [[NSRecursiveLock alloc] init];
//加锁
[recursiveLock lock];
//解锁
[recursiveLock unlock];

  6. NSCondition：对pthread_mutex_t的cond条件和mutex锁封装。

    //初始化锁
NSCondition *cond = [[NSCondition alloc] init];
//加锁
[cond lock];
//条件等待
[cond wait];
//唤醒条件等待
//唤醒一个条件等待
[cond signal];
//唤醒所有条件等待
[cond broadcast];
//解锁
[cond unlock];

  7. NSConditionLock：对pthread_mutex_的cond条件和mutex锁封装。会根据内部存储的条件condition的值，进行加锁。

    //初始化锁
NSConditionLock *condLock = [[NSConditionLock alloc] initWithCondition:1];
//加锁
[condLock lockWhenCondition:1];
//解锁
[condLock unlockWithCondition:2];
//加锁
[condLock lockWhenCondition:2];
//解锁
[condLock unlock];

  8. 在同步串行队列中开启子线程执行任务。

    dispatch_sync(dispatch_queue_create("sertal", DISPATCH_QUEUE_SERIAL), ^{
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        //执行操作
    });
});

  9. 使用信号量dispatch_semaphore_t控制线程最大并发数量：

    // 信号量的初始值
int value = 1;
//初始化信号量
dispatch_semaphore_t semaphore = dispatch_semaphore_create(value);
// 如果信号量的值<=0，当前线程就进入休眠等待（直到信号量的值>0）。
// 如果信号量的值>0，就减1，然后往下执行后面的代码。
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
// 让信号量的值加1
dispatch_semaphore_signal(semaphore);

  10. @synchronized：是封装了mutex的递归锁。

    @synchronized([self class]) {
    //执行操作
}

IOS线程同步方案性能比较：

从高到低：
os_unfair_lock
OSSpinLock
dispatch_semaphore
pthread_mutex
dispatch_queue(DISPATCH_QUEUE_SERIAL)
NSLock
NSCondition
pthread_mutex(recursive)
NSRecursiveLock
NSConditionLock
@synchronized

多线程文件读写安全，多读单写：

  • 使用读写锁pthread_rwlock_t：是“互斥锁”。

    //声明读写锁
pthread_rwlock_t rwlock;
//初始化读写锁
pthread_rwlock_init(&rwlock, NULL);
//读的加锁
pthread_rwlock_rdlock(&rwlock);
//读的解锁
pthread_rwlock_unlock(&rwlock);

//写的加锁
pthread_rwlock_wrlock(&rwlock);
//写的解锁
pthread_rwlock_unlock(&rwlock);

//销毁锁
pthread_rwlock_destroy(&rwlock);

  • 异步函数dispatch_async进行读的操作和异步栅栏dispatch_barrier_async进行写的操作：读写操作必须保证在同一个手动创建的并发队列中。

    //必须手动创建并发队列
dispatch_queue_t queue = dispatch_queue_create("concurrent", DISPATCH_QUEUE_CONCURRENT);
//异步h函数执行读的操作
dispatch_async(queue, ^{
    //读的操作
});

//异步栅栏函数进行写的操作，队列必须是手动创建的全局并发队列。
//如果不是，传入的是串行队列或者全局并发队列，异步栅栏会失效，效果等同于异步函数dispatch_async
dispatch_barrier_async(queue, ^{
    //写的操作
});
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
禁止转载，如需转载请通过简信或评论联系作者。
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 194,242评论 5赞 459
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 81,769评论 2赞 371
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 141,484评论 0赞 319
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 52,133评论 1赞 263
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 61,007评论 4赞 355
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 46,080评论 1赞 272
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 36,496评论 3赞 381
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 35,190评论 0赞 253
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 39,464评论 1赞 290
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2赞 309
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1赞 326
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,205评论 3赞 312
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 37,567评论 3赞 298
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0赞 17
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1赞 250
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2赞 341
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2赞 335