Am I missing any points in my argument in favor of atomic properties?
我读过这个问题(还有其他几个问题)：
原子属性和非原子属性有什么区别？
我完全理解(至少我希望如此)：-d)原子/非原子属性说明符是如何工作的：
原子保证"读"操作不会被"写"操作中断。非原子性并不能保证这一点。
既不原子也不非原子解竞争条件，其中一个线程正在读取，两个线程正在写入。没有办法预测读取操作返回的结果。这需要通过额外的同步来解决。
原子性和非原子性都不能保证整体数据的完整性；一个线程可以设置一个属性，而另一个线程在与第一个属性的状态不一致的状态下设置第二个属性。这也需要通过额外的同步来解决。
使我吃惊的是，人们分为两个阵营：
亲原子性：只使用
如果你不优化，那么你应该总是使用原子的，因为第1点。这样，在多线程应用程序中读取此属性时就不会得到一些完整的垃圾。当然，如果你关心第2点和第3点，你需要在上面添加更多的同步。
反对原子：使用原子根本没有意义。
因为Atomic并不能解决多线程应用程序中的所有问题，所以使用它根本就没有意义，因为您无论如何都需要在它上面添加更多的同步代码。它只会使事情变慢。
我倾向于支持原子能阵营，但我想做一个健全的检查，我没有错过任何东西。
缺乏一个非常具体的问题(尽管仍然是一个很好的问题)，我将以个人经验回答，fwiw。
一般来说，并发设计是很困难的。利用诸如GCD和ARC这样的现代便利设施，实现并发系统的工具肯定得到了改进。然而，并发的体系结构仍然非常困难。
一般来说，硬部分与个体属性无关；个体吸气剂和定位器。并发是在更高层次上实现的东西。
当前的技术状态是孤立的并发性。也就是说，同时运行的应用程序的各个部分使用与应用程序其余部分具有极少量连接的对象的独立图来实现这一点(通常，"连接"是通过回调进行的，回调捆绑了一点状态，并将其转移到其他队列，通常是用于更新UI的主队列)。
通过将并发表面积(进入代码的入口点必须是并发安全的)保持在一个绝对最小值，您可以同时降低复杂性和调试非常奇怪的、经常是不可恢复的、并发性问题所花费的时间(这会在您清醒的时候消耗掉)。
考虑到这些，原子属性的值是非常小的。当然，它们可以用于非常小的一组接口(api)，这些接口可能会受到多个线程的攻击，但这就是问题所在。
如果有对象的访问器正被快速地攻击，那么使它们成为原子对象可能会对性能造成重大影响，但过早的优化是最糟糕的事情。