1.锁的归类

在OC中锁分为互斥锁和自旋锁两种。

1.自旋锁

是一种用于保护多线程共享资源的锁，与一般互斥锁（mutex）不同之处在于当自旋锁尝试获取锁时以忙等待（busy waiting）的形式不断地循环检查锁是否可用。当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会一直等待（不会睡眠），当上一个线程的任务执行完毕，下一个线程会立即执行。

在多CPU的环境中，对持有锁较短的程序来说，使用自旋锁代替一般的互斥锁往往能够提高程序的性能。

自旋锁：OSSpinLock(自旋锁)、读写锁

2.互斥锁

当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会进入睡眠状态等待任务执行完毕，当上一个线程的任务执行完毕，下一个线程会自动唤醒然后执行任务，该任务也不会立刻执行，而是成为可执行状态（就绪）。互斥锁（mutex），⽤于保证在任何时刻，都只能有⼀个线程访问该对象。

• mutex函数

  在Posix Thread中定义有⼀套专⻔⽤于线程同步的mutex函数。mutex，⽤于保证在任何时刻，都只能有⼀个线程访问该对象。当获取锁操作失败时，线程会进⼊睡眠，等待锁释放时被唤醒。

  NSLock、NSCondtion、NSRecursiveLock底层都是对pthread的封装。

• 互斥和同步的理解

  • 互斥：两条线程处理，同一时间只有一个线程可以运行；
  • 同步：除了有互斥的意思外，同时还有一定的顺序要求，即按照一定的顺序执行。

• 递归锁

  就是同⼀个线程可以加锁N次⽽不会引发死锁NSRecursiveLock、@synchronized、pthread_mutex(recursive)

互斥锁：pthread_mutex(互斥锁)、@synchronized(互斥锁)、NSLock(互斥锁)、NSConditionLock(条件锁)、NSCondition(条件锁)、NSRecursiveLock(递归锁)、dispatch_semaphore_t(信号量)

3.自旋锁和互斥锁的特点

• 自旋锁会忙等，所谓忙等，即在访问被锁资源时，调用者线程不会休眠，而是不停循环在那里，直到被锁资源释放锁。

• 互斥锁会休眠，所谓休眠，即在访问被锁资源时，调用者线程会休眠，此时cpu可以调度其他线程工作，直到被锁资源释放锁。此时会唤醒休眠线程。

• 自旋锁优缺点

  优点在于，因为自旋锁不会引起调用者睡眠，所以不会进行线程调度，CPU时间片轮转等耗时操作。所有如果能在很短的时间内获得锁，自旋锁的效率远高于互斥锁。

  缺点在于，自旋锁一直占用CPU，他在未获得锁的情况下，一直运行自旋，所以占用着CPU，如果不能在很短的时间内获得锁，这无疑会使CPU效率降低。自旋锁不能实现递归调用。

4.锁的性能

图中锁的性能从高到底依次是：OSSpinLock(自旋锁) -> dispatch_semaphone(信号量) -> pthread_mutex(互斥锁) -> NSLock(互斥锁) -> NSCondition(条件锁) -> pthread_mutex(recursive 互斥递归锁) -> NSRecursiveLock(递归锁) -> NSConditionLock(条件锁) -> synchronized(互斥锁)

2.锁的作用

我们通过一个案例进行分析。模拟一个售票流程，总票数为20张，有4个窗口在同时进行售票，实时跟踪剩余票数。见下面代码：

@interface ViewController ()
@property (nonatomic, assign) NSUInteger ticketCount;
@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    self.ticketCount = 20;
    [self testSaleTicket];
}

- (void)testSaleTicket{

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 5; i++) {
            [self saleTicket];
        }
    });
   
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 5; i++) {
            [self saleTicket];
        }
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 3; i++) {
            [self saleTicket];
        }
    });

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        for (int i = 0; i < 10; i++) {
            [self saleTicket];
        }
    });
}

- (void)saleTicket{
    if (self.ticketCount > 0) {
        self.ticketCount--;
        sleep(0.1);
        NSLog(@"当前余票还剩：%lu张",(unsigned long)self.ticketCount);
    } else {
        NSLog(@"当前车票已售罄");
    }
}
@end
复制代码

