多线程如果等待锁的线程优先级较高，它会一直占用着 CPU 资源，优先级低的线程就无法释放锁，因为CPU的时间片会优先给高

常见的多线程方案

技术方案	简介	语言	线程生命周期	使用频率
pthread	通用的多线程API	C	程序员管理	几乎不用
NSThread	简单易用，可直接操作线程对象	OC	程序员管理	偶尔使用
GCD	充分利用设备的多核	C	自动管理	经常使用
NSOperation	基于GCD	OC	自动管理	经常使用

GCD 常用的函数

同步:dispatch_sync(dispatch_queue_t queue, dispatch_block_t block);
- queue:队列
  - 并发队列: dispatch_get_global_queue
  - 串行队列: dispatch_queue_create("myqueue", DISPATCH_QUEUE_SERIAL)
- block:任务
异步:dispatch_async(dispatch_queue_t queue, dispatch_block_t block)

同步和异步的区别主要是在当前线程执行任务，还是开辟新的线程执行任务

串行和并发的区别主要是是否能同时执行任务

配合performSelector需要注意的是当前线程是否被释放，以及 runloop是否被开启，及 runloop 中是否有任务（即有没有添加NSPort等事件来不让线程退出）
死锁问题：在同步队列中提交一个同步的任务，会产生相互等待

队列组的使用

异步并发执行任务1、任务2，等任务1、任务2都执行完成之后再执行任务3

let queue = DispatchQueue(label: "myqueue", attributes: .concurrent)
let group = DispatchGroup()
queue.async(group: group) {
    self.A()
}
queue.async(group: group) {
    self.B()
}

group.notify(queue: queue) {
    self.C()
}
group.notify(queue: queue) {
    self.D()
}

func A() {
    (0...5).forEach { (i) in
        print(i, Thread.current, "A")
    }
}

func B() {
    (0...5).forEach { (i) in
        print(i, Thread.current, "B")
    }
}

func C() {
    (0...5).forEach { (i) in
        print(i, Thread.current, "C")
    }
}

func D() {
    (0...5).forEach { (i) in
        print(i, Thread.current, "D")
    }
}

多线程安全隐患的解决方案

卖票问题
存钱问题
解决方案
- 使用线程同步技术
- 常见的线程同步技术就是加锁
- 死锁：永远也拿不到锁

iOS中的线程同步方案

OSSpinLock
- 自旋锁，等待锁的线程会处于忙等状态，一直占用着CPU资源
  - 这个跟 runloop 中的 run 很类似
- 这个锁在 iOS 10 之后就过期了
  - 'OSSpinLock' was deprecated in iOS 10.0: Use os_unfair_lock() from <os/lock.h> instead
  - 可能出现优先级反转的问题
  - blog.csdn.net/liaozhi85/a…
  - 如果等待锁的线程优先级较高，它会一直占用着 CPU 资源，优先级低的线程就无法释放锁，因为CPU的时间片会优先给高优先级的任务，所以高优先级的会一直在那里判断是不是解锁了，而导致CPU的时间片没有办法给到低优先级的线程去执行相应的任务。
os_unfair_lock
- 用于替代 OSSpinLock
- 互斥锁
- low-leve lock
pthread_mutex
- 互斥锁：等待锁的线程会处于休眠状态
- 递归锁：允许同一个线程对一把锁进行重复加锁
- 条件锁：
dispatch_semaphore
- 信号量的初值，可以用来控制线程并发访问的最大数量
- 信号量的初始值为1，代表同时只允许1条线程访问资源，保证线程同步
- 如果信号量的值 > 0，就让信号量的值减1，然后继续往下执行代码
- 互斥锁
```
创建锁
self.semaphore = dispatch_semaphore_create(1)
加锁
dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER)
解锁
dispatch_semaphore_signal(self.semaphore)
```
dispatch_queue(DISPATCH_QUEUE_SERIAL)
- queue.sync 表示在串行队列中同步执行任务，也就是一次只能执行一个任务，也就起到了锁的作用
NSLock
- 对 mutex 普通锁的封装
NSRecursiveLock
- 对 mutex 递归锁的封装
NSCondition
- 对 mutex 递归锁和 cond 的封装
NSConditionLock
- 对 NSCondition的封装
@synchronized
- 会生成 lock 对应的递归锁，然后进行加锁、解锁的操作
- 就是 mutex 递归锁的封装
- 从代码的角度来说他是最简单的方案
- 在 Swift 中已经不存在了，但是观察@synchronized的底层实现，其实就是调用了objc_sync_enter(lock)和objc_sync_exit(lock)方法
```
oc: 
@synchronized(lock) {
    
}

swift: 
objc_sync_enter(lock)
closure()
objc_sync_exit(lock)
```

