多线程是一把双刃剑，他即可以提高我们的运行效率，但是当资源共享多个线程同时存取同一块资源的时候，可能会造成引发数据错乱和数据安全问题。
资源共享
1块资源可能会被多个线程共享，也就是多个线程可能会访问同一块资源。
比如多个线程访问同一个对象、同一个变量、同一个文件当多个线程访问同一块资源的时候，很容易引发数据的错乱和数据安全问题
例如 ：变量a 为 100 两个线程访问变量a 然后都同时都加1然后写入，本来按照逻辑a应该是 102，但是当 两个线程同时访问a来进行操作的时候得到的结果成了101。这就会引发数据错乱。
线程锁
为了避免出现数据错乱这种情况，我们需要用到工具线程锁。
线程锁有以下几个基本类型
1.自旋锁： atomic 即OSSpinLock 在ios中已经不是线程安全的了，如果共享数据已经有其他线程加锁了，线程会以死循环的方式等待锁，一旦被访问的资源被解锁，则等待资源的线程会立即执行。（效率最高，如果一直等不到锁会较占用cpu资源）
2.信号锁：dispatch_semaphore是gcd中通过信号量来实现共享数据的数据安全。（效率第二）
3.互斥锁：pthread_mutex ，nslock ，synchronized都是互斥锁。如果共享数据已经有其他线程加锁了，线程会进入休眠状态等待锁。一旦被访问的资源被解锁，则等待资源的线程会被唤醒。（synchronized效率最低）
4.递归锁：pthread_mutex(recursive)与NSRecursiveLock ， 多次调用不会阻塞已获取该锁的线程。
5.条件锁：nsconditionlock 满足一定的条件的加锁和解锁，可以实现依赖关系。nscondition条件锁，也是通过信号量来解锁，主要用来实现生产者消费者模式。
1 自旋锁
在多线程要操作一个字符串时，为了保证只有一个线程在赋值或者取值的时候我们会考虑加锁。
实现原理 当属性加锁之后另外的线程则忙等（进入死循环等待属性解锁），一旦解锁立即读取资源，因此效率高，但是耗费CPU资源。
- atomic属性内部的锁称为 自旋锁
`
@property(atomic,copy)NSString *name;
`
atomic应该怎么在setter和getter中实现呢，原理是仅需要给self加锁，重写setter，getter：
@synthesize name = _name;
- (void)setName:(NSString *)name
{
@synchronized(self)
{
_name = [name copy];
}
}
- (NSString *)name
{
@synchronized(self)
{
return _name;
}
}
不过这么写，也不能保证线程安全。如果线程A调用了getter，同时线程B调用了setter，那么A线程getter得到的值，可能是B在set之前的原始值，也可能是B set的值。同时这个属性的值，也可能是B set的值。所以不建议用自旋锁
2.互斥锁 pthread_mutex
互斥锁的意思是某一时刻只允许一个线程访问某一资源。为了保证这一点，每个想要访问共享资源的线程，需要首先获得一个共享资源的互斥锁，一旦某个线程对共享资源完成了访问，就释放掉这个互斥锁，这样别的线程就有机会获取互斥锁，然后访问该共享资源了。
由于 pthread_mutex 有多种类型，可以支持递归锁等，因此在申请加锁时，需要对锁的类型加以判断，这也就是为什么它和信号量的实现类似，但效率略低的原因。
互斥锁的实现原理与信号量非常相似，不是使用忙等，而是阻塞线程并睡眠，需要进行上下文切换
- pthread_mutex
pthread表示的是POSIX thread，定义的是一组跨平台线程相关的API。
pthread_mutex互斥锁是一个非递归锁，如果同一线程重复调用加锁会造成死锁。
用法比较简单
static pthread_mutex_t pmutexLock;
pthread_mutex_init(&pLock, NULL);
//1.线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
NSLog(@"线程2 befor lock");
pthread_mutex_lock(&pLock);
NSLog(@"线程2");
pthread_mutex_unlock(&pLock);
});
//2.线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程1 before lock");
pthread_mutex_lock(&pLock);
sleep(3);
NSLog(@"线程1");
pthread_mutex_unlock(&pLock);
});
pthread_mutex(recursive) 递归锁，比较安全，同一线程有且仅有一次加锁，重复加锁不会死锁。无论加锁几次，只需解锁一次。
//参数isRecu 是否是递归锁
- (void)pthreadMutexWithRECURSIVE:(BOOL)isRecu
{
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
//设置锁的属性为递归
if (isRecu)
{
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&mutex, &attr);
pthread_mutexattr_destroy(&attr);
}
pthread_mutex_lock(&mutex);
NSLog(@"真是麻烦,看老子一会把你封装了");
while (YES) {
[NSThread sleepForTimeInterval:0.2];
//互斥锁 -- 保证锁内的代码,同一时间,只有一条线程执行!
//互斥锁 的范围 应该尽量小,范围大了 效率就差!!
//1.判断是否有票
//参数:任意OC对象都OK!一般用self!全局对象
//局部变量,每一个线程单独拥有的,因此没法加锁!!!
if (self.tickets > 0) {
//2.如果有就卖一张
self.tickets--;
NSLog(@"剩下%d张票 %@",self.tickets,[NSThread currentThread]);
}else{
//3.如果没有了,提示用户
NSLog(@"卖完了! %@",[NSThread currentThread]);
break;
}
}
pthread_mutex_unlock(&mutex);
pthread_mutex_destroy(&mutex);
}
- @synchronized
这其实是一个 OC 层面的锁， 主要是通过牺牲性能换来语法上的简洁与可读。
我们知道 @synchronized 后面需要紧跟一个 OC 对象，它实际上是把这个对象当做锁来使用。你调用 sychronized 的每个对象，Objective-C runtime 都会为其分配一个递归锁并存储在哈希表中。OC 在底层使用了一个互斥锁的数组(你可以理解为锁池)，通过对对象地址哈希值来得到对应的互斥锁。
若是在self对象上频繁加锁，那么程序可能要等另一段与此无关的代码执行完毕，才能继续执行当前代码，这样做其实并没有必要。
- (void)setName:(NSString *)name
{
//互斥锁
@synchronized(self)
{
_name = [name copy];
}
}
- NSLock
NSLock只是在内部封装了一个pthread_mutex，属性为PTHREAD_MUTEX_ERRORCHECK，它会损失一定性能换来错误提示。这里使用宏定义的原因是，OC 内部还有其他几种锁，他们的 lock 方法都是一模一样，仅仅是内部pthread_mutex互斥锁的类型不同。
通过宏定义，可以简化方法的定义。
NSLock比pthread_mutex略慢的原因在于它需要经过方法调用，同时由于缓存的存在，多次方法调用不会对性能产生太大的影响。
- (NSLock *)mutexLock
{//创建线程锁锁
if(!_mutexLock)
{
_mutexLock = [[NSLock alloc] init];
}
return _mutexLock;
}
- (void)action
/设置票的数量为5
_tickets = 5;
//线程1
dispatch_async(self.concurrentQueue, ^{
[self saleTickets];
});
//线程2
dispatch_async(self.concurrentQueue, ^{
[self saleTickets];
});
}
- (void)saleTickets
{
while (YES) {
[NSThread sleepForTimeInterval:0.2];
//加锁
[self.mutexLock lock];
//互斥锁 -- 保证锁内的代码,同一时间,只有一条线程执行!
//互斥锁 的范围 应该尽量小,范围大了 效率就差!!
//1.判断是否有票
//参数:任意OC对象都OK!一般用self!全局对象
//局部变量,每一个线程单独拥有的,因此没法加锁!!!
if (self.tickets > 0) {
//2.如果有就卖一张
self.tickets--;
NSLog(@"剩下%d张票 %@",self.tickets,[NSThread currentThread]);
}else{
//3.如果没有了,提示用户
NSLog(@"卖完了! %@",[NSThread currentThread]);
break;
//解锁
[self.mutexLock unlock];
}
}
自旋锁和互斥锁
-
相同点：
都能保证同一时间只有一个线程访问共享资源。都能保证线程安全。
-
不同点：
互斥锁：如果共享数据已经有其他线程加锁了，线程会进入休眠状态等待锁。一旦被访问的资源被解锁，则等待资源的线程会被唤醒。
自旋锁：如果共享数据已经有其他线程加锁了，线程会以死循环的方式等待锁，一旦被访问的资源被解锁，则等待资源的线程会立即执行。 自旋锁的效率高于互斥锁。
信号量 dispatch_semaphore是gcd中通过信号量来实现共享数据的数据安全。
不是使用忙等，而是阻塞线程并睡眠，需要进行上下文切换。
缺点
在时间较短的操作，没有自旋锁高效，会有上下文切换的成本。
优点
效率高。
由于信号量用的比较少，这里就不再多讲。想进一步了解的同学大家可以参考 这篇文章 iOS - dispatch_semaphore 和 NSCondition(转)
条件锁
- NSCondition
NSCondition 其实是封装了一个互斥锁和条件变量。NSCondition 的底层是通过条件变量(condition variable) pthread_cond_t 来实现的。条件变量有点像信号量，提供了线程阻塞与信号机制，因此可以用来阻塞某个线程，并等待某个数据就绪，随后唤醒线程。它仅仅是控制了线程的执行顺序。
互斥锁提供线程安全，条件变量提供线程阻塞与信号机制。
它的基本用法和NSLock一样，这里说一下NSCondition的特殊用法。
NSCondition提供更高级的用法，方法如下：
- (void)wait; //阻塞当前线程 直到等待唤醒
- (BOOL)waitUntilDate:(NSDate *)limit; //阻塞当前线程到一定时间 之后自动唤醒
- (void)signal; //唤醒一条阻塞线程 - (void)broadcast; //唤醒所有阻塞线程
- NSConditionLock
借助 NSCondition 来实现，它的本质就是一个生产者-消费者模型。“条件被满足”可以理解为生产者提供了新的内容。NSConditionLock 的内部持有一个 NSCondition 对象，以及 _condition_value 属性，在初始化时就会对这个属性进行赋值:
// 简化版代码
- (id) initWithCondition: (NSInteger)value {
if (nil != (self = [super init]))
{
_condition = [NSCondition new] ;
_condition_value = value;
}
return self;
}
它的 lockWhenCondition 方法其实就是消费者方法:
- (void) lockWhenCondition: (NSInteger)value {
[_condition lock];
while (value != _condition_value) {
[_condition wait];
}
}
对应的 unlockWhenCondition 方法则是生产者，使用了 broadcast 方法通知了所有的消费者:
- (void) unlockWithCondition: (NSInteger)value {
_condition_value = value;
[_condition broadcast];
[_condition unlock];
}
//调用方法
NSConditionLock *theLock = [[NSConditionLock alloc] init];
//线程1
dispatch_async(self.concurrentQueue, ^{
for (int i=0;i<=3;i++) {
[theLock lock];
NSLog(@"thread1:%d",i);
sleep(1);
[theLock unlockWithCondition:i];
}
});
//线程2
dispatch_async(self.concurrentQueue, ^{
[theLock lockWhenCondition:2];
NSLog(@"thread2");
[theLock unlock];
});
递归锁NSRecursiveLock
上文已经说过，递归锁也是通过 pthread_mutex_lock
函数来实现，在函数内部会判断锁的类型，如果显示是递归锁，就允许递归调用，仅仅将一个计数器加一，锁的释放过程也是同理。
NSRecursiveLock
与 NSLock
的区别在于内部封装的 pthread_mutex_t
对象的类型不同，前者的类型为 PTHREAD_MUTEX_RECURSIVE
// 实例类person
Person *person = [[Person alloc] init];
// 创建锁对象
NSRecursiveLock *theLock = [[NSRecursiveLock alloc] init];
// 创建递归方法
static void (^testCode)(int); testCode = ^(int value) {
[theLock tryLock];
if (value > 0) {
[person personA];
[NSThread sleepForTimeInterval:1];
testCode(value - 1);
}
[theLock unlock];
};
//线程A dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
testCode(5);
});
//线程B dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[theLock lock];
[person personB];
[theLock unlock];
});
1、总的来看，推荐dispatch_semaphore 或者 pthread_mutex作为实际项目的首选方案；
2、对于耗时较大又易冲突的读操作，可以使用读写锁代替pthread_mutex；
3、如果确认仅有set/get的访问操作，可以选用原子操作属性；
4、对于性能要求苛刻，可以考虑使用OSSpinLock，需要确保加锁片段的耗时足够小；
5、条件锁基本上使用面向对象的NSCondition和NSConditionLock即可；
6、@synchronized则适用于低频场景如初始化或者紧急修复使用；
