ios中的锁

想名真难

已于 2023-05-04 17:12:57 修改

阅读量1.2k

点赞数

分类专栏： runtime和多线程(包含runloop) 文章标签： ios

于 2019-10-22 22:39:03 首次发布

原文链接：https://www.jianshu.com/p/b1edc6b0937a

版权

runtime和多线程(包含runloop) 专栏收录该内容

56 篇文章 3 订阅

订阅专栏

代码测试可参考，只有实际写过才能更好的理解：

在平时开发中我们经常会使用多线程，多线程为我们带来了很大便利，也提高了程序的执行效率，但同时也带来数据风险：当至少有两个线程同时访问同一个变量，而且至少其中有一个是写操作时，就发生了Data race。所以这是就要利用一些同步机制来确保数据的准确性，锁就是同步机制中的一种。

什么是锁？锁 – 是保证线程安全常见的同步工具。锁是一种非强制的机制，每一个线程在访问数据或者资源前，要先获取(Acquire) 锁，并在访问结束之后释放(Release)锁。如果锁已经被占用，其它试图获取锁的线程会等待，直到锁重新可用。

怎么检测项目中的`Data race`？

只需要在设置中勾选Thread Sanitizer 即可，顺便可以勾选Pause on issues 就可以断点到相应的代码。

简单的性能测试

下图是针对iOS中的锁测试得出的，图中数字代表每次加解锁需要消耗的时间，单位为ns。

值得注意的是：1.这个数字仅仅代表每次加解锁的耗时，并不能全方面的代表性能。2.不同的机型和系统，不同的循环次数可能结果会略微有些差异。
但是还是可以看出@synchronized:是表现最差的。

在具体说这些锁之前，先来说几个概念定义：

临界区：指的是一块对公共资源进行访问的代码，并非一种机制或是算法。通俗点理解, 就是一段代码.
自旋锁：是用于多线程同步的一种锁，线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。一旦获取了自旋锁，线程会一直保持该锁，直至显式释放自旋锁。自旋锁是比较耗费 cpu 的，然而在互斥临界区计算量较小的场景下，它的效率远高于其它的锁。因为它是一直处于 running 状态，减少了线程切换上下文的消耗。

OSSpinLock（已废弃，不推荐，虽然效率最高，使用os_unfair_lock替代）
互斥锁（Mutex）：在编程中，来保证共享数据操作的完整性。每个对象都对应于一个可称为互斥锁的标记，这个标记用来保证在任一时刻，只能有一个线程访问该对象。通过将代码切片成一个一个的临界区而达成.NSLock, NSConditionLock, NSRecursiveLock, NSCondition，pthread_mutex，@synchronized，os_unfair_lock
读写锁：是计算机程序的并发控制的一种同步机制，也称“共享-互斥锁”、多读者-单写者锁) 用于解决多线程对公共资源读写问题。读操作可并发重入，写操作是互斥的。比如pthread_rwlock，读写锁通常用dispatch_barrier_async 实现
信号量（semaphore）：是一种更高级的同步机制，互斥锁可以说是semaphore在仅取值0/1时的特例。信号量可以有更多的取值空间，用来实现更加复杂的同步，而不单单是线程间互斥。
条件锁：就是条件变量，可以自己设置一个条件来定义加锁与释放锁的时机. NSCondition ， NSConditionLock中注意条件并不是bool类型的，而是一个固定的数字，加锁或者解锁，都会把condition修改为参数。
递归锁 ：递归锁允许同一个线程多次请求锁，而不会出现死锁的情况。属于对互斥锁的一种。@synchronized NSRecursiveLock ， pthread_mutex

互斥锁

1.NSLock：是Foundation框架中以对象形式暴露给开发者的一种锁，（Foundation框架同时提供了NSConditionLock，NSRecursiveLock，NSCondition）NSLock定义如下：

@protocol NSLocking

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

@end

@interface NSLock : NSObject <NSLocking> {
@private
    void *_priv;
}

- (BOOL)tryLock;
- (BOOL)lockBeforeDate:(NSDate *)limit;

@property (nullable, copy) NSString *name API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));

@end

tryLock 和 lock 方法都会请求加锁，唯一不同的是trylock在没有获得锁的时候可以继续做一些任务和处理。lockBeforeDate方法也比较简单，就是在limit时间点之前获得锁，没有拿到返回NO。
实际项目中：NSLock在AFNetworking的AFURLSessionManager.m中应用如下：

