锁

多线程中，锁大部分可以分成两种，互斥锁与自旋锁。

互斥锁 Mutex
互斥锁也称互斥量，属于sleep-waiting类型的锁，当线程访问被锁资源时，调用者线程会休眠，此时cpu可以调度其他线程工作。直到被锁资源释释放锁。此时会唤醒休眠线程。互斥锁的加锁与解锁操作回设计系统线程的调度与上下文切换。
自旋锁 Spinlock
属于busy-wait 类型的锁,调用者线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。一旦获取了自旋锁，线程会一直保持该锁，直至显式释放自旋锁。自旋锁会比互斥锁更加消耗CPU，自旋锁的效率也会比互斥锁更高。
死锁
两个运行单元都在等待对方停止运行，以获取系统资源，但是没有一方提前退出时，就称为死锁
加锁与解锁
加锁其实就是获得锁，获得这个这个资源的访问权限，解锁就是释放锁，其他线程就可以访问。

iOS的锁

在iOS中，实现锁有多种方式，一般有

@synchronized 同步代码块

@synchronized(self) {//入参self为所要保护的对象，内部其实是一个递归锁
// task
}

@synchronized可以很方便就给对象加锁，不用再额外声明锁，手动加锁和释放锁。需要保护的代码写在block即可，但是效率较慢。

NSLock 对象锁

  NSLock *mutexLock = [[NSLock alloc] init];
  [mutexLock lock];
  //task
  [mutexLock unlock];

NSRecursiveLock 递归锁
NSLock在递归中容易产生死锁，使用NSRecursiveLock可以避免这个问题，NSRecursiveLock可以在被同一线程重复获取时不会产生死锁。
NSConditionLock 条件锁
满足预设的条件，就可以获取锁
OSSpinLock 自旋锁
一般的互斥锁没有拿到锁之前，线程都会休眠，而自旋锁不会引起调用者线程休眠，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁。
pthread_mutex C语言实现的互斥锁

从效率上看，自然是OSSpinLock自旋锁的效率最高，执行耗时最小，但是OSSpinLock会出现优先级反转的问题，目前OSSpinLock的内部实现已经被os_unfair_lock代替。等待os_unfair_lock锁的其他线程会处于休眠状态，而并非忙等。

需要注意的是，iOS中的锁目前按照功能来分基本是两种，自旋锁和互斥锁，其他的锁基本本质是互斥锁，大体都是封装pthread_mutex而来。

typedef int32_t OSSpinLock OSSPINLOCK_DEPRECATED_REPLACE_WITH(os_unfair_lock);

image.png

优先级反转

在 iOS 中,高优先级high priority线程始终会在低优先级(low priority )线程前执行，一个线程不会受到比它更低优先级low priority线程的干扰。具体来说，如果一个低优先级的线程获得锁并访问共享资源，这时一个高优先级high priority的线程也尝试获得这个锁，它会处于 spin lock 的忙等状态从而占用大量 CPU。此时低优先级线程无法与高优先级线程争夺 CPU 时间片，从而导致任务迟迟完不成、无法释放 lock。除非开发者能保证访问锁的线程全部都处于同一优先级，否则 iOS 系统中所有类型的自旋锁都不能再使用了。

CPU调度

一般来说线程是程序执行的最小单元，一个线程包括：独有ID，程序计数器，寄存器集合，堆栈。同一进程可以有多个线程，它们共享进程的全局变量和堆数据。CPU的核心在同一个时刻只能执行一条线程，如果要执行的线程超过CPU的核心数时，就需要线程调度，简单来说就是：一个 CPU 核心轮流让各个线程分别执行一段时间。上一点所述，在线程调度里面，高优先级的线程会优先获得CPU时间片。线程调度还有其他算法，如FIFO，先排队的线程获得运行的CPU时间片。CPU调度使得等待的线程可以运行，这样的切换同时也会伴随着上下文的切换（寄存器数据、栈等），过多的上下文切换会带来资源开销。

公平锁与非公平锁

