多线程

1. 进程

1.1 定义

• 进程是指在系统中正在运行的一个应用程序。
• 每个进程之间是独立的，每个进程均运行在其专用且受保护的内存空间内。

2. 线程

2.1 定义

• 线程是进程的基本执行单元，一个进程（程序）的所有任务都在线程中执行。
• 1个进程要想执行任务，必须得有线程（每1个进程至少要有1条线程）

3. 线程的串行

• 1个线程中任务的执行是串行(顺序执行)的。
• 如果要在1个线程中执行多个任务，那么只能一个一个地按顺序执行这些任务。也就是说，在同一时间内，1个线程只能执行1个任务
  
• 因此，也可以认为线程是进程中的1条执行路径

4. 多线程

4.1 定义

• 1个进程中可以开启多条线程，每条线程可以并发（同时）执行不同的任务
  多线程技术可以提高程序的执行效率
  

4.2 多线程的原理

• 同一时间，CPU只能处理1条线程，只有1条线程在工作（执行）
• 多线程并发（同时）执行，其实是CPU快速地在多条线程之间调度（切换）
• 如果CPU调度线程的时间足够快，就造成了多线程并发执行的假象

思考：如果线程非常非常多，会发生什么情况？    * CPU会在N多线程之间调度，CPU会累死，消耗大量的CPU资源    * 每条线程被调度执行的频次会降低（线程的执行效率降低）

4.3 多线程的优缺点

4.3.1 多线程的优点

• 通过并发提高程序的执行效率
• 能适当提高资源利用率（CPU、内存利用率）

4.3.2 多线程的缺点

• 开启线程需要占用一定的内存空间（默认情况下，每一条线程都占用512KB），如果开启大量的线程，会占用大量的内存空间，降低程序的性能
• 线程越多，CPU在调度线程上的开销就越大
• 程序设计更加复杂：比如线程之间的通信、多线程的数据共享

4.4 多线程在开发中的应用

4.4.1 主线程

• 一个iOS程序运行后，默认会开启1条线程，称为“主线程”或“UI线程”

4.4.2 主线程的作用

• 显示\刷新UI界面（所有更新UI的操作都在主线程上执行）
• 处理UI事件（比如点击事件、滚动事件、拖拽事件等）

4.4.3 使用多线程的作用

• 别将比较耗时的操作放到主线程中！把比较耗时的操作放在后台线程中执行，因为耗时操作会卡住主线程，严重影响UI的流畅度，给用户一种“卡”的坏体验。

NSLog 是专门用来调试的，性能非常不好，在商业软件中，要尽量去掉！

4.5 iOS中多线程的实现方案

4.5.1 pthread实现多线程

4.5.1.1 pthread说明

• pthread 是属于 POSIX 多线程开发框架

4.5.1.2 函数原型

    参数说明：        ①. 线程代号的地址 C语言中类型的结尾通常 _t/Ref，而且不需要使用 *        ②. 线程的属性        ③. 调用函数的指针        ④. 传递给该函数的参数    返回值        0：表示正确        非0：表示错误码

使用举例：