运行结果如下图：

通过运行结果，发现因为异步操作的原因，出现了数据不安全问题，数据出现了混乱。通常我们会通过加锁的方式来保证数据的安全，用来保证在任一时刻，只能有一个线程访问该对象。

对象上面的案例进行修改，见下图：

添加一个@synchronized互斥锁，重新运行程序，发现其能够正常运行，并能够保证数据的安全性。@synchronized用着更方便，可读性更高，也是我们最常用的。

3.@synchronized实现原理

通过上面的案例我们了解到了锁的作用，那么@synchronized到底做了什么工作呢？这是我们所需要研究分析的。

1.底层探索

• clang分析实现原理

  提供下面一段代码，通过clang来查看其底层实现原理，加下图：

  

  clang之后生成.cpp文件，打卡.cpp文件，定位到main函数对应的位置。见下图：

  

  可以看到，调用了objc_sync_enter方法，并且使用了try-catch，在正常处理流程中，提供了_SYNC_EXIT结构体，最后也会调用对应的析构函数objc_sync_exit。

• 查看汇编流程

  首先我们可以通过汇编来分析，底层到底做了哪些操作。通过设置断点，并打开汇编调试，获取以下信息：

  

  通过汇编我们可以发现底层调用了两个方法分别是objc_sync_enter和objc_sync_exit，通过字面可以理解，分别是进入和退出。这与clang中看到的结果是一样的。

2.实现原理

在libObjc.dylib源码中分析其实现原理。搜索objc_sync_enter和objc_sync_exit两个方法的源码实现：

// enter
int objc_sync_enter(id obj)
{
    int result = OBJC_SYNC_SUCCESS;

    if (obj) {
        SyncData* data = id2data(obj, ACQUIRE);
        ASSERT(data);
        data->mutex.lock();
    } else {
        // @synchronized(nil) does nothing
        if (DebugNilSync) {
            _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
        }
        objc_sync_nil();
    }
    return result;
}

// exit
int objc_sync_exit(id obj)
{
    int result = OBJC_SYNC_SUCCESS;

    if (obj) {
        SyncData* data = id2data(obj, RELEASE); 
        if (!data) {
            result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
        } else {
            bool okay = data->mutex.tryUnlock();
            if (!okay) {
                result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
            }
        }
    } else {
        // @synchronized(nil) does nothing
    }
    return result;
}
复制代码

解读源码发现，enter方法和exit方法的实现流程是一一对应的。

首先加锁和解锁都会对obj进行判断，如果obj为空，则锁了个寂寞，什么也没有做，在libObjc.dylib源码中，没有查到objc_sync_nil()的相关实现。

如果obj不为空，在enter方法中，会封装一个SyncData对象，并对调用mutex属性进行上锁lock()；在exit方法时，同样获取对应的SyncData对象，然后调用data->mutex.tryUnlock();进行解锁。

• SyncData结构分析

  SyncData底层定义如下：

      typedef struct alignas(CacheLineSize) SyncData {
          struct SyncData* nextData;
          DisguisedPtr<objc_object> object;
          int32_t threadCount;  // number of THREADS using this block
          recursive_mutex_t mutex;
      } SyncData;
  
  复制代码

  • struct SyncData* nextData;包含了一个相同的数据结构，说明它是一个单项链表结构
  • object使用DisguisedPtr进行了包装
  • threadCount线程的数量，有多少个线程对该对象进行加锁
  • recursive_mutex_t mutex;递归锁

  从SyncData的属性可以判断，@synchronized支持递归锁，并且支持多线程访问。

• StripedMap数据结构

  首先要分析底层的数据存储结构。SyncData存储在一个hash表中，并且是静态的。见下面代码：

  static StripedMap<SyncList> sDataLists;
  
  class StripedMap {
  
      #if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
          enum { StripeCount = 8 };
  
      #else
          enum { StripeCount = 64 };
  
      #endif
  }
  复制代码

  给表为不同的架构环境提供了不同的容量，真机环境的容量为8，模拟环境的容量为64。而其元素为SyncList，SyncList的数据结构为：

  struct SyncList {
      SyncData *data;
  
      spinlock_t lock;
  
      constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
  };
  复制代码

  而SyncData是一个链表结构，至此形成了一个拉链结构。见下图：

  

