前言:

??在Objective-C中儒将，如果有多個線程要執(zhí)行同一份代碼沉噩，那么有時候會出問題捺宗。這種情況下，通常使用鎖來實現(xiàn)某種同步機制川蒙。在GCD出現(xiàn)之前蚜厉，有兩種方法，第一種采用內(nèi)置的"同步塊"(synchronization block):

-(void)synchronizedMethod{
@synchronized(self){
//Safe
}
}
??這種寫法會根據(jù)給定的對象畜眨，自動創(chuàng)建一個鎖昼牛，并等待塊中的代碼執(zhí)行完畢。執(zhí)行到這段代碼結(jié)尾處康聂，鎖就釋放了贰健。在本例中，同步行為所針對的對象是self恬汁。這么寫通常沒錯伶椿，因為它可以保證每個對象實例都能不受干擾地運行其synchronizedMethod方法。然而氓侧，濫用@synchronized(self)則會降低代碼效率脊另，因為共用同一個鎖的那些同步塊，都必須按順序執(zhí)行约巷。若是在self對象上頻繁加鎖尝蠕，那么程序可能等另一段與此無關(guān)的代碼執(zhí)行完畢，才能繼續(xù)執(zhí)行當前代碼载庭，這樣做其實并沒有必要看彼。

另一個辦法是直接使用NSLock對象：

_lock = [[NSLock alloc] init];

-(void)synchronizedMethod{
[_lock lock];
//Safe
[_lock unlock];
}

??也可以使用NSRecursiveLock 這種遞歸鎖(recursive lock)廊佩，線程能夠多次持有該鎖，而不會出現(xiàn)死鎖(deadlock)現(xiàn)象靖榕。
??這兩種方法都很好标锄，不過也有其缺陷。比方說茁计，在極端情況下料皇，同步塊會導致死鎖，另外星压，其效率也不見得很高践剂，而如果直接使用鎖對象的話，一旦遇到死鎖娜膘，就會非常麻煩逊脯。
??替代方案就是使用GCD，它能以更簡單竣贪、更高效的形式為代碼加鎖军洼。比方說，屬性就是開發(fā)者經(jīng)常需要同步的地方演怎，這種屬性需要做成原子的匕争。用atomic特性來修飾屬性，即可實現(xiàn)這一點爷耀。而開發(fā)者如果想自己編寫訪問方法的話甘桑，那么通常會這樣寫：

-(void)someString{
@synchronized(self){
return _someString;
}
}

-(void)setSomeString:(NSString *)someString{
@synchronized(self){
_someString = someString;
}
}

??剛才說過，濫用@synchronized(self)會很危險歹叮，因為所有同步塊都會彼此搶奪同一個鎖跑杭。要是有很多屬性都這么寫的話，那么每個屬性的同步塊都要等其他所有同步塊執(zhí)行完畢才能執(zhí)行盗胀，這也許并不是開發(fā)者想要的效果。我們只是想令每個屬性各自獨立地同步锄贼。
??順便說一下票灰，這么做雖然能提供某種程度的線程安全，但卻無法保證訪問該對象時該對象絕對是線程安全的宅荤。當然屑迂，訪問屬性的操作確實是原子的。使用屬性時冯键，必定能從中獲取到有效值惹盼，然而在同一個線程上多次調(diào)用獲取方法（getter），每次獲取到的結(jié)果卻未必相同惫确。在兩次訪問操作之間手报，其他線程可能會寫入新的屬性值蚯舱。
??有種簡單而高效的方法可以替代同步塊或鎖對象，那就是使用"串行同步隊列"（serial synchronization queue）掩蛤。將讀取操作以及寫入操作都安排在同一個隊列中枉昏，即可保證數(shù)據(jù)同步。
其用法如下：

_syncQueue = dispatch_queue_create("com.effective.syncQueue",NULL);
-(NSString *)someString{
__block NSString *localSomeString;
dispatch_sync(_syncQueue,^{
localSomeString = _someString;
});
}
-(void)setSomeString:(NSString *)someString{
dispatch_sync(_syncQueue,^{
_someString = someString;
});
}
??此模式的思路是：把設置操作與獲取操作都安排在序列化隊列里執(zhí)行揍鸟，這樣的話兄裂，所有針對屬性的訪問操作就都同步了。為了使塊代碼能夠設置局部變量阳藻，獲取方法中用到了__block語法晰奖，若是拋開這一點，那么這種寫法要比前面那些更為簡潔腥泥。全部加鎖任務都在GCD中處理匾南，而GCD是在相當深的底層來實現(xiàn)的，于是能夠做許多優(yōu)化道川。因此午衰，開發(fā)者無須擔心那些事，只要專心把訪問方法寫好就行冒萄。
??然而還可以進一步優(yōu)化臊岸。設置方法并不一定非得是同步的。設置實例變量所用的塊尊流，并不需要想設置方法返回什么值帅戒。也就是說，設置方法的代碼可以改成下面這樣:

