UIKit是线程不安全的
-
UIKit是线程不安全的，并且这是苹果有意的设计，主要是为了提升性能。具体原因，下面这篇文章写得很好：
线程安全类的设计
这个章节的内容都是这篇文章的节选
- 最容易犯的错误是在后台线程中对property赋值，比如图片，因为图片是在后台从网络上获取的。如果两个线程同时设置图片，很可能程序将直接崩溃，因为当前设置的图片可能会被释放两次。由于这是和时机相关的，因此崩溃通常发生在客户使用时，而并不是在开发过程中。
- 在大多数情况下，
UIKit类只应该在程序的主线程使用。无论是从UIResponder派生的类，还是那些涉及以任何方式操作你的应用程序的用户界面。 - 在异步块操作里一贯使用
__weak和不访问ivars是推荐的方式。 - 一般情况下，不可变类，像
NSArray是线程安全的，而它们的可变的变体，像NSMutableArray则不是。好的做法是写一些像return [array copy]来确保返回的对象实际上是不可变的。 - 单独使用原子属性不会让你的类线程安全的。它只会保护你在
setter中免受竞态条件(race conditions)，但不会保护你的应用程序逻辑。 - 在试图做线程安全之前，认真考虑是否是必要的。请确保它不是过早的优化。如果它像是一个配置类，考虑线程安全是没有意义的。更好的方法是抛出一些断言来确保它的正确使用：
void PSPDFAssertIfNotMainThread(void) {
NSAssert(NSThread.isMainThread,
@"Error: Method needs to be called on the main thread. %@",
[NSThread callStackSymbols]);
}
- 一个好的方法是使用一个并行
dispatch_queue为读/写锁，以最大限度地提高性能，并尝试只锁定那些真正需要的地方。
// header
@property (nonatomic, strong) NSMutableSet *delegates;
// in init
_delegateQueue = dispatch_queue_create("com.PSPDFKit.cacheDelegateQueue",
DISPATCH_QUEUE_CONCURRENT);
- (void)addDelegate:(id<PSPDFCacheDelegate>)delegate {
dispatch_barrier_async(_delegateQueue, ^{
[self.delegates addObject:delegate];
});
}
- (void)removeAllDelegates {
dispatch_barrier_async(_delegateQueue, ^{
self.delegates removeAllObjects];
});
}
- (void)callDelegateForX {
dispatch_sync(_delegateQueue, ^{
[self.delegates enumerateObjectsUsingBlock:^(id<PSPDFCacheDelegate> delegate, NSUInteger idx, BOOL *stop) {
// Call delegate
}];
});
}
_delegateQueue的类型是dispatch_queue_t，在其他地方定义，应该是个内部成员变量
- 除非
addDelegate:或removeDelegate:每秒被调用上千次，否则下面是更简洁的方法：
// header
@property (atomic, copy) NSSet *delegates;
- (void)addDelegate:(id<PSPDFCacheDelegate>)delegate {
@synchronized(self) {
self.delegates = [self.delegates setByAddingObject:delegate];
}
}
- (void)removeAllDelegates {
self.delegates = nil;
}
- (void)callDelegateForX {
[self.delegates enumerateObjectsUsingBlock:^(id<PSPDFCacheDelegate> delegate, NSUInteger idx, BOOL *stop) {
// Call delegate
}];
}
实际的例子
在weex的SDK中有线程安全的字典和数组，以字典为例：
- 采用继承现有的字典方式
/**
* @abstract Thread safe NSMutableDictionary
*/
@interface WXThreadSafeMutableDictionary<KeyType, ObjectType> : NSMutableDictionary
@end
- 这个可以讨论，可以直接从
NSObject过来，不过要重新设计一下对外的接口。本人更倾向于这种组合模式，接口可以自定义，按照需求来，用特殊的名字，防止使用过度。更有定制化的味道。比如key规定为NSString类型
用继承的方式，直接重写父类的方法。这种方式是接口更通用，而且不用自己想接口的名字和调用方式。使用起来，跟普通的字典没什么两样。使用起来更方便。
内部用了一个队列，额外包含了一个字典
@interface WXThreadSafeMutableDictionary ()
@property (nonatomic, strong) dispatch_queue_t queue;
@property (nonatomic, strong) NSMutableDictionary* dict;
@end
- 是并行队列，用到了指针地址作为名字的一部分，保证唯一性
- (instancetype)initCommon {
self = [super init];
if (self) {
NSString* uuid = [NSString stringWithFormat:@"com.taobao.weex.dictionary_%p", self];
_queue = dispatch_queue_create([uuid UTF8String], DISPATCH_QUEUE_CONCURRENT);
}
return self;
}
NSString和UTF8String是不一样的，GCD是c函数
- 有些方法用同步执行的方式实现“线程安全”
- (id)objectForKey:(id)aKey {
__block id obj;
dispatch_sync(_queue, ^{
obj = _dict[aKey];
});
return obj;
}
- 有些方法用异步栅栏实现“线程安全”
- (void)setObject:(id)anObject forKey:(id<NSCopying>)aKey {
aKey = [aKey copyWithZone:NULL];
dispatch_barrier_async(_queue, ^{
_dict[aKey] = anObject;
});
}
- copy给的是内部成员变量字典的副本，并不是真正自己的副本。这个就是本人不大喜欢继承的原因。（很多时候，组合比继承要好理解一点）
- (id)copy {
__block id copyInstance;
dispatch_sync(_queue, ^{
copyInstance = [_dict copy];
});
return copyInstance;
}
同步机制
保证线程安全的措施。下面两篇文章不错：
iOS中保证线程安全的几种方式与性能对比
iOS开发里的线程安全机制
Foundation对象
- 使用
@synchronized关键字 - 使用
NSLock - 使用
NSRecursiveLock - 使用
NSConditionLock - 使用
NSCondition类
GCD方式
dispatch_semaphorepthread_mutexOSSpinLock
小结
- 单例的时候，就用
dispatch_once，就不要用@synchronized关键字 - 一般情况下，使用
@synchronized(self)关键字，虽然性能耗一点，大多数情况下够用了，简单好用 - 接下来，考虑的是
NSOperation和NSOperationQueue，并发数为1就是串行队列，线程安全；或者设置下依赖，不用管同步异步，串行并行等事情 - 再接下来，可以考虑用
GCD的同步执行和栅栏，就像前面例子提到的那样，weex中用的那样，线程安全的字典或者数组，可以作为参考 - 再接下来，可以考虑用
NSLock、NSRecursiveLock、NSConditionLock，用到这些的，已经算比较复杂了，要注意死锁问题，时序是否按照预想的发展。没有必要，还是不要用比较好。 - 如果考虑性能问题，那就用最后的大招
dispatch_semaphore、
pthread_mutex、OSSpinLock
