@synchronized 本质是个递归锁，不需要程序员手动加解锁，并且不会产生死锁问题，因此在开发中的使用频率比较高，下面我们来研究一下他的底层实现。
一、底层调用实现
@synchronized是个关键字，没法在代码中直接跳转查看定义，最直接的办法就是打上断点、看汇编：
代码跑起来看汇编：
在汇编中，有两个关键代码，
objc_sync_enter、objc_sync_exit，他们对应的就是加锁和解锁操作。
当然我们也可以通过clang(可以参考：ios 编译调试技巧
)来看一下，整理后@synchronized对应的代码如下：
{
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(@"-----");
} 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);
}
}
二、源码实现
2.1 objc_sync_enter
我们这里用的是objc4-756.2的源码，搜索objc_sync_enter找到实现：
// Begin synchronizing on 'obj'.
// Allocates recursive mutex associated with 'obj' if needed.
// Returns OBJC_SYNC_SUCCESS once lock is acquired.
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上进行同步 - 如果需要，分配与
obj关联的递归互斥体。 - 获取锁之后，返回
OBJC_SYNC_SUCCESS。从代码看，返回始终未成功，这是因为当锁被占用时，会阻塞 （data->mutex.lock();）到锁释放，然后往下执行。
如果obj为空则不会加解锁，但是被包裹在@synchronized(nil){}中的代码块依然会正常执行，因为没有阻塞当前线程。也就是说：加锁失败，不影响代码继续向下执行。
2.2 id2data()函数实现
SyncData* data = id2data(obj, ACQUIRE);
data->mutex.lock();
先来了解一下SyncData：
typedef struct alignas(CacheLineSize) SyncData {
struct SyncData* nextData;
DisguisedPtr object;
int32_t threadCount; // number of THREADS using this block
recursive_mutex_t mutex;
} SyncData;
这个结构体有四个对象，：
nextData：指向下一个SyncData，这看上去是一个单向链表。
object：对象指针，objc_object即OC对象，它保存了被锁定对象obj（@synchronized(obj)）的指针
threadCount：记录正在使用这个代码块的线程数
mutex：递归锁，获取到SyncData对象后，即调用它的lock()方法
下面来看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;
// ........
return result;
}
lockp：从命名看似乎是自旋锁，但是看关系链：spinlock_t -> mutex_tt -> os_unfair_lock ，os_unfair_lock就是用来替代OSSpinLock这个自旋锁的互斥锁，文档注释：
@discussion
已淘汰的OSSpinLock的替代品。 不会发生争抢，只会等待内核被解锁唤醒。
与OSSpinLock一样获取锁是无序的，例如未锁定者在有机会尝试获取锁之前，解锁者可能会立即重新获取锁。这对于性能可能是有利的，但是也可能使等待者挨饿。
listp：SyncData的二重指针，刚才知道SyncData是个链表，这个listp就是链表的头指针
result：锁定对象obj关联的SyncData结构体。
2.2.1 快速缓存
检查当前线程单项快速缓存中是否有匹配的对象
// Check per-thread single-entry fast cache for matching object
bool fastCacheOccupied = NO;
SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
if (data) {
fastCacheOccupied = YES;
if (data->object == object) {
// Found a match in fast cache.
uintptr_t lockCount;
result = data;
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: {
lockCount++;
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
break;
}
case 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 ACQUIRE
OSAtomicDecrement32Barrier(&result->threadCount);
}
break;
case CHECK:
// do nothing
break;
}
return result;
}
}
fastCacheOccupied：标记线程的快速缓存是否已占用，如果找到就标记为YES，无论这个缓存是否关联了当前要被锁定的对象
data：当前线程的私有数据，非所有数据，只是链表中某个节点的指针
如果快速缓存中恰好是和当前对象关联的锁，那么对这个锁计数+1，如果是解锁，就-1。
快速缓存中的SyncData和锁的计数，都属于线程的私有数据，是当前线程独有的，其他线程访问不到。
2.2.2 线程整体缓存
线程私有数据只保存一个节点的地址，如果没有，还要从线程的整体缓存中查找，检查已拥有锁的线程整体缓存中是否有匹配的对象：
// Check per-thread cache of already-owned locks for matching object
SyncCache *cache = fetch_cache(NO);
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->list[i] = cache->list[--cache->used];
// atomic because may collide with concurrent ACQUIRE
OSAtomicDecrement32Barrier(&result->threadCount);
}
break;
case CHECK:
// do nothing
break;
}
return result;
}
}
SyncCache的结构：
typedef struct SyncCache {
//可以保存SyncCacheItem的总数，已开辟的缓存空间，默认为4，2倍扩容
unsigned int allocated;
unsigned int used; //保存已使用数量
SyncCacheItem list[0]; //以及缓存链表的头节点地址
} SyncCache;
SyncCacheItem的结构：
typedef struct {
SyncData *data;
unsigned int lockCount; // number of times THIS THREAD locked this block
} SyncCacheItem;
lockCount：当前线程持锁计数器
如果缓存命中，加锁则对持锁计数器+1，如果是释放锁就-1；并且当持锁计数器为0的时候，要将已使用数SyncCache->used做-1操作。
2.2.3 无缓存
如果没有缓存，会操作使用清单listp，使用空闲节点或创建新节点：
// 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) {
//开始遍历链表，如果找到节点中存在当前对象的锁，goto done
if ( p->object == object ) {
result = p;
// atomic because may collide with concurrent RELEASE
OSAtomicIncrement32Barrier(&result->threadCount);
goto done;
}
//记录第一个空闲节点
if ( (firstUnused == NULL) && (p->threadCount == 0) )
firstUnused = p;
}
// no SyncData currently associated with object
if ( (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;
firstUnused：局部变量，用于记录链表中第一个没有使用的节点。由于程序中可能会对很多对象使用锁，但是使用完了之后这个节点还在链表中而占用它的线程已经没有了，那么这个节点就可以被拿来直接用于当前的对象，省的再去开辟新的内存空间插入链表，即省时又剩空间。
未找到缓存，同时有了新的SyncData节点，那么更新线程缓存：
done:
lockp->unlock();
if (result) {
#if SUPPORT_DIRECT_THREAD_KEYS
if (!fastCacheOccupied) {
// Save in fast thread cache
tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);
} else
#endif
{
// Save in thread cache
if (!cache) cache = fetch_cache(YES);
cache->list[cache->used].data = result;
cache->list[cache->used].lockCount = 1;
cache->used++;
}
}
fastCacheOccupied：1、为NO，线程快速缓存没有被占用，则将结果保存到快速缓存；2、为YES，线程快速缓存已被占用，将节点保存到线程整体缓存中
从前面的代码知道，只要线程快速缓存存在，无论是否命中当前需要被锁的对象，fastCacheOccupied都会被置为YES。也就是说，线程私有数据的快速缓存只缓存第一次，且只保存第一次的这一个节点指针。
苹果为什么这么做，个人猜想：
1、线程第一次使用同步锁锁定的对象，也很可能是该线程需要锁定频率最高的对象，比如我们经常使用@synchronized(self)
2、该对象的同步锁可能已经被其他线程缓存到私有数据了，当前线程又无法访问其他线程的私有数据，如果替换的话，会重复缓存
2.2.4 listp
无缓存时从链表取对象，那么保存对象锁的链表具体是什么样子的呢：
spinlock_t *lockp = &LOCK_FOR_OBJ(object);
SyncData **listp = &LIST_FOR_OBJ(object);
//使用多个并行列表来减少不相关对象之间的争用。
// Use multiple parallel lists to decrease contention among unrelated objects.
#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap sDataLists;
关于SyncList：
struct SyncList {
SyncData *data;
spinlock_t lock;
constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
}
从全局静态变量sDataLists，以obj为索引获取到的对象类型为StripedMap，同时对其取地址&SyncList.data后返回。下面是StripedMap部分源码：
// or as StripedMap where SomeStruct stores a spin lock.
template
class StripedMap {
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
enum { StripeCount = 8 };
#else
enum { StripeCount = 64 };
#endif
struct PaddedT {
T value alignas(CacheLineSize);
};
PaddedT array[StripeCount];
static unsigned int indexForPointer(const void *p) {
uintptr_t addr = reinterpret_cast(p);
return ((addr >> 4) ^ (addr >> 9)) % StripeCount; // 哈希函数
}
public:
T& operator[] (const void *p) {
return array[indexForPointer(p)].value;
}
const T& operator[] (const void *p) const {
return const_cast>(this)[p];
}
//.......
}
T& operator[]：C++操作符重载，通过obj取值T
indexForPointer：数组的索引是通过一个hash算法获取
虽然真机的hash表大小只有8，但是这个方法取到得的是链表，虽然不同的对象可能取到同一个链表，但链表中有多个节点，每个节点又保存了和不同对象相关联的锁，这样就避免了hash冲突
。
2.3 解锁 objc_sync_exit()
主要通过函数id2data()获得锁，然后tryUnlock()。
// End synchronizing on 'obj'.
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
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;
}
三、总结
-
@synchronized()是递归锁，同一线程可重入，只是内部有个持锁计数器而已 - 进入@synchronized()代码块时会执行
objc_sync_enter(id obj)加锁 - 核心方法是通过
id2data()来获取到对象锁节点SyncData
3.1. 首先从当前线程的私有数据（快速缓存）中查找
3.2. 从当前线程整体缓存中查找，检查已拥有锁的线程缓存中是否有匹配的对象
3.3. 从全局静态listp对象锁链表中查找，并更新线程缓存 - 退出@synchronized()代码块，执行
objc_sync_enter(id obj)解锁
lockCount：被锁次数，可递归重入
threadCount：SyncData影响的多线程统计
注意点：
在使用@synchronized(obj){}时，如果obj为nil，就不会加锁，而代码块中的代码依然会正常执行，那就会存在风险，如下：
for (int i = 0; i < 200000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
@synchronized (_testArray) {
_testArray = [NSMutableArray array];
}
});
}
多线程中_testArray可能会被release置nil，这个时候会加锁失败，同时如果发生多次release，就会crash。