自旋锁、互斥锁汇编分析

自旋锁：

libsystem_platform.dylib`_OSSpinLockLockSlow:
0x7fff5245b90b <+10>: jmp    0x7fff5245b91e            ; <+29>
->  0x7fff5245b90d <+12>: cmpl   $-0x1, %eax
    0x7fff5245b910 <+15>: jne    0x7fff5245b92d            ; <+44>
    0x7fff5245b912 <+17>: testl  %ecx, %ecx
    0x7fff5245b914 <+19>: je     0x7fff5245d29f            ; _OSSpinLockLockYield
    0x7fff5245b91a <+25>: pause  
    0x7fff5245b91c <+27>: incl   %ecx
    0x7fff5245b91e <+29>: movl   (%rdi), %eax
    0x7fff5245b920 <+31>: testl  %eax, %eax
    0x7fff5245b922 <+33>: jne    0x7fff5245b90d            ; <+12>

jne表示如果相等就跳转，所以他是一直在循环的询问锁是不是解开了

互斥锁：(这个汇编跟进去的流程远比上面的长，要耐心)

libsystem_kernel.dylib`__psynch_mutexwait:
    0x7fff523b84b8 <+0>:  movl   $0x200012d, %eax          ; imm = 0x200012D 
    0x7fff523b84bd <+5>:  movq   %rcx, %r10
->  0x7fff523b84c0 <+8>:  syscall 
    0x7fff523b84c2 <+10>: jae    0x7fff523b84cc            ; <+20>
    0x7fff523b84c4 <+12>: movq   %rax, %rdi
    0x7fff523b84c7 <+15>: jmp    0x7fff523b6a89            ; cerror_nocancel
    0x7fff523b84cc <+20>: retq

就是说没锁的时候，就会调用syscall，让线程休眠不做事了。

性能对比

os_unfair_lock > OSSpinLock > dispatch_semaphore > pthread_mutex > dispatch_queue > NSLock > NSCondition > pthread_mutex(recursive) > NSRecurisiveLock > NSConditionLock > @sychronizedii

锁的demo地址

自旋锁、互斥锁比较

什么情况使用自旋锁

预计线程等待锁的时间很短
加锁的代码被经常调用，但竞争不激烈
CPU资源不紧张
多核处理器

什么情况使用互斥锁比较划算

预计线程等待锁的时间较长，如有 I/O操作
加锁的代码复杂或者循环量大或者竞争激烈
单核处理器

atomic

给属性加上atomic修饰，可以保证属性的setter和getter都是原子性操作，也就是保证 setter 和 getter 内部是线程同步的，在 iOS 开发中一般不使用，因为太耗性能了，而在 macOS 中可以经常使用。而且他也不是性能安全的，同存安全，同写安全，同读同写不安全。

取值操作 - 赋值操作很接近
if (!atomic) return *slot;
spinlock_t& slotlock = PropertyLocks[slot]
slotlock.lock()
id value = objc_retain(*slot)
slotlock.unlock()

读写安全(多读单写如何实现)

需求：可以同时多个线程读取文件，但是只能一个线程修改，并且修改的时候不能读取。如果使用普通的锁，那么读取文件的时候也是要加锁的，这样的情况并不是很理想。

pthread_rwlock: 读写锁
- 等待锁的线程会进入休眠
dispatch_barrier_async:异步栅栏调用
- 传入的并发队列必须是自己创建的，而不能是通过global()获取的
- 如果传入的是一个串行或者是一个全局的并发队列，那这个函数和dispatch_async函数的效果相同

let queue = DispatchQueue(label: "myqueue", attributes: .concurrent)
func barrierlock() {
    (0...4).forEach { _ in
        Thread(target: self, selector: #selector(write3), object: nil).start()
        Thread(target: self, selector: #selector(read3), object: nil).start()
    }
}

@objc func read3() {
    queue.async {
        print("read", self.i)
    }
}

@objc func write3() {
    queue.sync(flags: .barrier) {
        self.i += 1
        print("write", i)
    }
}