我明白，atomic的含义解释为原子属性和非原子属性之间的区别是什么？但我想知道的是：

问：除了性能问题，在任何地方使用原子属性都有什么副作用吗？

答案似乎是否定的，因为现在iPhone的性能相当快。那么为什么有那么多人还在使用non-atomic？

即使是atomic也不能保证线程安全，但它仍然比什么都没有要好，对吗？

Even atomic does not guarantee thread safety, but it's still better than nothing, right?

错了。编写了一些非常复杂的并发程序之后，我建议使用完全相反的方法。您应该保留atomic，以便在真正有意义的时候使用，并且在不使用atomic编写并发程序之前，您可能无法完全理解这一点。如果我正在编写一个多线程程序，我不希望程序错误被屏蔽(例如，竞争条件)。我希望并发性问题清晰明了。这样，它们更容易识别、复制和更正。

认为某些线程安全性比没有好的信念是有缺陷的。程序要么是线程安全的，要么不是。使用Atomic可以使程序的这些方面对并发性相关的问题更具抵抗力，但这并不能给您带来多少好处。当然，崩溃可能会减少，但程序仍然毫无疑问是错误的，它仍然会以神秘的方式爆炸。我的建议是：如果你不想花时间去学习和编写正确的并发程序，只需保持它们的单线程(如果这听起来有点刺耳：这并不意味着刺耳-它会让你免于很多头痛)。多线程和并发是一个庞大而复杂的主题——要学会在许多领域中编写真正正确、长寿的程序需要很长时间。

当然，在某些情况下，可以使用atomic来实现线程安全性，但使每个访问原子都不能保证线程安全性。此外，单靠atomic属性就可以使类真正具有线程安全性是非常罕见的(统计上的)，特别是当类的复杂性增加时；使用一个ivar的类比使用5个ivar的类更可能是真正安全的。atomic属性是我很少使用的一个特性(同样，一些相当大的代码基和并发程序)。如果原子能使类真正具有线程安全性，那么这实际上是一个小问题。

性能和执行复杂性是避免它们的主要原因。与非原子访问相比，访问原子变量的频率和简单性，原子的使用加起来非常快。也就是说，原子访问相对于执行的任务引入了许多执行复杂性。

自旋锁是实现原子属性的一种方式。那么，如果知道同步原语不能保证线程安全，您是否希望同步原语(如spin锁或mutex)隐式地围绕每个get和set？我当然不会！使实现中的每个属性访问都是原子的，可能会消耗大量的CPU时间。只有当您有明确的理由这样做时才应该使用它(也被dasbinkellicht+1提到)。实现细节：有些访问不需要自旋锁来支持atomic的保证；它依赖于一些东西，比如架构和变量的大小。

所以回答你的问题"有副作用吗？"在tl；dr格式中：正如您所指出的，性能是主要原因，而原子保证的适用性以及它对您的有用性在抽象级别上非常狭窄(经常被误解)，并且它掩盖了真正的错误。

你不应该为你不使用的东西付钱。与插入式计算机的CPU周期以时间为代价不同，移动设备上的CPU周期以时间和电池使用为代价。如果您的应用程序是单线程的，那么没有理由使用atomic，因为锁定和解锁操作将浪费时间和电池。电池比时间更重要：虽然与添加额外操作相关的延迟对最终用户来说可能是不可见的，但所花费的周期将减少移动设备单次充电后的工作时间，这是许多用户认为非常重要的措施。