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 1count = 10;countFinished = true;//thread 2while (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中出现如下提示：
