如何用Xcode8解决多线程问题

Xcode 8诞生有段时日了，不知道大家对其中的新Feature是否都学习过一遍了，今天给大家介绍下Xcode 8中一个很实用的特性，Thread Sanitizer，用来解决平时编写代码时难以调试的多线程问题，顺道梳理下一些常见的容易混淆的多线程概念。

Thread Sanitizer

这款工具集成在Xcode 8中，主要帮助定位多线程相关的问题，还没有了解过的同学可以先查看 WWDC 2016 Session 412。官方的介绍当中它可以查出以下多线程相关的问题：

• Use of uninitialized mutexes
• Thread leaks (missing pthread_join)
• Unsafe calls in signal handlers (ex:malloc)
• Unlock from wrong thread
• Data races

前面四项出现的场景较少，真正体现这款工具强大之处的是最后一项，检查data races，也是我们平时写多线程代码时最容易遇到的问题，一旦踩坑，现象往往是偶现的，难以调试。

在开始介绍Thread Sanitizer如何使用之前，我们应该先花点时间了解下什么是data race，以及它到底有什么危害，建议先看下我之前写过的一篇关于iOS多线程安全的文章。

data race的定义很简单：当至少有两个线程同时访问同一个变量，而且至少其中有一个是写操作时，就发生了data race。这段定义只是描述了什么是data race，却没有说明data race会带来什么严重后果，这是因为data race可能会造成多种影响，而且有些影响不一定是致命的（比如crash）。data race也不是什么罕见的场景，只要涉及到多线程编程，遇到的概率非常之高，下面我们看一些data race具体的例子及其危害。

场景一：计算出错

这也是大学课程里经常举例的一个场景，Objective C代码如下：

__block int count = 0;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    for (int i = 0; i < 10000; i ++) {
        count ++;
    }
});
for (int i = 0; i < 10000; i ++) {
    count ++;
}

最后计算的结果有很大概率小于20000，原因是count ++为非原子操作。这也是data race的场景，这种race没有crash也没有memory corruption，因此有些人把这种race称作benign race(良性的race)。不过上面提到的WWDC视频中，苹果的工程师说到：

There is No Such Thing as a “Benign” Race

意思是，只要发生data race，就没有良性一说了，因为虽然程序没有crash，但count最后的值还是出错了，这种 错误必然会导致逻辑上的错误，如果这个count值代表的是你银行卡余额，你应该会更加同意苹果工程师的观点。

场景二：Crash！

这种场景是真正会导致crash和memory corruption的，发生在两个线程同时对同一个变量执行写操作时，比如如下Objective C代码：

NSMutableString* str = [@"" mutableCopy];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    for (int i = 0; i < 10000; i ++) {
        [str setString:@"1234567890"];
    }
});
for (int i = 0; i < 10000; i ++) {
    [str setString:@"abcdefghigk"];
}

这也属于data race的场景，一般会出现在对于复杂对象（class或者struct）的多线程写操作中，原因是因为写操作本身不是原子的，而且写操作背后会调用更多的内存操作，多线程同时写时，会导致这块内存区间处于中间的不稳定状态，进而crash，这是真正的恶性的data race。

场景三：乱序

过去几年Review代码的经历中，看到过不少如下使用公共变量来做多线程同步的，比如：

//thread 1
count = 10;
countFinished = true;

//thread 2
while (countFinished == false) {
    usleep(1000);
}
NSLog(@"count: %d", count);

按理说，count最后会输出值10。可实际上，编译器并不知道thread 2对count和countFinished这两个变量的赋值顺序有依赖，所以基于优化的目的，有可能会调整thread 1中count = 10;和countFinished = true;生成的最后指令的执行顺序，最后也就导致count值输出的时机不对，虽然最后count的值还是10。这也可以看做是一种benign race，因为也不会crash，而是程序的流程出错。而且这种错误的调试及其困难，因为逻辑上是完全正确的，不明白其中缘由的同学甚至会怀疑是系统bug。

遇到这种多线程读写状态，而且存在顺序依赖的场景，不能简单依赖代码逻辑。解决这种data race场景有一个简单办法：加锁，比如使用NSLock，将对顺序有依赖的代码块整个原子化，加锁之所以有用是因为会生成memory barrier，从而避免了编译器优化。

