iOS开发中的锁

在开发中当遇到一些耗时的操作时我们经常会开启一个子线程，这样来提升执行效率、避免主线程卡顿。但是使用子线程时会涉及到资源抢夺的问题，给要执行的代码加锁是问题的解决方式，下面就是iOS中各种锁的使用总结：

1、OSSpinLock以及属性里的automic // 自旋锁

已经不推荐使用。
是一把自旋锁，也就是在等待锁打开的这个线程，等待的原理是执行一个循环直到上一个线程执行完后把锁打开。这样的锁就会造成优先级反转问题，即如果高优先级的线程在锁外面等待，锁里面低优先级的正在执行的线程需要等高优先级线程先执行完.

automic使用的是哪个锁？iOS 中automic属性关键字使用的是什么锁？

2. os_unfair_lock

iOS10以后才能使用的，是OSSpinLock的替代方案。
有人通过代码的执行时的汇编推断它的原理是pthread_mutex互斥锁，这里不介绍了。

3、pthread_mutex// 互斥锁

是系统底层的API，通过设置属性可以形成普通互斥锁、递归锁(嵌套锁)、条件锁. 系统的很多锁是基于此封装的（NSLock\NSConditionLock\NSRecursive）
使用方法这里不列举，推荐根据情况使用封装好的API。

4、@synchronize// 对pthread_mutex递归锁的封装

使用方法是

   @synchronized (self /* 这里写一个每个线程来到这里时都一样的对象 */) {
        // 这里时要加锁执行的代码
    }

5、NSLock、NSRecursiveLock

NSLock它是对3中pthread_mutex普通锁的封装。使用很方便，调用lock和unlock方法即可。
NSRecursiveLock是对pthread_mutex递归锁的封装，它初始化时创建的是一把递归锁(：在同一个线程递归调用一个加了锁的方法时能够解开锁之后再加锁)。使用方法跟NSLock一样。下图是pthread_设置为递归锁。

pthread_递归锁.png

6、NSCondition、NSConditionLock

NSCondition是对pthread_mutex及其条件con的封装，是一种条件锁(：可以在加锁后的代码中判断条件，不成立可以调用wait等待，暂时把锁解开并且让本线程休眠，等到其它线程执行到条件成立时发送的signal信号时这里会重新加锁后执行)

NSCondition.png

NSConditionLock是可以设置具体条件的条件锁，使用方法与上面相似。

7、dispatch_semaphore// 信号量

dispatch_semaphore并不是锁，但是可以通过设置信号量来控制最大并发数为1（即同一时间只能有一个线程执行），以此达到加锁的效果。

总结：个人认为不考虑性能的条件下，使用NS开头的API来加锁。