• id2data方法

  id2data实现源码见下图：

  

  这里包含3个大步骤，首先通过tls，从线程缓存中获取当前线程的SyncData进行相关处理；如果缓存中存在对应的SyncData则从缓存中获取并处理；最后包括一些内部的初始化插入缓存等操作。

流程分支比较多，具体会调用哪些流程呢？下面通过案例结合lldb调试进行分析。

3.案例跟踪

单线程递归加锁object不变

引入下面的案例，在一个子线程中递归添加同一个锁。见下图：

• 断点1：案例的104行

  运行程序，在案例的104行设置断点，跟踪进入id2data方法。此时StripedMap表中64个数据全是空。见下图：

  

  继续跟踪调试，会调用tls_get_direct方法，获取当前线程绑定的SyscData，因为是第一次进行加锁，所以这里的data是空。见下图：

  

  紧接着会从当前线程的缓存列表中获取对应的SyncData，很显然此时缓存中也没有存储该对象，所以此时也是空。见下图：

  

  当前线程绑定的SyncData和线程对应的缓存列表中的SyncData都为空，则会从哈希表中获取，当前的表中也没有对应的数据，见下图：

  

  上面三个地方都没有找到对应的SyncData，最终会创建一个SyncData，并采用头插法将数据插入到对应listp头部。见下图：

  

  完成SyncData创建后，会绑定到当前线程上（一个线程只会绑定一个，并且绑定后不再改变），注意此时并没有保存到线程对应的缓存列表中。见下图：

  

  最后返回result，完成加锁功能。

• 断点2：案例的107行

  从此断点开始，进行该对象的第二次加锁。进入id2data方法，此时哈希表中已经有一个数据，也就是此时对象对应的listp此时也不再为空（同一个对象）。见下图：

  

  继续运行程序，再次获取当前线程绑定的SyncData，此时不再为空，并且object相同。见下图：

  

  线程绑定的SyncData对应的object，与此时的object相同，再次创建锁，并且锁次数++，见下图：

  

• 断点3：案例的110行

  进行第三次加锁时，因为此时object没有发生改变，线程也没有改变，此时哈希表依然是一个元素，同时对应的listp也只有一个元素，此时上锁此时会变为3。见下图：

  

单线程递归加锁object变化

引入下面这个案例，我们直接从第二个断点开始分析，见下图：

第一个断点的处理流程我们已经分析了，此时会创建一个新的SyncData，并且会绑定到当前线程中。

• 断点2：案例的108行

  object为person2，此时线程已经绑定了person1对应的SyncData，所以线程绑定关系已经被占用，但是object不相同。见下图：

  

  因为person2对象是第一次加锁，所以线程对应缓存列表和listp中都没有对应的SyncData。见下图：

  

  person2初次进入，会进行对象的创建，并将SyncData放入缓存列表中。见下图：

  

  如果下次person2再次加锁时，会从缓存列表中获取。而如果person1再次加锁，会从当前线程中获取，因为当前线程已经绑定了person1对应的SyncData。

多线程递归加锁object变化

引入下面的案例，见下图：

上面案例中，前两个加锁过程这里不再分析，和上面单线程是一样的，我们从多线程时开始分析，也就是第113行开始。

• 断点1：案例的113行

  从断点1处进行跟踪，进入id2data方法，此时哈希表中的数据个数为2，也就是外层线程添加的两个SyncData。见下图：

  

  继续跟踪代码，从线程中获取其绑定的SyncData，此时为NULL，因为是新的线程，还没有加过锁，所以绑定数据为空，fastCacheOccupied=NO。见下图：

  

  接着，从缓存列表中获取对应的SyncData，也是NULL，所以这里的缓存列表也是和线程一一对应的。见下图：

  

  紧接着，会从listp中获取对应的数据，在外层线程中，已经添加了person1和person2对应的SyncData，所以这里是可以获取的。并且会针多线程操作，从而是threadCount加1，此时对应的线程数会变成2**见下图：

  

  获取数据后，因为前面fastCacheOccupied=NO，则会将该SyncData绑定到当前这个线程，也就是每个线程都会默认绑定第一个object，见下图：

  

