AFNetwoking 和 SDWebImage 内部都是用的 NSOperation
GCD
- 同步/异步 和 串行/并行
- dispatch_barrier_async
- dispatch_group
同步/异步 和 串行/并行
分为：
- dispatch_sync(serial_queuq, ^{//任务});
- dispatch_async(serial_queuq, ^{//任务});
- dispatch_sync(concurrentQueuq, ^{//任务});
- dispatch_async(concurrentQueuq, ^{//任务});
串行
- 同步串行
1、请思考下面这段代码会发生什么？
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
dispatch_sync(dispatch_get_main_queue(), ^{
[self dosomething];
})
}
上面这段代码会发生死锁，死锁的原因是：队列引起的循环等待，并不是线程引起的循环等待
这段代码的逻辑：在主队列中提交了viewDidLoad任务，然后提交 block任务，这2个任务最终都需要分派的主线程中执行。比如说分派 viewDidLoad到主线程中处理，在执行过程当中，需要调用block，当block同步调用完成后，viewDidLoad方法才能继续向下执行，所以viewDidLoad调用结束或者说处理需要依赖于后续提交的block任务。主队列的性质是先进先出，Block任务要执行，依赖于 viewDidLoad任务完成。这个过程就造成死锁。
2、请思考下面这段代码会死锁吗？
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
dispatch_queue_t queue = dispatch_queue_create(DISPATCH_QUEUE_SERIAL, 0);
dispatch_async(serialQueue, ^{
[self dosomething];
});
}
这段代码没有问题，原因如下：
代码逻辑：以上代码涉及2个队列，一个是主队列，一个是串行队列。
在viewDidLoad运行在主线程中，viewDidLoad执行到某一时刻时，需要同步提交任务到对应的串行队列上。同步提交，意味着在当前线程执行，所以串行队列提交的任务，最终也是在主线程中执行，串行队列中提交的任务在主线程当中执行完成后，才去继续执行主队列viewDidLoad后续的代码逻辑.
-
主线程和主队列的关系：主队列是主线程中的一个串行队列，所有的和UI的操作(刷新或者点击按钮)都必须在主线程中的主队列中去执行，否则无法更新UI，每一个应用程序只有唯一的一个主队列用来更新 UI。
-
队列和线程的关系：在一个线程内可能有多个队列，这些队列可能是串行的或者是并行的，按照同步或者异步的方式工作
异步的，则会开启新的线程工作
同步的，会在当前线程内工作，不会创建新的线程
注意：并行同步队列，不会创建新的线程而且会是顺序执行相当于串行同步队列 -
同步并发
1、思考下面这段代码的输出结果
- (void)viewDidLoad
{
NSLog(@"----1");
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_sync(queue, ^{
NSLog(@"----2");
dispatch_sync(queue, ^{
NSLog(@"----3");
});
NSLog(@"-----4");
});
NSLog(@"-----5");
}
注意：只要是以同步的方式提交任务，无论是串行队列还是并行队列都是在当前线程执行任务。
输出结果是：
如果把上面代码里的并行队列换成串行队列，将发生死锁
- 异步并发
1、请思考下面这段代码的输出结果？
- (void)viewDidLoad
{
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(queue, ^{
NSLog(@"---6");
[self performSelector:@selector(printLog) withObject:nil afterDelay:0];
NSLog(@"----8");
});
}
- (void)printLog
{
NSLog(@"7");
}
上面代码的执行结果是：6和8，7是不会打印的，因为 performSelector:withObject: afterDelay: 即使是延迟0秒，默认也是需要开启 RunLoop 的，而子线程中 RunLoop 默认是没有开启的，因此这个方法在这里是会失效的。
dispatch_barrier_async()
- 怎样利用 GCD 实现多读单写？
具体实现如下：
#import "UserCenter.h"
@interface UserCenter()
@property (nonatomic, strong) NSMutableDictionary *userCenterDict;
@property (nonatomic, assign) dispatch_queue_t queue;
@end
@implementation UserCenter
- (instancetype)init
{
self = [super init];
if (self) {
//创建并发队列
dispatch_queue_t queue = dispatch_queue_create("read_write_queue", DISPATCH_QUEUE_CONCURRENT);
self.queue = queue;
//用户数据中心，可能多个线程需要数据访问
self.userCenterDict = [NSMutableDictionary dictionary];
}
return self;
}
- (void)objectForKey:(NSString *)key
{
__block id obj;
//同步读取指定数据，这里用同步是因为要求立刻返回结果，所以用同步
dispatch_sync(self.queue, ^{
obj = [self.userCenterDict objectForKey:key];
});
}
- (void)setObject:(id)obj forKey:(NSString *)key
{
//异步栅栏调用设置数据
dispatch_barrier_async(self.queue, ^{
[self.userCenterDict setObject:obj forKey:key];
});
}
@end
dispatch_group_async()
思考如何使用GCD实现这个需求：A、B、C三个任务并发，完成后执行任务D？
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
dispatch_group_t group = dispatch_group_create();
dispatch_queue_t queue = dispatch_queue_create("group.create", DISPATCH_QUEUE_CONCURRENT);
dispatch_group_async(group, queue, ^{
//任务1；
});
dispatch_group_async(group, queue, ^{
//任务2；
});
dispatch_group_async(group, queue, ^{
//任务3；
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
//任务4；
});
}
NSOperation
需要和 NSOperationQueue 配合使用来实现多线程方案
- 请思考使用
NSOperation有哪些优势和特点？
- 可以添加任务依赖，主要通过
operation addDependency:和operation removeDependency:来实现 - 任务执行状态控制
- 可以控制最大并发量
任务执行状态控制
- isReady 是否处于就绪状态
- isExecuting 当前任务是否处于正在执行中
- isFinished 当前任务是否完成
- isCanceled 当前任务是否已取消
状态控制主要涉及 main 方法和 start 方法
- 如果只重写了
main方法，底层控制变更任务执行完成状态，以及任务退出 - 如果重写了
start方法，自行控制任务状态
下面参考 GNUstep 关于 NSOperation 的源来看下内部实现机制
start.png
状态
状态2
image.png
Q：系统怎样移除一个 isFinished = YES 的NSOperation的?
A：通过KVO来移除 NSOperationQueue 里的 NSOperation
NSThread
通常是结合 RunLoop 来一块考察的
- NSThread 启动流程
其中里面的 main 函数是 NSThread 内部的 main 函数
下面是 start 方法的内部实现机制，同样是基于 gnustep-base-1.24.9
start函数
image.png
image.png
image.png
NSThread的执行原理是内部创建了一个 pThread 执行线程，然后当 main 函数或者我们指定的target的selector方法执行结束以后，会为我们执行线程退出的管理操作，如果我们要想维护一个常驻线程的话，需要在 NSThread 对应的 selector 方法中去维护 runloop 的事件循环。
多线程的锁
- iOS当中都有哪些锁，或者你使用过哪些锁？
- @synchronized
- atomic
- OSSpinLock
- NSRecursiveLock
- NSLock
- dispatch_semaphore_t
上面就构成了我们经常使用的锁，这些锁应用在不同的场景下
@synchronized
一般在创建单例对象的时候使用
atomic
- 修改属性的关键字
- 对被修饰的对象进行原子操作（赋值操作保证安全，其他情况下不保证安全），示例如下：
OSSpinLock(自旋锁)
- 循环等待询问，不释放当前资源，类似一个
while操作，循环检测是否能获得锁的访问，如果不能，继续轮询，直到可以获得 - 应用场景：用于轻量级数据访问，简单的int值+1/-1操作
NSLock
Q：以上代码有什么问题？
A：methodA, 加锁后，methodB又对同一把锁进行加锁，就相当于已经获取到了锁，又再次获取这个锁，就会由于重入的原因导致死锁。可以使用递归锁NSRecursiveLock来解决这个问题，递归锁的特点就是可以重入。
dispatch_semaphore_t
//根据一个初始值创建信号量
dispatch_semaphore_create（信号量值）
//如果信号量的值<=0，当前线程就会进入休眠等待（直到信号量的值>0）;如果信号量的值>0，就减1，然后往下执行后面的代码。
dispatch_semaphore_wait（信号量，等待时间）
//提高信号量(让信号量的值加1)
dispatch_semaphore_signal(信号量)
下面是 wait 方面的内部处理逻辑，如果信号量值为0，则唤醒
下面是 signal 的内部机制
常见面试题
我们使用GCD来实现一些简单的线程同步，包括一些子线程的分配，包括多读单写这些场景的解决，对于 NSOperation 由于它可以方便地让我们对状态进行控制，添加依赖，移除依赖
网友评论