多线程出现最多的就是安全问题，解决多线程安全问题就是加锁。
锁的种类有很多，每种锁使用场景、性能上都有所不同，我们写一个测试demo，测试各种锁的耗时，demo下载地址。
这里需要注意一下，运行起来耗时并不是固定的，设备型号不同，版本号不同，是否使用模拟器执行完代码打印的结果并不相同，甚至都使用模拟器，打印结果都不一定每次相同，这个耗时仅供参考。
@synchronized
我们平时用的最多的锁就是@synchronized，这个锁的原理是什么，我们先来分析它。
分析它底层实现用什么方法呢？首先我们可以用xcrun生成对应的C++文件，看底层实现，或者我们直接打断点进入汇编去一步一步跟流程看它执行了哪些操作。
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
@autoreleasepool {
// Setup code that might create autoreleased objects goes here.
appDelegateClassName = NSStringFromClass([AppDelegate class]);
@synchronized (appDelegateClassName) {
NSLog(@"123");
}
}
return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
我们把main.m文件生成C++文件，可以省去很多干扰，到main.m文件目录执行xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc main.m -o main.cpp生成对应C++文件。
找到对应实现，首先我们先自己整理下格式，生成的格式不太方便我们研究，
{
id _rethrow = 0;
id _sync_obj = (id)appDelegateClassName;
objc_sync_enter(_sync_obj);
try {
struct _SYNC_EXIT {
_SYNC_EXIT(id arg) : sync_exit(arg) {}
~_SYNC_EXIT() {objc_sync_exit(sync_exit);}
id sync_exit;
}
_sync_exit(_sync_obj);
NSLog((NSString *)&__NSConstantStringImpl__var_folders_zc_4wbtwwn978v9__lzhp1kr15h0000gn_T_main_7e7e5b_mi_0);
} catch (id e) {_rethrow = e;}
{
struct _FIN {
_FIN(id reth) : rethrow(reth) {}
~_FIN() { if (rethrow) objc_exception_throw(rethrow); }
id rethrow;
}
_fin_force_rethow(_rethrow);
}
}
我们分析加锁流程，肯定是加锁成功，会执行try里面代码，catch里面不会执行，所以并不需要关心。try里面的结构体声明我们可以放在外面，先调用构造函数_sync_exit(_sync_obj);相当于结构体sync_exit赋值_sync_obj，当结构体释放时，调用析构函数时，执行objc_sync_exit(sync_exit)，等价于objc_sync_exit(_sync_obj)，所以我们可以简化成以下代码：
id _rethrow = 0;
id _sync_obj = (id)appDelegateClassName;
objc_sync_enter(_sync_obj);
objc_sync_exit(_sync_obj);
接下来打个断点，进入汇编看下执行流程：
我们可以看到，汇编流程和我们上面分析流程差不多，要研究底层实现，就得去源码中查看相关代码。
int objc_sync_enter(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
SyncData* data = id2data(obj, ACQUIRE);
ASSERT(data);
data->mutex.lock();
} else {
// @synchronized(nil) does nothing
if (DebugNilSync) {
_objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
}
objc_sync_nil();
}
return result;
}
这里有个细节，obj如果是空的话，注释写的很明白does nothing也就是什么都不做不会加锁直接执行代码块里面的内容，所以我们使用的时候，obj不能为空，否则没有加锁效果。
再看一下objc_sync_exit的实现对比着看。
int objc_sync_exit(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
SyncData* 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 {
// @synchronized(nil) does nothing
}
return result;
}
我们在C++代码中看返回值也没用使用的地方，这两个方法返回值也只是个标记加锁状态，没太多作用，所以重点代码就是：SyncData* data = id2data(obj, ACQUIRE);和SyncData* data = id2data(obj, RELEASE);。
首先我们先看下这个值的类型的定义：
typedef struct alignas(CacheLineSize) SyncData {
struct SyncData* nextData;
DisguisedPtr<objc_object> object;
int32_t threadCount; // number of THREADS using this block
recursive_mutex_t mutex;
} SyncData;
第一个参数也是SyncData，并且命名是next也就是这个结构是个单向链表。
DisguisedPtr<objc_object>是对数据进行封装。
recursive_mutex_t是一个递归锁，递归锁不能多线程使用，但是有了threadCount之后，就可以支持多线程使用了。
再看下第二个参数
enum usage { ACQUIRE, RELEASE, CHECK };
一个枚举值，标记是获取、释放还是检查。
然后我们看下id2data方法实现，这个应该是最核心的代码了。
先分析下前三行代码：
spinlock_t *lockp = &LOCK_FOR_OBJ(object);
SyncData **listp = &LIST_FOR_OBJ(object);
SyncData* result = NULL;
listp为什么是个二级指针，为后面链表处理头插法做准备，一级指针无法满足需求。
找到实现：
#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap<SyncList> sDataLists;
可以看到，sDataLists是个哈希列表，并且是个全局静态变量，这点很重要。
从StripedMap实现里面看还有个细节：
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
enum { StripeCount = 8 };
#else
enum { StripeCount = 64 };
#endif
也就是真机情况下，这个哈希列表容量是8，其他情况容量是64。
在可调式源码工程中，这个方法打断点，看下sDataLists的数据：
可以看到一共有64个数据。
下面我们开始分析方法主要实现，分析之前，需要对这些方法有个全局把控，大概知道这里面在干什么，大代码块收起，然后发现主要就几块内容：
整体看完我们就一块一块的分析。上面5块我们把他们叫成代码块一、代码块二、码块三、代码块四、码块五。
SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
看这行代码前，首先要了解一个概念TLS：
线程局部存储（Thread Local Storage，TLS）：是操作系统为线程单独提供的私有空间，通常只有有限的容量。Linux系统下通常通过pthread库中的pthread_key_create()、pthread_getspecific()、pthread_setspecific()、pthread_key_delete()进行操作。
再看两个函数：
OSAtomicDecrement32Barrier()，原子性减1并存储。
OSAtomicIncrement32Barrier()，原子性加1并存储。
代码块一：
拿到data后先判断data是否有值，没有值的话什么都不做，有值的话再判断data-object和object是否相同，不相同也什么都不做，相同的话，继续下面流程。
这里还把fastCacheOccupied设置为YES，下面使用，再存储的时候直接存到缓存里面不存tls了。为什么有这个操作，因为map容量固定，当hash算法算出下标相同时，会存在相同链表中，从tls取出只是固定的那个，其他对象对应的SyncData就只能放在别的地方也就是缓存里面。
- 先获取了锁的次数
lockCount，记录了加锁几次。threadCount和lockCount容错处理- 根据策略，
ACQUIRE把lockCount加1并存储。RELEASE把lockCount减1并存储，如果减到0，还要把threadCount也减1，并且从tls删除return result;
代码块二：
SyncCache *cache = fetch_cache(NO);，先把锁的线程缓存数据都拿出来，然后遍历，直到匹配到object相等时，跟上面操作差不多，对lockCount进行处理。lockCount减到0时候，从cache列表删除这个数据
image下一块代码我们看见这里面有个加锁解锁的过程，这个并不是
@synchronized的锁，而是锁中间内存开辟创建的代码，防止多线程抢占资源问题，这个需要注意一下。
代码块五：
我们先看done这块代码，因为上面会跳过来。
- 先判断
result有值才会走下面逻辑。- 如果是
RELEASE直接返回nil- 如果不是
ACQUIRE，会报错处理- 如果
result->object != object，会报错处理- 如果是没从
tls取的，直接把tls设置下- 否则就是缓存，如果
cache是空的，再去取一次缓存，这是参数是YES也就是去创建缓存。然后把result存到缓存里面。
代码块三：
这快分析完了，回到上面
- 遍历
listp链表，p不为空时，才会走里面代码，也就是这块并不是第一次会进来，而是后面才会来- 如果
p->object == object，threadCount加1跳到done- 如果
firstUnused没被赋值过并且p->threadCount == 0，firstUnused = p- 如果
RELEASE或者CHECK，直接跳到done- 如果
firstUnused有值，则赋值给result，并且跳到done
总结下这小块逻辑，就是其他线程同一个对象加锁，过来会threadCount加1，其他线程不同对象，过来会找到链表最后一个位置，新建个对象，赋值存储
代码块四：
先开辟内存空间，result设置值，然后利用头插法，插入到listp链表的第一个位置。
总结：
-
@synchronized参数一般用self因为保证参数生命周期大于这段代码执行生命周期，否则会有问题 -
@synchronized参数一般用self可以减少链表数据的创建，节约性能 -
@synchronized真机模拟器性能不同因为StripeCount值不同 -
@synchronized支持递归可重入表现在lockCount++ -
@synchronized支持多线程表现在threadCount++ -
@synchronized参数不要为空，否则没有加锁作用