• 断点2：案例的116行

  进行person2的加锁操作，此时首先会获取当前线程绑定的SyncData，因为此时已经绑定了person1，tls对应的Object不相同。

  然后会从线程对应的缓存列表中获取，因为当前线程没有添加过，所以这里查询不到，最终会在listp中获取对应的SyncData。与此同时会进行threadCount加1操作。完成以上操作后，会将该SyncData添加到线程对应的缓存列表中。见下图：

  

在新线程中的流程与外层线程的逻辑是一样的，只是线程绑定的数据和缓存列表数据不一样。

4.@synchronized原理总结

通过上面的分析，objc_sync_enter可以得出以下流程图，在获取SyncData之后，会调用属性mutex.lock();进行加锁。见下图：

注意事项：上图中多线程的情况需要注意，只要遇到新开线程，开始加锁，tls和cache一定是空，肯定是listp中查找，或者是create。一个线程中第一个添加的Object一定会绑定到tls中，并且在当前线程中不会改变。如果tls已经完成设置，之后添加的SyncData都会添加到缓存列表中。

objc_sync_exit流程和这个相反，同样会调用id2data方法，获取SyncData，对lockCount和threadCount进行减操作。如果count等于0，则会从相应的绑定关系和缓存列表中移除。

综上：@synchronized是一个支持多线程的递归锁。

4.NSLock和NSRecursiveLock的使用

引入一个案例，见下面代码：

- (void)lg_testRecursive{
    for (int i= 0; i<10; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            static void (^testMethod)(int);
            testMethod = ^(int value){
                    if (value > 0) {
                        NSLog(@"current value = %d",value);
                        testMethod(value - 1);
                    }
            };
            testMethod(10);
        });
    }
}
复制代码

案例中开启十个线程，进行10到1的输出打印，运行上面代码，运行结果见下图：

其中testMethod为静态block，因为多线程的影响，所以运行结果错乱无序的，这点很好理解。如何解决混乱的问题呢？加锁！但是锁加在哪里呢？很显然testMethod(10);方法调用的地方是核心步骤。见下图：

验证结果和我们的分析是一致的，我们在分析@synchronized时知道，数据结构SyncData中分装了recursive_mutex_t递归互斥锁，@synchronized是一个支持多线程递归的锁。

1.NSLock

使用NSLock进行加锁，将锁加在业务代码外层，修改后代码如下：

NSLock启到了作用，那么通常我们在开发过程中会将锁业务代码中，即将锁放在testMethod方法内部，见下图：

此时程序没有正常输出，为什么呢？因为在调用textMethod方法之后，lock加锁，内部又继续调用testMethod，导致重复加锁。

这里说明NSLock是不支持递归加锁的！

2.NSRecursiveLock

使用NSRecursiveLock进行加锁，将锁加在业务代码外层，修改后代码如下：

正常运行，并得到了预期的效果，如果将NSRecursiveLock加在业务代码内部呢？

通过上面的运行结果发现，NSRecursiveLock在完成一次业务操作后就崩溃了。

说明NSRecursiveLock支持单线程内的递归加锁，但是并不支持多线程递归。

5.NSCondition的使用

NSCondition的对象实际上作为⼀个锁和⼀个线程检查器：锁主要为了当检测条件时保护数据源，执⾏条件引发的任务；线程检查器主要是根据条件决定是否继续运⾏线程，即线程是否被阻塞。

• NSCondition提供的API

  1. [condition lock]; ⼀般⽤于多线程同时访问、修改同⼀个数据源，保证在同⼀时间内数据源只被访问、修改⼀次，其他线程的命令需要在lock外等待，只到unlock，才可访问
  2. [condition unlock];与lock同时使⽤
  3. [condition wait];让当前线程处于等待状态
  4. [condition signal]; CPU发信号告诉线程不⽤在等待，可以继续执⾏

