一、多线程简述
线程是程序执行流的最小单元，一个线程包含：独有 ID，程序计数器 (Program Counter)，寄存器汇合，堆栈。同一过程能够有多个线程，它们共享过程的全局变量和堆数据。
这里的 PC (Program Counter) 指向的是以后的指令地址，通过 PC 的更新来运行咱们的程序，一个线程同一时刻只能执行一条指令。当然咱们晓得线程和过程都是虚构的概念，实际上 PC 是 CPU 外围中的寄存器，它是理论存在的，所以也能够说一个 CPU 外围同一时刻只能执行一个线程。
不论是多处理器设施还是多核设施，开发者往往只须要关怀 CPU 的外围数量，而不需关怀它们的物理形成。CPU 外围数量是无限的，也就是说一个设施并发执行的线程数量是无限的，当线程数量超过 CPU 外围数量时，一个 CPU 外围往往就要解决多个线程，这个行为叫做线程调度。
线程调度简略来说就是：一个 CPU 外围轮流让各个线程别离执行一段时间。当然这两头还蕴含着简单的逻辑，后文再来剖析。
iOS 开发交换技术群：563513413，不论你是大牛还是小白都欢送入驻，分享 BAT, 阿里面试题、面试教训，探讨技术，大家一起交流学习成长！
二、多线程的优化思路
在挪动端开发中，因为零碎的复杂性，开发者往往不能冀望所有线程都能真正的并发执行，而且开发者也不分明 XNU 何时切换内核态线程、何时进行线程调度，所以开发者要常常思考到线程调度的状况。
1、缩小线程切换
当线程数量超过 CPU 外围数量，CPU 外围通过线程调度切换用户态线程，意味着有上下文的转换（寄存器数据、栈等），过多的上下文切换会带来资源开销。尽管内核态线程的切换实践上不会是性能累赘，开发中还是应该尽量减少线程的切换。
2、线程优先级衡量
通常来说，线程调度除了轮转法以外，还有优先级调度的计划，在线程调度时，高优先级的线程会更早的执行。有两个概念须要明确：
- IO 密集型线程：频繁期待的线程，期待的时候会让出工夫片。
- CPU 密集型线程：很少期待的线程，意味着长时间占用着 CPU。
非凡场景下，当多个 CPU 密集型线程霸占了所有 CPU 资源，而它们的优先级都比拟高，而此时优先级较低的 IO 密集型线程将继续期待，产生线程饿死的景象。当然，为了防止线程饿死，零碎会逐步提高被“冷清”线程的优先级，IO 密集型线程通常状况下比 CPU 密集型线程更容易获取到优先级晋升。
尽管零碎会主动做这些事件，然而这总归会造成工夫期待，可能会影响用户体验。所以笔者认为开发者须要从两个方面衡量优先级问题：
- 让 IO 密集型线程优先级高于 CPU 密集型线程。
- 让紧急的工作领有更高的优先级。
比方一个场景：大量的图片异步解压的工作，解压的图片不须要立刻反馈给用户，同时又有大量的异步查问磁盘缓存的工作，而查问磁盘缓存工作实现过后须要反馈给用户。
图片解压属于 CPU 密集型线程，查问磁盘缓存属于 IO 密集型线程，而后者须要反馈给用户更加紧急，所以应该让图片解压线程的优先级低一点，查问磁盘缓存的线程优先级高一点。
值得注意的是，这里是说大量的异步工作，意味着 CPU 很有可能满负荷运算，若 CPU 资源入不敷出的状况下就没那个必要去解决优先级问题。
4、主线程工作的优化
有些业务只能写在主线程，比方 UI 类组件的初始化及其布局。其实这方面的优化就比拟多了，业界所说的性能优化大部分都是为了加重主线程的压力，仿佛有些偏离了多线程优化的领域了，上面就基于主线程工作的治理大抵列举几点吧：
内存复用
通过内存复用来缩小开拓内存的工夫耗费，这在零碎 UI 类组件中利用宽泛，比方 UITableViewCell 的复用。同时，缩小开拓内存意味着缩小了内存开释，同样能节约 CPU 资源。
懒加载工作
既然 UI 组件必须在主线程初始化，那么就须要用时再初始化吧，swift 的写时复制也是相似的思路。
工作拆分排队执行
通过监听 Runloop 行将完结等告诉，将大量的工作拆分开来，在每次 Runloop 循环周期执行大量工作。其实在实际这种优化思路之前，应该想想能不能将工作放到异步线程，而不是用这种比拟极其的优化伎俩。
主线程闲暇时执行工作
// 这里是主线程上下文
`dispatch_async(dispatch_get_main_queue(), ^{
// 等到主线程闲暇执行该工作
});`
三、对于“锁”
多线程会带来线程平安问题，当原子操作不能满足业务时，往往须要应用各种“锁”来保障内存的读写平安。
罕用的锁有互斥锁、读写锁、空转锁，通常状况下，iOS 开发中互斥锁 pthread_mutex_t、dispatch_semaphore_t，读写锁 pthread_rwlock_t 就能满足大部分需要，并且性能不错。
在读取锁失败时，线程有可能有两种状态：
- 空转状态：线程执行空工作循环期待，当锁可用时立刻获取锁。
- 挂起状态：线程挂起，当锁可用时须要其余线程唤醒。
唤醒线程比拟耗时，线程空转须要耗费 CPU 资源并且工夫越长耗费越多，由此可知空转适宜大量工作、挂起适宜大量工作。
实际上互斥锁和读写锁都有空转锁的个性，它们在获取锁失败时会先空转一段时间，而后才会挂起，而空转锁也不会永远的空转，在特定的空转工夫过后依然会挂起，所以通常状况下不必刻意去应用空转锁，Casa Taloyum 在博客中有具体的解释。
1、OSSpinLock 优先级反转问题
优先级反转概念：比方两个线程 A 和 B，优先级 A < B。当 A 获取锁访问共享资源时，B 尝试获取锁，那么 B 就会进入忙等状态，忙等工夫越长对 CPU 资源的占用越大；而因为 A 的优先级低于 B，A 无奈与高优先级的线程抢夺 CPU 资源，从而导致工作迟迟实现不了。解决优先级反转的办法有“优先级天花板”和“优先级继承”，它们的外围操作都是晋升以后正在访问共享资源的线程的优先级。
2、防止死锁
很常见的场景是，同一线程反复获取锁导致的死锁，这种状况能够应用递归锁来解决，pthread_mutex_t 应用 pthread_mutex_init_recursive() 办法初始化就能领有递归锁的个性。
应用 pthread_mutex_trylock() 等尝试获取锁的办法能无效的防止死锁的状况
3、最小化加锁工作
开发者应该充沛的了解业务，将锁蕴含的代码区域尽量放大，不会呈现线程平安问题 的代码就不要用锁来爱护了，这样能力进步并发时锁的性能。
4、时刻留神不可重入办法的平安
当一个办法是可重入的时候，能够放心大胆的应用，若一个办法不可重入，开发者应该多注意，思考这个办法会不会有多个线程拜访的状况，若有就老老实实的加上线程锁。
5、编译器的适度优化
编译器可能会为了提高效率将变量写入寄存器而临时不写回，不便下次应用，咱们晓得一句代码转换为指令不止一条，所以在变量写入寄存器没来得及写回的过程中，可能这个变量被其它线程读写了。编译器同样会为了提高效率对它认为程序无关的指令调换程序。
以上都可能会导致正当应用锁的中央依然线程不平安，而 volatile 关键字就能够解决这类问题，它能阻止编译器为了效率将变量缓存到寄存器而不及时写回，也能阻止编译器调整操作 volatile 润饰变量的指令程序。
原子自增函数就有相似的利用：int32_t OSAtomicIncrement32(volatile int32_t *__theValue)。
6、CPU 乱序执行
CPU 也可能为了提高效率而去替换指令的程序，导致加锁的代码也不平安，解决这类问题能够应用内存屏障，CPU 越过内存屏障后会刷新寄存器对变量的调配。