@synchronized是我们iOS开发中常见的锁，其本质是递归锁，其作用是创建一个互斥锁，保证此时没有其他线程对传入的对象进行修改,保证代码的安全性。开发中不需要程序员手动加解锁，不会产生死锁问题。对于@synchronized的使用，我们在创建单例和防止多线程同时执行同一段代码时候使用，相比于使用NSLock创建锁对象、加锁、解锁来说，@synchronized的使用更方便，并且其可读性更高。

使用@synchronized也是很方便的，首先在@synchronized()中小括号内需要一个参数，这个参数表示信号量，我们针对不同的逻辑可以定义不同的信号量，这个信号量可以是任何对象，包括self,或者我们手动定义的信号量，其中@synchronized(){...}中中括号是定义的要加锁的代码，当程序开始执行代码时候，当前线程会对其进行加锁，执行完成之后进行解锁操作，此时其他线程才能进行此段代码执行操作。

在说@synchronized原理之前我们先想一下这几个问题：

1、 锁如何与我们传入@synchronized中的对象关联的？

2、 @synchronized中小括号中的参数为nil会怎么样？

接下来我们将通过对其原理的剖析为大家一一解惑。

我们可以在main.m文件中添加以下代码通过汇编调试查看@synchronized底层调用：

int main(int argc, char * argv[]) {    NSString * appDelegateClassName;    @autoreleasepool {        // Setup code that might create autoreleased objects goes here.        appDelegateClassName = NSStringFromClass([AppDelegate class]);    }    NSLog(@"====begin===synchronized");    @synchronized (appDelegateClassName) {        NSLog(@"-======test-synchronized--");    }    NSLog(@"====end===synchronized");    return UIApplicationMain(argc, argv, nil, appDelegateClassName);}

通过汇编调试查看其代码运行截图如下：

从截图中我们可以看到在@synchonized执行打印前后分别调用了objc_sync_enter和objc_sync_exit.

通过对上述main.m文件clang编译代码其截图如下：

从clang编译后的代码我们可以看到objc_sync_enter(_sync_obj)这个是和我们断点汇编查看中是一样的,其中_sync_objc就是我们通过小括号传过来的参数;然后是try{}逻辑，其内部是有一个结构体_SYNC_EXIT{},这个结构体内部包含构造方法_SYNC_EXIT(id arg)和析构方法~_SYNC_EXIT();调用_sync_exit(_sync_obj)方法,初始化结构体_SYNC_EXIT(id arg);NSLog()函数的执行是我们要加锁的代码，当try{}执行完成之后，会调用析构方法~_SYNC_EXIT(),最终执行objc_sync_exit(sync_exit)方法；如果发生异常就会调用objc_exception_throw(rethrow)方法，去执行异常的跑出；至此@synchronized的整体的调用顺序我们就可以简单理解为：objc_sync_enter(_sync_obj)----->NSLog()方法（我们要加锁的逻辑代码）---->objc_sync_exit(sync_exit);

接下来我们重点查看一下objc_sync_enter()和objc_sync_exit()

查看objc_sync_enter源码我们从libobjc中查看，其方法截图如下：

我们查看源码可知objc_sync_enter(id obj)中参数obj就是我们通过@synchronized()小括号传进来的参数；首先会判断传进来的参数obj是否存在，如果不存在，则会调用objc_sync_nil(),查看其内部其实是什么也没做的，如果存在就会将传入的obj 通过id2data去创建一个SyncData的结构体指针，然后通过data->mutex.lock()来实现上锁,其中mutex就是用于保证线程在某一时刻只有该线程可以访问对象，获取锁操作失败，线程会进入睡眠，所以@synchronized是一种互斥锁。

查看objc_sync_exit()源码，其截图如下：

从objc_sync_exit(id obj)源码中可知也会判断obj是否存在，如果不存在同样不会做任何事，如果存在同样会通过id2data传入obj参数获取SyncData *data,如果data存在会通过data->mutex.tryUnlock()去解锁。

我们从objc_sync_enter()和objc_sync_exit()源码可知其都调用了id2data()方法获取SyncData结构数据，其中两个方法只是入参不同，接下来我们看一下SyncData的数据结构：

从SyncData定义来看，可知它是一个结构体，其中第一个成员变量是指向下一个SyncData，可见其是一个链表结构，第二个成员变量object是传入的obj；第三个指当前有多少个线程在使用这个block;第四个mutex是互斥锁，代表递归属性；

接下来我们查看一下id2data()方法的源码，由于id2data()方法中源码很长，我将其分为4部分给大家介绍，有兴趣的同学可以查看完整源码：

1、 快速缓存中查找，如果支持快速缓存则从缓存中读取，其代码注释及截图如下：

快速缓存中查找是从线程中读取数据data，如果与传入的object相同,则赋值给result,并且将lockCount++或lockCount--,调用tls_set_direct()方法更新到制定的key中，如果lockCount为0时，则会释放线程缓存，将缓存值SYNC_DATA_DIRECT_KEY置为NULL,同时更新result下的线程数。

2、 线程缓存，快速缓存未找到就会从线程缓存中读取线程和任务，其代码注释及截图如下：

在说线程缓存之前，我们先来了解一下SyncCache,看一下其数据结构：

从其结构来看我们知道SyncCache是一个结构体对象，用来存储线程，list[0]表示当前线程的链表data,其存储着SyncData结构的data和lockCount.

从代码中我们可以看到其实线程缓存的读取任务和快速缓存逻辑是一样，都是最终去查询syncdata和lockCount，只是查询时的结构不同，内存缓存是从SyncCache中去读取的，其中fetch_cache()方法就是缓存的查询和创建，有兴趣的同学可以查看一下该方法。针对读取大家可以看一下下图加深点印象：

3、 循环遍历，所有缓存都找不到，循环遍历每个线程和任务进行操作。

这里循环遍历是在缓存中都不在下进行，从全局的listp链表中寻找Syncdata，如果遍历也没找到，有空节点的话，就会给空节点进行赋值。

4、 done, 如果不是当前对象或者进行中抛出异常，如果正常存在则会存入快速缓存和线程缓存中便于下一次查找。代码注释及截图如下：

至此id2data()方法的过程讲解完成，其实总的来说该方法就是根据传入的object去找到SyncData的过程，先从快速缓存中查找，再从线程缓存SyncCache中查找，缓存中不存在就会从全局链表listp中查找，如果链表中也不存在，就会自己创建一个，最终存储在快速缓存和线程缓存中方便下次查找。其过程图如下：

针对前面所说的问题，相信大家看过源码之后心中已有答案了吧。@synchronized中传入object的内存地址，被用作key，通过一定的hash函数映射到一个系统全局维护的递归锁中，所以不论我们传什么值，只要有内存地址都可以达到同步锁的效果；当你在@synchronized中传入nil时，相当于你没有进行加锁操作，同时你的代码也不会是线程安全的。@synchronized使用起来很简单方便，但是其内部实现起来还是很复杂的，需要注意的是我们要在使用过程中注意传入object的生命周期，如果参数传nil,其同步锁的效果也将失去。至此@synchronized原理介绍及注意事项先到这里，欢迎大家沟通和指正。