线程安全/锁的机制及适用场景

互斥锁：mutex，用于保证在任何时刻，都只能有一个线程访问该对象。当获取锁操作失败时，线程会进入睡眠，等待锁释放时被唤醒 


自旋锁：spinlock，在任何时刻同样只能有一个线程访问对象。但是当获取锁操作失败时，不会进入睡眠，而是会在原地自旋，直到锁被释放。这样节省了线程从睡眠状态到被唤醒期间的消耗，在加锁时间短暂的环境下会极大的提高效率。但如果加锁时间过长，则会非常浪费CPU资源 


读写锁：rwlock，区分读和写，处于读操作时，可以允许多个线程同时获得读操作。但是同一时刻只能有一个线程可以获得写锁。其它获取写锁失败的线程都会进入睡眠状态，直到写锁释放时被唤醒。 
注意：写锁会阻塞其它读写锁。当有一个线程获得写锁在写时，读锁也不能被其它线程获取；写优先于读，当有线程因为等待写锁而进入睡眠时，则后续读者也必须等待 
适用于读取数据的频率远远大于写数据的频率的场合。 


RCU：即read-copy-update，在修改数据时，首先需要读取数据，然后生成一个副本，对副本进行修改。修改完成后，再将老数据update成新的数据。使用RCU时，读者几乎不需要同步开销，既不需要获得锁，也不使用原子指令，不会导致锁竞争，因此就不用考虑死锁问题了。而对于写者的同步开销较大，它需要复制被修改的数据，还必须使用锁机制同步并行其它写者的修改操作。在有大量读操作，少量写操作的情况下效率非常高 


信号量：semaphore，是用于线程间同步的，当一个线程完成操作后就通过信号量通知其它线程，然后别的线程就可以继续进行某些操作了。 


信号量和互斥锁的区别：

1. 信号量是用于线程间同步的，而互斥锁是用于线程的互斥的
2. 互斥量的获取和释放都是在同一线程中完成的，pthread_mutex_lock(),pthread_mutex_unlock()。而信号量的获得和释放是在不同的线程的操作为sem_wait(),sempost()；
3. 互斥量的值只能为0和1，而信号量只要value>0，其它线程就可以sem_wait成功，成功后信号量value减一。若value值不大于0，则sem_wait阻塞，直到sem_post释放后value加1。因此信号量的值可以为非负整数

==================================================

1. NSLock
   • NSLock是Cocoa提供给我们最基本的锁对象，这也是我们经常使用的，除lock和unlock外，NSLock还提供了tryLock和lockBeforeDate:两个方法，前一个方法会尝试加锁，如果锁不可用（已经被锁住），并不会阻塞线程，直接返回NO。后一个方法则会在指定的Date之前尝试加锁，如果在指定的时间内都不能加锁，则返回NO
2.  synchronized（互斥锁）
   • synchronized会创建一个异常捕获handler和一些内部的锁，所以使用@synchronized替换普通锁的代价是要付出更多的时间消耗
   • 创建给给@synchronized指令的对象是一个用来区别保护块的唯一标识符。如果你在两个不同的线程里面执行上述方法，每次在一个线程传递了一个不同的对象给anObj参数，那么每次都将会拥有它的锁，并持续处理，中间不会被其他线程阻塞。然而如果你传递的是同一个对象，那么多个线程中的一个线程会首先获得该锁，而其他线程将会被阻塞直到第一个线程完成它的临界区
   • 作为一个预防措施。@synchronized块隐式的添加一个异常处理例程来保护代码，该处理例程会在异常抛出的时候自动的释放互斥锁，这就意味着为了使用@synchronized指令，你必须在你的代码中启用异常处理。如果你不想让隐式的异常处理例程带来额外的开销，那么可以使用其他的锁
3. atomic
   • atomic只是给成员变量的set和get方法加了一个锁，防止多线程一直去读写这个成员变量。但这也仅仅是对读写的锁定，并不是线程安全。而且使用atomic比nonatomic慢了将近20倍
4. OSSpinlock
   • 自旋锁
   • 耗时最少
   • 自旋锁几乎不进入内核，仅仅是重新加载自旋锁
   • 如果自旋锁被占用时间在一百纳秒以内，性能还是比较高的，因为减少了代价较高的系统调用和一系列的上下文切换
   • 但是该锁不是万能的，如果该锁占用的时间比较多的时候，使用该锁会导致占用的cpu较多
5. pthread_mutex
   • 是底层的API，在各种加锁方式中属于性能比较高的
   • 如果自旋锁占用的时间比较多，那么使用pthread是一个不错的选择
6. NSConditionLock（条件锁）
   • 条件锁与特定的与用户定义的条件有关，它可以确保一个线程可以获取满足一定条件的锁
   • 内部涉及到信号量机制，一旦一个线程获取锁以后，它可以放弃锁并设置相关条件，这时候其他锁竞争该锁
   • 线程之间的竞争激烈，涉及到条件锁检测、线程间通信、系统调用，上下文切换比较频繁
7. NSRecursiveLock递归锁
   • NSRecursiveLock实际上定义的是一个递归锁，这个锁可以被同一线程多次请求，而不会引起死锁。这主要是用在循环或者递归操作中
8. 总结：
   • 如果只是粗略的使用锁，不考虑性能可以使用synchronized
   • 如果对效率有较高的要求，采用OSSpinLock
   • 因为pthread的锁也是使用OSSpinLock实现的，而且在OSSpinLock的实现过程中，并没有进入系统kernel，使用OSSpinLock可以节省系统调用和上下文切换
   • NSLock/NSConditionLock/NSRecursive耗时接近。220ms左右
   • dispatch_barrier_async的性能并没有我们想象中的纳闷好，这与线程同步调度开销有关