详解 iOS 常用锁 — @synchronized

@synchronized是比较常见的线程间同步锁,其使用相当简单:

@synchronized (self) {
  NSLog(@"-----synchronized-----");
}

可在上述代码synchronized行断点,并通过xcode转换为汇编代码,或通过终端用clang命令翻译源码:
clang -x objective-c -rewrite-objc -isysroot /.../main.m

可看到 @synchronized 代码块调用了两个函数:

objc_sync_enter
objc_sync_exit

1. objc_sync_enter

必要时开辟一个关联着obj的互斥递归锁,进入与obj关联的同步工作,当获得锁之后返回OBJC_SYNC_SUCCESS。

// 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;
}

objc_sync_enter主要逻辑:
obj 不为空时,获取 SyncData *data,取出 data->mutex 进行加锁;
obj 为空时,执行 obj_sync_nil,通过源码查看其实什么也没有处理。

2. 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;
}

objc_sync_exit 也是找到对应的 SyncData,然后进行解锁。

可以看出,@synchronized 核心是一个互斥递归锁。
objc_sync_enter 的过程主要是关于 SyncData 的创建、获取及相关处理,SyncData结构如下:

typedef struct alignas(CacheLineSize) SyncData {
    struct SyncData* nextData;
    DisguisedPtr<objc_object> object;
    int32_t threadCount; 
    recursive_mutex_t mutex;
} SyncData;

3. id2data

id2data方法中可分为6个基本操作,简要过程如下:

static SyncData* id2data(id object, enum usage why) {

    //// 步骤 1
    //// 获取listp,及对其操作的锁lockp
    spinlock_t *lockp = &LOCK_FOR_OBJ(object);
    SyncData **listp = &LIST_FOR_OBJ(object);
    SyncData* result = NULL;

#if SUPPORT_DIRECT_THREAD_KEYS
    // 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) {
        //// 步骤 2
        //// 从TLS中获取SyncData
        // ....
    }
#endif

    // Check per-thread cache of already-owned locks for matching object
    SyncCache *cache = fetch_cache(NO);
    if (cache) {
        //// 步骤 3
        //// 从cache中获取SyncData
        // ....
    }

    // 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();
    {
        //// 步骤 4
        //// 在全局的listp中查找object对应的SyncData,并修改
        // ....
    }

    //// 步骤 5
    //// 创建新的SyncData,并头插至listp链表

    // malloc a new SyncData and add to list.
    // XXX calling malloc with a global lock held is bad practice,
    // might be worth releasing the lock, mallocing, and searching again.
    // But since we never free these guys we won't be stuck in malloc very often.
    result = (SyncData*)calloc(sizeof(SyncData), 1);
    result->object = (objc_object *)object;
    result->threadCount = 1;
    new (&result->mutex) recursive_mutex_t();
    result->nextData = *listp;
    *listp = result;
    
 done:
    lockp->unlock();
    if (result) {
        //// 步骤 6
        //// 在TLS、cache中存储新创建的SyncData
    }

    return result;
}

具体实现可查苹果源码:https://opensource.apple.com/source/objc4/objc4-680/runtime/objc-sync.mm

步骤1 — 获取listp,及对其操作的锁lockp
spinlock_t *lockp = &LOCK_FOR_OBJ(object);
SyncData **listp = &LIST_FOR_OBJ(object);

// 两个宏的定义
#define LOCK_FOR_OBJ(obj) sDataLists[obj].lock
#define LIST_FOR_OBJ(obj) sDataLists[obj].data
static StripedMap<SyncList> sDataLists;

其中,StripedMap是一个哈希表:

template<typename T>
class StripedMap {
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
    enum { StripeCount = 8 };
#else
    enum { StripeCount = 64 };
#endif
    // 内部有一个T类型的value值
    struct PaddedT {
        T value alignas(CacheLineSize);
    };
    // array来存储PaddedT
    PaddedT array[StripeCount];
    // 哈希函数
    static unsigned int indexForPointer(const void *p) {
        uintptr_t addr = reinterpret_cast<uintptr_t>(p);
        return ((addr >> 4) ^ (addr >> 9)) % StripeCount;
    }

 public:
    T& operator[] (const void *p) { 
        return array[indexForPointer(p)].value; 
    }
// ...

StripedMap 内部是一个容量为8的数组,存储T类型的数据,当前存储的就是SyncList

struct SyncList {
    SyncData *data;
    spinlock_t lock;
    constexpr SyncList() : data(nil), lock(fork_unsafe_lock) { }
};

以上两个宏的主要作用是,通过哈希算法得出obj所在的SyncList,进一步取出对应的data和一把针对listpspinlock_t锁

步骤2 — 从TLS中获取SyncData
#if SUPPORT_DIRECT_THREAD_KEYS
    // Check per-thread single-entry fast cache for matching object
    // 检查单独线程的快速缓存
    bool fastCacheOccupied = NO;
    // 通过tls来获取SyncData
    SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
    if (data) {
        fastCacheOccupied = YES;
    // 校验取出的data是否和此次的object一致
        if (data->object == object) {
            // Found a match in fast cache.
            uintptr_t lockCount;

            result = data;
            // 获取当前线程中对于object的加锁次数,因为是递归锁,所以存在多次加锁
            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: {
            // ACQUIRE类型表示新增加了一次锁
                lockCount++;
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                break;
            }
            case RELEASE:
            // RELEASE表示此次加锁结束了
                lockCount--;
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                // 0代表当前线程已经没有针对object加锁,此时thread_count需要减一
                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;
        }
    }
#endif

从当前线程的本地存储 TLS 中快速查找 obj 对应的 SyncData,若找到,则根据传入的参数ACQUIRE/RELEASE 来修改 lockCount 以及 threadCount,同时更新tls中的值。

步骤3 — 从cache中获取SyncData

如果tls中没有找到对应的SyncData,会进入步骤3:

// 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;
            // 遍历cache查找object对应的cacheItem
            // 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;
        }
    }