- (instancetype)initWithSessionConfiguration:(NSURLSessionConfiguration *)configuration {
    ...
    self.lock = [[NSLock alloc] init];
    self.lock.name = AFURLSessionManagerLockName;
    ...
}
- (void)setDelegate:(AFURLSessionManagerTaskDelegate *)delegate
            forTask:(NSURLSessionTask *)task
{
    ...
    [self.lock lock];
    self.mutableTaskDelegatesKeyedByTaskIdentifier[@(task.taskIdentifier)] = delegate;
    [delegate setupProgressForTask:task];
    [self addNotificationObserverForTask:task];
    [self.lock unlock];
}

2.pthread_mutex： NSLock实际是封装了一下 pthread_mutex ，因为NSLock加入了错误处理，所以性能会比 pthread_mutex有所下降。

pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);  // 定义锁的属性
pthread_mutex_t mutex;
pthread_mutex_init(&mutex, &attr); // 创建锁
pthread_mutex_lock(&mutex); // 申请锁
NSLog(@"pthread_mutexattr_t互斥锁");
 pthread_mutex_unlock(&mutex); // 释放锁

实际项目中： 在YYKit的YYMemoryCach中可以看到

- (instancetype)init {
    ...
    pthread_mutex_init(&_lock, NULL);
    ...
}
- (void)_trimToCost:(NSUInteger)costLimit {
    BOOL finish = NO;
    pthread_mutex_lock(&_lock);
    if (costLimit == 0) {
        [_lru removeAll];
        finish = YES;
    } else if (_lru->_totalCost <= costLimit) {
        finish = YES;
    }
    pthread_mutex_unlock(&_lock);
    if (finish) return;
    
    NSMutableArray *holder = [NSMutableArray new];
    while (!finish) {
        if (pthread_mutex_trylock(&_lock) == 0) {
            if (_lru->_totalCost > costLimit) {
                _YYLinkedMapNode *node = [_lru removeTailNode];
                if (node) [holder addObject:node];
            } else {
                finish = YES;
            }
            pthread_mutex_unlock(&_lock);
        } else {
            usleep(10 * 1000); //10 ms
        }
    }
   ...
}

自旋锁

1.OSSpinLock:

@import Darwin.os.lock;

/*
 // 初始化
 os_unfair_lock_t unfairLock = &(OS_UNFAIR_LOCK_INIT);
 // 加锁
 os_unfair_lock_lock(unfairLock);
 // 尝试加锁
 BOOL b = os_unfair_lock_trylock(unfairLock);
 // 解锁
 os_unfair_lock_unlock(unfairLock);
 os_unfair_lock 用法和 OSSpinLock 基本一致，就不一一列出了。
 */
- (void)osspinlock {
    __block OSSpinLock theLock = OS_SPINLOCK_INIT;//在iOS10之后被ns_unfair_lock替换
    
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSSpinLockLock(&theLock);
        NSLog(@"线程1开始");
        [self Test];
        NSLog(@"线程1结束");
        OSSpinLockUnlock(&theLock);
        
    });
    
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSSpinLockLock(&theLock);
        NSLog(@"线程2开始");
        [self Test];
        NSLog(@"线程2结束");
        OSSpinLockUnlock(&theLock);
        
    });
}

上面是OSSpinLock使用方式，编译会报警告，已经废弃了，OSSpinLock大家也已经不再用它了，因为它在某一些场景下已经不安全了，可以参考 YY大神的不再安全的 OSSpinLock，在Protocol Buffers项目中你可以看到这样的注释，大家已经用新的方案替换了。

在iOS 中，系统维护了 5 个不同的线程优先级/QoS: background，utility，default，user-initiated，user-interactive。高优先级线程始终会在低优先级线程前执行，一个线程不会受到比它更低优先级线程的干扰。这种线程调度算法会产生潜在的优先级反转问题，从而破坏了 spin lock。

具体来说，如果一个低优先级的线程获得锁并访问共享资源，这时一个高优先级的线程也尝试获得这个锁，它会处于 spin lock 的忙等状态从而占用大量 CPU。此时低优先级线程无法与高优先级线程争夺 CPU 时间，从而导致任务迟迟完不成、无法释放 lock。这并不只是理论上的问题，libobjc 已经遇到了很多次这个问题了，于是苹果的工程师停用了 OSSpinLock。

优先级高的持续占有cpu，直到获取到资源。低优先级的竞争不过cpu，但是拿着资源，无法使用。导致死锁。

os_unfair_lock:(互斥锁)
os_unfair_lock 是苹果官方推荐的替换OSSpinLock的方案，但是它在iOS10.0以上的系统才可以调用。os_unfair_lock是一种互斥锁，它不会向自旋锁那样忙等，而是等待线程会休眠。

os_unfair_lock_t unfairLock;
 unfairLock = &(OS_UNFAIR_LOCK_INIT);
