【iOS】 锁
iOS 锁
文章目录
- iOS 锁
- 前言
- 线程安全
- 锁
- 互斥锁
- pthread_mutex
- @synchronized (互斥递归锁)
- @synchronized问题:
- 小结
- NSLock
- NSRecursiveLock
- NSCondition
- NSConditionLock
- 自旋锁
- OSSpinLock(已弃用)
- atomic
- atomic修饰的属性绝对安全吗?
- os_unfair_lock
- 读写锁
- 互斥锁和自旋锁的对比
- 小结
- 使用场景
前言
笔者在之前学习了有关于GCD的内容,今天来学习一下有关于锁的知识
常见的各类锁的性能比较:
从高到底依次是：OSSpinLock(自旋锁) -> dispatch_semaphone（信号量） -> pthread_mutex（互斥锁） -> NSLock（互斥锁） -> NSCondition（条件锁） -> pthread_mutex（recursive 互斥递归锁） -> NSRecursiveLock（递归锁） -> NSConditionLock（条件锁） -> synchronized（互斥锁）
线程安全
首先认识一下为什么要线程安全?
多个线程访问统一块资源的时候,很容易引起一个数据混乱问题.比方说下面这段代码:
__block int num = 0;while (num < 5) {dispatch_async(que, ^{num++;});
}
if (num >= 5) {NSLog(@"%ld", num);
}
这里就出现了一个数据的竞态的问题,我们最后输出的结果不会和我们的预期一致,我们想要的是一个当他大于5的时候就应该推出了,但是结果和我们想得不太一样.这里的输出结果是这个:
这里为什么会出现这个问题,是因为对于num这个致的操作不是原子性的,可能会出现多个线程同时访问到这个内存,当时都是3,然后每个线程各自给他加一导致了一个 + 3的效果,从而导致了一个线程问题.
可以理解为我们同时访问一个临界区的内容:然后让数据同时增加.
这里我们就引入了一个互斥访问的概念:
任意时刻只允许至多一个线程访问,从而保证一个线程的可以安全对于共享资源进行操作,从而解决这种临界区问题
解决方法可以看这个图片:
常见的解决临界区问题,用于一个同步计数就是加锁
锁
作用
锁最为一种非强制的机制,被用阿里保证线程安全,每一个线程在访问数据或者资源钱,要先获取锁,并在访问结束之后释放锁,如果锁已经被占用,其他想要获取锁的线程会等待知道锁重新可以使用
不要将过多的其他操作代码放到锁里面，否则一个线程执行的时候另一个线程就一直在等待，就无法发挥多线程的作用了
分类
在iOS中锁的基本种类只有两种：互斥锁、自旋锁 读写锁(其实是一种特殊的自旋锁)，其他的比如条件锁、递归锁、信号量都是上层的封装和实现
互斥锁
互斥锁防止两条线程同时对同一公共资源进行读写的机制.当获取锁操作失败的时候,线程会进入睡眠,等待锁释放时被唤醒
互斥锁(Mutual exclusion，缩写Mutex)防止两条线程同时对同一公共资源(比如全局变量)进行读写的机制。当获取锁操作失败时，线程会进入睡眠，等待锁释放时被唤醒:
- 递归锁:可重入锁,同一个线程在锁释放前可以再次获得锁,即可以递归调用
- 非递归锁:不可重入,必须等锁释放后才可以再次获取锁
pthread_mutex
pthread_mutex就是互斥锁本身——当锁被占用，而其他线程申请锁时，不是使用忙等，而是阻塞线程并睡眠.
// 导入头文件
#import <pthread.h>// 全局声明互斥锁
pthread_mutex_t _lock;// 初始化互斥锁
pthread_mutex_init(&_lock, NULL);// 加锁
pthread_mutex_lock(&_lock);
// 这里做需要线程安全操作
// 解锁
pthread_mutex_unlock(&_lock);// 释放锁
pthread_mutex_destroy(&_lock);
@synchronized (互斥递归锁)
- 开启汇编调试，发现
@synchronized在执行过程中，会走底层的objc_sync_enter和objc_sync_exit方法
int objc_sync_enter(id obj)
{int result = OBJC_SYNC_SUCCESS;if (obj) { // 传入不为nilSyncData* data = id2data(obj, ACQUIRE); //重点ASSERT(data);data->mutex.lock(); // 加锁} else { //传入nil// @synchronized(nil) does nothingif (DebugNilSync) {_objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");}objc_sync_nil();}return result;
}int objc_sync_exit(id obj)
{int result = OBJC_SYNC_SUCCESS;if (obj) { // obj不为nilSyncData* data = id2data(obj, RELEASE); if (!data) {result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;} else {bool okay = data->mutex.tryUnlock(); //解锁if (!okay) {result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;}}} else { //obj为nil时,什么也不做// @synchronized(nil) does nothing}return result;
}
通过上面两个实现逻辑的对比，发现它们有一个共同点，在obj存在时，都会通过id2data方法，获取SyncData
这时候看一下SyncData
typedef struct alignas(CacheLineSize) SyncData {struct SyncData* nextData; // 类似于链表的结构DisguisedPtr<objc_object> object; //锁住的对象int32_t threadCount; // number of THREADS using this blockrecursive_mutex_t mutex; // 递归锁
} SyncData;
typedef struct {SyncData *data;unsigned int lockCount; // number of times THIS THREAD locked this block
} SyncCacheItem;typedef struct SyncCache {unsigned int allocated;unsigned int used;SyncCacheItem list[0]; // 用于存储线程,其中当前的线程的链表data,用于存储SyncData和lockCount
} SyncCache;封装了recursive_mutex_t属性，可以确认@synchronized确实是一个递归互斥锁,然后可以看出他是一个一个链表的形式存储的,
然后之所以一个线程会需要多个SyncData是为了给对应的一个对象加上锁,实现一个对象记别的一个管理
这时候进入id2data方法(进入id2data源码，从上面的分析，可以看出，这个方法是加锁和解锁都复用的方法)
static SyncData* id2data(id object, enum usage why) //枚举值和锁住的对象传入
{spinlock_t *lockp = &LOCK_FOR_OBJ(object);SyncData **listp = &LIST_FOR_OBJ(object);SyncData* result = NULL;#if SUPPORT_DIRECT_THREAD_KEYS //(tls) 本地的局部线程缓存// Check per-thread single-entry fast cache for matching objectbool fastCacheOccupied = NO;//通过KVC方式对线程进行获取,线程绑定的dataSyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);//如果线程缓存中有data,执行if流程if (data) {fastCacheOccupied = YES;//如果在线程空间找到了dataif (data->object == object) {// Found a match in fast cache.uintptr_t lockCount;result = data;//通过KVC获取lockCount,lockCount用来记录被锁了几次,即该锁可嵌套lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);if (result->threadCount <= 0 || lockCount <= 0) {_objc_fatal("id2data fastcache is buggy");}switch(why) {case ACQUIRE: {//objc_sync_enter走这里，传入的是ACQUIRE -- 获取lockCount++;//通过lockCount判断被锁了几次,即表示 可重入tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);//设置break;}case RELEASE://objc_sync_exit走这里，传入的why是RELEASE -- 释放lockCount--;tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);if (lockCount == 0) {// remove from fast cache//移除快速缓存的部分tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);// atomic because may collide with concurrent ACQUIREOSAtomicDecrement32Barrier(&result->threadCount);}break;case CHECK:// do nothingbreak;}return result;}}
#endif// Check per-thread cache of already-owned locks for matching objectSyncCache *cache = fetch_cache(NO);//判断缓存中是否有该线程//如果cache中有,方法与线程缓存一致.if (cache) {unsigned int i;for (i = 0; i < cache->used; i++) { //遍历总表SyncCacheItem *item = &cache->list[i];if (item->data->object != object) continue;// Found a match.result = item->data;if (result->threadCount <= 0 || item->lockCount <= 0) {_objc_fatal("id2data cache is buggy");}switch(why) {case ACQUIRE: //加锁item->lockCount++;break;case RELEASE: // 解锁item->lockCount--;if (item->lockCount == 0) {// remove from per-thread cache//清楚cache中清楚标识cache->list[i] = cache->list[--cache->used];// atomic because may collide with concurrent ACQUIREOSAtomicDecrement32Barrier(&result->threadCount);}break;case CHECK:// do nothingbreak;}return result;}}// Thread cache didn't find anything.// Walk in-use list looking for matching object// Spinlock prevents multiple threads from creating multiple // locks for the same new object.// We could keep the nodes in some hash table if we find that there are// more than 20 or so distinct locks active, but we don't do that now.//第一次进入,所有缓存都找不到lockp->lock();{SyncData* p;SyncData* firstUnused = NULL;for (p = *listp; p != NULL; p = p->nextData) { //cache中找到了if ( p->object == object ) { //如果不等于空,且与object相同result = p; //赋值// atomic because may collide with concurrent RELEASEOSAtomicIncrement32Barrier(&result->threadCount);goto done;}if ( (firstUnused == NULL) && (p->threadCount == 0) )firstUnused = p;}// no SyncData currently associated with object//没有与当前对象关联的SyncDataif ( (why == RELEASE) || (why == CHECK) )goto done;// an unused one was found, use it//第一次进入,没有找到if ( firstUnused != NULL ) {result = firstUnused;result->object = (objc_object *)object;result->threadCount = 1;goto done;}}// Allocate a new SyncData and add to list.// XXX allocating memory with a global lock held is bad practice,// might be worth releasing the lock, allocating, and searching again.// But since we never free these guys we won't be stuck in allocation very often.posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData)); //创建赋值result->object = (objc_object *)object;result->threadCount = 1;new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);result->nextData = *listp;*listp = result;done:lockp->unlock();if (result) {// Only new ACQUIRE should get here.// All RELEASE and CHECK and recursive ACQUIRE are // handled by the per-thread caches above.if (why == RELEASE) {// Probably some thread is incorrectly exiting // while the object is held by another thread.return nil;}if (why != ACQUIRE) _objc_fatal("id2data is buggy");if (result->object != object) _objc_fatal("id2data is buggy");#if SUPPORT_DIRECT_THREAD_KEYSif (!fastCacheOccupied) { // 判断是否支持栈存缓存,支持KVC形式赋值存入tls// Save in fast thread cachetls_set_direct(SYNC_DATA_DIRECT_KEY, result);tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);} else
#endif{// Save in thread cacheif (!cache) cache = fetch_cache(YES);//第一次存储时，对线程进行了绑定cache->list[cache->used].data = result;cache->list[cache->used].lockCount = 1;cache->used++;}}return result;
}
这边先给出一个图来帮助理解:
- 首先我们可以通过这种图看出一个线程的数据是通过
哈希表结构中通过SyncList结构来组装多线程的情况,这里先通过线程来对应多个链表,然后把多个对于不同对象的锁的内容组织成一个链表.SyncData通过链表的形式组装当前可重入的情况,(也就是在一个线程中可以多次加锁不会出现死锁的问题). lockCount、threadCount,解决了递归互斥锁，解决了嵌套可重入
这里简单在介绍一下相关流程:
- 现在tls中进行一个寻找
- 在
tls_get_direct方法中以线程为key，通过KVC的方式获取与之绑定的SyncData，即线程data。其中的tls（），表示本地局部的线程缓存 - 判断data的加锁对象和我们的这次传入的对象是否一致
- 如果不一致就获取对应的一个lockCount,实现一个重入
- 通过传入的一个why来判读是加锁还是解锁
- 在
- 如果tls中没有，则在
cache缓存中查找- 通过
fetch_cache方法查找cache缓存中是否有线程 - 如果有，则遍历
cache总表，读取出线程对应的SyncCacheItem - 从
SyncCacheItem中取出data，然后后续步骤与tls的匹配是一致的
- 通过
- 如果cache中也没有，即
第一次进来，则创建SyncData，并存储到相应缓存中
第一进入没有锁:
- threadCount 和 lockCount 全部设置成1
- 存储到
tls
进入有数据,但是在同一个数据且对同一个对象加锁:
- lockCount 加1
- 存储到
tls
不是第一次进来，且是不同线程
- threadCount 加一
- 存储到tls
@synchronized问题:
for (int i = 0; i < 200000; i++) {dispatch_async(dispatch_get_global_queue(0, 0), ^{@synchronized (self.array) {self.array = [NSMutableArray array];}});}
这里我们给self.array加锁,我们注意到在@synchronized里面对于nil对象是不做任何处理的,这里会导致一个问题也就是我们会访问到野指针,因为我们每一次set方法会释放原先的内容,在retain,可能在某一个瞬间他被retain了两次导致了我们出现访问坏内存的文体:
注意：野指针 vs 过渡释放
野指针：是指由于过渡释放产生的指针还在进行操作过渡释放：每次都会retain 和 release
小结
@synchronized是一个递归互斥锁@synchronized的可重入，即可嵌套，主要是由于lockCount和threadCount的搭配- 但是由于底层中
链表查询、缓存的查找以及递归，是非常耗内存以及性能的，导致性能低，所以在前文中，该锁的排名在最后 - 不能使用
非OC对象作为加锁对象，因为其object的参数为id @synchronized (self)这种适用于嵌套次数较少的场景。
NSLock
底层是通过pthread_mutex互斥锁实现的
NSLock *lock = [[NSLock alloc] init];
dispatch_async(dispatch_get_global_queue(0, 0), ^{static void (^testMethod)(int);testMethod = ^(int value){[lock lock];if (value > 0) {NSLog(@"current value = %d",value);testMethod(value - 1);}[lock unlock];};testMethod(10);});
这里会出现一个递归阻塞的问题:
会出现一直等待的情况，主要是因为
嵌套使用的递归，使用NSLock（简单的互斥锁，如果没有回来，会一直睡觉等待），即会存在一直加lock，等不到unlock 的堵塞情况
NSRecursiveLock
NSRecursiveLock有一个标识PTHREAD_MUTEX_RECURSIVE，而NSLock是默认的,这个用来解决一个递归嵌套调用的问题
NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];dispatch_async(dispatch_get_global_queue(0, 0), ^{static void (^testMethod)(int);testMethod = ^(int value){[lock lock];if (value > 0) {NSLog(@"current value = %d",value);testMethod(value - 1);}[lock unlock];};testMethod(10);});
这样就解决了这里的一个递归嵌套加锁的问题:
但是如果在外层加一个for循环又会出现问题:
NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];for (int i = 0; i< 100; i++) {dispatch_async(dispatch_get_global_queue(0, 0), ^{static void (^testMethod)(int);testMethod = ^(int value){[lock lock];if (value > 0) {NSLog(@"current value = %d",value);testMethod(value - 1);}[lock unlock];};testMethod(10);});}
for循环在block内部对同一个对象进行了多次锁操作，直到这个资源身上挂着N把锁，最后大家都无法一次性解锁——找不到解锁的出口
就是线程1中加锁1,线程2中加锁2.解锁1等待解锁2,解锁2等待解锁1,无法结束解锁–=形成死锁
解决： 可以采用使用缓存的@synchronized，因为它对对象进行锁操作，会先从缓存查找是否有锁syncData存在。如果有，直接返回而不加锁，保证锁的唯一性
NSCondition
条件锁是一种特殊类型的同步机制,用来管理不同线程间的执行顺序,让某些线程能在满足特定条件的时候才会继续
NSCondition是一个条件锁，可能平时用的不多，但与信号量相似：线程1需要等到条件1满足才会往下走，否则就会堵塞等待，直至条件满足
NSCondition的对象实际上作为一个锁 和 一个线程检查器
- 锁是为了当检测条件的时候保护数据源,执行条件引发的任务
- 线程检查器主要是根据条件决定是否继续运行线程,即线程是否被阻塞
//初始化
NSCondition *condition = [[NSCondition alloc] init]//一般用于多线程同时访问、修改同一个数据源，保证在同一 时间内数据源只被访问、修改一次，其他线程的命令需要在lock 外等待，只到 unlock ，才可访问
[condition lock];//与lock 同时使用
[condition unlock];//让当前线程处于等待状态
[condition wait];//CPU发信号告诉线程不用在等待，可以继续执行
[condition signal];- 它也是对于下层
pthread_mutex的一个封装 wait操作会阻塞线程.让他进入休眠状态,直到超时signal操作是唤醒一个正在休眠等待的线程broadcast会唤醒所有正在等待的线程
NSConditionLock
NSConditionLock是条件锁，一旦一个线程获得锁，其他线程一定等待
和上面的NSCondition对比,NSConditonLock使用更加简单
//初始化
NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];//表示 conditionLock 期待获得锁，如果没有其他线程获得锁(不需要判断内部的 condition) 那它能执行此行以下代码，如果已经有其他线程获得锁(可能是条件锁，或者无条件 锁)，则等待，直至其他线程解锁
[conditionLock lock]; //表示如果没有其他线程获得该锁，但是该锁内部的 condition不等于A条件，它依然不能获得锁，仍然等待。如果内部的condition等于A条件，并且 没有其他线程获得该锁，则进入代码区，同时设置它获得该锁，其他任何线程都将等待它代码的 完成，直至它解锁。
[conditionLock lockWhenCondition:A条件]; //表示释放锁，同时把内部的condition设置为A条件
[conditionLock unlockWithCondition:A条件]; // 表示如果被锁定(没获得 锁)，并超过该时间则不再阻塞线程。但是注意:返回的值是NO,它没有改变锁的状态，这个函 数的目的在于可以实现两种状态下的处理
return = [conditionLock lockWhenCondition:A条件 beforeDate:A时间];//其中所谓的condition就是整数，内部通过整数比较条件NSConditionLock，其本质就是NSCondition + Lock
对于NSCondition的一个再次的封装
NSConditionLock可以设置锁条件，即condition值，而NSCondition只是信号的通知
自旋锁
自旋锁：线程反复检查锁变量是否可⽤。由于线程在这⼀过程中保持执⾏， 因此是⼀种忙等待。⼀旦获取了⾃旋锁，线程会⼀直保持该锁，直⾄显式释 放⾃旋锁
自旋锁避免了进程上下问的调度开销,因此对于线程只会阻塞很短事件的场合是有效的
OSSpinLock(已弃用)
自旋锁之所以不安全，是因为获取锁后，线程会一直处于忙等待，造成了任务的优先级反转。
其中的忙等待机制可能会造成高优先级任务一直running等待，占用时间片，而低优先级的任务无法抢占时间片，会造成一直不能完成，锁未释放的情况
OSSpinLock lock = OS_SPINLOCK_INIT;
OSSpinLockLock(&lock);
OSSpinLockUnlock(&lock);
因为他会出现一个优先级反转的问题,所以在后面就把它弃用了.
在OSSpinLock被弃用后，其替代方案是内部封装了os_unfair_lock，而os_unfair_lock在加锁时会处于休眠状态，而不是自旋锁的忙等状态
atomic
这里看底层的一个实现:
static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{if (offset == 0) {object_setClass(self, newValue);return;}id oldValue;id *slot = (id*) ((char*)self + offset);if (copy) {newValue = [newValue copyWithZone:nil];} else if (mutableCopy) {newValue = [newValue mutableCopyWithZone:nil];} else {if (*slot == newValue) return;newValue = objc_retain(newValue);}if (!atomic) {oldValue = *slot;*slot = newValue;} else { // 加锁修饰不加锁修饰spinlock_t& slotlock = PropertyLocks[slot];slotlock.lock();oldValue = *slot;*slot = newValue; slotlock.unlock();}objc_release(oldValue);
}
- 原子性的set方法加了锁
spinlock_t - 非原子性就是直接赋值.
这个锁其实就是os_unfair_lock代替了OSSpinLock
using spinlock_t = mutex_tt<LOCKDEBUG>;class mutex_tt : nocopy_t {os_unfair_lock mLock;...
}
这里还进行了一个加盐操作,还采用了加盐操作来避免哈希冲突
id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {if (offset == 0) {return object_getClass(self);}// Retain release worldid *slot = (id*) ((char*)self + offset);if (!atomic) return *slot;// Atomic retain release worldspinlock_t& slotlock = PropertyLocks[slot];slotlock.lock();id value = objc_retain(*slot);slotlock.unlock();// for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.return objc_autoreleaseReturnValue(value);
}
getter方法中对atomic的处理，同setter是大致相同的
atomic修饰的属性绝对安全吗?
atomic这个方法只可以保证我们的setter和getter方法的线程安全,并不能保证数据安全:
dispatch_async(dispatch_get_global_queue(0, 0), ^{for (int i = 0; i < 10000; i++) {self.index = self.index + 1;NSLog(@"%ld--%ld", i, self.index);}});dispatch_async(dispatch_get_global_queue(0, 0), ^{for (int i = 0; i < 10000; i++) {self.index = self.index + 1;NSLog(@"%ld--%ld", i, self.index);}});
如上图所示,这里并没有保证一个线程安全,
- atmic只可以保证变量在取值和赋值的时候的线程安全
- 不可以保证加锁是安全
os_unfair_lock
由于OSSpinLock并不安全，因此苹果推出了os_unfair_lock以解决优先级反转的问题
//创建一个锁os_unfair_lock_t unfairLock;
//初始化unfairLock = &(OS_UNFAIR_LOCK_INIT);//加锁os_unfair_lock_lock(unfairLock);//解锁os_unfair_lock_unlock(unfairLock);
读写锁
读写锁实际是一种特殊的自旋锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作。这种锁相对于自旋锁而言，能提高并发性，因为在多处理器系统中，它允许同时有多个读者来访问共享资源，最大可能的读者数为实际的CPU数
-
写者是具有排他性的,一个读写锁只能有一个写者,但不能同时拥有读者和写者,在读写锁保持期间也是抢占失效的
-
如果读写锁当前没有读者也没有写者,那么写着可以立刻获得读写锁,否则他就会自旋在哪里,知道没有任何读者和写者.如果读写锁没有写者，那么读者可以⽴即获得该读写锁，否则读者必须⾃旋在那⾥，直到写者释放该读写锁
//初始化锁
pthread_rwlock_t lock;
pthread_rwlock_init(&_lock, NULL);//读加锁
pthread_rwlock_rdlock(&_lock);
//读尝试加锁
pthread_rwlock_trywrlock(&_lock)//写加锁
pthread_rwlock_wrlock(&_lock);
//写尝试加锁
pthread_rwlock_trywrlock(&_lock)//解锁
pthread_rwlock_unlock(&_lock);
//销毁
pthread_rwlock_destroy(&_lock);
现在基本上不采用,都采用栅栏函数来实现一个多读单写.
互斥锁和自旋锁的对比
前者线程会从sleep(加锁)->解锁, 这个过程中有上下文的一个切换,cpu的抢占,信号的发送和开销.
后者的线程一直都是running,死循环检查所得一个标志位,机制并不复杂
互斥锁的起始原始开销要高于自旋锁，但是基本是一劳永逸，临界区持锁时间的大小并不会对互斥锁的开销造成影响，而自旋锁是死循环检测，加锁全程消耗cpu。起始开销虽然低于互斥锁，但随着持锁时间编程，加锁的开销是线程增长。
小结
OSSpinLock由于安全性问题,在iOS10之后就被废了,底层实现采用os_unfair_lock代替
OSSpinLock会处于忙等待os_unfair_lock会处于休眠状态
atomic原子锁自带一把自旋锁，只能保证setter、getter时的线程安全，在日常开发中使用更多的还是nonatomic修饰属性
atomic只有当属性调用setter.getter时的线程安全,会加上自旋锁OSSpinLock用于保证同一个时刻只有一个线程调用属性的杜或者写nonatomic线程不安全
@synchronized在底层维护了一个哈希表进行线程data的存储，通过链表表示可重入（即嵌套）的特性，虽然性能较低，但由于简单好用，使用频率很高
NSLock、NSRecursiveLock底层是对pthread_mutex的封装
NSCondition和NSConditionLock是条件锁，底层都是对pthread_mutex的封装，当满足某一个条件时才能进行操作，和信号量dispatch_semaphore类似
使用场景
- 如果只是简单的使用,例如涉及线程安全,使用
NSLock - 如果是
循环嵌套,推荐使用@synchronized主要因为使用递归锁的性能不如使用synchronized - 在循环嵌套中,如果对递归掌握的很好,则建议使用
递归锁 - 如果是
循环嵌套，并且还有多线程影响时，例如有等待、死锁现象时，建议使用@synchronized