上述所说替换自旋锁OSSpinLock的os_unfair_lock，其实是非公平锁，平时使用的锁基本都是公平锁，这一类锁有着FIFO的特性,
多个线程情况下排队，先到先获得锁。如果进入等待的顺序为12345，则最后等待结束被执行的顺序也是12345。但是如果使用的是非公平锁，前面的任务马上要执行完毕，若释放锁的时候，正好一个新的线程6来访问资源，而此时位于队列头的线程1还没有被唤醒（因为线程上下文切换是需要不少开销的），此时后来的线程6则优先获得锁，成功打破公平，成为非公平锁。但是如果线程6来访问时，锁不是刚好释放，或者线程1已经被唤醒，线程6还是得进入线程队列中休眠等待CPU的唤醒执行。

信号量（Semaphore）

信号量是一个同步对象，用于保持在0至指定最大值之间的一个计数值。当线程完成一次对该semaphore对象的等待（wait）时，该计数值（- 1）加锁；当线程完成一次对semaphore对象的释放（release）时，计数值（+ 1）释放锁。简单来说，信号量为0的时候，线程会阻塞，一直等待该信号量对象的计数值变成大于0的状态。

如在OC中，
关于信号量主要有三个函数：

dispatch_semaphore_create(long value);
创建信号量，参数为设置信号量的初始值
dispatch_semaphore_signal(dispatch_semaphore_t dsema);
发送当前信号量，参数为当前创建的信号量
dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);
等待信号量，第一个为当前等待的信号量，第二个参数为超时时间。当等待时间超过超时时间就不会继续等待了。

信号量是一个整型值，在创建的时候会有一个初始值。当执行dispatch_semaphore_signal发送信号的时候信号量会加1，dispatch_semaphore_wait在信号量小于或等于0的时候会一直等待，直到超时，并且会阻塞该线程，当信号量大于0时会继续执行并对信号量执行减1操作。

  dispatch_queue_t queue = 
  dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
  dispatch_semaphore_t lock = dispatch_semaphore_create(0);//信号量初始为0
  dispatch_async(queue, ^{
      // task1
      dispatch_semaphore_signal(lock);// 使信号量+1并返回
  });
  dispatch_semaphore_wait(lock, DISPATCH_TIME_FOREVER);//堵塞当前线程，等待task1结束，信号量加1，释放锁。
  // task2 
  //只有当task1执行完,信号量+1之后,才会执行这里

数值为N的信号量允许N个线程并发访问。

如果信号量是一个任意的整数，通常被称为计数信号量（Counting semaphore），或一般信号量（general semaphore）；如果信号量只有二进制的0或1，称为二进制信号量（binary semaphore）。在linux系统中，二进制信号量（binary semaphore）又称互斥量（Mutex）。

所以说，互斥量和信号量本质上一样，都是用来表示对资源的访问权，但是互斥量表示资源某个时刻最多只能被一个线程占用，也就是资源计数最多是1，而信号量的资源计数可以超过1，即同时被多个线程占用。

两者对比的话，简单来说，

互斥量就是N个线程，争夺一把锁，
信号量就是N个线程，争夺M把锁，当信号量的计数值只有0、1（二进制信号量），那么M = 1，这时候，和互斥量的性质是一样的。

信号量死锁问题

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    [self testSemaphore];
}

/// 主线程运行
- (void)testSemaphore
{
    NSLog(@"1");
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
            dispatch_async(dispatch_get_main_queue(), ^{//主线程
                sleep(1);
                NSLog(@"2");
                dispatch_semaphore_signal(semaphore);
            });
    NSLog(@"3");
    //堵塞当前线程
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    NSLog(@"4");
}

这时候输出

2021-05-15 23:28:12.156395+0800 TestProject[10564:1787212] 1
2021-05-15 23:28:12.156641+0800 TestProject[10564:1787212] 3

就死锁了，两个运行单元出现互相等待的情况。因为dispatch_semaphore_wait卡主了主线程，而dispatch_async(dispatch_get_main_queue()又是在主线程中运行，需要等里面的block运行结束，信号量+1，释放锁后，wait才会结束。解决这个问题，可以把避免在主线程中执行Block，或者wait的时间可以手动设置短一些。

参考文章

https://zh.wikipedia.org/wiki/%E4%BF%A1%E8%99%9F%E6%A8%99
https://blog.ibireme.com/2016/01/16/spinlock_is_unsafe_in_ios/

多线程的锁与信号量

锁