使用 dispatch_once 来执行只需要运行一次的线程安全代码
单例模式 对 OC 开发者来说并不陌生, 常见的实现方式为: 在类中编写名为 sharedInstance 的方法, 该方法只会返回全类功能够用的单例实例.而不会在每次调用时都创建新的实例, 假设 有个类叫做 EOCClass, 那么这个共享实例的方法一般都会这样写.
+ (id)shareInstance{
static EOCClass * shareInstance = nil;
@synchronized(self){
if (!shareInstance) {
shareInstance = [[self alloc]init];
}
}
return shareInstance;
}
为保证线程安全,上述代码将创建单例实例的代码包裹在同步块里面. 无论是好是坏, 这样的代码随处可见.
不过,GCD 引入了一项特性,能使单例实现起来更为容易, 所用的函数是:
void dispatch_once (dispatch_once_t * token,
dispatcg_block_t block);
此处函数接受类型为 dispatch_once_t 的特殊参数, 称其为'标记(token)', 此外还接受 块参数, 对于给定的标记来说, 该函数保证相关的块 必定会执行, 且只执行一次, 首次调用该函数时,必然会执行块中的代码, 最重要的一点在于,此操作完全是线程安全的, 请注意,对于只需要执行一次的 块 来说,.每次调用时传入的标记都必须完全相同, 因此,开发者通常将标记白能量声明在 static 或 global 作用域里.
刚才实现单例模式所用的 shareInstance 方法, 可以用此函数改写
+ (id)shareInstance{
static EOCClass * shareInstance = nil;
static dispatch_once_t once_token;
dispatch_once(&once_token, ^{
if (!shareInstance) {
shareInstance = [[self alloc]init];
}
});
return shareInstance;
}
使用 dispatch_once 可以简化代码并且彻底保证线程安全, 开发者根本无需担心加锁或同步, 所有问题都由 GCD 在底层处理, 由于每次调用时都必须使用完全相同的标记, 所以标记要声明为 static,把该变量定义在 static 作用域中, 可以保证编译器在每次执行 shareInstance 方法时都会复用这个变量, 而不会创建新变量.
此外,dispanch_once 更加高效, 他没有使用重量级的同步机制, 若是那样的话,每次运行代码前都要获取同步锁,相反,此函数采用 '原子访问' 来查询标记, 以判断其所对应的代码原来是否已经执行过,很明显, 后者比前者快的多.
总结:
经常需要编写 '字需要执行一次的线程安全代码, 通过 GCD 所提供的 dispatch_once 函数,很容易就能实现此功能,
标记应该声明在 static 或 global 的作用域中, 这样的话, 再把只需要执行那个一次的块 给 dispatch_once 函数时, 传进去的标记也是相同的.
不要使用 dispatch_get_current_queue
使用 GCD 时,经常需要判断当前代码正在哪个队列上,向多个队列派发任务时. 更是如此, 例如, Mac OS X 与 iOS 的 UI 事务都需要在主线程上执行,而这个线程就相当于 GCD 中的主队列, 有时似乎需要判断当前代码是不是在主队列上执行, 有这么一个函数
dispatch_queue_t dispatch_get_current_queue;
文档中说, 此函数返回当前正在执行的代码的队列, 确实如此, 不过用的时候大家要小心, 实际上, iOS 系统 从 6.0 版本起,已经正式弃用 .
该函数有种典型的错误用法, 就是用它检测当前队列是不是某个特定的队列, 试图以此来避免同步派发时可能遭遇的死锁问题, 考虑下面的两个存取方法, 其代码用队列来保证对实例变量的访问操作是同步的.
- (NSString *)someString{
__block NSString *localSomeString;
dispatch_sync(_syncQueue,^{
locaSomeString = _someString;
});
}
- (void)setSomeString:(NSString *)someString{
dispatch_sync(_syncQueue,^{
_someString = someString;
});
}
这种写法的问题在于, 获取方法 (getter) 可能会死锁. 假如调用获取方法的队列恰好是同步操作所针对的队列(本例中是 _syncQueue), 那么 dispatch_sync 就一直不会返回,直到 块 执行完毕为止, 可是, 应该执行 块 的那个目标队列却是当前队列, 而当前队列的 dispatch_sync 又一直阻塞着,它在等待目标队列把这个 块 执行完,这样一来, 块 就永远没有机会执行了,
