线程安全：指某个函数、函数库在多线程环境中被调用时，能够正确地处理多个线程之间的共享变量，使程序功能正确完成。</br>
在写属性的我们常常在加上nonatomic，有时我们也用atomic,这两个有什么区别？
区别在于：
atomic:
1.默认的
2.会保证 CPU 能在别的线程来访问这个属性之前，先执行完当前流程
3.速度和nonatomic相比速度比较慢
4.系统生成的 getter/setter 会保证 get、set 操作的完整性，不受其他线程影响,所以你调get和set方法是线程安全。如果你重载了get,set方法就不能保证了。
nonatomic:
1.速度快
2.非线程安全（iOS中很可能会出现crash）
下面举个多线程访问同一个用nonatomic修饰crash 的例子：
说明下例子中的arr属性是用nonatomic声明的。
for (NSInteger i = 0; i<10000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSArray * test = obj.arr;
});
dispatch_async(dispatch_get_global_queue(0, 0), ^{
obj.arr = [NSArray arrayWithObject:@"test"];
});
}
可以很容易的看到报错信息为
(lldb) bt
* thread #3: tid = 0xdcd1, 0x0000000105951acb libobjc.A.dylib`objc_msgSend + 11, queue = 'com.apple.root.default-qos', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
可以看到是报坏内存访问。可以看到nonatomic多线程读写确实有问题。
再多问一句，为什么有问题？为什么会crash?</br>
下面我们调整下上面的代码。
将代码改为：
for (NSInteger i = 0; i<10000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
NSArray * test = obj.arr;
});
}
不论怎么运行代码一切正常。</br>
下面继续修改代码
for (NSInteger i = 0; i<10000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
obj.arr = [NSArray arrayWithObject:@"test"];
});
}
发现代码一运行就crash,报错和最开始一样。其实这说明多个线程同时读一个属性是没有问题，如果一旦有多个线程写就会出问题。
现在想想问为什么同时写会有问题？
同时写其实是多个线程调一个属性的set方法，在MRC的set方法逻辑大概如下：
-(void)setArr:(NSArray *)arr {
if (arr!=_arr) {
[_arr release];
_arr = [arr retain];
}
}
比如Thread 1 和 2同时对self.arr进行了赋值，当两者都越过了if (arr!=_arr)的判断的时候，就会产生[_arr release]执行了两次，造成过度释放的crash危险。
不过我们现在是ARC,其实原理很类似。
那让我们来看看ARC时代是怎么处理的，对于ARC中不复写Setter的属性（我相信是绝大多数情况），Objective-C的底层源码是这么处理的：
static inline void reallySetProperty(id self, SEL _cmd, id newValue,
ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
id oldValue;
// 计算结构体中的偏移量
id *slot = (id*) ((char*)self + offset);
if (copy) {
newValue = [newValue copyWithZone:NULL];
} else if (mutableCopy) {
newValue = [newValue mutableCopyWithZone:NULL];
} else {
// 某些程度的优化
if (*slot == newValue) return;
newValue = objc_retain(newValue);
}
// 危险区
if (!atomic) {
// 第一步
oldValue = *slot;
// 第二步
*slot = newValue;
} else {
spin_lock_t *slotlock = &PropertyLocks[GOODHASH(slot)];
_spin_lock(slotlock);
oldValue = *slot;
*slot = newValue;
_spin_unlock(slotlock);
}
objc_release(oldValue);
}
由于我们声明的属性是nonatomic,所以线程1和2有可能同时持有oldValue，然后无论是线程1或者线程2执行到最后都会执行objc_release(oldValue)，所以最终还是会crash.</br>
是不是用了atomic就可以保证线程安全了？
再举个例子：
如果线程 A 调了 getter，与此同时线程 B 、线程 C 都调了 setter——那最后线程 A get 到的值，3种都有可能：可能是 B、C set 之前原始的值，也可能是 B set 的值，也可能是 C set 的值。同时，最终这个属性的值，可能是 B set 的值，也有可能是 C set 的值。
这种情况是不是也可以说明用了atomic不能保证线程安全，用了atomic只能保证你调系统生成的get和set方法是线程安全。</br>
上面的情况是一种线程不安全的表现，下面再举一个线程不安全的例子：
NSString *strings[3];
strings[0] = @"First";
strings[1] = @"Second";
strings[2] = @"Third";
//1.
_arr = [NSMutableArray arrayWithObjects:strings count:3];
//2.
_arr = [NSMutableArray arrayWithObject:@"daliangbaby"];
NSString * firstObj = [_arr objectAtIndex:1];
如果这种情况1.2都是一个线程中执行，我们很容易发现代码有问题，明显下标越界。
但如果你的项目写的很复杂，1和2两句代码在不同的地方，然后还在不同的线程，你就会奇怪，明明我的数组有有3个元素，怎么会越界？
所以遇到这种问题，你要检查下代码，看看是否多个线程更改了指针变量更改了指向的不可变对象。
为了防止你的不信，我们将上述代码变化下：
@property (atomic, strong) NSArray* arr;
//thread A
for (int i = 0; i < 100000; i ++) {
if (i % 2 == 0) {
self.arr = @[@"1", @"2", @"3"];
}
else {
self.arr = @[@"1"];
}
NSLog(@"Thread A: %@\n", self.arr);
}
//thread B
for (int i = 0; i < 100000; i ++) {
if (self.arr.count >= 2) {
NSString* str = [self.arr objectAtIndex:1];
}
NSLog(@"Thread B: %@\n", self.arr);
}
如果这上面这种形式，你是不是该想这都能崩溃，虽然前面已经使用了对arr.count属性进行判断，但是如果前面判断完在thread A对arr进行操作，执行完这句self.arr = @[@"1"]后再来执行这句NSString* str = [self.arr objectAtIndex:1];是不是肯定崩溃。
这种情况你用了atomic都没用。
那改怎么办呢？
有一个比较简单的办法是使用局部变量，看下面的代码：
@property (atomic, strong) NSArray* arr;
for (int i = 0; i < 100000; i ++) {
if (i % 2 == 0) {
self.arr = @[@"1", @"2", @"3"];
}
else {
self.arr = @[@"1"];
}
NSLog(@"Thread A: %@\n", self.arr);
}
//thread B
for (int i = 0; i < 100000; i ++) {
NSArray * middleArr = _arr;
if (middleArr.count >= 2) {
NSString* str = [middleArr objectAtIndex:1];
}
NSLog(@"Thread B: %@\n", self.arr);
}
这样应该没有问题了吧。
看来局部变量相当有用哈。
上面的问题除了使用局部变量，还有没有别的方式可以保证线程安全的？
答案是有的，加锁，加锁就可以。
常用的加锁方式有以下几种：
1.@synchronized
2.NSLock
3.dispatch_semaphore_t
4.OSSpinLock
这几种锁都可以带来原子性，性能的损耗从上至下依次更小。
就拿影响最大的来说它的影响程度对我们来说绝大多数也是可以接受的。所以除非遇到你特别在意这些性能的时候， 大多数情况你喜欢用那个就用那个，最重要的事情是你要用正确。
前面的问题怎么解决呢？
看下面修改后的代码：
//thread A
@synchronized (self) {
for (int i = 0; i < 100000; i ++) {
if (i % 2 == 0) {
self.arr = @[@"1", @"2", @"3"];
}
else {
self.arr = @[@"1"];
}
NSLog(@"Thread A: %@\n", self.arr);
}
};
//thread B
@synchronized (self) {
for (int i = 0; i < 100000; i ++) {
if (self.arr.count >= 2) {
NSString* str = [self.arr objectAtIndex:1];
}
NSLog(@"Thread B: %@\n", self.arr);
}
}
这样就可以保证在执行A线程@synchronized里面的代码时，B线程不会进去，同样在执行B线程时，A线程@synchronized里面的代码不会被执行。
当然使用@synchronized也有一些注意点：
- 如果多条线程访问同一个资源, 那么必须使用同一把锁才能锁住
- 在开发中, 尽量不要加锁, 如果必须要加锁, 一定记住, 锁的范围不能太大, 哪里会有安全隐患就加在哪里，注意加锁的范围不要太大。
所以上面其实只需要对
if (self.arr.count >= 2) {
NSString* str = [self.arr objectAtIndex:1];
}
加锁就可以了。
除了synchronized还有NSLock，还有dispatch_semaphore_t。基本上我常用的就这几种。
下面重点介绍下dispatch_semaphore_t这一种：
对于她来说主要有三个方法：
dispatch_semaphore_create(long value)
传入值必须>=0, 若传入为0则阻塞线程并等待timeout,时间到后会执行其后的语句.
dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);
可以理解为lock,会使得signal值-1.需要注意的是可以在timeout 的时间内等到信号量大于等于1，这个方法的返回值为0.
dispatch_semaphore_signal(signal)：可以理解为unlock,会使得signal值+1
看看下面的这段代码
dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
NSMutableArray *array = [NSMutableArrayarray];
for (int index = 0; index < 100000; index++) {
dispatch_async(queue, ^(){
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);//
NSLog(@"addd :%d", index);
[array addObject:[NSNumber numberWithInt:index]];
dispatch_semaphore_signal(semaphore);
});
}
上面的代码可以保证 addObject只会在一个线程中执行，因为信号量只有一个，只要有一个线程在执行，信号量就为0了，这时只有执行了 dispatch_semaphore_signa对信号量进行加1，for循环才能继续运行下去。