• 案例分析

  模拟生产和消费的需求，开启多个线程进行产品生产，同时开启多个线程进行销售产品。见下面案例：

  #pragma mark **-- NSCondition**
  - (void)lg_testConditon{
      NSCondition *testCondition = [[NSCondition alloc] init];
  
      // 创建-生产者
      for (int i = 0; i < 50; i++) {
         dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
              [self lg_producer];
          });
         dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
              [self lg_producer];
          });
      }
      
      // 创建-消费者
      for (int i = 0; i < 50; i++) {
          dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
              [self lg_consumer];
          });
  
          dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
              [self lg_consumer];
          });
      }
  }
  
  - (void)lg_producer{
      [_testCondition lock]; // 操作的多线程影响
  
      self.ticketCount = self.ticketCount + 1;
      NSLog(@"生产一个 现有 count %zd",self.ticketCount);
  
      [_testCondition signal]; // 信号
  
      [_testCondition unlock];
  }
  
  - (void) lg_consumer {
      [_testCondition lock];  // 操作的多线程影响
  
      if (self.ticketCount == 0) {
          NSLog(@"等待 count %zd",self.ticketCount);
          [_testCondition wait];
      }
  
      // 注意消费行为，要在等待条件判断之后
      self.ticketCount -= 1;
      NSLog(@"消费一个 还剩 count %zd ",self.ticketCount);
  
      [_testCondition unlock];
  }
  复制代码

  这里需要注意的是，生产线、消费线需要进行加锁处理，以保证多线程安全，于此同时，生产和消费之前也存在关系，比如库存数的安全！通过[_testCondition wait];模拟库存不足，让消费窗口停止消费；用[_testCondition signal];模拟已有库存可以消费，向等待的线程发送信号，开始执行。

  运行效果见下图：

  

6.Foundation源码了解锁的封装

前面提到NSLock、NSCondtion、NSRecursiveLock底层都是对pthread的封装。下面来探索一下其底层的实现。由于OC环境中锁相关的内容都是封装在Fundation框架下的，Fundation框架并不开源，只能查看一些声明：

在实现，定义了一个NSLocking协议，并且提供了lock和unlock方法。所以我们使用的⽐如条件锁，递归锁都会有对应的lock方法和unlock方法。

Swift中Fundation框架是开源的，我们可以通过Swift环境的Fundation框架探索锁的实现原理。

• NSLock

  源码中全局搜索NSLock:，获取NSLock锁定义的地方，见下图：

  

  在构造函数init中，底层调用了pthread_mutex_init函数。见下图：

  

  lock方法中，调用了pthread_mutex_lock函数；unlock方法中，调用了pthread_mutex_lock函数。底层就是对pthread的封装。

• NSRecursiveLock

  采用相同的方式，搜索递归锁NSRecursiveLock。见下图：

  发现其也是对pthread的封装，并且通过在init方法中，通过pthread_mutexattr_settype(attrs, Int32(PTHREAD_MUTEX_RECURSIVE))进行递归设置。

• NSCondition

  NSCondition底层也是对pthread进行了封装，见下图：

  

  除了进行pthread_mutex互斥处理外，还对pthread_cond进行了处理，同时提供了wait、signal、broadcase方法。

• NSConditionLock

  NSConditionLock底层没有直接操作pthread_mutex，见下图：

  

  但是实现中提供了一个NSCondition属性和一个pthread_t属性，通过这两个属性，实现加锁和线程方面的相关处理。

7.NSConditionLock分析

NSConditionLock也是一种条件锁，⼀旦⼀个线程获得锁，其他线程⼀定等待。

• 相关API

  • [xxxx lock]; 表示 xxx 期待获得锁，如果没有其他线程获得锁（不需要判断内部的condition) 那它能执⾏此⾏以下代码，如果已经有其他线程获得锁（可能是条件锁，或者⽆条件锁），则等待，直⾄其他线程解锁；
  • [xxx lockWhenCondition:A条件]; 表示如果没有其他线程获得该锁，但是该锁内部的condition不等于A条件，它依然不能获得锁，仍然等待。如果内部的condition等于A条件，并且没有其他线程获得该锁，则进⼊代码区，同时设置它获得该锁，其他任何线程都将等待它代码的完成，直⾄它解锁；
  • [xxx unlockWithCondition:A条件]; 表示释放锁，同时把内部的condition设置为A条件；
  • return = [xxx lockWhenCondition:A条件 beforeDate:A时间]; 表示如果被锁定（没获得锁），并超过该时间则不再阻塞线程。但是注意：返回的值是NO，它没有改变锁的状态，这个函数的⽬的在于可以实现两种状态下的处理。