场景四：内存泄漏

iOS刚诞生不久时，还没有多少Best Practise，不少人写单例的时候还不会用到dispatch_once_t，而是采用如下直白的写法：

Singleton *getSingleton() {
    static Singleton *sharedInstance = nil;
    if (sharedInstance == nil) {
        sharedInstance = [[Singleton alloc] init];
    }
    return sharedInstance;
}

这种写法的问题是，多线程环境下，thread A和thread B会同时进入sharedInstance = [[Singleton alloc] init];，Singleton被多创建了一次，MRC环境就产生了内存泄漏。

这是个经典的例子，也是data race的场景之一，其结果是造成额外的内存泄漏，这种race也可以算作是benign的，但也是我们平时编写代码应该避免的。

上面几个是我们写iOS代码比较容易遇到的，还有其他一些就不一一举例了，只要理解了data race的含义都不难分析这些race导致的具体问题。

BOOL是否多线程安全？

在之前那篇iOS多线程安全的文章中，我提到对于BOOL类型的property来说，声明为atomic并没有意义，nonatmoic对于BOOL的get，set也是安全的。

@property (nonatomic, assign) BOOL isValid;

原理我也简单解释了一下，但之后有一些朋友私底下和我交流，还是对这一观点存疑。

实际上，上面的WWDC视频中，苹果的工程师也提到了这一点：有些人认为pointer sized的变量操作时是天然多线程安全的。所谓的pointer size也就是我们指针变量的大小，64位系统为8字节。这位工程师提到，这种看法是问题的，理由如下：

On some architectures (ex., x86) reads and writes are atomic

But even a “benign” race is undefined behavior in C

May cause issues with new compilers or architectures

C标准对于这种行为定义是undefined behavior，意思是最后的结果是不确定的，不同的编译器针对不同的CPU架构所产生的最后执行文件，其执行结果是没有规定的，如果有哪个硬件平台上出现了crash，那么也没有违背C的标准，因为C没有规定其一定是原子操作。

同时，据我所知（扒过一些资料），以及我这么些年写iOS代码的经历，nonatomic修饰的BOOL确实是原子操作且多线程安全的，我也没找到什么样的CPU架构下，pointer sized的变量是非原子操作的。

所以，更准确更严格的说法应该是：现阶段的iOS设备软硬件环境下，BOOL的读写是原子的，不过将来不一定，苹果官方和C标准都没有做任何保证。

如何使用Thread Sanitizer

启用Thread Sanitizer的方式很简单，只需要在Xcode的scheme中勾选Thread Sanitizer即可，如下图：

这里要注意的是，Thread Sanitizer现阶段只能在模拟器环境下执行，真机还不支持，而且我测试发现，只支持64位系统，也就是说iPhone 5及其更早的模拟器也不支持，iPhone 5s之后才是64位系统。

勾选之后，重新编译运行代码即可，我用下面一段代码做测试：

__block int count = 0;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    for (int i = 0; i < 10000; i ++) {
        count ++;
    }
});
for (int i = 0; i < 10000; i ++) {
    count ++;
}

运行之后会在Xcode中出现如下提示：

很直观，Xcode直接提示你发生了data race的变量及其代码位置，同时还清晰的展示了函数当前的各线程调用栈，十分清晰，接下来你要做的就是增加同步操作，比如加锁，从而消除data race，再运行测试是否生效。

原理

Thread Sanitizer的工作原理在WWDC的视频中也介绍过了，大家可以仔细看下视频，大致原理是记录每个线程访问变量的信息来做分析，值得一提的是，现阶段的Thread Sanitizer最多只同时记录4个线程的访问信息，在复杂的场景下，可能出现偶尔检测不出data race的场景，所以需要长时间经常性的运行来尽可能多的发现data race，这也是为什么苹果建议默认开启Thread Sanitizer，而且Thread Sanitizer造成的额外性能损耗非常之小。

结束语

以上就是Xcode 8新增的多线程问题调试工具Thread Sanitizer，了解背后原理再去使用工具才更得心应手，赶紧拿公司项目跑一跑吧，发现一堆data race可能性一般来说是还是比较高的 :)