atomic是否是安全的?
首先要明确的是, 实际上atomic是安全的, 而且是绝对安全的
atomic实际上就是原子操作, 所谓原子, 就是不可再分割, 已经是最小的操作单位了(所谓操作指的是对内存的读写), 很多在讨论OC下的atomic不安全, 不能保证数据的并发性, 认为atomic本身是不安全的, 实际上, 并非atomic不安全.
一个数据的线程安全, 简单说就是这部分的数据即使有多个线程同时读写, 也不会出现数据错乱的情况, 内存的最后状态总是可以预见的, 如果这块内存的数据被一个多线程读写之后, 出现的结果是不可预见的, 那么就可以说这块内存是"线程不安全的".
- atomic: 原子属性, 线程安全, 效率较低. 可以当成人通过一扇门, 一次只能通过一个人.
- nonatomic: 非原子属性, 线程不安全, 效率高. 可以多个人同时进出门.
atomic实际上相当于一个引用计数器, 如果被标记了atomic, 那么被标记了的内存本身就有了一个引用计数器, 第一个占用这块内存的线程, 会给这个计数器+1, 在这个线程操作这块内存期间, 其他线程在访问这个内存的时候, 如果发现"引用计数器"不为0, 则阻塞, 实际上阻塞并不等于休眠, 它是基于CPU轮询, 休眠除非被唤醒, 否则无法继续执行, 阻塞则不同, 每个CPU轮询片到这个线程的时候都会尝试继续往下执行, 可见阻塞相对于休眠来讲, 阻塞是主动的, 休眠是被动的, 如果引用计数器为0, 轮询片到这,则先给这块内存的引用计数器+1, 然后再去操作, atomic实现操作序列化的具体过程大概是就是这样.
如果一个数据占的内存特别大, 那么读写这块内存数据需要的时间也就越长, 如果这个时间长度远远超过线程调度的轮询片, 那么就有极大可能出现并发问题.(一块内存在被一条线程读写的时间, 快到其他线程来到的时候就已经结束, 那么就不会出现线程安全问题, 反之, 就会出现线程安全的问题)
以OC下的NSArray *为例子, 如果一个多线程操作这个数据, 会有两个层级的并发问题:
- 指针本身
- 指针所指向的内存
指针本身也是占用内存的, 并且一定是8个字节, 第二部分, 指针所指向的内存, 这个占多少字节就不一定了, 有可能非常大, 有可能很小.
所以在考虑NSArray *array 这个数据array多线程操作的时候, 必须分成两部分来描述, 一个是&array这个指针本身, 另一个则是它所指向的内存的array. &array是一块8字节的内存空间, 里面的值就是有n字节内存array的首地址.
现在联系上atomic, 如果是@property(atomic)NSArray *array, 会有什么影响? 首先要明确的是atomic作为修饰符修饰的是这个指针即&array, 跟array没有任何关系. 被atomic修饰之后, 你不可能随意去多线程操作&array, 这个8字节的内存, 但是对8字节里面所指向的n字节没有任何限制, 这就是会出现atomic线程不安全的真相.
本身atomic修饰的是一个指针, 让这个指针所指的内存是线程安全的, atomic没有任何问题, 有问题的是未对n字节做任何的限制.
我们知道, 这个8字节里面存储的数据, 是n字节数据的头地址, 如果更改8字节数据的内容, 那么最后通过这个指针访问到的数据就会完全不一样. 8字节相当于楼管, 里面的数据相当于整栋楼的钥匙, 给你不同的钥匙, 你是不是就进的是不同的房间? 通过atomic我们可以保证这个"指针"被有序的访问, 也仅仅只能保证到这.
首先构建一个不加任何保护的场景, 看看会出现什么问题
现在我们有一个8字节的指针, 假如我们做一个初始化NSArray *array = [[NSArray alloc] init] 这个操作, 实际上这个操作有两个意思:
- 给8字节的&array赋值
- 开辟了一块n字节的内存去给array
我们只说这8字节的地址赋值, 如果没有atomic修饰, 并且假设现在有两个线程正在操作这个指针, 一个就是上面的初始化线程, 另一个线程就是读这个8字节的指针. 首先, 假如8字节内部存放的是0x1234567890这个内存地址, 8字节需要写入这个值, 但与此同时, 另一个读线程现在要读这个8字节里面的值. 假如这个8字节只写了一半的时候另一个线程来读, 那它读到的可能是0x1234560000, 实际上, 等它读完, 写线程仍然还未完成, 这个时候, [[NSArray alloc] init] 的头部地址正确的应该是0x1234567890, 而读线程读到的是0x1234560000 这时候会出现什么情况? 最好的情况, 无非就是个野指针, 因为谁也不知道这块地址是否有效或者是否有什么重要的数据. 最坏的情况, 这个野指针指向的是重要的一段数据, 后果可想而知.
所以atomic的意义就在于此, 在0x1234567890写完之前, 读线程无法读取, 同样的道理, 在读线程正在读的过程中, 写线程是无法改变8字节的.
atomic能避免这8字节的值因为多线程的原因被意外破获, 仅此而已
考虑场景二, 假如现在有atomic修饰, 假如现在有两个线程正在操作这个指针, 根据上面的结论, 这两个线程"先后"正确的获取到了内存地址, 也就是说, 都先后, 正确的找到了8字节内容所指向的n字节内容, 虽然找到这n个字节内容的顺序有先后, 但是不影响这两个线程同时去操作这n个字节的数据.
但是这样问题又来了, 两个线程同时去操作n字节内容, 如果两个线程都是读线程, 一般不会有问题, 但是假如至少有一个是写线程, 那问题又来了, 还是一个读写同步的问题, 因此atomic虽然规范了找到这n字节内容的先后顺序, 但是不能规范对这n字节内容的读写, 这就是atomic的局限性.
至于为什么基本都是使用nonatomic来修饰OC中的属性, 这是因为这些操作都是在主线程中做的操作, 没有多线程的情况, 也就不会有并发的问题了.
