线程锁

2020-07-09 本文已影响0人六横六竖亚

多线程下为了访问安全，对同一块资源按照顺序进行的线程同步技术，加锁最常见。

申请锁的操作为原子操作，保证只有一个线程在申请锁。

原理：执行do-while循环，忙等，不切线程，适合小的等待操作，效率最高。

缺点：1、递归调用可能死锁；2、其他线程未获得锁的情况下一直自旋占用CPU；3、多线程下的优先级反转问题（低优先级线程先获得锁，高优先级线程循环忙等申请锁占用大量CPU，低优先级线程无法争抢到资源导致无法完成任务释放锁）

注：iOS10下推出os_unfair_lock_t来代替，线程会进入休眠而非忙等。

原理和信号量类似，遇锁时让出时间片进入休眠，等待上下文切换唤醒，由于系统切换上下文需要时间，所以比较适合等待时间较长的场景（如果等待时间较短，忙等比休眠更高效且不消耗CPU资源）。总体性能仅次于自旋锁和信号量。

NORMAL普通锁：等待队列，先进先出获得锁。

ERRORCHECK检错锁（NSLock）：同一个线程请求锁会返回错误防止嵌套死锁，其他线程访问同普通锁。

RECURSIVE递归锁（NSRecursiveLock）：允许同一线程多次获得锁和多次unlock解锁，要一一对应。

DEFAULT适应锁：锁释放后重新竞争，没有等待队列。

互斥锁和自旋锁的比较

自旋锁会产生优先级反转，用互斥锁会比较安全。

自旋锁在循环等待的时候会消耗cpu的性能。

互斥锁在cpu线程调度的时候会消耗cpu性能。

所以：互斥锁，比较适合临界代码比较耗时间的，如有网络阻塞、IO阻塞的情况。自旋锁，因为一直消耗cpu，所以一般比较适合临界代码比较少的，比较适合短时间操作的，如从mutable对象里面(dictioanry array hashtable) 读写操作的情况。

GCD的一种同步方式，采用信号量的实现原理加锁，性能第二。

signal = dispatch_semaphore_create(long value > 0) //创建信号量

dispatch_semaphore_signal(signal) //传入的信号量+1

dispatch_semaphore_wait(signal, timeout) //信号量>0则执行代码，并信号量-1；若=0则进入wait；wait过程中执行了dispatch_semaphore_signal，则继续执行；如果wait直到timeOut，也会继续执行。

注：互斥锁和信号量的区别？互斥锁主要对资源加锁，信号量更偏向于流程的概念，可以跨线程。

@synchronize(self) { //lock，do Something }

传入对象作为标记，Runtime为对象创建一个递归锁存在hash表中。牺牲性能，提供可读性和用法便利。

底层实现：get方法（objc_getProperty）、set方法（reallySetProperty）内，用了spinlock_t（其实底层用了mutex_t互斥锁替换以前的自旋锁）锁进行加锁解锁操作。

注：atomic一定线程安全吗？否。因为只锁了get、set方法，只保证进入时安全，不保证多线程访问下的资源安全。