os_unfair_lock_lock(unfairLock);
NSLog(@"os_unfair_lock_t");
os_unfair_lock_unlock(unfairLock);

读写锁

上文有说到，读写锁又称共享-互斥锁，实际中大部分是通过gcd实现读写锁的,在AFN上有体现, ios实现读写锁,AFN的实现_想名真难的博客-CSDN博客_ios 读写锁
pthread_rwlock：

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

// 声明属性
@property (nonatomic, assign) pthread_rwlock_t rwlock;


// 初始化
pthread_rwlock_init(&_rwlock, NULL);
 
// 读加锁
- (void)read {
    pthread_rwlock_rdlock(&_rwlock);
    NSLog(@"read");
    pthread_rwlock_unlock(&_rwlock);
}
 
// 写加锁
- (void)wtite {
    pthread_rwlock_wrlock(&_rwlock);
    NSLog(@"write");
    pthread_rwlock_unlock(&_rwlock);
}

// 销毁锁
- (void)dealloc {
    pthread_rwlock_destroy(&_rwlock);
}

递归锁

递归锁有一个特点，就是同一个线程可以加锁N次而不会引发死锁。
1.NSRecursiveLock:

NSRecursiveLock *recursiveLock = [[NSRecursiveLock alloc]init];  
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        
        static void (^RecursiveMethod)(int);
        RecursiveMethod = ^(int value) {
            
            [recursiveLock lock];
            if (value > 0) {
                
                NSLog(@"value = %d", value);
                sleep(2);
                RecursiveMethod(value - 1);
            }
            [recursiveLock unlock];
        };
        
        RecursiveMethod(5);
    });

NSRecursiveLock在YYKit中YYWebImageOperation.m中有用到：

_lock = [NSRecursiveLock new];
- (void)dealloc {
    [_lock lock];
    ...
    ...
    [_lock unlock];
}

2.pthread_mutex(recursive):
pthread_mutex锁也支持递归，只需要设置PTHREAD_MUTEX_RECURSIVE即可

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);

3.@synchronized也属于递归锁, 用传入的对象关联一个递归锁, 详细看@synchronized 递归锁详解_想名真难的博客-CSDN博客_递归锁原理:
实际项目中：AFNetworking中 isNetworkActivityOccurring属性的getter方法

- (BOOL)isNetworkActivityOccurring {
    @synchronized(self) {
        return self.activityCount > 0;
    }
}

条件锁

1. NSCondition:
定义：

@interface NSCondition : NSObject <NSLocking> {
@private
    void *_priv;
}

- (void)wait;
- (BOOL)waitUntilDate:(NSDate *)limit;
- (void)signal;
- (void)broadcast;

遵循NSLocking协议，使用的时候同样是lock,unlock加解锁，wait是傻等，waitUntilDate:方法是等一会，都会阻塞掉线程，signal是唤起一个在等待的线程, 被唤起的线程会开始工作, ,，broadcast是广播全部唤起。

NSCondition *lock = [[NSCondition alloc] init];
//Son 线程
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [lock lock];
    if (No Money) {
        // wait会使线程进入休眠,同时释放掉锁; 
        // 当有signal或者broadcast的时候, 线程会开始工作,同时再次加锁,
        [lock wait]; 

    }
    NSLog(@"The money has been used up.");
    [lock unlock];
});
    
 //Father线程
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [lock lock];
    NSLog(@"Work hard to make money.");
    [lock signal];
    [lock unlock];
 });

2.NSConditionLock:
定义：

@interface NSConditionLock : NSObject <NSLocking> {
@private
    void *_priv;
}

