【OC梳理】atomic的安全性？

之前的文章提到了，atomic保证了属性的原子性,但并不能保证线程的安全性，这种说法其实不是很准确。

atomic保证了属性的原子性,并且在其有效范围内是线程安全的。

为什么这么说呢？

什么是原子性？

并发程序想要正确地执行，必须要保证原子性、可见性以及有序性。
原子性：一个操作或多个操作要么全部执行完成且执行过程不被中断，要么就不执行。
可见性：当多个线程同时访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
有序性：程序执行的顺序按照代码的先后顺序执行。

为什么说atomic不能保证线程的安全性？
之前的文章(包括网上的一些文章也)提到了，如果使用多线程同时修改其属性值，因为不能保证线程的执行顺序，所以执行的结果也不能确定，举个例子：

/// atomic
@property (atomic,copy) NSString *atomicString;

...{
    dispatch_queue_t queue;
    dispatch_group_t group;
}

...{
   // 创建队列
    queue = dispatch_get_global_queue(0, 0);
    // 创建队列组
    group = dispatch_group_create();

    // 调用测试方法
    [self atomicTest];

    // 输出结果
    dispatch_group_notify(group, queue, ^{
        NSLog(@"%@", self.atomicString);
    });
}

// 测试方法
- (void)atomicTest{
    NSString *str1 = @"1";
    NSString *str2 = @"2";
    NSString *str3 = @"3";
    NSString *str4 = @"4";
    
    dispatch_group_async(group, queue, ^{
        self.atomicString = str1;
    });
    dispatch_group_async(group, queue, ^{
        self.atomicString = str2;
    });
    dispatch_group_async(group, queue, ^{
        self.atomicString = str3;
    });
    dispatch_group_async(group, queue, ^{
        self.atomicString = str4;
    });
}

上面的代码，最后输出的结果，是不确定的:

 Demo[22059:1089792] 4
 Demo[22059:1089790] 3
 Demo[22059:1089809] 4
 Demo[22059:1089789] 2
 Demo[22059:1089792] 2
 Demo[22059:1089790] 3
 Demo[22059:1089810] 2
...

我们修改一下上面的代码：

- (void)atomicTest{
    NSString *str1 = @"1";
    NSString *str2 = @"2";
    NSString *str3 = @"3";
    NSString *str4 = @"4";
    
    dispatch_group_async(group, queue, ^{
        self.atomicString = str1;
        if (self.atomicString != str1) {
            NSLog(@"1 --->%@",self.atomicString);
        }
    });
    dispatch_group_async(group, queue, ^{
        self.atomicString = str2;
        if (self.atomicString != str2) {
            NSLog(@"2 --->%@",self.atomicString);
        }
    });
    dispatch_group_async(group, queue, ^{
        self.atomicString = str3;
        if (self.atomicString != str3) {
            NSLog(@"3 --->%@",self.atomicString);
        }
    });
    dispatch_group_async(group, queue, ^{
        self.atomicString = str4;
        if (self.atomicString != str4) {
            NSLog(@"4 --->%@",self.atomicString);
        }
    });
}

写入之后立即读取，如果读取到的值和写入的值不同，就输出，然后，让我们执行100次(为了提高出现的概率，你可以多一些次数)：

for (int i = 0; i < 100; i ++) {
    [self atomicTest];
}

OK，输出的结果如下：

 Demo[22168:1092067] 1 --->2
 Demo[22168:1092069] 2 --->4
 Demo[22168:1092083] 3 --->1

真的不是线程安全的哦！

什么样的对象是线程安全的？

类要成为线程安全的，需要满足以下条件：

正确性

首先必须在单线程环境中有正确的行为，也就是说，在单线程的情况下，对它的操作序列会以正确的顺序执行。
例如：

for (int i = 0; i < 10; i ++) {
        [self atomicTest:i];
}

- (void)atomicTest:(int)i{
    NSString *str = [NSString stringWithFormat:@"这是一串很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长的字符串-->%d",i];
    self.atomicString = str;
    NSLog(@"赋值 --> %@",self.atomicString);
}

以上代码会按顺序执行，最后的输出必然是这样的：

 Demo[24260:1156641] 赋值 ... --> 0
 Demo[24260:1156641] 赋值 ... --> 1
 Demo[24260:1156641] 赋值 ... --> 2
 Demo[24260:1156641] 赋值 ... --> 3
 Demo[24260:1156641] 赋值 ... --> 4
 Demo[24260:1156641] 赋值 ... --> 5
 Demo[24260:1156641] 赋值 ... --> 6
 Demo[24260:1156641] 赋值 ... --> 7
 Demo[24260:1156641] 赋值 ... --> 8
 Demo[24260:1156641] 赋值 ... --> 9

线程安全性

在被多个线程访问时，不管运行时环境执行这些线程有什么样的时序安排或者交错，它必须仍然有如上所述的正确行为，并且在调用的代码中没有任何额外的同步。其效果就是，在所有线程看来，对于线程安全对象的操作是以固定的、全局一致的顺序发生的。
怎么理解呢？
假设有多条线程，同时对上面的self.atomicString进行赋值操作，并且线程中不需要添加任何保证同步的代码，结果是它们的赋值都成功了，并且赋值的顺序与线程执行赋值代码的时间顺序相同，那么就可以认为是满足条件的，例如：

