ios中的锁_ios中的锁集-CSDN博客

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

在平时开发中我们经常会使用多线程，多线程为我们带来了很大便利，也提高了程序的执行效率，但同时也带来数据风险：当至少有两个线程同时访问同一个变量，而且至少其中有一个是写操作时，就发生了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。