synchronized, NSLock, 递归锁, 条件锁
图中锁的性能从高到底依次是：OSSpinLock(自旋锁) -> dispatch_semaphone（信号量） -> pthread_mutex（互斥锁） -> NSLock（互斥锁） -> NSCondition（条件锁） -> pthread_mutex（recursive 互斥递归锁） -> NSRecursiveLock（递归锁） -> NSConditionLock（条件锁） -> synchronized（互斥锁）
自旋锁(OSSpinLock, atomic) -> 线程会反复检查变量是否可用 -> 忙等待 ->
会一直保持该锁 ->对于线程只会阻塞很短时间的场合是有效的.
互斥锁 (@synchronized , NSLock, pthread_mutex) -> 多线程编程 -> 防止两条线程同时对同一公共资源（例如全局变量）进行读写的机制 ->将代码切成一个个临界区.
条件锁 (NSCondition, NSConditionLock) ->条件变量 -> 资源要求不满足 -> 进入休眠, 资源被分配到->条件锁打开.
递归锁(pthread_mutex(recursive), NSRecursiveLock) ->同一个线程可以加锁N次而不会引发死锁 -> 特殊的互斥锁，即是带有递归性质的互斥锁
信号量(dispatch_semaphore) -> 更高级的同步机制 -> 互斥锁可以说是semaphore在仅取值0/1时的特例 ->实现更加复杂的同步
读写锁(特殊的自旋锁) -> 特殊的自旋锁 -> 一个读写锁同时只能有一个写者或者多个读者
- OSSpinLock -> 自旋锁之所以不安全，是因为获取锁后，线程会一直处于忙等待，造成了任务的优先级反转。->废弃 -> os_unfair_lock (加锁,休眠)
- atomic -> reallySetProperty -> spinlock_t加锁 -> 底层调用os_unfair_lock加锁 -> 防止哈希冲突 -> 加盐
- synchronized ->objc_sync_enter和objc_sync_exit
- 哈希表 ->SyncList -> 多线程
- SyncData - >链表 ->当前可重入
- tls线程缓存, cache缓存
- lockCount, threadCount ->递归互斥锁
总结:
1.@synchronized -> 递归锁
2.@synchronized ->可重入(lockCount , threadCount) -> 可嵌套
3.@synchronized -> 链表
- 链表查询, 缓存查找以及递归 -> 耗内存 -> 耗性能 -> 性能低
- 方便简单, 不用解锁,使用频率高
- 不能对非OC对象加锁
- @synchronized (self) ->嵌套次数较少的场景 -> 锁住的对象也并不永远是self
8 嵌套次数较多 -> 锁self过多 -> 使用NSLock ,信号量
4. NSLock
NSLock -> 下层pthread_mutex的封装 -> 符号断点 -> Foundation ,但是不开源 ->借助Swift开源的Foundation分析
NSLock的性能仅次于pthead_mutex
5. pthread_mutex
互斥锁本身 -> 阻塞线程并睡眠
6. NSRecursiveLock
底层 -> pthread_mutex的封装 -> Swift的Foundation研究
NSLock 和 NSRecursiveLock底层几乎一样 ->NSRecursiveLock -> init -> 标识符PTHREAD_MUTEX_RECURSIVE
递归锁 -> 解决一种嵌套形式 -> 循环嵌套
7. NSCondition
条件锁 -> 锁和线程检查器
锁 -> 检查条件,保护数据源, 执行条件引发的任务
线程检查器 -> 根据条件是否运行线程
底层 -> Swift, Foundation -> pthread_mutex的封装
8. NSConditionLock
条件锁, 一个线程获得锁, 其他线程都要等待
NSConditionLock -> NSCondition + Lock
总结
OSSpinLock自旋锁由于安全性问题，在iOS10之后已经被废弃，其底层的实现用os_unfair_lock替代
使用OSSpinLock及所示，会处于忙等待状态
而os_unfair_lock是处于休眠状态
atomic原子锁自带一把自旋锁，只能保证setter、getter时的线程安全，在日常开发中使用更多的还是nonatomic修饰属性
atomic：当属性在调用setter、getter方法时，会加上自旋锁osspinlock，用于保证同一时刻只能有一个线程调用属性的读或写，避免了属性读写不同步的问题。由于是底层编译器自动生成的互斥锁代码，会导致效率相对较低
nonatomic：当属性在调用setter、getter方法时，不会加上自旋锁，即线程不安全。由于编译器不会自动生成互斥锁代码，可以提高效率
@synchronized在底层维护了一个哈希表进行线程data的存储，通过链表表示可重入（即嵌套）的特性，虽然性能较低，但由于简单好用，使用频率很高
NSLock、NSRecursiveLock底层是对pthread_mutex的封装
NSCondition和NSConditionLock是条件锁，底层都是对pthread_mutex的封装，当满足某一个条件时才能进行操作，和信号量dispatch_semaphore类似
锁的使用场景
如果只是简单的使用，例如涉及线程安全，使用NSLock即可
如果是循环嵌套，推荐使用@synchronized，主要是因为使用递归锁的 性能 不如 使用@synchronized的性能（因为在synchronized中无论怎么重入，都没有关系，而NSRecursiveLock可能会出现崩溃现象）
在循环嵌套中，如果对递归锁掌握的很好，则建议使用递归锁，因为性能好
如果是循环嵌套，并且还有多线程影响时，例如有等待、死锁现象时，建议使用@synchronized
