锁｜@synchronized - Lab.Lawliet

1143 字

6 分钟

锁｜@synchronized

2021-09-13

2026-10-12

iOS

底层知识梳理

一、定位到 synchronized 相关源码#

那么 synchronized 是怎么实现的呢？在 Xcode 中 @synchronized 是无法直接点进去的。我们尝试在 objc 源码中找线索。

这里找到了成对出现的 objc_sync_exit / objc_sync_enter。怀疑他就是 @synchronized 的底层实现。那么如何来验证一下呢？

这里我决定将 OC 代码还原为 C++ 代码来看看。

通过 clang -rewrite-objc main.m -o main.cpp 来进行还原。定位到 main 函数，其中的确成对出现了 objc_sync_exit / objc_sync_enter。

1
int main(int argc, const char * argv[]) {
2
    /* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool;
3
        NSObject *obj = ((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("NSObject"), sel_registerName("new"));
4
        { id _rethrow = 0; id _sync_obj = (id)obj; objc_sync_enter(_sync_obj);
5
            try {
6
                struct _SYNC_EXIT { _SYNC_EXIT(id arg) : sync_exit(arg) {}
7
                    ~_SYNC_EXIT() {objc_sync_exit(sync_exit);}
8
                    id sync_exit;
9
                } _sync_exit(_sync_obj);
10

11
                NSLog((NSString *)&__NSConstantStringImpl__var_folders_py_7v1wvf813z5bmw0hr97yplwc0000gn_T_main_7d2c6c_mi_0);
12
            } catch (id e) {_rethrow = e;}
13
            { struct _FIN { _FIN(id reth) : rethrow(reth) {}
14
                ~_FIN() { if (rethrow) objc_exception_throw(rethrow); }
15
                id rethrow;
16
            } _fin_force_rethow(_rethrow);}
17
        }
18

19
    }
20
    return 0;
21
}

接下来我们可以放心的在 objc 源码中继续探索了。

二、 objc_sync_enter#

1
int objc_sync_enter(id obj)
2
{
3
    int result = OBJC_SYNC_SUCCESS;
4
    if (obj) {
5
        // 通过传入的 obj 创建一个 SyncData
6
        SyncData* data = id2data(obj, ACQUIRE);
7
        ASSERT(data);
8
        data->mutex.lock();
9
    } else {
10
        /// 如果传入的 obj 为空的话什么都不做
11
        // @synchronized(nil) does nothing
12
        if (DebugNilSync) {
13
            _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
14
        }
15
        objc_sync_nil();
16
    }
17
    return result;
18
}

这里会利用传入的 obj 通过 id2data 获取一个 SyncData 结构体指针
如果传入的 obj 为空，什么都不做

三、 objc_sync_exit#

1
int objc_sync_exit(id obj)
2
{
3
    int result = OBJC_SYNC_SUCCESS;
4
    if (obj) {
5
        SyncData* data = id2data(obj, RELEASE);
6
        if (!data) {
7
            result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
8
        } else {
9
            // 尝试解锁
10
            bool okay = data->mutex.tryUnlock();
11
            if (!okay) {
12
                // 解锁失败
13
                result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
14
            }
15
        }
16
    } else {
17
        // @synchronized(nil) does nothing
18
    }
19
    return result;
20
}

四、 SyncData 的数据结构#

1
typedef struct alignas(CacheLineSize) SyncData {
2
    struct SyncData* nextData;
3
    DisguisedPtr<objc_object> object;
4
    int32_t threadCount;  // number of THREADS using this block
5
    recursive_mutex_t mutex;
6
} SyncData;

nextData
- SyncData 指针，可见是个 单向链表 的结构
- 这个结构是 synchronized 可嵌套使用的关键点，后续会降到
object
- 传入的 obj
threadCount
- 有多少个线程在使用当前 block
mutex
- 递归锁

五、 id2data#

1
static SyncData* id2data(id object, enum usage why)
2
{
3
    spinlock_t *lockp = &LOCK_FOR_OBJ(object);
4
    SyncData **listp = &LIST_FOR_OBJ(object);
5
    SyncData* result = NULL;
6

7
    。。。
8
}

5.1 找到 object 对应的数据结构#

LOCK_FOR_OBJ
- 找到对应的锁 spinlock_t
LIST_FOR_OBJ
- 找到对应的 SyncData 的指针的指针

通过源码是从一个全剧静态哈希表 static StripedMap<SyncList> sDataLists 中获取的。

5.2 sDataLists 全剧静态哈希表#

通过源码可以发现，貌似一个Hash表的结构。

容量大小 StripeCount#

真机容量为 8，其他为 64

1
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
2
    enum { StripeCount = 8 };
3
#else
4
    enum { StripeCount = 64 };
5
#endif

范型容器 array#

这里容器的类型为 SyncList

1
struct PaddedT {
2
    T value alignas(CacheLineSize);
3
};
4

5
PaddedT array[StripeCount];

容器元素 SyncList#

1
struct SyncList {
2
    SyncData *data;
3
    spinlock_t lock;
4
    constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
5
};

哈希下标算法 indexForPointer#

地址 addr 右移 4位 得到 A
地址 addr 右移 9位 得到 B
A 异或 B 得到 C
用 C 模 容量 得到下标
- 保证了不会越界

1
static unsigned int indexForPointer(const void *p) {
2
    uintptr_t addr = reinterpret_cast<uintptr_t>(p);
3
    return ((addr >> 4) ^ (addr >> 9)) % StripeCount;
4
}

思考一下：下标冲突了怎么办？

哈希冲突：拉链法（单向链表）#

上面的图很好的描绘了哈希冲突时的情况
- obj 计算出的下标冲突时会在链表中添加一个节点

sDataLists

5.3 查找TLS快速缓存（如果支持的话）#

通过 线程局部存储（TLS：Thread Local Storage） 查找快速缓存。

5.4 fetch_cache 查找缓存#

内部操作和 查找TLS快速缓存 基本一致。

5.5 未命中缓存#

遍历链表查找

5.6 第一次进入及链表操作#

这里通过头插法插入解决哈希冲突

到这里再回头看拉链法的那张图是否就更清楚了？

六、 SyncCacheItem#

作为缓存的数据结构，其中的 lockCount 代表了，这个一个 Block 在 当前线程 锁了多少次（即嵌套锁）。

1
typedef struct {
2
    SyncData *data;
3
    unsigned int lockCount;  // number of times THIS THREAD locked this block
4
} SyncCacheItem;

七、总结#

这里的设计十分巧妙，刚开始发现在真机下容器的大小只有 8 的时候还在想，难道最多只能有 8 个锁么？结果其中还存在单向链表的数据结构，同时使用单向链表还解决了哈希冲突。赞叹真的是很精妙的设计呀！👍

从源码中我们也可以注意到一些点：
- 锁的对象不要为空
- 锁的对象的生命周期要合适，不要中途就被释放了
  - 这也是平时我们用 self 的原因
- 尽量选择一样的 obj 来加锁，可以使 sDataLists 结构更简单

参考#

锁｜性能分析

栅栏函数

1

一、定位到 synchronized 相关源码

5.1 找到 object 对应的数据结构

5.2 sDataLists 全剧静态哈希表

5.3 查找TLS快速缓存（如果支持的话）

一、 定位到 synchronized 相关源码#