多线程，作为实现软件并发执行的一个重要的方法，也开始具有越来越重要的地位！
正式因为多线程能够在时间片里被CPU快速切换，造就了以下优势
- 资源利用率更好
- 程序设计在某些情况下更简单
- 程序响应更快
但是并不是非常完美，因为多线程常常伴有资源抢夺的问题，作为一个高级开发人员并发编程那是必须要的，同时解决线程安全也成了我们必须要要掌握的基础
原子操作
自旋锁其实就是封装了一个spinlock_t自旋锁
自旋锁：如果共享数据已经有其他线程加锁了，线程会以死循环的方式等待锁，一旦被访问的资源被解锁，则等待资源的线程会立即执行。自旋锁下面还会展开来介绍
互斥锁：如果共享数据已经有其他线程加锁了，线程会进入休眠状态等待锁。一旦被访问的资源被解锁，则等待资源的线程会被唤醒。
下面是自旋锁的实现原理：
这里有一篇关于原子性的比较有意思的文章，这里也贴出来，大家可以一起交流讨论
为什么说atomic有时候无法保证线程安全呢？
不再安全的 OSSpinLock
操作在底层会被编译为汇编代码之后不止一条指令，因此在执行的时候可能执行了一半就被调度系统打断，去执行别的代码，而我们的原子性的单条指令的执行是不会被打断的，所以保证了安全.
自旋锁的BUG
尽管原子操作非常的简单，但是它只适合于比较简单特定的场合。在复杂的场合下，比如我们要保证一个复杂的数据结构更改的原子性，原子操作指令就力不从心了，
如果临界区的执行时间过长，使用自旋锁不是个好主意。之前我们介绍过时间片轮转算法，线程在多种情况下会退出自己的时间片。其中一种是用完了时间片的时间，被操作系统强制抢占。除此以外，当线程进行 I/O 操作，或进入睡眠状态时，都会主动让出时间片。显然在 while 循环中，线程处于忙等状态，白白浪费 CPU 时间，最终因为超时被操作系统抢占时间片。如果临界区执行时间较长，比如是文件读写，这种忙等是毫无必要的
下面开始我们又爱又恨的锁
iOS锁
锁并是一种非强制机制，每一个现货出呢个在访问数据或资源之前视图获取(Acquire)锁，并在访问结束之后释放(Release)锁。在锁已经被占用的时候试图获取锁，线程会等待，知道锁重新可用！
信号量
二元信号量(Binary Semaphore)只有两种状态：占用与非占用。它适合被唯一一个线程独占访问的资源。当二元信号量处于非占用状态时，第一个试图获取该二元信号量的线程会获得该锁，并将二元信号量置为占用状态，伺候其他的所有试图获取该二元信号量的线程将会等待，直到该锁被释放
现在我们在这个基础上，我们把学习的思维由二元->多元的时候，我们的信号量由此诞生，多元信号量简称信号量
- 将信号量的值减1
- 如果信号量的值小于0，则进入等待状态，否则继续执行。访问玩资源之后，线程释放信号量，进行如下操作
- 将信号量的值加1
- 如果信号量的值小于1，唤醒一个等待中的线程
互斥量
互斥量(Mutex)又叫互斥锁和二元信号量很类似，但和信号量不同的是，信号量在整个系统可以被任意线程获取并释放；也就是说哪个线程锁的，要哪个线程释放锁。
具体详细的用法可以参考：常见锁用法
Mutex可以分为递归锁(recursive mutex)和非递归锁(non-recursive mutex)。 递归锁也叫可重入锁(reentrant mutex)，非递归锁也叫不可重入锁(non-reentrant mutex)。
二者唯一的区别是：
- 同一个线程可以多次获取同一个递归锁，不会产生死锁。
- 如果一个线程多次获取同一个非递归锁，则会产生死锁。
NSLock 是最简单额互斥锁！但是是非递归的！直接封装了pthread_mutex 用法非常简单就不做赘述
@synchronized 是我们互斥锁里面用的最频繁的，但是性能最差！
底层clang
我们发现objc_sync_enter函数是在try语句之前调用，参数为需要加锁的对象。因为C++中没有try{}catch{}finally{}语句，所以不能在finally{}调用objc_sync_exit函数。因此objc_sync_exit是在_SYNC_EXIT结构体中的析构函数中调用，参数同样是当前加锁的对象。这个设计很巧妙，原因在_SYNC_EXIT结构体类型的_sync_exit是一个局部变量，生命周期为try{}语句块，其中包含了@sychronized{}代码需要执行的代码，在代码完成后，_sync_exit局部变量出栈释放，随即调用其析构函数，进而调用objc_sync_exit函数。即使try{}语句块中的代码执行过程中出现异常，跳转到catch{}语句，局部变量_sync_exit同样会被释放，完美的模拟了finally的功能。
