将如下代码clang查看一下
self.lockA = [[NSObject alloc] init];
@synchronized(self.lockA) {
NSLog(@"lockA");
};
得到如下结果:@Synchronized会变成一对基于try-catch的objc_sync_enter和objc_sync_exit的代码
((void (*)(id, SEL, NSObject *))(void *)objc_msgSend)((id)self, sel_registerName("setLockA:"), ((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("NSObject"), sel_registerName("alloc")), sel_registerName("init")));
{ id _rethrow = 0; id _sync_obj = (id)((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)self, sel_registerName("lockA")); 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_8k_blmkswp957j3hbcpmjdtsvhw0000gn_T_TestSynchronized_ae1d39_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);}
};
既然如此,我么可以来看看objc_sync_enter内部做了什么。通过源码我们可以找到:
int result = OBJC_SYNC_SUCCESS;
if (obj) {
SyncData* data = id2data(obj, ACQUIRE);
require_action_string(data != NULL, done, result = OBJC_SYNC_NOT_INITIALIZED, "id2data failed");
result = recursive_mutex_lock(&data->mutex);
require_noerr_string(result, done, "mutex_lock failed");
} 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();
}
done:
return result;
可以看到,源码中现将obj转换成SyncData,然后开启了SyncData的mutex锁。并且@synchronized(nil)不起任何作用,SyncData结构体如下:
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;
• mutex,一把递归锁,这也是为什么我们可以在@Synchronized里面嵌套@Synchronized的原因。
• DisguisedPtr,这里DisguisedPtr其实就是对裸对象指针objc_object的一层包装改写。用于对象释放后指向的指针。
通过这边文章http://satanwoo.github.io/2019/01/01/Synchronized/可知,id2data函数内部实现会生成一个SyncList链表来管理SyncData,每一次都在多线程中执行如下代码:
- (void)test
{
@synchronized (self.testArray) {
self.testArray = @[].mutableCopy;
}
}
testArray每次都会被赋予不同的值。例如当前节点为SyncDataO,A线程现在生成新的SyncDataA节点(同时B线程在等待A修改完毕并解锁),当新的节点产生后,下一个B线程执行SyncDataO节点上的处理(因为SyncDataA生成过程中,该线程一直在等待,但是此时后者已经获取到了SyncDataO),那么当再次进来一个新的线程C执行新的更改时,获取到的SyncDataC与SyncDataO不是同个节点,那么也就不是同一个锁,这时这两者可以同时运行。参考setter内部代码实现:(代码来自http://satanwoo.github.io/2019/01/01/Synchronized/)
static inline void reallySetProperty(id self, SEL _cmd, id newValue,
ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
id oldValue;
// 计算结构体中的偏移量
id *slot = (id*) ((char*)self + offset);
if (copy) {
newValue = [newValue copyWithZone:NULL];
} else if (mutableCopy) {
newValue = [newValue mutableCopyWithZone:NULL];
} else {
// 某些程度的优化
if (*slot == newValue) return;
newValue = objc_retain(newValue);
}
// 危险区
if (!atomic) {
// 第一步
oldValue = *slot;
// 第二步
*slot = newValue;
} else {
spin_lock_t *slotlock = &PropertyLocks[GOODHASH(slot)];
_spin_lock(slotlock);
oldValue = *slot;
*slot = newValue;
_spin_unlock(slotlock);
}
objc_release(oldValue);
}
可知,当setter完成后,我们会释放oldValue,但是
oldValue = *slot; id *slot = (id*) ((char*)self + offset);
也就是说*slot的值有可能都是SyncDataK的值,那么就有可能出现objc_release的可能是同一块内存,也就会出现double free导致崩溃。
总结:对于@Synchronized(obj)的使用,尽量保证传入的obj对象不会再锁中被更改,同时多个不同的更改应该建立不同的obj。例如
@Synchronized(lockA){
self.A = xxx;
};
@Synchronized(lockB){
self.B = xxx;
};
其本身的性能问题在目前来看,并不是我们应该优先考虑的点,相比直接用NSLock,还是@Synchronized略快。所以我们在使用过程中,尽量避免在@Synchronized代码块中进行耗时操作即可,
文章参考:
http://www.cocoachina.com/ios/20161205/18279.html
http://satanwoo.github.io/2019/01/01/Synchronized/