我对Objective-C中@synchronized(obj) { ... }指令的理解是它与C＃中的lock(obj) { ... }构造基本相同，即......
@synchronized / lock块的任何线程必须在执行块中的任何代码之前获取该互斥锁（并且如果它已经被保留，将等待获取互斥锁，然后再继续）。在C＃中，强烈建议不要使用lock(this)（请参阅Why is lock(this) {...} bad?）示例），主要是因为您无法控制谁锁定您的互斥锁或何时（因为其他人可能正在使用您的互斥锁）对象作为互斥体）。
我认为这个概念也适用于Objective-C中的@synchronized(self)，但我的团队的一位高级开发人员告诉我@synchronized的功能与lock不同，上述SO帖子中的问题不适用。
我想我的问题是 - 我对@synchronized的误解是什么？当@synchronized(self)不是时，为什么lock(this)会安全？
感谢。
答案 0 :(得分：0)
对事物有不同的态度。我快速浏览了你链接到的C＃答案，如果你用@synchronized做同样的事情，你就会被钉死在十字架上。您应该在绝对最短的时间内使用@synchronized，并且绝对不应该调用任何可以同时使用@synchronized的其他内容。遵守这条规则，你没事。我想在C＃中你会一样好，但在C＃中他们认为其他人做蠢事。
有一个避免死锁的简单策略（如果你遵循它）：有一组“0级”锁：当你持有“0级”锁时，你不能试图获得任何其他锁。然后你有一组“1级”锁：当你持有“1级”锁时，你可以获得一个“0级”锁，但没有别的。依此类推：如果您持有“等级n”锁定，则可能会获得较低级别的锁定，但不会获得相同或更高级别的锁定。 Voila：没有死锁可能。
不是0级的@synchronized非常罕见，你应该认真思考它。还有其他同步机制，如串行队列，也可以正常工作。