-(void)setSomeString:(NSString *)someString{
dispatch_async(_syncQueue,^{
_someString = someString;
});
}

??這次只是把同步派發(fā)改成了異步派發(fā)崖技，從調(diào)用者的角度來看逻住，這個小改動可以提升設置方法的執(zhí)行速度，而讀取操作與寫入操作依然會按順序執(zhí)行迎献。但這么改有個壞處：如果你測一下程序性能瞎访，那么可能會發(fā)現(xiàn)這種寫法比原來慢，因為執(zhí)行異步派發(fā)時吁恍，需要拷貝塊扒秸。若拷貝塊所用的事件明顯超過執(zhí)行塊所花的事件，則這種做法將比原來更慢冀瓦。由于本書所舉的這個例子很簡單伴奥，所以改完之后很可能會變慢。然而翼闽，若是派發(fā)給隊列的塊要執(zhí)行更為繁重的任務拾徙，那么仍然可以考慮這種備選方案。
??多個獲取方法可以并發(fā)執(zhí)行感局，而獲取方法與設置方法之間不能并發(fā)執(zhí)行尼啡，利用這個特點暂衡，還能寫出更快一些的代碼來。此時正可以提現(xiàn)GCD寫法的好處來玄叠。用同步塊或鎖對象古徒，是無法輕易實現(xiàn)下面這種方案的。這次不用串行隊列读恃，而改用并發(fā)隊列隧膘。(concurrent queue)

_syncQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0);
-(NSString *)someString{
__block NSString *localSomeString;
dispatch_sync(_syncQueue,^{
localSomeString = _someString;
});
}
-(void)setSomeString:(NSString *)someString{
dispatch_async(_syncQueue,^{
_someString = someString;
});
}

??像現(xiàn)在這樣寫代碼，還無法正確實現(xiàn)同步寺惫。所有讀操作與寫入操作都會在同一個隊列中執(zhí)行疹吃，不過由于是并發(fā)隊列，所以讀取與寫入操作可以隨時執(zhí)行西雀。而我們恰恰不想讓這些操作隨意執(zhí)行萨驶。此問題用一個簡單的GCD功能即可解決，它就是柵欄(barrier)艇肴。下列函數(shù)可以向隊列中派發(fā)塊腔呜，將其作為柵欄使用：

void dispatch_barrier_async(dispatch_queue_t queue, dispatch_block_t block);
void dispatch_barrier_sync(dispatch_queue_t queue, dispatch_block_t block);

??在隊列中，柵欄塊必須單獨執(zhí)行再悼，不能與其他塊并行核畴。這只對并發(fā)隊列有意義，因為串行隊列中的塊總是按順序逐個執(zhí)行的冲九。并發(fā)隊列如果發(fā)現(xiàn)接下來要處理的塊是個柵欄塊(barrier block)谤草，那么就一直要等待當前所有并發(fā)塊都執(zhí)行完畢，才會單獨執(zhí)行這個柵欄塊莺奸。待柵欄塊執(zhí)行過后丑孩，再按正常方法繼續(xù)向下處理。

??在本例中灭贷，可以用柵欄塊來實現(xiàn)屬性的設置方法温学。在設置方法中使用了柵欄塊之后，對屬性的讀取操作依然可以并發(fā)執(zhí)行甚疟，但是寫入操作卻必須單獨執(zhí)行了仗岖。實現(xiàn)代碼如下:

_syncQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0);
-(NSString *)someString{
__block NSString *localSomeString;
dispatch_sync(_syncQueue,^{
localSomeString = _someString;
});
return localSomeString;
}
-(void)setSomeString:(NSString *)someString{
dispatch_barrier_async(_syncQueue,^{
_someString = someString;
});
}

在這個并發(fā)隊列中，讀取操作是用普通的塊來實現(xiàn)的古拴，而寫入操作則是用柵欄塊來實現(xiàn)的箩帚。讀取操作可以并行真友，但寫入操作必須單獨執(zhí)行黄痪，因為它是柵欄塊

??測試一下性能，你就會發(fā)現(xiàn)盔然，這種做法肯定比使用串行隊列要快桅打。注意設置函數(shù)也可以改用同步的柵欄塊（synchronous barrier）來實現(xiàn)是嗜，那樣做可能會更高效，原因執(zhí)行異步派發(fā)挺尾，需要拷貝塊鹅搪。最好還是測一測每種做法的性能，然后從中選出最適合當前場景的方案遭铺。

總結(jié):

*派發(fā)隊列可用來表示同步語義(synchronization semantic)丽柿，這種做法要比使用@synchronized塊或NSLock對象更簡單

*將同步與異步派發(fā)結(jié)合起來，可以實現(xiàn)與普通加鎖機制一樣的同步行為魂挂，而這么做卻不會阻塞執(zhí)行異步派發(fā)的線程甫题。

*使用同步隊列及柵欄塊，可以令同步塊行為更為高效涂召∽狗牵總之，多用派發(fā)隊列果正，少用同步鎖炎码。