为什么要有锁？

在使用多线程的时候多个线程可能会访问同一块资源，这样就很容易引发数据错乱和数据安全等问题，这时候就需要我们保证每次只有一个线程访问这一块资源，锁应运而生。

上锁的方式

一般的锁都会提供trylock和lock两种。trylock会返回上锁是否成功。

lock一般在接下来的代码必须上锁才能进行。没必要用trylock知道上锁是否成功。

trylock一般在锁失败也能继续执行一些操作时使用

自旋锁与互斥锁都能保证同一时间只有一个线程访问共享资源。都能保证线程安全。

自旋锁与互斥锁的区别：

互斥锁：如果共享数据已经有其他线程加锁了，线程会进入休眠状态等待锁。一旦被访问的资源被解锁，则等待资源的线程会被唤醒。

自旋锁：如果共享数据已经有其他线程加锁了，线程会以死循环的方式等待锁，一旦被访问的资源被解锁，则等待资源的线程会立即执行。

自旋锁的效率高于互斥锁。

1.OSSpinLock（自旋锁）

OSSpinLock已经不再线程安全,OSSpinLock有潜在的优先级反转问题。不再安全的 OSSpinLock

导入头文件：#import<libkern/OSAtomic.h>

下面是OSSpinLock使用的代码，由于已经被废弃，所以代码基本上都是警告的

运行之后的打印情况如下

可以发现在锁住线程1时，线程2是等线程1完全执行完再执行的。

OS_SPINLOCK_INIT：默认值为0,在locked状态时就会大于0，unlocked状态下为0

OSSpinLockLock(&oslock)：上锁，参数为OSSpinLock地址

OSSpinLockUnlock(&oslock)：解锁，参数为OSSpinLock地址

OSSpinLockTry(&oslock)：尝试加锁，可以加锁则立即加锁并返回YES,反之返回NO

2.dispatch_semaphore 信号量

初始化信号量为1个的时候，代码如下：

执行代码的结果如下：

初始化信号量为2个的时候，修改创建信号量的代码如下

dispatch_semaphore_t signal = dispatch_semaphore_create(2);

运行结果如下：

初始化信号量为0个的时候，修改创建信号量的代码如下

dispatch_semaphore_t signal = dispatch_semaphore_create(0);

运行结果如下：

先解释下代码的意思

dispatch_time_t：dispatch_time(DISPATCH_TIME_NOW, (int64_t)3* NSEC_PER_SEC);该方法中第一个参数表示从什么时候开始，第二个参数表示具体的时间长度

dispatch_semaphore_create(1)：传入值必须>=0, 若传入为0则阻塞线程并等待timeout,时间到后会执行其后的语句

dispatch_semaphore_wait(signal, overTime)：可以理解为lock,会使得signal值-1

dispatch_semaphore_signal(signal)：可以理解为unlock,会使得signal值+1

参考iOS 开发中的八种锁（Lock）对信号量的比喻

停车场剩余4个车位，那么即使同时来了四辆车也能停的下。如果此时来了五辆车，那么就有一辆需要等待。

信号量的值（signal）就相当于剩余车位的数目，dispatch_semaphore_wait函数就相当于来了一辆车，dispatch_semaphore_signal就相当于走了一辆车。停车位的剩余数目在初始化的时候就已经指明了（dispatch_semaphore_create（long value）），调用一次 dispatch_semaphore_signal，剩余的车位就增加一个；调用一次dispatch_semaphore_wait 剩余车位就减少一个；当剩余车位为 0 时，再来车（即调用 dispatch_semaphore_wait）就只能等待。有可能同时有几辆车等待一个停车位。有些车主没有耐心，给自己设定了一段等待时间，这段时间内等不到停车位就走了，如果等到了就开进去停车。而有些车主就像把车停在这，所以就一直等下去。

通过上面三种情况下的运行结果可以发现：

当信号量的值为1时在线程1中执行了dispatch_semaphore_wait(signal, overTime);后会把线程1dispatch_semaphore_signal(signal);之前的代码执行完再去执行线程2中的代码。

当信号量的值为2时会切换执行线程1，2的代码。

当信号量为0时会先被阻塞设置的三秒钟，然后切换执行线程1，2。

AFNetworking中对于dispatch_semaphore_t的使用

dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);//创建信号量

//这个block中的代码会在子线程运行

[self.session getTasksWithCompletionHandler:^(NSArray *dataTasks, NSArray *uploadTasks, NSArray *downloadTasks) {

if ([keyPath isEqualToString:NSStringFromSelector(@selector(dataTasks))]) {

tasks = dataTasks;

} else if ([keyPath isEqualToString:NSStringFromSelector(@selector(uploadTasks))]) {

tasks = uploadTasks;

} else if ([keyPath isEqualToString:NSStringFromSelector(@selector(downloadTasks))]) {

tasks = downloadTasks;

} else if ([keyPath isEqualToString:NSStringFromSelector(@selector(tasks))]) {

tasks = [@[dataTasks, uploadTasks, downloadTasks] valueForKeyPath:@"@unionOfArrays.self"];

}

//当操作完子线程之后在字线程中直接释放信号量，不再等待，主线程继续执行

dispatch_semaphore_signal(semaphore);

}];