- (void)pthreadDemo{    // 创建线程    pthread_t threadId;    NSString *str = @"Hello Pthread";    int result = pthread_create(&threadId, NULL, &demo, (__bridge void *)(str));    if (result == 0)    {        NSLog(@"OK");    }    else    {        NSLog(@"error %d", result);    }}void *demo(void *param){    NSString *tmp = (__bridge NSString *)(param);    NSLog(@"%@, %@", [NSThread currentThread], tmp);    return NULL;}

注意事项：
* void ()(void *)
返回值 (函数指针)(参数)

void * 和 OC 中的 id 是等价的
id(*)(id)

• 在 ARC 开发中，如果设计到和 C 语言中相同的数据类型进行转换时，需要使用 __bridge “桥接”

• 在 MRC 开发中，不需要桥接

• 在 OC 中，如果是 ARC 开发，编译器会在编译的时候，自动根据代码结构，添加 retain, release, autorelease

• ARC 只负责 OC 部分的代码，不负责 C 的代码，如果 C 语言的框架出现 retain/create/copy 字样的函数，都需要release
• 关于桥接的添加，可以利用 Xcode 辅助实现！

4.5.2 NSThread实现多线程

4.5.2.1 方式一

- (void)threadDemo1{    // 实例化/加载 => alloc（分配内存） / init(初始化)    NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(demo:) object:@"Thread"];    // 启动线程    [thread start];}- (void)demo:(id)obj{    for (int i = 0; i<2; i++)    {        NSLog(@"%@ %@", [NSThread currentThread], obj);    }}

4.5.2.1 方式二

- (void)threadDemo2{    NSLog(@"1--%@", [NSThread currentThread]);    // detachNewThreadSelector 会理解在后台线程执行 selector 方法    // detach => 分离一个自线程执行 demo: 方法    [NSThread detachNewThreadSelector:@selector(demo:) toTarget:self withObject:@"Detach"];}

4.5.2.1 方式三

- (void)threadDemo3{    NSLog(@"1--%@", [NSThread currentThread]);    // 是 NSObject 的一个分类方法，意味着所有的 NSObject 都可以使用此方法，在其他线程执行方法！    // 特点：没有thread字眼，一旦制定，就会立即在后台线程执行 selector 方法    // performSelectorInBackground 隐式的多线程方法    // 这种方法，在使用的时候更加灵活！    [self performSelectorInBackground:@selector(demo:) withObject:@"background"];}

4.5.2.1 方式四

- (void)threadDemo4{    Person *p = [[Person alloc] init];    [p performSelectorInBackground:@selector(loadData) withObject:nil];}

由于- (void)performSelectorInBackground:(SEL)aSelector withObject:(id)arg方法是NSObject对象的分类（@interface NSObject (NSThreadPerformAdditions)），所以只要是直接或间接继承自NSObject的对象，都可以调用performSelectorInBackground方法。

4.6 多线程的安全隐患

4.6.1 出现隐患的场景

• 多条线程抢夺同一块资源。

4.6.2 解决方案

• 使用互斥锁或者自旋锁。

4.6.2.1 互斥锁

• 1) 互斥锁的使用格式
  
  • @synchronized(锁对象) { // 需要锁定的代码 }
    注意：锁定1份代码只用1把锁，用多把锁是无效的
• 2) 互斥锁的优缺点
  
  • 优点：能有效防止因多线程抢夺资源造成的数据安全问题
  • 缺点：需要消耗大量的CPU资源
互斥锁的锁定范围，应该尽量小，锁定范围越大，效率越差！

4.6.2.2 自旋锁

• 1) 原子性与非原子性
  
  • nonatomic： 非原子属性
  • atomic：原子属性(线程安全)，就是针对多线程设计的，是默认属性
    多个线程写入属性时，保证同一时间只有一个线程能够执行写入操作
    单(线程)写多(线程)读的一种多线程技术，同样有可能出现“脏数据”，重新读一下。
    实际上，原子属性内部也有一把锁，自旋锁

OC 中定义属性，通常会声成 _成员变量
如果同时重写了属性的 getter & setter 方法，_成员变量 就不自动生成！
@synthesize 合成指令，在 Xcode 4.5 之前非常多！Xcode 4.5 之前的属性不会自动生成 _成员变量！


4.6.2.3 互斥锁与自旋锁的异同

• 共同点
  都能保证同一时间，只有一条线程执行锁定范围的代码

• 不同点

  • 互斥锁：如果发现有其他线程正在执行锁定的代码，线程会进入休眠状态，等待其他线程执行完毕，打开锁之后，线程会被唤醒

  • 自旋锁：如果发现有其他线程正在执行锁定的代码，线程会用死循环的方式，一直等待锁定代码执行完成！
    自旋锁更适合执行非常短的代码！

无论什么锁，都是要付出代价的！