轉(zhuǎn)自?原文鏈接

無并發(fā)，不編碼。而只要一說到多線程或者并發(fā)的代碼，我們可能就很難繞開對(duì)于鎖的討論。簡單來說，為了在不同線程中安全地訪問同一個(gè)資源，我們需要這些訪問順序進(jìn)行。Cocoa 和 Objective-C 中加鎖的方式有很多，但是其中在日常開發(fā)中最常用的應(yīng)該是@synchronized，這個(gè)關(guān)鍵字可以用來修飾一個(gè)變量，并為其自動(dòng)加上和解除互斥鎖。這樣，可以保證變量在作用范圍內(nèi)不會(huì)被其他線程改變。舉個(gè)例子，如果我們有一個(gè)方法接受參數(shù)，需要這個(gè)方法是線程安全的話，就需要在參數(shù)上加鎖：

如果沒有鎖的話，一旦anObj的內(nèi)容被其他線程修改的話，這個(gè)方法的行為很可能就無法預(yù)測了。

但是加鎖和解鎖都是要消耗一定性能的，因此我們不太可能為所有的方法都加上鎖。另外其實(shí)在一個(gè) app 中可能會(huì)涉及到多線程的部分是有限的，我們也沒有必要為所有東西加上鎖。過多的鎖不僅沒有意義，而且對(duì)于多線程編程來說，可能會(huì)產(chǎn)生很多像死鎖這樣的陷阱，也難以調(diào)試。因此在使用多線程時(shí)，我們應(yīng)該盡量將保持簡單作為第一要?jiǎng)?wù)。

扯遠(yuǎn)了，我們回到@synchronized上來。雖然這個(gè)方法很簡單好用，但是很不幸的是在 Swift 中它已經(jīng) (或者是暫時(shí)) 不存在了。其實(shí)@synchronized在幕后做的事情是調(diào)用了objc_sync中的objc_sync_enter和objc_sync_exit方法，并且加入了一些異常判斷。因此，在 Swift 中，如果我們忽略掉那些異常的話，我們想要 lock 一個(gè)變量的話，可以這樣寫：

更進(jìn)一步，如果我們喜歡以前的那種形式，甚至可以寫一個(gè)全局的方法，并接受一個(gè)閉包，來將objc_sync_enter和objc_sync_exit封裝起來：

再結(jié)合 Swift 的尾隨閉包的語言特性，這樣，使用起來的時(shí)候就和 Objective-C 中很像了：