iOS多线程_NSLock

自旋锁(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 操作。只有所有的锁住和解锁操作都平衡的时候，锁才真正被释放给其他线程获得。