iOS的类中，使用@property声明属性的时候，会有诸多前缀可以选择，其中包括strong、weak、copy、assign、readwrite、readonly、atomic、nonatomic等等。而nonatomic前缀又是我们最经常用到的前缀之一。那么我们为什么要用nonatomic前缀呢？
atmoic/nonatmoic是什么？
- atmoic：原子属性，为系统默认的属性，会为修饰的成员变量的setter方法自动加锁（自旋锁），使得线程安全，但较为消耗资源，效率相对低些。是一种单写多度的多线程技术，可能出现脏数据。
- nonatomic：非原子属性，开发中最常用的属性，不会为修饰的成员变量的setter方法加锁，虽然线程不安全，但效率高
锁的机制
在原子性中，最为核心的机制，便是锁的机制。通过锁的机制，可以保证线程的安全性，保证成员变量的安全性，这是我们选择才不采用原子性最主要考虑的方面
那么锁是什么呢？
简而言之，锁是用来将当前操作的对象锁住，让该对象在编辑时，有且只有一个操作能执行，其他操作需在当前操作结束后才能进行
那么iOS中有哪些常用的锁呢？
自旋锁：是用于多线程同步的一种锁，线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。一旦获取了自旋锁，线程会一直保持该锁，直至显式释放自旋锁。 自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合是有效的
互斥锁（Mutex）：是一种用于多线程编程中，防止两条线程同时对同一公共资源（比如全局变量）进行读写的机制。该目的通过将代码切片成一个一个的临界区而达成
读写锁：是计算机程序的并发控制的一种同步机制，也称“共享-互斥锁”、多读者-单写者锁) 用于解决多线程对公共资源读写问题。读操作可并发重入，写操作是互斥的。 读写锁通常用互斥锁、条件变量、信号量实现
ps：以上常用锁的内容参考自 SuperMario_Nil 的 iOS开发中的11种锁以及性能对比
延伸 - 自旋锁和互斥锁：
- 共同点：
都能够保证线程安全
无论什么锁，都很损耗性能，效率不高 - 不同点：
互斥锁：如果线程被锁在外面，那么就会进入休眠状态，等待锁打开，然后被唤醒
自旋锁：如果线程被锁在外面，那么就会用死循环的方式，一直等待锁打开
为什么nonatomic线程不安全却最为常用呢？
- 线程安全：我们一般在操作变量的时候，极少遇到在多线程下对于类的成员变量进行操作的情况。所以在一般情况下不用需要考虑线程安全的问题，直接使用nonatomic就可以
- 性能消耗：从上面锁的介绍中我们可以了解到锁的机制。atomic是一种自旋锁。当我们一旦获取了自旋锁，线程会一直保持该锁直至显示释放该锁。而在单一线程的操作中，其实并不需要去获取这个锁来防止多线程操作对于成员变量的同时修改，所以选择nonatomic可以避免多余的性能损耗
注意事项：
- 如果是对象可能被多线程访问的资源，我们就需要将其定义成atomic
- 当我们用@property生成成员变量时，系统是默认设置为atomic，如非必要，记得将其修改为nonatomic
延伸：
iOS中的另一种锁 @synchronized
@synchronized 也是用来保证线程安全的一种加锁方式
// @synchronized的用法如下
@synchronized (self) {
// 添加锁要上锁的执行代码
}
注意：
- 加锁的代码量要尽可能少
- 添加的OC对象必须在多个线程中是同一对象
- 优点是不需要显式的创建锁对象，便可以实现锁的机制
- @synchronized代码块会隐式的添加一个异常处理例程来保护代码，该处理例程会在抛出异常时自动释放互斥锁，而隐式的异常处理例程带来额外的开销
- atomic的加锁方式是自动加锁，而@synchronized是手动加锁，根据需要来选择加锁方式
- atomic只会对写入的过程进行上锁，对于访问的过程是不受限制的。对于像售货类（共享资源）的操作，用atomic并不安全，不安全在读取上。而@synchronized不会出现这样的情况，因为它是一种单写单独的模式
多线程延伸：
- UIKit框架都是线程不安全的，为了线程安全会导致资源占用过大和效率下降，为了避免过多性能消耗UI操作一般都放在特定的UI线程（即主线程）
