深入理解iOS之多线程篇

多线程的原理

CPU在不同的线程之间以一个非常小的时间片不断的进行调度。

• 多线程的实现原理：事实上，同一时间内单核的CPU只能执行一个线程，多线程是CPU快速的在多个线程之间进行切换（调度），造成了多个线程同时执行的假象。

• 如果是多核CPU就真的可以同时处理多个线程了。

• 多线程的目的是为了同步完成多项任务，通过提高系统的资源利用率来提高系统的效率。

多线程技术方案

1、pthread

• 一套通用的多线程API
• 适用于Unix/Linux/Windows等系统
• 跨平台/可移植
• 使用难度大
• C语言，需要手动管理线程生命周期

2、NSThread

• 使用更加面向对象
• 简单易用，可直接操作线程对象
• OC语言，需要手动管理线程对象

3、GCD

• 苹果为多核并行运算开发的解决方案
• 会自动利用更多的CPU内核（比如双核、四核）
• 程序员只需要将任务添加到队列中，不需要编写任何线程管理代码
• OC语言，自动管理生命周期

4、NSOperation

• 基于GCD，但是比GCD多了一些简单实用的功能
• 使用更加面向对象
• 可添加完成的代码块，在操作完成之后执行
• 添加操作之间的依赖关系，方便的控制执行顺序
• 可以设定操作执行的优先级
• 可以很方便的取消一个操作的执行
• 使用KVO观察对操作执行状态的更改：isExecuteing、isFinished、isCancelled
• OC语言，手动管理生命周期
  
  

• 新建：实例化线程对象
• 就绪：向线程对象发送start消息，线程对象被加入可调度线程池等待CPU调度
• 运行：CPU负责调度可调度线程池中线程执行。当前线程任务执行完毕后，进入就绪状态，即有一个短暂停留期，如果在这期间有新的任务，则继续执行这个任务，如果没有新的任务，则线程销毁，等有下一个任务的时候，则开启新的线程执行。
• 阻塞：当满足某个预定条件时，可以使用休眠或锁，阻塞线程执行。sleepForTimeInterval（休眠指定时长），
  sleepUntilDate（休眠到指定日期），
  @synchronized(self)：（互斥锁）。
• 死亡：正常死亡，线程执行完毕。
  非正常死亡，在线程内部中止执行(如[NSThread exit] ),
  在线程外死亡，当满足某个条件后，在线程内部中止执行或者在主线程中止线程对象。

线程的exit、cancel和suspend操作区别。

• exit：一旦强行终止线程，后续的所有代码都不会被执行
• cancel：并不会直接取消线程，只是给线程对象添加isCancelled标记
• suspend：挂起状态，通过resume，可以恢复线程的任务执行

1.为什么要线程安全
2.多线程安全隐患分析
3.多线程安全隐患的解决方案
4.锁的分类-13种锁
4.1.1OSSpinLock
4.1.2os_unfair_lock
4.1.3pthread_mutex
4.1.4NSLock
4.1.5NSRecursiveLock
4.1.6NSCondition
4.1.7NSConditionLock
4.1.8dispatch_semaphore
4.1.9dispatch_queue
4.1.10@synchronized
4.1.11atomic
4.1.12pthread_rwlock
4.1.13dispatch_barrier_async
5.性能对比
6.常见的死锁

2 os_unfair_lock

从iOS10开始才支持 , os_unfair_lock锁的线程会处于休眠状态，并非忙等

6 NSCondition（条件锁）

• NSCondition 的对象实际上作为一个锁和一个线程检查器：锁主要为了当检测条件时保护数据源，执行条件引发的任务；线程检查器主要是根据条件决定是否继续运行线程，即线程是否被阻塞。

• NSCondition是对mutex和cond的封装，更加面向对象，我们使用起来也更加的方便简洁

7 NSConditionLock

• lock不分条件，如果锁没被申请，直接执行代码
• unlock不会清空条件，之后满足条件的锁还会执行
• unlockWithCondition:我的理解就是设置解锁条件(同一时刻只有一个条件，如果已经设置条件，相当于修改条件)
• lockWhenCondition:满足特定条件,执行相应代码
• NSConditionLock同样实现了NSLocking协议，试验过程中发现性能很低。
• NSConditionLock也可以像NSCondition一样做多线程之间的任务等待调用，而且是线程安全的。
  NSConditionLock是对NSCondition的进一步封装，可以设置具体的条件值

@synchronized是对mutex递归锁的封装， @synchronized(obj)内部会生成obj对应的递归锁，然后进行加锁、解锁操作

13 dispatch_barrier_async

这个函数传入的并发队列必须是自己通过dispatch_queue_cretate创建的 如果传入的是一个串行或是一个全局的并发队列，那这个函数便等同于dispatch_async函数的效果

6.常见的死锁

案例一：

NSLog(@"1"); // 任务1
dispatch_sync(dispatch_get_main_queue(), ^{
    NSLog(@"2"); // 任务2
});
NSLog(@"3"); // 任务3

结果，控制台输出：

1

分析

• dispatch_sync表示一个同步线程；
• dispatch_get_main_queue表示运行在主线程中的主队列；
• 任务2是同步线程的任务。

首先执行任务1，这是肯定没问题的，只是接下来，程序遇到了同步线程，那么它会进入等待，等待任务2执行完，然后执行任务3。但这是队列，有任务来，当然会将任务加到队尾，然后遵循FIFO原则执行任务。那么，现在任务2就会被加到最后，任务3排在了任务2前面，问题来了：

任务3要等任务2执行完才能执行，任务2由排在任务3后面，意味着任务2要在任务3执行完才能执行，所以他们进入了互相等待的局面。【既然这样，那干脆就卡在这里吧】这就是死锁。

案例三

dispatch_queue_t queue = dispatch_queue_create("com.demo.serialQueue", DISPATCH_QUEUE_SERIAL);
NSLog(@"1"); // 任务1
dispatch_async(queue, ^{
    NSLog(@"2"); // 任务2
    dispatch_sync(queue, ^{  
        NSLog(@"3"); // 任务3
    });
    NSLog(@"4"); // 任务4
});
NSLog(@"5"); // 任务5

结果，控制台输出：

1
5
2
// 5和2的顺序不一定

分析
这个案例没有使用系统提供的串行或并行队列，而是自己通过dispatch_queue_create函数创建了一个DISPATCH_QUEUE_SERIAL的串行队列。

• 执行任务1；
• 遇到异步线程，将【任务2、同步线程、任务4】加入串行队列中。因为是异步线程，所以在主线程中的任务5不必等待异步线程中的所有任务完成；
• 因为任务5不必等待，所以2和5的输出顺序不能确定；
• 任务2执行完以后，遇到同步线程，这时，将任务3加入串行队列；
• 又因为任务4比任务3早加入串行队列，所以，任务3要等待任务4完成以后，才能执行。但是任务3所在的同步线程会阻塞，所以任务4必须等任务3执行完以后再执行。这就又陷入了无限的等待中，造成死锁。

NSLog(@"1"); // 任务1
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    NSLog(@"2"); // 任务2
    dispatch_sync(dispatch_get_main_queue(), ^{
        NSLog(@"3"); // 任务3
    });
    NSLog(@"4"); // 任务4
});
NSLog(@"5"); // 任务5

1
2
5
3
4
// 5和2的顺序不一定复制代码