前言
鎖，在我們的iOS開發(fā)中還是經(jīng)常用到的翰苫，特別是在一些多線程的安全訪問方面提供了提供了便捷的方案止邮。鎖，分為自旋鎖,互斥鎖,讀寫鎖等類型奏窑。在iOS下导披，我們常見的鎖包括:@synchronized,NSLock,dispatch_semphore,NSCondition,NSConditionLock,NSRecursiveLock等。本篇文章我們就重點分析下@synchronized的本質(zhì)埃唯。
開始
首先從一個大家熟悉的賣票案例說起：
- (void)demo11
{
_totalCount = 20;
[self startSaleTicket];
}
- (void)startSaleTicket{
dispatch_async(dispatch_queue_create("queue_1", DISPATCH_QUEUE_CONCURRENT), ^{
for (int i = 0; i < 30; i++) {
[self saleTicket];
}
});
dispatch_async(dispatch_queue_create("queue_2", DISPATCH_QUEUE_CONCURRENT), ^{
for (int i = 0; i < 15; i++) {
[self saleTicket];
}
});
}
- (void)saleTicket{
if (_totalCount > 0) {
_totalCount--;
sleep(0.1);
NSLog(@"當(dāng)前余票還剩：%ld張",_totalCount);
}else{
NSLog(@"當(dāng)前車票已售罄");
}
}
以上代碼表示有兩個并發(fā)隊列同時執(zhí)行異步的買票任務(wù)撩匕，這就意味著saleTicket在某個時刻或者多個時刻同時被多個任務(wù)訪問，而導(dǎo)致數(shù)據(jù)的不同步墨叛，從而導(dǎo)致數(shù)據(jù)的不安全止毕。輸出結(jié)果：
2020-11-09 16:29:05.728246+0800 TestApp[13533:7920231] 當(dāng)前余票還剩：18張
2020-11-09 16:29:05.728246+0800 TestApp[13533:7920234] 當(dāng)前余票還剩：19張
2020-11-09 16:29:05.728464+0800 TestApp[13533:7920234] 當(dāng)前余票還剩：17張
2020-11-09 16:29:05.728464+0800 TestApp[13533:7920231] 當(dāng)前余票還剩：17張
2020-11-09 16:29:05.728604+0800 TestApp[13533:7920234] 當(dāng)前余票還剩：16張
2020-11-09 16:29:05.728624+0800 TestApp[13533:7920231] 當(dāng)前余票還剩：15張
2020-11-09 16:29:05.728750+0800 TestApp[13533:7920234] 當(dāng)前余票還剩：13張
2020-11-09 16:29:05.728752+0800 TestApp[13533:7920231] 當(dāng)前余票還剩：13張
2020-11-09 16:29:05.728925+0800 TestApp[13533:7920234] 當(dāng)前余票還剩：12張
2020-11-09 16:29:05.729969+0800 TestApp[13533:7920231] 當(dāng)前余票還剩：11張
2020-11-09 16:29:05.730211+0800 TestApp[13533:7920234] 當(dāng)前余票還剩：10張
...............省略一些打印數(shù)據(jù)...............
2020-11-09 16:29:05.733704+0800 TestApp[13533:7920231] 當(dāng)前余票還剩：1張
2020-11-09 16:29:05.734041+0800 TestApp[13533:7920234] 當(dāng)前余票還剩：0張
2020-11-09 16:29:05.735104+0800 TestApp[13533:7920231] 當(dāng)前車票已售罄
2020-11-09 16:29:05.735527+0800 TestApp[13533:7920234] 當(dāng)前車票已售罄
2020-11-09 16:29:05.735923+0800 TestApp[13533:7920231] 當(dāng)前車票已售罄
從輸出的結(jié)果可以看到，整個數(shù)據(jù)一開始就發(fā)生了錯誤巍实。接下來我們使用@synchronized給saleTicket加鎖然后再執(zhí)行：
- (void)saleTicket{
@synchronized (self) {
if (_totalCount > 0) {
_totalCount--;
sleep(0.1);
NSLog(@"當(dāng)前余票還剩：%ld張",_totalCount);
}else{
NSLog(@"當(dāng)前車票已售罄");
}
}
}
2020-11-09 16:31:46.802605+0800 TestApp[13600:7921875] 當(dāng)前余票還剩：19張
2020-11-09 16:31:46.802823+0800 TestApp[13600:7921875] 當(dāng)前余票還剩：18張
2020-11-09 16:31:46.803009+0800 TestApp[13600:7921875] 當(dāng)前余票還剩：17張
2020-11-09 16:31:46.803180+0800 TestApp[13600:7921874] 當(dāng)前余票還剩：16張
2020-11-09 16:31:46.803327+0800 TestApp[13600:7921874] 當(dāng)前余票還剩：15張
2020-11-09 16:31:46.803493+0800 TestApp[13600:7921875] 當(dāng)前余票還剩：14張
................省略一些打印數(shù)據(jù).................
2020-11-09 16:31:46.809983+0800 TestApp[13600:7921874] 當(dāng)前余票還剩：1張
2020-11-09 16:31:46.810512+0800 TestApp[13600:7921874] 當(dāng)前余票還剩：0張
2020-11-09 16:31:46.811509+0800 TestApp[13600:7921874] 當(dāng)前車票已售罄
2020-11-09 16:31:46.812906+0800 TestApp[13600:7921874] 當(dāng)前車票已售罄
2020-11-09 16:31:46.813443+0800 TestApp[13600:7921874] 當(dāng)前車票已售罄
此時的打印結(jié)果就不會出現(xiàn)異常的數(shù)據(jù)了滓技。那@synchronized是怎么做到的吶？內(nèi)部都做了些什么棚潦？
我們首先通過斷點并打開Always Show Disassembly來看下匯編的信息令漂，是否有一些線索：
從匯編中，能看到的是在執(zhí)行前后多了
objc_sync_enter 和objc_sync_exit指令，可能有用先記錄下叠必。接下來我們通過
clang來看下@synchronized最終轉(zhuǎn)化為了什么：首先荚孵，我們在
main.m中，添加幾行代碼：
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
@autoreleasepool {
// Setup code that might create autoreleased objects goes here.
appDelegateClassName = NSStringFromClass([AppDelegate class]);
}
@synchronized (appDelegateClassName) {
NSLog(@"@synchronized");
}
return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
通過clang編譯后的代碼：
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
/* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool;
appDelegateClassName = NSStringFromClass(((Class (*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("AppDelegate"), sel_registerName("class")));
}
{ 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((NSString *)&__NSConstantStringImpl__var_folders_yy_htpy_x9s09v1zf7ms0jgytwr0000gn_T_main_54c387_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);}
}
return UIApplicationMain(argc, argv, __null, appDelegateClassName);
}
比較凌亂纬朝，我們整理一下：
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
/* @autoreleasepool */
{ __AtAutoreleasePool __autoreleasepool;
appDelegateClassName = NSStringFromClass(((Class (*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("AppDelegate"), sel_registerName("class")));
}
/* @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((NSString *)&__NSConstantStringImpl__var_folders_yy_htpy_x9s09v1zf7ms0jgytwr0000gn_T_main_54c387_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);
}
}
return UIApplicationMain(argc, argv, __null, appDelegateClassName);
}
這里第一個作用域的內(nèi)容是關(guān)于@autoreleasepool相關(guān)的收叶，關(guān)于這部分內(nèi)容可以直接看我的iOS-OC底層-@autoreleasepool分析 這篇文章。第二個作用域中的內(nèi)容就是關(guān)系@synchronized了共苛，還是挺復(fù)雜的??判没。這里我們并不需要看太多：
1.首先需要注意到的是objc_sync_enter(_sync_obj);這跟在匯編看到的是一致的
2.然后是一個try{}包裹邏輯，內(nèi)部有一個struct _SYNC_EXIT結(jié)構(gòu)體隅茎，并且包換一個構(gòu)造方法_SYNC_EXIT(id arg)和析構(gòu)方法~_SYNC_EXIT(),
3._sync_exit(_sync_obj);初始化結(jié)構(gòu)體執(zhí)行_SYNC_EXIT(id arg)
4.NSLog()澄峰，這是需要加鎖的代碼塊主體。
5.當(dāng)try{}執(zhí)行完時辟犀，會觸發(fā)結(jié)構(gòu)體的~_SYNC_EXIT()的析構(gòu)方法俏竞，即objc_sync_exit(sync_exit)方法。
所以這里簡單的理解就是：
objc_sync_enter(_sync_obj) ->代碼主體 -> objc_sync_exit(sync_exit)
而catch部分我們就不做分析了,當(dāng)發(fā)生異常后會執(zhí)行objc_exception_throw堂竟。
到此魂毁，我們需要探索的重點就鎖定在了objc_sync_enter()和objc_sync_exit()的兩個方法的具體實現(xiàn)中來，通過匯編跟蹤下這兩個方法在哪個庫中(以objc開頭出嘹，通常是在libobjc.dylib中)：
果不其然席楚，確實就在
libobjc中，查看源碼：
// 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;
}
這里的參數(shù)id obj其實就是@synchronized時傳入的參數(shù)疚漆；判斷obj是否存在酣胀，如果存在，就通過id2data()方法讀取一個SyncData* data娶聘，然后通過data->mutex.lock()來上鎖榨惠。這里要說一下mutex:
mutex：用于保證在任何時刻吹散，都只能有一個線程訪問該對象误堡。 當(dāng)獲取鎖操作失敗時佑颇，線程會進入睡眠，等待鎖釋放時被喚醒狡耻。
這也就意味著墩剖，@synchronized實質(zhì)上是一種(遞歸)互斥鎖。
而當(dāng)obj == nil時夷狰，即@synchronized(nil),看else內(nèi)部注釋：@synchronized(nil) does nothing
這里還是要看下objc_sync_nil()做了什么：
BREAKPOINT_FUNCTION(
void objc_sync_nil(void)
);
# define BREAKPOINT_FUNCTION(prototype) \
OBJC_EXTERN __attribute__((noinline, used, visibility("hidden"))) \
prototype { asm(""); }
這里是一個宏定義的實現(xiàn)岭皂，但內(nèi)部也沒有做什么實質(zhì)性的處理。
// 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;
}
再看下int objc_sync_exit(id obj)沼头，當(dāng)obj存在爷绘，同樣會通過id2data(obj, RELEASE)去獲取SyncData* data,如果存在,會通過data->mutex.tryUnlock();去解鎖书劝。當(dāng)obj不存在，則dose nothing土至。
從上面的源碼中我們可以發(fā)現(xiàn)购对，兩個方法內(nèi)部都調(diào)用了同樣的方法id2data(),
只是第二個傳參有所不同，一個是ACQUIRE陶因，一個是RELEASE骡苞。我們重點看下id2data()方法：
先預(yù)覽下這部分代碼：
我們把代碼大致分成如圖的4個部分：
-
#if SUPPORT_DIRECT_THREAD_KEYS .. #endif部分 -
SyncCache *cache = fetch_cache(NO);部分 -
lockp->lock();到lockp->unlock();部分 -
if(result)部分
這里我們要注意代碼注釋還是非常有價值的，首先是判斷是否支持DIRECT_THREAD_KEYS的方式讀取緩存楷扬，如果不支持就通過per-thread cache讀取緩存解幽；如果緩存中不存在則嘗試通過in-use list查找，找到后插入緩存毅否；如果都沒有亚铁，即第一次進入，則通過posix_memalign()創(chuàng)建新的SyncData螟加，最終寫入緩存。
static SyncData* id2data(id object, enum usage why)
{
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) {
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;
}
}
#endif
// 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;
}
}
// 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) {
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;
done:
lockp->unlock();
if (result) {
// Only new ACQUIRE should get here.
// All RELEASE and CHECK and recursive ACQUIRE are
// handled by the per-thread caches above.
if (why == RELEASE) {
// Probably some thread is incorrectly exiting
// while the object is held by another thread.
return nil;
}
if (why != ACQUIRE) _objc_fatal("id2data is buggy");
if (result->object != object) _objc_fatal("id2data is buggy");
#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++;
}
}
return result;
}
首先看第1部分：
這里先擴展一下TLS相關(guān)的概念：線程局部存儲(Thread Local Storage,TLS)吞琐，是操作系統(tǒng)為線程單獨提供的私有空間捆探，通常只有有限的容量。通常通過pthread庫中的：
pthread_key_create(),
pthread_getspecific(),
pthread_setspecific(),
pthread_key_delete()
等API來存取一些數(shù)據(jù)或保存一些狀態(tài)站粟。簡單的理解就是給線程也提供了一些KVC的存取操作的能力黍图。
這里主要存儲就是兩個值SYNC_DATA_DIRECT_KEY：SyncData *data和
SYNC_COUNT_DIRECT_KEY：uintptr_t lockCount。
這里先看下SyncData的數(shù)據(jù)結(jié)構(gòu)：
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;
SyncData內(nèi)部實際是是一個單鏈表結(jié)構(gòu)奴烙，每一個結(jié)構(gòu)都會指向nextData;
threadCount來記錄當(dāng)前線程數(shù)助被，object即傳入的參數(shù)，mutex核心的鎖結(jié)構(gòu)切诀。
接下來揩环，如果找到了data，將data賦值給result,同時將lockCount ++或者lockCount--幅虑，并通過tls_set_direct()更新到對應(yīng)的key丰滑。當(dāng)lockCount == 0時，會將線程緩存值SYNC_DATA_DIRECT_KEY置為NULL倒庵，同時threadCount --;
第2部分：
這里其實還是讀取緩存,還是先看下SyncCache數(shù)據(jù)結(jié)構(gòu)：
typedef struct {
SyncData *data;
unsigned int lockCount; // number of times THIS THREAD locked this block
} SyncCacheItem;
typedef struct SyncCache {
unsigned int allocated;
unsigned int used;
SyncCacheItem list[0];
} SyncCache;
只是這里查詢的結(jié)構(gòu)有所不同褒墨，其最終還是去查詢SyncData和lockCount。然后其他的增減邏輯就一模一樣了擎宝。
第三部分：
//Thread cache didn't find anything.
//Walk in-use list looking for matching object
第四部分：
// Allocate a new SyncData and add to list.
首次執(zhí)行郁妈，新創(chuàng)建SyncData,
// Save in fast thread cache
// Save in thread cache
最后通過一個圖標(biāo)來總結(jié)下：
從圖中可以看出：
- 鎖的內(nèi)部首先是一個
SyncCache結(jié)構(gòu)體，包含著一個list數(shù)組绍申，存放著SyncCacheItem類型的數(shù)據(jù)噩咪，該元素表示某一個線程被鎖定的任務(wù)锄奢； -
SyncCacheItem結(jié)構(gòu)包含一個SyncData *data,和int lockCount,其中lockCount記錄這這條線程上鎖的總數(shù)，data記錄著被鎖定的任務(wù)剧腻； -
SyncData,內(nèi)部包含了一個nextData拘央，也是SyncData類型，表示下一個被鎖定的任務(wù)书在，所以這里是一個單鏈表的結(jié)構(gòu)灰伟，來記錄整個任務(wù)鏈。
使用中的注意事項
@synchronized儒旬，由于需要各種鏈表的查詢栏账，創(chuàng)建等操作，所以在整個iOS鎖的性能排名上還是比較靠后的栈源。但由于它使用起來非常的簡單挡爵，而且不需要做額外的上鎖解鎖操作，所以在項目中使用頻率還是挺高的甚垦。
先寫一個案例：
- (void)demo33
{
for (int i = 0; i < 100000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
self->_testArray = [NSMutableArray array];
});
}
}
在執(zhí)行demo33時茶鹃，會發(fā)生EXC_ACCESS崩潰
這是由于多個異步線程在給
self.testArray賦值，即retain新值艰亮，release舊值闭翩，但在某一個瞬間，retain和release在多個異步線程的情況下迄埃，發(fā)生資源搶占疗韵，導(dǎo)致沒有成對執(zhí)行，而導(dǎo)致了release野指針的情況侄非，如下：
2020-11-10 16:37:08.198551+0800 TestApp[45349:8517346] @synchronized
2020-11-10 16:37:08.364108+0800 TestApp[45349:8517491] *** -[__NSArrayM release]: message sent to deallocated instance 0x6000032b0ae0
2020-11-10 16:37:08.364115+0800 TestApp[45349:8517494] *** -[__NSArrayM release]: message sent to deallocated instance 0x60000324cea0
接下來蕉汪，我們給代碼添加一個@synchronized鎖
- (void)demo33
{
for (int i = 0; i < 100000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
@synchronized (self.testArray) {
self.testArray = [NSMutableArray array];
}
});
}
}
此時還是發(fā)生了崩潰，
同樣是由于
objc_release去釋放了一個野指針導(dǎo)致逞怨。這里要注意的就是
@synchronized()的參數(shù)了者疤，self.testArray在多次的賦值過程中，在某個瞬間可能為nil骇钦，而@synchronized(nil)意味著加鎖失敗宛渐，就相當(dāng)于沒有鎖，所以這里崩潰的情況就跟之前的一樣了眯搭。再次修改代碼窥翩，把
@synchronized()傳入的參數(shù)修改為self:
- (void)demo33
{
for (int i = 0; i < 100000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
@synchronized (self) {
self.testArray = [NSMutableArray array];
}
});
}
}
此時執(zhí)行代碼，結(jié)果顯示正常鳞仙。
所以這里要注意寇蚊，當(dāng)使用@synchronized鎖時，要保證該鎖傳入的參數(shù)在使用期間不能為nil棍好，否則鎖將失去意義仗岸，比如這里使用生命周期更長的self允耿，但這里不僅限于self,只要保證在使用期間不為nil就是可以的。再者就是基于@synchronized的性能表現(xiàn)不是很好扒怖，所以還是盡量選擇其他鎖來替代它较锡。
總結(jié)
這篇文章有問題，寫的不好５裂鳌Ｂ煸獭！俯邓！摸不著頭腦Ｂ饴ァ！；蕖鸟整！謹慎閱讀！ｋ獭＠禾酢！
