iOS开发中的各种锁

iOS开发中的各种锁

• OSSpinlock
• os_unfair_lock
• dispath_semaphore
• pthread_mutex
• pthread_rwlock
• pthread_cond
• NSCondition
• NSConditionLock
• NSLock
• NSCuresiveLock
• @synchronized

锁儿们

自旋锁

性能最高的锁。

原理：如果共享数据被其他线程加锁，那么当前线程会一死循环的方式等待解锁，一旦访问的资源被解锁，则等待线程就会立即执行。

由此可见，如果共享资源被锁了，线程不会进入等待状态，他会循环的锁的状态，所以实际上会消耗CPU的资源。

也就是说，在较为耗时的操作，并不适合使用自旋锁。比如：读写硬盘这种就不适合用自旋锁。而读写缓存，和内存可以是用自旋锁。

为什么自选锁的性能会比较高：

主动出让时间片（也就是互斥的做法）会导致操作系统切换到另外一个县城，这种上下文切换会通常占用10微妙左右的时间，来回调度起码就是两次。所以如果等待时间特别短，可能只有几个微妙，那么自旋锁的忙等明显要比互斥锁的休眠更加高效。

iOS的自旋锁：

• OSSpinlock:iOS10以后被废弃，因其不安全，有可能造成死锁。
• os_unfair_lock:iOS之后才可以使用，代替 OSSpinlock的方案

在iOS中线程优先级有五个（QoS）：

• QOS_CLASS_BACKGROUND
• QOS_CLASS_UTILITY
• QOS_CLASS_UTILITY
• QOS_CLASS_USER_INITATED
• QOS_CLASS_USER_INTERACTIVE

由上到下是低到高。

GCD是四个级别：

• Dispath_QUEUE_PRIORITY_HIGH

相当于 QOS_CLASS_USER_INITATED

• Dispath_QUEUE_PRIORITY_DEFAULT

相当于 QOS_CLASS_DEFAULT

• Dispath_QUEUE_PRIORITY_LOW

相当于 QOS_CLASS_UTILITY

• Dispath_QUEUE_PRIORITY_BACKGROUND

相当于 QOS_CLASS_BACKGROUND

OSSpinlock可能造成死锁的原因：

有可能在优先级比较低的线程里对共享资源进行加锁了，然后高优先级的线程抢占了低优先级的调用CPU时间，导致高优先级的线程一直在等待低优先级的线程释放锁，然而低优先级根本没法抢占高优先级的CPU时间。

这种情况我们称作 优先级倒转。

互斥锁：

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

互斥锁不会同时被两个不同的线程同时得到。也就是如果是当前线程加的锁，别的线程是没有办法获取这个锁，也就没有办法对他进行解锁。

iOS中的互斥锁

• pthread_mutex
• NSLock
• NSCuresiveLock
• @synchronized

互斥锁属性：

• PTHREAD_MUTEX_NORMAL 0：普通锁

当一个线程获得锁以后，其余请求锁的线程讲形成一个等待队列，并在解锁后按优先级获得锁。

• PTHREAD_MUTEX_ERRORCHECK 1:检错锁

如果同一个线程多次请求同一个锁，则返回错误，否则按照PTHREAD_MUTEX_NORMAL逻辑来

• PTHREAD_MUTEX_RECURSIVE 2：嵌套锁

允许同一个线程对同一个锁获得多次，也可以解锁多次。如果多个线程请求，也是需要等解锁之后才能竞争。

• PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL

读写锁

原理：允许多个线程同时对同一个数据进行读操作，而只允许一个线程进行写操作。这是因为读操作不会改变数据的内容，是安全的；而写操作会改变数据的内容，是不安全的。

iOS中的读写锁

• pthread_rwlock_t

条件锁

原理:进入等待，直到满足条件后执行。

iOS中的条件锁

• NSCondition
• NSConditionLock
• pthread_cond

信号量加锁

原理：多元信号量允许多个线程访问同一个资源，多元信号量简称信号量(Semaphore)，对于允许多个线程并发访问的资源，这是一个很好的选择。一个初始值为N的信号量允许N个线程并发访问。

其实严格的来说信号量不能算锁。

而且如果信号量设置为1，我们可以把它当作互斥锁来用

iOS中的信号量加锁

• dispatch_semaphore