爲什麼Objective-C中的@synchronized（self）不像鎖（這是C＃中的）？

Question

我在Objective-C的@synchronized(obj) { ... }指令的理解是，它本質上是一樣的lock(obj) { ... }結構在C＃中，即..

• 雙方創造一種局部的，匿名的互斥體綁在指定對象的
• 任何線程輸入@synchronized/lock塊都必須在執行塊中的任何代碼之前獲取該互斥體（並且如果它已經保留，將在繼續之前等待獲取該互斥體）。

在C＃中，使用lock(this)強烈反對（見Why is lock(this) {...} bad?）爲例），主要是因爲你再有超過誰鎖住你的互斥或沒有控制的情況下（因爲別人可以用你的對象作爲一個互斥體） 。

我認爲這個概念也適用於@synchronized(self)在Objective-C，但有人告訴我，由一位資深開發商在我的球隊是@synchronized功能不同於lock，並在上面SO後的擔憂並不適用。

我想我的問題是 - 我對@synchronized有什麼誤解？爲什麼@synchronized(self)安全lock(this)不是？

謝謝。

Answer 1

對事物有不同的態度。我快速瀏覽了您鏈接的C＃答案，如果您使用@synchronized做了同樣的事情，那麼您將被釘十字架。你應該使用@synchronized的時間絕對最少，並且你絕對不應該調用任何可以同時使用@synchronized的其他東西。遵守這個規則，你很好。我想在C＃中你會一樣好，但是在C＃中他們假設其他人做愚蠢的事情。

有一個簡單的策略，以避免死鎖（如果你按照它）：有一組「零級」鎖：當你持着「零級」鎖住你不能試圖獲得其它任何鎖。然後你有一套「1級」鎖：當你持有「1級」鎖時，你可以獲得一個「0級」鎖，但沒有別的。依此類推：如果你持有一個「n級」鎖，你可以在較低的級別獲得鎖，但是沒有任何級鎖。 Voila：沒有可能的僵局。

@synchronized不在級別0將是非常罕見的，你應該認真考慮它。還有其他同步機制，如串行隊列，也可以很好地工作。