- (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;

当我们在使用多线程的时候，只有一把会lock和unlock的锁就不能满足我们的需要了。因为普通的锁只关心锁与不锁，但是并不在乎什么时候才能开锁，而在处理资源共享场景的时候，多数情况下只有满足一定条件下才能打开这把锁。（Condition：条件）
NSConditionLock实现步骤：
NSConditionLock实现了NSLocking协议，一个线程会等待另一个线程unlock或者unlockWithCondition:之后再走lock或者lockWhenCondition:之后的代码。
锁定和解锁的调用可以随意组合，也就是说 lock、lockWhenCondition:与unlock、unlockWithCondition: 是可以按照自己的需求随意组合的。

1、只有 condition 参数与初始化时候的 condition 相等，lock 才能正确进行加锁操作。
2、unlockWithCondition: 并不是当 condition 符合条件时才解锁，而是解锁之后，修改 condition 的值。

在来个例子

- (void)nsconditionlock {
    NSConditionLock * cjlock = [[NSConditionLock alloc] initWithCondition:0];
    
    //1、线程 1 解锁成功
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        [cjlock lock];
        NSLog(@"线程1加锁成功");
        sleep(1);//线程休眠一秒
        [cjlock unlock];
        NSLog(@"线程1解锁成功");
    });
    
    //2、初始化时候的 condition 参数为0，所以此处加锁失败，返回NO，此处线程阻塞。全部现成执行完毕后执行此处锁
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(1);//线程休眠一秒
        [cjlock lockWhenCondition:1];
        NSLog(@"线程2加锁成功");
        [cjlock unlock];
        NSLog(@"线程2解锁成功");
    });
    
    //3、tryLockWhenCondition尝试加锁  初始化时候的 condition 参数为0，所以此处加锁成功。方法就算条件不满足，也会返回 NO，不会阻塞当前线程。
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(2);
        
        if ([cjlock tryLockWhenCondition:0]) {
            NSLog(@"线程3加锁成功");
            sleep(2);
            /*
             A：成功案例
             这里会先解锁当前的锁，之后修改condition的值为100.在下一个condition为100的线程中会加解锁成功，如果下个锁中的condition等待的值不是100，那么就会导致加锁失败。
             */
            [cjlock unlockWithCondition:100];
            NSLog(@"线程3解锁成功");
            
            /*
             B：失败案例
             [cjlock unlockWithCondition:4];
             NSLog(@"线程3仍然会解锁成功，之后修改condition的值为4");
             */
            
        } else {
            NSLog(@"线程3尝试加锁失败");
        }
    });
    
    //4、lockWhenCondition:beforeDate:方法会在约定的时间内一直等待 condition 变为 2，并阻塞当前线程，直到超时后返回 NO。
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        if ([cjlock lockWhenCondition:100 beforeDate:[NSDate dateWithTimeIntervalSinceNow:10]]) {
            NSLog(@"线程100加锁成功");
            [cjlock unlockWithCondition:1];
            NSLog(@"线程100解锁成功");
        } else {
            NSLog(@"线程100尝试加锁失败");
        }
    });
}

信号量

dispatch_semaphore:
信号量在初始化时要指定 value，随后内部将这个 value 存储起来。实际操作时会存两个 value，一个是当前的 value，一个是记录初始 value。信号的 wait 和 signal 是互逆的两个操作。如果 value 大于 0，wait将 value 减一,然后做事情，此时如果 value 小于零就一直等待。signal会使value+1，所以wait 和 signal必须是成对出现的.
初始 value 必须大于等于 0，如果为 0 并随后调用 wait 方法，线程将被阻塞直到别的线程调用了 signal 方法。用法如下

-(void)test_semaphore{
       dispatch_queue_t queque = dispatch_queue_create("queue", DISPATCH_QUEUE_CONCURRENT);
       //异步执行
       dispatch_async(queque, ^{
           dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
           [self getToken:semaphore];
           dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
           [self request];
       });
       
       NSLog(@"main thread");
}
-(void)getToken:(dispatch_semaphore_t)semaphore{
   NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration]];
   NSURLSessionTask *task = [session dataTaskWithRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.baidu.com"]] completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
       NSLog(@"get Token");
       //成功拿到token，发送信号量:
       dispatch_semaphore_signal(semaphore);
   }];
   [task resume];
}
-(void)request{
   dispatch_async(dispatch_get_main_queue(), ^{
       NSLog(@"刷新数据");
   });
}

信号量不止可以用于加锁, 还可以把异步执行任务转换为同步执行任务. 本来方法是异步的, 但是想要同步的知道结果,就可以是线程阻塞,等到有结果了,在return; 注意如果主线程这么操作会造成卡顿哦~

比如说：AFNetworking 中 AFURLSessionManager.m 里面的 tasksForKeyPath: 方法。通过引入信号量的方式，等待异步执行任务结果，获取到 tasks，然后再返回该 tasks。

总结：

其实本文写的都是一些再基础不过的内容，在平时阅读一些开源项目的时候经常会遇到一些保持线程同步的方式，因为场景不同可能选型不同，这篇就做一下简单的记录吧。一定要动手试试哦

iOS中的多种锁（Lock）

iOS开发中的11种锁以及性能对比

进阶：iOS 锁和源码

想名真难

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
1
评论
ios中的锁

代码测试可参考，只有实际写过才能更好的理解：https://www.jianshu.com/p/6d6832e42936在平时开发中我们经常会使用多线程，多线程为我们带来了很大便利，也提高了程序的执行效率，但同时也带来数据风险：当至少有两个线程同时访问同一个变量，而且至少其中有一个是写操作时，就发生了Data race。所以这是就要利用一些同步机制来确保数据的准确性，锁就是同步机制中的一种。...
复制链接

扫一扫