iOS线程安全

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)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 delegate, NSUInteger idx, BOOL *stop) { 
            // Call delegate 
        }]; 
    }); 
} 

_delegateQueue的类型是 dispatch_queue_t，在其他地方定义，应该是个内部成员变量

• 除非addDelegate:或removeDelegate:每秒被调用上千次，否则下面是更简洁的方法：

// header 
@property (atomic, copy) NSSet *delegates; 
 
- (void)addDelegate:(id)delegate { 
    @synchronized(self) { 
        self.delegates = [self.delegates setByAddingObject:delegate]; 
    } 
} 
 
- (void)removeAllDelegates { 
    self.delegates = nil; 
} 
 
- (void)callDelegateForX { 
    [self.delegates enumerateObjectsUsingBlock:^(id delegate, NSUInteger idx, BOOL *stop) { 
        // Call delegate 
    }]; 
} 

实际的例子

在weex的SDK中有线程安全的字典和数组，以字典为例：

• 采用继承现有的字典方式

/**
 *  @abstract Thread safe NSMutableDictionary
 */
@interface WXThreadSafeMutableDictionary : 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)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_semaphore
• pthread_mutex
• OSSpinLock

小结

• 单例的时候，就用dispatch_once，就不要用@synchronized关键字
• 一般情况下，使用@synchronized(self)关键字，虽然性能耗一点，大多数情况下够用了，简单好用
• 接下来，考虑的是NSOperation和NSOperationQueue，并发数为1就是串行队列，线程安全；或者设置下依赖，不用管同步异步，串行并行等事情
• 再接下来，可以考虑用GCD的同步执行和栅栏，就像前面例子提到的那样，weex中用的那样，线程安全的字典或者数组，可以作为参考
• 再接下来，可以考虑用NSLock、NSRecursiveLock、NSConditionLock，用到这些的，已经算比较复杂了，要注意死锁问题，时序是否按照预想的发展。没有必要，还是不要用比较好。
• 如果考虑性能问题，那就用最后的大招dispatch_semaphore、
  pthread_mutex、OSSpinLock