一个类要么是多线程安全的，要么它就不是。
前言
多线程情况下的随机crash是在iOS 编程过程中比较常见的一种�问题， 并且这种类型的bug排查和修改都相对比较困难。网络上有挺多讲解多线程概念和基本用法的文章，在此我就不重复讲解了。 不过我发现很少有文章对各种不同实现进行对比和测试。所以就写了这一篇文章。
本文主要是通过探索如何实现一个线程安全的model类， 从而验证不同的实现方式是否能真正实现线程安全，同时也对�这些实现的性能做一个初步的横向比较。
在Objective-C中，多线程相关的概念主要有atomic, NSLock, @synchronize, GCD, NSOperation. 由于NSOperation在底层上是通过GCD来实现的，所以本文将�主要讨论前4种概念相关的实现方式。
�
代码实现
详细的实现代码请参考https://github.com/jiakai-lian/ThreadSafeClassDesign 。
无保护：
@property(nonatomic, copy) NSArray *subItems;Atomic：
@property(atomic, copy) NSArray *subItems;-
NSLock：
@interface ItemLock()@property (nonatomic, strong) NSRecursiveLock *lock; @end @implementation ItemLock @synthesize subItems = _subItems; - (instancetype)init { self = [super init]; if (self) { _subItems = [NSArray array]; } return self; } #pragma mark - Public - (NSArray *)subItems { [self.lock lock]; NSArray * array = _subItems; [self.lock unlock]; return array; } - (void)addsubItem:(NSString *)string { [self.lock lock]; NSMutableArray * array = [NSMutableArray arrayWithArray:self.subItems]; [array addObject:string]; self.subItems = array; [self.lock unlock]; } #pragma mark - Private - (NSRecursiveLock *)lock { static NSRecursiveLock *internalLock = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ internalLock = [[NSRecursiveLock alloc] init]; }); return _lock = internalLock; } @end -
@synchronized(self)：
@implementation ItemSyncSelf @synthesize subItems = _subItems; - (instancetype)init { self = [super init]; if (self) { _subItems = [NSArray array]; } return self; } #pragma mark - Public - (NSArray *)subItems { @synchronized (self) { return _subItems; } } - (void)addsubItem:(NSString *)string { @synchronized (self) { NSMutableArray * array = [NSMutableArray arrayWithArray:self.subItems]; [array addObject:string]; self.subItems = array; } } @end -
Serial Queue + sync read + sync write：
@implementation ItemSyncQueue@synthesize subItems = _subItems; - (instancetype)init { self = [super init]; if (self) { _subItems = [NSArray array]; } return self; } #pragma mark - Public - (NSArray *)subItems { __block NSArray * array; dispatch_sync(self.syncQueue, ^{ array = _subItems; }); return array; } - (void)addsubItem:(NSString *)string { dispatch_sync(self.syncQueue, ^{ NSMutableArray * array = [NSMutableArray arrayWithArray:_subItems]; [array addObject:string]; _subItems = array.copy; }); } #pragma mark - Private - (dispatch_queue_t) syncQueue { static dispatch_queue_t queue = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ queue = dispatch_queue_create("com.jiakai.ItemSyncQueue", DISPATCH_QUEUE_SERIAL); }); return queue; } @end -
Serial Queue + sync read + async write：
@implementation ItemAsyncSetter@synthesize subItems = _subItems; - (instancetype)init { self = [super init]; if (self) { _subItems = [NSArray array]; } return self; } - (NSArray *)subItems { __block NSArray* array; dispatch_sync(self.syncQueue, ^{ array = _subItems; }); return array; } - (void)addsubItem:(NSString *)string { dispatch_async(self.syncQueue, ^{ NSMutableArray * array = [NSMutableArray arrayWithArray:_subItems]; [array addObject:string]; self.subItems = array; }); } #pragma mark - Private - (dispatch_queue_t)syncQueue { static dispatch_queue_t queue = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ queue = dispatch_queue_create("com.jiakai.ItemAsyncSetter", DISPATCH_QUEUE_SERIAL); }); return queue; } @end -
Concurrent Queue + sync read + barrier async write：
@implementation ItemBarrierAsyncSetter@synthesize subItems = _subItems; - (instancetype)init { self = [super init]; if (self) { _subItems = [NSArray array]; } return self; } - (NSArray *)subItems { __block NSArray *array; dispatch_sync(self.syncQueue, ^{ array = _subItems; }); return array; } - (void)addsubItem:(NSString *)string { dispatch_barrier_async(self.syncQueue, ^{ NSMutableArray * array = [NSMutableArray arrayWithArray:_subItems]; [array addObject:string]; self.subItems = array; }); } #pragma mark - Private - (dispatch_queue_t)syncQueue { static dispatch_queue_t queue = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ queue = dispatch_queue_create("com.jiakai.ItemBarrierAsyncSetter", DISPATCH_QUEUE_CONCURRENT); }); return queue; } @end 测试代码：
以下代码利用dispath_apply 去重复异步调用同一个block, 调用次数在此例子中为10000次。 也就是说，从参数传入的item变量理论上同时会被10000个线程同时访问。因此如果实现存在多线程问题，还是比较容易暴露出来的。
void testScenario(id <ItemProtocol> item) {
@autoreleasepool {
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_apply(DISPATCH_QUEUE_COUNT, queue, ^(size_t i) {
if(!(i%10))
{
[item addsubItem:@"subItems"];
}
else
{
NSUInteger n = [item subItems].count;
n++;
}
});
}
}
��实验结果分析
以下是不同实现方式的�线程安全的实验结果：
| 类/Queue | 读 | 写 | �线程安全 | 原因分析 |
|---|---|---|---|---|
| 无保护 | N/A | N/A | N | |
| Atomic | N/A | N/A | N | 很多人误解，以为设置成atomic就可以保证线程安全， 其实并非如此。具体原因见文末的补充说明 |
| NSLock | N/A | N/A | Y | 互斥锁可以保证锁之间的所有操作都是互斥的。性能基本上和@sychronized相当。 |
| @sychornized(self) | N/A | N/A | Y | 这种方式是最偷懒省事的办法。�性能方面相对要差一些 |
| SerialQueue | Sync | Sync | Y | 不管是sync 还是async 操作，serial queue可以保证一次只有一个block在执行，所以是线程安全的。 |
| SerialQueue | Sync | Async | Y | 同上 |
| ConcurrentQueue | Sync | Sync | N | 不管是sync write，还是async write 是无法保证线程安全的。因为在任意时间点，可能有多个write block在queue中运行。 |
| ConcurrentQueue | Sync | Async | N | �同上 |
| ConcurrentQueue | Sync | BarrierAsync | Y | 改用Barrier Async write 以后，写操作之间是互斥的。同时在写操作完成之前，不会�执行之后加入的read操作，所以不会发生在数据在写的过程当中被读取的情况。 |
线程安全实现之间的性能比较
总结
�总体来说，�并发读互斥写（Concurrent read，Exclusive write）是一个比较理想的多线程工作�模式， 在确保线程安全同时也保留了多线程的性能优势。在Objective-C中，这种模式的具体实现就是concurrentQueue+sync read+barrier async write。当然，如果对于少量代码需要线程安全，同时性能方面要求不高的应用场景来说，@sychronized也是一种比较便捷的实现方式。
补充说明
-
为什么atomic 无法保证线程安全
Atomic 只能保证单步操作的原子性。因此，对于简单的赋值或者读取操作，atomic还是可以保证该操作的完整性。但是，一旦涉及到多步骤操作，还是需要lock等其他的同步机制来确保线程安全。
实例：
@peroperty(atomic, strong) NSMutableArray * array;
array = [NSMutableArray array]; //线程安全
[array addObject:dummyObject];//线程不安全，在读取array后，执行addObject 的过程中，array所指向的object 可能已经在其他地方被释放了
而在实际应用中，大部分操作都是多步骤操作，atomic可以在一定程度上减少crash的几率，从而掩盖多线程问题，但是却无法从根本上解决线程安全问题。
-
为什么说@sychronized（self）的性能差
@sychronized 所包含的代码片段 一次只允许一个线程执行，同时又会阻塞调用线程， 类似上述表格中Serial queue + dispatch sync 的组合 。一旦这些代码片段同时被多个线程访问，就会对性能造成较大的影响。
-
测试代码中读操作：写操作数量 9：1 的原因说明
在实际的项目中，绝大部分情况都是读取数据，只有小部分情况需要写数据。 这样的设置主要是为了模拟实际的使用情况，增加测试结果的可参考性。
如有错漏，欢迎指正。
参考资料
https://www.objc.io/issues/2-concurrency/thread-safe-class-design/
http://stackoverflow.com/questions/19179358/concurrent-vs-serial-queues-in-gcd
https://www.mikeash.com/pyblog/friday-qa-2011-10-14-whats-new-in-gcd.html
Effective Objective-C 2.0 - Item 41
