我在支持原子属性的论点中是否遗漏了任何要点？答案

【问题标题】：Am I missing any points in my argument in favor of atomic properties?我在支持原子属性的论点中是否遗漏了任何要点？
【发布时间】：2013-02-15 18:59:18
【问题描述】：

我读过这个问题（以及其他几个问题）：

我完全理解（至少我希望如此 :-D）属性的原子/非原子说明符是如何工作的：

让我挑眉的是，人们分为两个阵营：

Pro atomic：使用nonatomic 仅用于性能优化是有意义的。

如果您不进行优化，那么由于第 1 点，您应该始终使用 atomic。这样，在多线程应用程序中读取此属性时，您不会得到一些完全的废话。当然，如果您关心第 2 点和第 3 点，则需要在其之上添加更多同步。

反对 atomic：使用 atomic 根本没有意义。

由于 atomic 并不能解决多线程应用程序中的所有问题，因此使用它根本没有意义，因为无论如何您都需要在其之上添加更多同步代码。它只会让事情变得更慢。

我倾向于亲原子阵营，但我想做一个健全的检查，我没有错过任何东西。

【问题讨论】：

好吧，我很懒，所以我只使用非原子并编写没有竞争条件的代码:) 但你决定，真的。我会选择“当你可以避免锁定时，为什么会有额外的开销，而且这还不够呢？”
恕我直言，现在有很多方法可以减少多线程应用程序中的状态（锁定）（NSOperations、GCD（在主线程上传递）、回调，甚至是 RAC），其中很多没有实际意义。我倾向于“在适当的时候使用”
问题到底是什么？一切都很好，你设定了一个坚实的前提，但你想要回答的具体问题是什么？如果它是“哪个阵营是正确的”，那么实际上并没有正确的答案（但是无论哪种方式都有很多错误的答案:)。
2bbum：主要是一个“健全性检查”问题。我只是想确保我没有错过任何重要的东西（我知道它有点不符合 SO 格式）。

【解决方案1】：

缺少一个非常具体的问题（尽管仍然是一个很好的问题），我将用个人经验来回答，FWIW。

一般来说，并发设计很难。借助 GCD 和 ARC 等现代便利，实现并发系统的工具无疑得到了改进。然而，并发的架构仍然非常困难。

而且，一般来说，困难的部分与个别属性无关；单独的 getter 和 setter。并发是在更高级别实现的东西。

当前最先进的技术是孤立的并发。也就是说，您的应用程序中同时运行的部分使用与应用程序其余部分的连接极少的对象的隔离图来执行此操作（通常，“连接”是通过捆绑一些状态和折腾的回调）它转移到其他队列，通常是用于更新 UI 的主队列）。

通过将并发表面积（代码中必须是并发安全的入口点的数量）保持在绝对最小值，您可以降低复杂性和调试时间，这非常奇怪，而且通常无法重现, 并发问题（这会影响你的理智）。

鉴于所有这些，原子属性的价值非常小。当然，它们对于应该是非常小的接口集（API）很有用，可能会被多个线程撞到，但仅此而已。

如果您有快速访问访问器的对象，将它们设为原子可能会显着影响性能，但过早的优化是魔鬼的手指。

【讨论】：