多线程篇一:多线程基础
线程和进程
- 什么是进程
- 进程是指在系统中正在运行的一个应用程序
- 每个进程之间是独立的,每个进程均运行在其专用且受保护的内存空间内
- 比如同时打开迅雷、Xcode,系统就会分别启动2个进程
- 通过“活动监视器”可以查看Mac系统中所开启的进程
- 什么是线程
- 1个进程(应用程序)要想执行任务,必须得有线程(每1个进程至少要有1条线程)
- 一个进程(程序)的所有任务都在线程中执行
- 比如使用酷狗播放音乐、使用迅雷下载电影,都需要在线程中执行
多线程
- 线程的串行
- 1个线程中任务的执行是串行的
- 如果要在1个线程中执行多个任务,那么只能一个一个地按顺序执行这些任务
- 也就是说,在同一时间内,1个线程只能执行1个任务
- 因此,也可以认为线程是进程中的1条执行路径
- 比如在1个线程中下载3个文件(分别是文件A、文件B、文件C)
- 1个线程中任务的执行是串行的
- 什么是多线程
- 1个进程中可以开启多条线程,每条线程可以并行(同时)执行不同的任务
- 进程<=>车间,线程<=>车间工人
- 多线程技术可以提高程序的执行效率
- 比如同时开启3条线程分别下载3个文件(分别是文件A、文件B、文件C)
- 多线程的原理
- 同一时间,CPU只能处理1条线程,只有1条线程在工作(执行)
- 多线程并发(同时)执行,其实是CPU快速地在多条线程之间调度(切换)
- 如果CPU调度线程的时间足够快,就造成了多线程并发执行的假象
- 思考:如果线程非常非常多,会发生什么情况?
- CPU会在N多线程之间调度,CPU会累死,消耗大量的CPU资源
- 每条线程被调度执行的频次会降低(线程的执行效率降低)
- 多线程的优缺点
- 多线程的优点
- 能适当提高程序的执行效率
- 能适当提高资源利用率(CPU、内存利用率)
- 多线程的缺点
- 创建线程是有开销的,iOS下主要成本包括:内核数据结构(大约1KB)、栈空间(子线程512KB、主线程1MB,也可以使用-setStackSize:设置,但必须是4K的倍数,而且最小是16K),创建线程大约需要90毫秒的创建时间
- 如果开启大量的线程,会降低程序的性能
- 线程越多,CPU在调度线程上的开销就越大
- 程序设计更加复杂:比如线程之间的通信、多线程的数据共享
- 多线程的优点
多线程在iOS开发中的应用
- 什么是主线程
- 一个iOS程序运行后,默认会开启1条线程,称为“主线程”或“UI线程”
- 主线程的主要作用
- 显示\刷新UI界面
- 处理UI事件(比如点击事件、滚动事件、拖拽事件等)
- 主线程的使用注意
- 别将比较耗时的操作放到主线程中
- 耗时操作会卡住主线程,严重影响UI的流畅度,给用户一种“卡”的坏体验
iOS中多线程的实现方案
技术方案 简介 语言 线程生命周期 使用频率
1. 一套通用的多线程API
pthread 2. 适用于Unix\Linux\Windows等系统 C 程序员管理 几乎不用
3. 跨平台\可移植
4. 使用难度大
NSThread 1. 使用更加面向对象 OC 程序员管理 偶尔使用
2.简单易用,可直接操作线程对象
GCD 1.旨在替代NSThread等线程技术 C 自动管理 经常使用
2.充分利用设备的多核
1.基于GCD(底层是GCD)
NSOperation 2.比GCD多了一些更简单实用的功能 OC 自动管理 经常使用
3.使用更加面向对象
NSThread
- 一个NSThread对象就代表一条线程
创建和启动线程
-
创建和启动线程
NSThread *thread = [[NSThread alloc] initWithTarget:self selector:@selector(run) object:nil]; // 线程一启动,就会在线程thread中执行self的run方法 [thread start];
-
主线程相关用法
+ (NSThread *)mainThread; // 获得主线程 - (BOOL)isMainThread; // 是否为主线程 + (BOOL)isMainThread; // 是否为主线程
-
其他用法
//获得当前线程 NSThread *current = [NSThread currentThread]; //线程的名字 - (void)setName:(NSString *)n; - (NSString *)name;
-
其他创建线程方式
//创建线程后自动启动线程 [NSThread detachNewThreadSelector:@selector(run) toTarget:self withObject:nil]; //隐式创建并启动线程 [self performSelectorInBackground:@selector(run) withObject:nil];
- 上述2种创建线程方式的优缺点
- 优点:简单快捷
- 缺点:无法对线程进行更详细的设置
- 上述2种创建线程方式的优缺点
线程的状态
-
线程7种状态的相互转换(其他语言,但比较全面,不是iOS)
- 执行new方法,在内存中会开辟一块空间存放线程对象,线程就进入了初始状态;
- 当该对象调用了start()方法,就会将该线程对象放入到可调度线程池中,就进入可运行状态runnable;
- 进入可运行状态后,当该对象被操作系统选中,获得CPU时间片就会进入运行状态;
- 进入运行状态后情况就比较复杂了
- run()方法或main()方法结束后,线程就进入终止状态;
- 当线程调用了自身的sleep()方法或其他线程的join()方法,就会进入阻塞状态(该状态既停止当前线程,但并不释放所占有的资源)。当sleep()结束或join()结束后,该线程进入可运行状态,继续等待OS分配时间片;
- 线程调用了yield()方法,意思是放弃当前获得的CPU时间片,或者当前的CPU时间片用完,回到可运行状态,这时与其他进程处于同等竞争状态,OS有可能会接着又让这个进程进入运行状态;
- 当线程刚进入可运行状态(注意,还没运行),发现将要调用的资源被synchroniza(同步),获取不到锁标记,将会立即进入锁池状态,等待获取锁标记(这时的锁池里也许已经有了其他线程在等待获取锁标记,这时它们处于队列状态,既先到先得),一旦线程获得锁标记后,就转入可运行状态,等待OS分配CPU时间片;
- 当线程调用wait()方法后会进入等待队列(进入这个状态会释放所占有的所有资源,与阻塞状态不同),进入这个状态后,是不能自动唤醒的,必须依靠其他线程调用notify()或notifyAll()方法才能被唤醒(由于notify()只是唤醒一个线程,但我们由不能确定具体唤醒的是哪一个线程,也许我们需要唤醒的线程不能够被唤醒,因此在实际使用时,一般都用notifyAll()方法,唤醒有所线程),线程被唤醒后会进入锁池,等待获取锁标记。
-
控制线程状态
//启动线程 //进入就绪状态 -> 运行状态。当线程任务执行完毕,自动进入死亡状态 - (void)start; //阻塞(暂停)线程,进入阻塞状态 + (void)sleepUntilDate:(NSDate *)date; + (void)sleepForTimeInterval:(NSTimeInterval)ti; //强制停止线程,进入死亡状态 + (void)exit;
注意:一旦线程停止(死亡)了,就不能再次开启任务
CPU的时间是按时间片分的,而不是一个时间点,并发问题是由于CPU线程切换导致的。
if(i == 1) {
i++; //断点1
system.out.print(i);
} //断点2
- 有两个线程A,B同时执行这一段代码,假设A线程先被CPU调度,然而A线程在断点1处,时间片到期了,此时A线程的代码并没有执行完,但是CPU此时会调度B线程,并不会管A线程是不是执行完了这一段代码。
- 再接着假设B线程现在执行完了这一段代码(当然也可能没有执行完),CPU 现在就又会调度A线程,并且从A线程的断点1处继续执行(注意不是重新执行,CPU切换的时候保存了线程的上下文)
- 总结:CPU切换线程并不会管你线程是否将代码执行完,而是和分给线程的时间片是否到期有关,时间片到期了就会切换线程,并发也就由此产生了。
代码举例
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
[NSThread detachNewThreadSelector:@selector(run) toTarget:self withObject:nil];
}
- (void)run{
for (NSInteger i = 0; i<100; i++) {
NSLog(@"-----%zd", i);
if (i == 49) {
[NSThread exit]; // 直接退出当前线程
// 直接退出当前应用程序
// exit(<#int#>)
}
}
}
- (void)run2{
NSLog(@"-------");
// [NSThread sleepForTimeInterval:2]; // 让线程睡眠2秒(阻塞2秒)
// [NSThread sleepUntilDate:[NSDate distantFuture]];
[NSThread sleepUntilDate:[NSDate dateWithTimeIntervalSinceNow:2]];
NSLog(@"-------");
}
多线程的安全隐患
- 资源共享
- 1块资源可能会被多个线程共享,也就是多个线程可能会访问同一块资源
- 比如多个线程访问同一个对象、同一个变量、同一个文件
- l当多个线程访问同一块资源时,很容易引发数据错乱和数据安全问题
- 安全隐患解决 – 互斥锁
- 当A线程访问时,锁住,不允许其他线程访问,当A线程访问完毕,开锁。其他线程访问,同样加锁开锁。
-
互斥锁使用格式
//锁对象:通常为控制器。特点:该对象整个程序中不死 @synchronized(锁对象) { // 需要锁定的代码 }
- 注意:锁定1份代码只用1把锁,用多把锁是无效的
- 互斥锁的优缺点
- 优点:能有效防止因多线程抢夺资源造成的数据安全问题
- 缺点:需要消耗大量的CPU资源
- 互斥锁的使用前提:多条线程抢夺同一块资源
- 相关专业术语:线程同步
- 线程同步的意思是:多条线程在同一条线上执行(按顺序地执行任务)
- 互斥锁,就是使用了线程同步技术
原子和非原子属性
- nonatomic与atomic
- OC在定义属性时有
nonatomic
和atomic
两种选择 - atomic:原子属性,为setter方法加锁(默认就是atomic)
- nonatomic:非原子属性,不会为setter方法加锁
- OC在定义属性时有
- 原子和非原子属性的选择
- atomic:线程安全,需要消耗大量的资源
- nonatomic:非线程安全,适合内存小的移动设备
- iOS开发的建议
- 所有属性都声明为nonatomic
- 尽量避免多线程抢夺同一块资源
- 尽量将加锁、资源抢夺的业务逻辑交给服务器端处理,减小移动客户端的压力
- 注意!!!
- atomic是为setter方法加锁,只能说明使用set方法给对象成员变量赋值是安全的。
- 如果使用KVC给对象成员变量赋值,那么仍然会出现多线程问题。
- 因此atomic并不能保证成员变量的访问安全,只能保证通过set方法访问成员变量安全
线程间通信
- 什么叫做线程间通信:在1个进程中,线程往往不是孤立存在的,多个线程之间需要经常进行通信
- 线程间通信的体现
- 1个线程传递数据给另1个线程
- 在1个线程中执行完特定任务后,转到另1个线程继续执行任务
-
线程间通信常用方法
- (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg waitUntilDone:(BOOL)wait; - (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait;
使用举例
-
场景:通过子线程下载图片,下载完成之后回到主线程刷新UI
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event { //开启 [self performSelectorInBackground:@selector(download3) withObject:nil]; } - (void)download3{ // 图片的网络路径 NSURL *url = [NSURL URLWithString:@"http://img.pconline.com.cn/images/photoblog/9/9/8/1/9981681/200910/11/1255259355826.jpg"]; // 加载图片,根据图片的网络路径去下载图片数据 NSData *data = [NSData dataWithContentsOfURL:url]; // 生成图片 UIImage *image = [UIImage imageWithData:data]; // 回到主线程,显示图片 //注意:这里是调用self.imageView的setImage:方法设置图片,比较巧妙!!! [self.imageView performSelector:@selector(setImage:) onThread:[NSThread mainThread] withObject:image waitUntilDone:NO]; // [self.imageView performSelectorOnMainThread:@selector(setImage:) withObject:image waitUntilDone:NO]; // [self performSelectorOnMainThread:@selector(showImage:) withObject:image waitUntilDone:YES]; } //- (void)showImage:(UIImage *)image{ // self.imageView.image = image; //}