- (void)atomicTest:(int)i{
    dispatch_group_async(group, queue, ^{
        NSString *str = [NSString stringWithFormat:@"这是一串很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长的字符串-->%d",i];
        self.atomicString = str;
    });
    dispatch_group_async(group, queue, ^{
        NSLog(@"赋值 --> %@",self.atomicString);
    }
}

然后调用：

for (int i = 0; i < 10; i ++) {
    [self atomicTest:i];
}

调用后，虽然赋值的顺序不固定，但是结果是线程都能够正常赋值：

Demo[24329:1158653] 赋值 ... --> 0
Demo[24329:1158640] 赋值 ... --> 3
Demo[24329:1158641] 赋值 ... --> 2
Demo[24329:1158639] 赋值 ... --> 1
Demo[24329:1158640] 赋值 ... --> 4
Demo[24329:1158653] 赋值 ... --> 5
Demo[24329:1158638] 赋值 ... --> 6
Demo[24329:1158652] 赋值 ... --> 7
Demo[24329:1158659] 赋值 ... --> 8
Demo[24329:1158661] 赋值 ... --> 9

从上面的结果看来，似乎atomicString这个对象的确是线程安全的。
但是，别高兴的太早，让我们把循环次数改成100次：

Demo[27727:1292377] 赋值 ... --> 3
...
Demo[27727:1292399] 赋值 --> 这是一串很长...很长的字符串--->6
\210长很长很长很长很长很长很长很长很长很长很长的字符串--->5
...
Demo[27727:1292409] 赋值 --> 这是一串很长...很长\345
...
Demo[27727:1292409] 赋值 ... -->99

为什么会出现这种情况？

让我们从atomic的实现方式讲起：

atomic方法的实现

用atomic修饰的属性，系统会在生成的getter和setter方法中添加@synchronized，类似下面的代码：

-(void)setAtomicString:(NSString *)atomicString{
    @synchronized(self){
        if (_atomicString != atomicString) {
            _atomicString = atomicString;
        }
    }
}

-(NSString *)atomicString{
    @synchronized(self){
        return _atomicString;
    }
}

我们知道，@synchronized会给传入的对象分配一个递归锁（当然还有一些别的操作，具体可以看这篇文章），那么为什么会有上面的情况出现呢？

原因在于，在于对象的赋值过程，OC中的对象“=”赋值的过程其实只是对象指针的赋值，当指针地址赋值完成后，@synchronized起到的作用已经结束了。

那么在输出的过程中，由于在其他线程给_atomicString重新赋值，原来的内存地址有可能已经被释放，新产生的str占用了某些内存，导致了输出结果的错乱。
让我们来做几个实验：

test1

-(void)setAtomicString:(NSString *)atomicString{
    @synchronized(self){
        if (_atomicString != atomicString) {
            _atomicString = atomicString;
            // 在这里直接输出
            NSLog(@"赋值 --> %@",_atomicString);
        }
    }
}

输出结果正常，可见@synchronized的代码执行完毕后才会解锁。

test2

我们在线程里加上信号量来控制，看看效果：

/// 信号量
@property (nonatomic,strong) dispatch_semaphore_t semaphore_t;

...
// 初始化信号量
self.semaphore_t = dispatch_semaphore_create(1);
...

- (void)atomicTest:(int)i{
    dispatch_group_async(group, queue, ^{
        NSString *str = [NSString stringWithFormat:@"这是一串很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长的字符串--->%d",i];
        self.atomicString = str;
    });
    dispatch_group_async(group, queue, ^{
        // 加锁
        dispatch_semaphore_wait(self.semaphore_t,DISPATCH_TIME_FOREVER);
        NSLog(@"赋值 --> %@",self.atomicString);
        // 解锁
        dispatch_semaphore_signal(self.semaphore_t);
    });
}

输出结果也是正常的。

test3

接下来，将属性设置为nonatomic:

/// atomic
@property (nonatomic,strong) NSString *atomicString;

执行100000次(emm...由于对象指针的大小只有8个字节（64位），出问题的概率比较小)，出现了野指针：

这是由于，在指针写到一半时，另外一个线程获取到了它的地址，比如说，地址是0x1122334455667788，在写入到一半时，被读取了，读到的可能是0x1122334400000000，而这个地址是无效的（当然，如果这个地址恰好也是一个NSString，并且是某些隐私信息的话...后果你懂的）。

总结

从上面的实验看到，atomic修饰的变量只能保证在获取对象的指针时是线程安全的，而不能保证这个指针指向的内存地址是线程安全的。
或者说：

atomic的作用域只是于对象的指针。

所以在使用多线程时，对于会产生并发问题的指针对象（这种情况并不多见），最好使用atomic进行修饰（对于非指针类型的基本变量，不用考虑，直接用nonatomic就好了）。