• 案例分析

  引入一个案例来了解NSConditionLock。见下面代码：

  - (void)lg_testConditonLock{
  
      // 创建条件锁 - 需要满足条件2，否则不执行
      NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];
  
      dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
          [conditionLock lockWhenCondition:1];
  
          NSLog(@"线程 1");
  
          [conditionLock unlockWithCondition:0];
      });
  
      dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
          [conditionLock lockWhenCondition:2];
  
          sleep(0.1);
  
          NSLog(@"线程 2");
  
          [conditionLock unlockWithCondition:1];
      });
  
      dispatch_async(dispatch_get_global_queue(0, 0), ^{
         [conditionLock lock];
  
         NSLog(@"线程 3");
  
         [conditionLock unlock];
      });
  }
  复制代码

  上面的案例执行顺序是怎样的呢？运行结果见下图：

  

  关键是lockWhenCondition方法所起到的作用是什么！下面进行分析：

  • NSConditionLock创建时，设置的条件时2，也就是说需要满足条件2，否则不执行；
  • 线程 1调⽤[NSConditionLock lockWhenCondition:1]，此时因为不满⾜当前条件，所以会进⼊waiting状态，当前进⼊到waiting时，会释放当前的互斥锁；
  • 此时当前的线程 3调⽤[NSConditionLock lock:]，本质上是调⽤[NSConditionLock lockBeforeDate:]，这⾥不需要⽐对条件值，所以线程 3会打印；
  • 接下来线程 2执⾏[NSConditionLock lockWhenCondition:2]，因为满⾜条件值，所以线程 2会打印，打印完成后会调⽤[NSConditionLock unlockWithCondition:1],这个时候将value设置为1，并发送boradcast， 此时线程 1接收到当前的信号，唤醒执⾏并打印;
  • ⾃此当前打印为 线程 3->线程 2->线程 1；
  • [NSConditionLock lockWhenCondition:]：这⾥会根据传⼊的condition值和Value值进⾏对⽐，如果不相等，这⾥就会阻塞，进⼊线程池，否则的话就继续代码执⾏；
  • [NSConditionLock unlockWithCondition:]: 这⾥会先更改当前的value值，然后进⾏⼴播，唤醒当前的线程。

8.读写锁

• 概念理解

  读写锁实际是⼀种特殊的⾃旋锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进⾏读访问，写者则需要对共享资源进⾏写操作。

  这种锁相对于⾃旋锁⽽⾔，能提⾼并发性，因为在多处理器系统中，它允许同时有多个读者来访问共享资源，最⼤可能的读者数为实际的逻辑CPU数。写者是排他性的，⼀个读写锁同时只能有⼀个写者或多个读者（与CPU数相关），但不能同时既有读者⼜有写者。在读写锁保持期间也是抢占失效的。

  如果读写锁当前没有读者，也没有写者，那么写者可以⽴刻获得读写锁，否则它必须⾃旋在那⾥，直到没有任何写者或读者。如果读写锁没有写者，那么读者可以⽴即获得该读写锁，否则读者必须⾃旋在那⾥，直到写者释放该读写锁。

  ⼀次只有⼀个线程可以占有写模式的读写锁, 但是可以有多个线程同时占有读模式的读写锁. 正是因为这个特性,当读写锁是写加锁状态时, 在这个锁被解锁之前, 所有试图对这个锁加锁的线程都会被阻塞.当读写锁在读加锁状态时, 所有试图以读模式对它进⾏加锁的线程都可以得到访问权, 但是如果线程希望以写模式对此锁进⾏加锁, 它必须直到所有的线程释放锁.

  通常, 当读写锁处于读模式锁住状态时, 如果有另外线程试图以写模式加锁, 读写锁通常会阻塞随后的读模式锁请求, 这样可以避免读模式锁⻓期占⽤, ⽽等待的写模式锁请求⻓期阻塞.读写锁适合于对数据结构的读次数⽐写次数多得多的情况. 因为, 读模式锁定时可以共享, 以写模式锁住时意味着独占, 所以读写锁⼜叫共享-独占锁.

