自旋锁(atomic 原子锁)
OC在定义属性时，经常会提到nonatomic和atomic的两种选择。
atomic：我们成为原子属性，它默认会为setter方法加锁 (如果不写,这个,就会默认atomic)，线程安全，但需要消耗大量的资源。
nonatomic：非原子属性，不会为setter方法加锁，非线程安全,适合内存小的移动设备。
综上所述，移动端属性应该尽可能都使用nonatomic；
尽量避免多线程抢夺同一块资源；
尽量将加锁,资源的抢夺的业务移交给服务器，减少移动端的压力
互斥锁 synchronize
多线程存在资源抢夺 ，只要是加锁就会消耗性能，想锁住代码，多个线程必须使用同一把锁，加锁范围尽量缩小。
一般情况下，能不开启多线程，就不要开启新的线程。 如果只需要在网络上单纯的加载数据，而不是多处去修改相同数据，就可以使用多线程。
常见的数据安全场景：
- 购票
- 电影票订座
- 抢购商品
如上几个场景我们可以总结到规律是假如多人（多个客户端）都有可能操作同样资源，这时候就需要注意数据安全的问题。
注意：移动端引入多线程的更多的是防止加载耗时操作，影响主线程，造成主线程的阻塞。而不是去操作大量数据防止数据安全问题。（我这里说的是更多的情况下）。
NSLock 与 NSRecursiveLock区别
1、互斥锁，当一个线程进行访问的时候，该线程获得锁，其他线程进行访问的时候，将被操作系统挂起，直到该线程释放锁，其他线程才能对其进行访问，从而却确保了线程安全。
2、但是如果连续锁定两次，则会造成死锁问题。那如果想在递归中使用锁，那要怎么办呢，这就用到了 NSRecursiveLock 递归锁。
3、递归锁，顾名思义，可以被一个线程多次获得，而不会引起死锁。它记录了成功获得锁的次数，每一次成功的获得锁，必须有一个配套的释放锁和其对应，这样才不会引起死锁。只有当所有的锁被释放之后，其他线程才可以获得锁
NSLock 举例感官认识
#import "ZYViewController.h"
@interface ZYViewController () {
int ticketCount;
NSLock *_lock;
}
@end
@implementation ZYViewController
- (void)viewDidLoad {
[super viewDidLoad];
_lock = [[NSLock alloc] init];
ticketCount = 5;
//方法默认是同步执行的
// [NSThread detachNewThreadSelector:@selector(buyTickets_a) toTarget:self withObject:nil];
// [NSThread detachNewThreadSelector:@selector(buyTickets_b) toTarget:self withObject:nil];
dispatch_queue_t queue = dispatch_queue_create("com.Maker",DISPATCH_QUEUE_SERIAL);
dispatch_async(queue, ^ {
NSLog(@"任务_1 %d",[NSThread isMainThread]);
[self buyTickets_a];
});
NSLog(@"任务_2 %d",[NSThread isMainThread]);
[self buyTickets_b];
}
- (void)buyTickets_a {
// [_lock lock];
@synchronized(self) {
NSLog(@"甲开始买票");
if (ticketCount >= 1) {
NSLog(@"还剩下%d张票,甲开始买票",ticketCount);
ticketCount = ticketCount - 1;
NSLog(@"甲买完票了,还剩下%d张",ticketCount);
}
else {
NSLog(@"票不够1张,不能给甲办理买票手续");
}
}
// [_lock unlock];
}
- (void)buyTickets_b {
// [_lock lock];
@synchronized (self) {
NSLog(@"乙开始买票");
if (ticketCount >= 5) {
NSLog(@"还剩下%d张票,乙开始买票",ticketCount);
ticketCount = ticketCount - 5;
NSLog(@"乙买完票了,还剩下%d张",ticketCount);
}
else {
NSLog(@"票不够5张,不能给乙办理买票手续");
}
}
// [_lock unlock];
}
- (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}
@end
正常运行结果如下：
情况一：
任务_1 0
任务_2 1
甲开始买票
还剩下5张票,甲开始买票
甲买完票了,还剩下4张
乙开始买票
票不够5张,不能给乙办理买票手续
情况二：
任务_2 1
任务_1 0
乙开始买票
还剩下5张票,乙开始买票
乙买完票了,还剩下0张
甲开始买票
票不够1张,不能给甲办理买票手续
注意：假如不存在_lock或者不存在@synchronized (self)就会存在数据安全问题。运行结果如下：
错误运行结果：
任务_2 1
任务_1 0
乙开始买票
甲开始买票
还剩下5张票,乙开始买票
还剩下5张票,甲开始买票
乙买完票了,还剩下0张
甲买完票了,还剩下-1张
注意：死锁就是一种常见情况，锁被被多次的 lock，自己就会被阻塞，由于以上的代码非常的简短，所以很容易能识别死锁，但在较为复杂的代码中，就不那么容易发现了，那么如何在递归或循环中正确的使用锁呢？此处的 lock 变量如果换用 NSRecursiveLock 对象，问题便得到解决了，NSRecursiveLock 类定义的锁可以在同一线程多次 lock，而不会造成死锁。递归锁会跟踪它被多少次 lock。每次成功的 lock 都必须平衡调用 unlock 操作。只有所有的锁住和解锁操作都平衡的时候，锁才真正被释放给其他线程获得。