顺带看一下 SyncCacheItem、fetch_cache 的实现:

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

static SyncCache *fetch_cache(bool create)
{
    _objc_pthread_data *data;

    data = _objc_fetch_pthread_data(create);
    if (!data) return NULL;

    if (!data->syncCache) {
        if (!create) {
            return NULL;
        } else {
            // 默认缓存容量为4
            int count = 4;
            data->syncCache = (SyncCache *)
                calloc(1, sizeof(SyncCache) + count*sizeof(SyncCacheItem));
            data->syncCache->allocated = count;
        }
    }

    // Make sure there's at least one open slot in the list.
    // 扩容
    if (data->syncCache->allocated == data->syncCache->used) {
        data->syncCache->allocated *= 2;
        data->syncCache = (SyncCache *)
            realloc(data->syncCache, sizeof(SyncCache) 
                    + data->syncCache->allocated * sizeof(SyncCacheItem));
    }

    return data->syncCache;
}

可以发现,其实和步骤2类似,步骤3会从 SyncCache 中取出对应的 SyncData,之后进行步骤2中类似的处理。

步骤4 — 查找并修改全局listp中与object对应的SyncData

若cache还没有创建,那么需要从全局的listp链表中寻找Syncdata,如果这也没找到,但是找到了空结点,就对空结点进行赋值。

// 加锁
lockp->lock();

    {
        SyncData* p;
        SyncData* firstUnused = NULL;
        // 在全局的listp链表中查找object对应的SyncData
        for (p = *listp; p != NULL; p = p->nextData) {
            if ( p->object == object ) {
                result = p;
                // atomic because may collide with concurrent RELEASE
                // 找到说明当前线程是第一次对object进行加锁,此时需要threadCount+1
                OSAtomicIncrement32Barrier(&result->threadCount);
                goto done;
            }
            // 如果当前结点的threadCount为0,即当前结点对应的object没有一条线程有加锁操作
            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;
        }
    }

其中,可能会找到了空结点,这个空结点挺有意思。

步骤5 — 创建新的SyncData,并头插至listp链表

紧接着上面的listp查找,如果listp没有空结点,只能创建新的结点,并头插至链表listp中:

// 链表中的结点都被占用,此时只能创建新的结点了
    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);
    // 头插法插入到当前的listp链表中
    result->nextData = *listp;
    *listp = result;
步骤6 — 在TLS、cache中存储新建的SyncData
done:
    // 此时object对应的syncdata已经创建完毕,并且存储完成,对于多线程已经没有了风险,可以解锁了
    lockp->unlock();
    if (result) {
        ...
#if SUPPORT_DIRECT_THREAD_KEYS
    // 如果快速缓存即tls还没有被占用,存储快速缓存中
        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
    // 否则存储到线程的缓存syncCache中
        {
            // Save in thread cache
            // cache不存在的话需要先创建cache
            if (!cache) cache = fetch_cache(YES);
            cache->list[cache->used].data = result;
            cache->list[cache->used].lockCount = 1;
            cache->used++;
        }
    }
    return result;
id2data总结

关于 id2data 方法,其本质就是一个找object对应的SyncData的过程,先从tls即fast cache中找,再从线程的syncCache中找,最后从全局的listp链表中找,都找不到的话只能自己创建,然后存储到对应的位置。

StripedMap、listp 和 SyncData 的存储结构

从前面的代码可以看到,在ios系统中,全局的哈希表容量为8:

@synchronized数据之间的详细关系
id2data方法的完整调用流程

在分析过 id2data 后,回头在看 objc_sync_enter、objc_sync_exit 就比较简单了,也是找到对应的 SyncData,获取到递归互斥锁,然后进行加/解锁。

4. @synchronized 注意事项

以下代码意图在多线程中对_testArray进行初始化操作,在执行过程中出现了崩溃:

崩溃原因是同时有两条线程执行了赋值代码时,导致原有的_testArray旧值被释放了两次。
我们对操作加@synchronized锁,仍然出现了崩溃:

主要原因是以_testArray为参数加锁,当 _testArray 发生变化之后,在后续的线程和之前的线程中加锁的对象已经发生了变化,导致不同的线程取出了不一样的syncData,也导致锁的失效,从而引发了后续的崩溃问题。

如果我们针对self进行加锁,就可以避免这个问题。

参考文章:
https://juejin.cn/post/6903162266489880584
https://juejin.cn/post/6844904086161063944
//www.greatytc.com/p/a816e8cf3646

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,204评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,091评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,548评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,657评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,689评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,554评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,302评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,216评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,661评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,851评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,977评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,697评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,306评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,898评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,019评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,138评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,927评论 2 355

推荐阅读更多精彩内容