• API

  • pthread_rwlock_t lock; // 结构
  • pthread_rwlock_init(&lock, null); // 初始化
  • pthread_rwlock_rdlock(&lock); // 读加锁
  • pthread_rwlock_tryrdlock(&lock); // 读尝试加锁
  • pthread_rwlock_wdlock(&lock); // 写加锁
  • pthread_rwlock_trywdlock(&lock); // 写尝试加锁
  • pthread_rwlock_unlock(&lock); // 解锁
  • pthread_rwlock_destory(&lock); // 销毁

• pthread_rwlock_t的使用

  引入下面的案例，开启十个线程，同时进行读写操作， 要求：

  • 可以实现多读，多读不互斥
  • 单写，读写互斥
  • 写写互斥

  见下面实现：

  #import <Pthread.h>
  
  @interface ViewController ()
  
  @property (nonatomic, assign) NSUInteger ticketCount;
  @property (nonatomic,assign) pthread_rwlock_t lock;
  
  @end
  
  @implementation ViewController
  
  - (void)viewDidLoad {
      [super viewDidLoad];
      
      self.ticketCount = 0;
      [self rwTest];
  }
  
  - (void)rwTest {
      // 初始化
      pthread_rwlock_init(&_lock, NULL);
      // 全局队列
      dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
      // 开启读写
      for (int i = 0; i<10; i++) {
  
          dispatch_async(queue, ^{
              [self read];
          });
  
          dispatch_async(queue, ^{
              [self read];
          });
          
          // 写
          dispatch_async(queue, ^{
              [self write];
          });
      }
  }
  
  // 读流程
  -(void)read{
      // 读加锁
      pthread_rwlock_rdlock(&_lock);
  
      sleep(1);
      NSLog(@"读……%zd", self.ticketCount);
      
      // 解锁
      pthread_rwlock_unlock(&_lock);
  }
  
  // 写
  -(void)write{
      // 写加锁
      pthread_rwlock_wrlock(&_lock);
  
      sleep(1);
      NSLog(@"写……%zd", ++self.ticketCount);
  
      // 解锁
      pthread_rwlock_unlock(&_lock);
  }
  
  @end
  复制代码

  运行结果见下图：

  

  通过上面的案例可以反映出读写锁同时只能有⼀个写者，并且可以保证多读同时进行。

• GCD栅栏函数的使用

  通过栅栏函数也可以满足以上的需求。

  #import <pthread.h>
  @interface ViewController ()
  @property (nonatomic, assign) NSUInteger ticketCount;
  // 并发队列-多读
  @property (nonatomic, strong) dispatch_queue_t qCONCURRENT;
  // 串行队列-限制读取顺序
  @property (nonatomic, strong) dispatch_queue_t qSERIAL;
  @end
  
  @implementation ViewController
  
  - (void)viewDidLoad {
      [super viewDidLoad];
  
      self.ticketCount = 0;
  
      // 队列初始化
      self.qCONCURRENT = dispatch_queue_create("selfCONCURRENT", DISPATCH_QUEUE_CONCURRENT);
  
      self.qSERIAL = dispatch_queue_create("selfSERIAL", DISPATCH_QUEUE_SERIAL);
  
      [self go_testReadWrite];
  }
  
  - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event{
      // 写  栅栏函数，保证读写的互斥
      dispatch_barrier_async(self.qCONCURRENT, ^{
          [self writeAction];
      });
  }
  
  #pragma read wirte
  - (void)go_testReadWrite{
      // 多线程读
      for (int i = 0; i < 2000; i++) {
          dispatch_async(self.qCONCURRENT, ^{
              [self readAction];
          });
  
          dispatch_async(self.qCONCURRENT, ^{
              [self readAction];
          });
  
          dispatch_async(self.qCONCURRENT, ^{
              [self readAction];
          });
      }
  }
  
  - (void)readAction {
  
      // 保证读取顺序
      dispatch_async(self.qSERIAL, ^{
          sleep(1);
          NSLog(@"读 ..... %ld ------ %@", self.ticketCount, [NSThread currentThread]);
      });
  }
  
  - (void)writeAction {
      sleep(1);
      NSLog(@"写 ..... %ld ------ %@", ++self.ticketCount, [NSThread currentThread]);
  }
  
  复制代码

  运行结果见下图：