iOS总结-锁(一)

参考:https://www.jianshu.com/p/8b8a01dd6356
在平时开发中，我们经常使用到多线程，但是同时会带来Data race .
而我们可以用到锁，我们在使用多线程的时候多个线程可能会被访问同一块资源，这样就很容易引发数据错乱和数据安全等问题，这时候就需要我们保证每次只有一个线程访问这一块资源，锁应运而生。
ibireme大神不在安全的OSSpinLock  中有关9种锁的性能在单线程进行了简单测试


 

看到除了OSSpinLock外，dispatch_semaphore和pthread_mutex的性能是最高的。
OSSpinLock

注释掉第一个线程OSSponLockUnlock(&oslock)

会发现当我们在锁住第一个线程后,线程2会一直等待(自旋锁不会让等待的进入睡眠状态),有时候线程1会自己解锁,跟着线程2就会立即执行.
dispatch_semaphore 信号量

可以看到执行的顺序，还是出现了不一样，但是一样的，是会阻塞另一个。
dispatch_semaphore_create(1): 传入>= 0 ,如果= 0 ,阻塞线程并等待timeout,时间到后会执行其后的语句
dispatch_semaphore_wait(signal,overTime): 可以理解为lock ,  使得signal -1
dispatch_semaphore_signal(signal)  可以理解为unlock, 使得signal +1
信号量可以通俗的解释为：信号量的值signal 是剩余车位的数目，dispatch_semaphore_wait 相当于来了一辆车，dispatch_semaphore_signal 相当于走了一辆车。 dispatch_semaphore_create() 调一次
dispatch_semaphore_signal 剩余车位增加一个， 调一次
dispatch_semaphore_wait 剩余车位的减少一个 ， 当剩余车位为0 ，再来车（dispatch_semaphore_wait）只能等待。有可能同时又几辆车等待一个车位，有些车主没有耐心，给自己设定一段等待时间，这段时间等不到停车位就走了，等到了开进去，而有些车主把车停着，一直等下去》
pthread_mutex

打印结果还会出现

这点很疑惑？
pthread_mutex(recursive)  pthread递归锁
加锁后只能有一个线程访问该对象,后面的线程需要排队,并且lock和unlock是对应出现的,同一线程多次lock是不允许的,而递归锁允许同一个线程在未释放其拥有的锁时反复对该锁进行加锁操作.


 

如果初始化时用pthread_mutex_init(&pLock,NULL)会出现死锁.

NSLock
经常用到这个加锁的,其中的方法有 lock/unlock , trylock:能加锁返回YES

 

NSCondition

唤醒一个等待线程

唤醒所有线程

NSRecursiveLock 递归锁

@synchronized

 

NSConditionLock条件锁

上面执行顺序,是按照当前condition的值,初始化为0 ,然后解锁后为1 , 再为3,有点串联执行的
NSConditionLock可以实现任务之间的依赖