//因为创建了0的信号量，在这边设置永远等待，导致主线程中等待之后的代码都不会执行，此时去执行子线程

dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);

这样做的原因：

因为getTasksWithCompletionHandler：是系统方法，方法中的代码一定会在子线程执行，这样做可以阻断主线程，防止在读取数据的过程中发生数据的改变。

3.pthread_mutex(互斥锁)

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

代码:

运行结果：

pthread_mutex的用法基本与OSSpinLock差不多，pthread_mutex的pthread_mutex_trylock();方法锁成功时，返回的是0。

4.pthread_mutex(recursive)(递归锁)

一般的锁，lock和unlock是成对出现的，同一线程中不能多次进行lock操作，而递归锁允许同一个线程在未释放其拥有的锁时反复对该锁进行加锁操作。

例子如下：

执行后的运行结果如下图：

可以发现代码在运行时先进行了五次上锁操作，等递归完之后再进行了五次解锁。若是把锁换成pthread_mutex，修改代码如下：

执行结果如下：

可以发现在执行第二次上锁时代码不再继续执行。

5.NSLock

使用方法：

lock：上锁

unlock：解锁

trylock：能加锁返回 YES 并执行加锁操作，不能加锁返回 NO

lockBeforeDate：在传入的时间内尝试加锁，若能加锁则执行加锁操作并返回 YES，不能加锁返回 NO

例子：

示例代码

打印结果

在这个例子中由于在线程一中先上锁了，但是线程1在上锁之后进入了1秒钟的休眠，此时先去执行了线程2，所以线程2上锁失败了。线程3由于在两秒之后加锁的，此时线程1中已经解锁，所以线程3加锁成功。

6.NSCondition

NSCondition的API如下

wait：进入等待状态，在进入等待状态后会对当前线程解锁

waitUntilDate:：让一个线程等待到某一个时间

signal：（信号）唤醒一个等待的线程

broadcast：（广播）唤醒所有等待的线程

例子一：

线程一中调用wait方法

把第一个线程中的[cLock wait]该行代码去掉后，打印结果如下：

在第一种情况下会发现线程2能正常执行，线程1在调用wait方法之前的代码都能执行，wait方法之后的由于没有变唤醒就无法执行。

第二种情况下线程1的所有代码都被执行，但是线程2在上锁之后的代码无法被执行，出现了死锁情况。

由此得出结论wait方法中包含了unlock操作。把wait方法换成waitUntilDate结果也相同。

例子二：等待3秒执行线程

在这个例子中线程一调用了waitUntilDate方法后，线程1在上锁成功后3秒打印。

这个方法中可以看到线程1上锁成功后没调用unlock之前线程2的代码还是被执行了，也验证了上面的观点，实际实验中去掉 [clock lock]和[clock unlock]得出的结论一样。

例子三：唤醒一个等待的线程

当调用两次[cLock signal]方法后两个线程都会执行，只调用一次应该是按顺序唤醒一个线程（多次测试中打印的都是线程1）。

当去掉第一个线程的[clock unlock]，并且调用两次[cLock signal]时，会发现只执行第一个线程。跟上面得出的结论有所区别，所以猜测当线程从等待到被唤醒时会默认加上锁。

7.NSRecursiveLock

这也是一个递归锁。递归锁可以被同一线程多次上锁，而不会引起死锁。这主要是用在循环或递归操作中。

使用方式和pthread_mutex(recursive)类似，代码如下

运行结果

若把NSRecursiveLock换成NSLock后执行一次打印就无法继续打印，出现了死锁。

NSRecursiveLock 方法里还提供了两个方法，用法跟上面的相同

- (BOOL)tryLock;

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

8.@synchronized

@synchronized(obj)指令使用的obj为该锁的唯一标识，只有当标识相同时，才为满足互斥。@synchronized指令实现锁的优点就是我们不需要在代码中显式的创建锁对象，便可以实现锁的机制，但作为一种预防措施，@synchronized块会隐式的添加一个异常处理例程来保护代码，该处理例程会在异常抛出的时候自动的释放互斥锁。如果obj传入nil，则锁是无效的。

用self做为锁对象

打印结果

由上述测试可以看出线程1在@synchronized代码块中执行时，线程2无法继续执行。等线程1中的@synchronized代码块执行完后才开始继续执行线程2。

当把锁对象换成nil（@synchronized(nil)）或者线程1，2使用不同锁对象时线程1，2会同时执行。

9.NSConditionLock 条件锁

用法跟NSLock差不多，多了一个Condition参数，可以理解为一个条件标示。

NSConditionLock的API：

condition属性：外部传入的condition与当前对象的condition相同才会获取到lock对象，反之阻塞当前线程，直到condition相同

- (void)lockWhenCondition:(NSInteger)condition; condition与内部相同才会获取锁对象并立即返回，否则阻塞线程直到condition相同

- (BOOL)tryLock;尝试获取锁对象，获取成功需要配对unlock

- (void)unlockWithCondition:(NSInteger)condition; //解锁，并且设置lock.condition = condition

condition的默认值为0，所以第一次上锁时若传condition值，则值必须为0。