<p>Xcode 8诞生有段时日了，不知道大家对其中的新Feature是否都学习过一遍了，今天给大家介绍下Xcode 8中一个很实用的特性，Thread Sanitizer，用来解决平时编写代码时难以调试的多线程问题，顺道梳理下一些常见的容易混淆的多线程概念。</p>    <h3>Thread Sanitizer</h3>    <p>这款工具集成在Xcode 8中，主要帮助定位多线程相关的问题，还没有了解过的同学可以先查看 <a href="/misc/goto?guid=4959732193516443805" rel="nofollow,noindex">WWDC 2016 Session 412</a> 。官方的介绍当中它可以查出以下多线程相关的问题：</p>    <ul>     <li>Use of uninitialized mutexes</li>     <li>Thread leaks (missing pthread_join)</li>     <li>Unsafe calls in signal handlers (ex:malloc)</li>     <li>Unlock from wrong thread</li>     <li><strong>Data races</strong></li>    </ul>    <p>前面四项出现的场景较少，真正体现这款工具强大之处的是最后一项，检查data races，也是我们平时写多线程代码时最容易遇到的问题，一旦踩坑，现象往往是偶现的，难以调试。</p>    <p>在开始介绍Thread Sanitizer如何使用之前，我们应该先花点时间了解下什么是data race，以及它到底有什么危害，建议先看下我之前写过的一篇关于iOS多线程安全的文章。</p>    <p>data race的定义很简单： 当至少有两个线程同时访问同一个变量，而且至少其中有一个是写操作时，就发生了data race 。这段定义只是描述了什么是data race，却没有说明data race会带来什么严重后果，这是因为data race可能会造成多种影响，而且有些影响不一定是致命的（比如crash）。data race也不是什么罕见的场景，只要涉及到多线程编程，遇到的概率非常之高，下面我们看一些data race具体的例子及其危害。</p>    <p>场景一：计算出错</p>    <p>这也是大学课程里经常举例的一个场景，Objective C代码如下：</p>    <pre>  <code class="language-objectivec">__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 ++;  }</code></pre>    <p>最后计算的结果有很大概率小于20000，原因是 count ++ 为非原子操作。这也是data race的场景，这种race没有crash也没有memory corruption，因此有些人把这种race称作 <strong>benign race(良性的race)</strong> 。不过上面提到的WWDC视频中，苹果的工程师说到：</p>    <p>There is No Such Thing as a “Benign” Race</p>    <p>意思是，只要发生data race，就没有良性一说了，因为虽然程序没有crash，但count最后的值还是出错了，这种 错误必然会导致逻辑上的错误，如果这个count值代表的是你银行卡余额，你应该会更加同意苹果工程师的观点。</p>    <p>场景二：Crash！</p>    <p>这种场景是真正会导致crash和memory corruption的，发生在两个线程同时对同一个变量执行写操作时，比如如下Objective C代码：</p>    <pre>  <code class="language-objectivec">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"];  }</code></pre>    <p>这也属于data race的场景，一般会出现在对于复杂对象（class或者struct）的多线程写操作中，原因是因为写操作本身不是原子的，而且写操作背后会调用更多的内存操作，多线程同时写时，会导致这块内存区间处于中间的不稳定状态，进而crash，这是真正的恶性的data race。</p>    <p>场景三：乱序</p>    <p>过去几年Review代码的经历中，看到过不少如下使用公共变量来做多线程同步的，比如：</p>    <pre>  <code class="language-objectivec">//thread 1  count = 10;  countFinished = true;    //thread 2  while (countFinished == false) {      usleep(1000);  }  NSLog(@"count: %d", count);</code></pre>    <p>按理说，count最后会输出值10。可实际上，编译器并不知道thread 2对 count 和 countFinished 这两个变量的赋值顺序有依赖，所以基于优化的目的，有可能会调整thread 1中 count = 10; 和 countFinished = true; 生成的最后指令的执行顺序，最后也就导致count值输出的时机不对，虽然最后count的值还是10。这也可以看做是一种benign race，因为也不会crash，而是程序的流程出错。而且这种错误的调试及其困难，因为逻辑上是完全正确的，不明白其中缘由的同学甚至会怀疑是系统bug。</p>    <p>遇到这种多线程读写状态，而且存在顺序依赖的场景，不能简单依赖代码逻辑。解决这种data race场景有一个简单办法： <strong>加锁</strong> ，比如使用NSLock，将对顺序有依赖的代码块整个原子化，加锁之所以有用是因为会生成memory barrier，从而避免了编译器优化。</p>    <p>场景四：内存泄漏</p>    <p>iOS刚诞生不久时，还没有多少Best Practise，不少人写单例的时候还不会用到dispatch_once_t，而是采用如下直白的写法：</p>    <pre>  <code class="language-objectivec">Singleton *getSingleton() {      static Singleton *sharedInstance = nil;      if (sharedInstance == nil) {          sharedInstance = [[Singleton alloc] init];      }      return sharedInstance;  }</code></pre>    <p>这种写法的问题是，多线程环境下，thread A和thread B会同时进入 sharedInstance = [[Singleton alloc] init]; ，Singleton被多创建了一次，MRC环境就产生了内存泄漏。</p>    <p>这是个经典的例子，也是data race的场景之一，其结果是造成额外的内存泄漏，这种race也可以算作是benign的，但也是我们平时编写代码应该避免的。</p>    <p>上面几个是我们写iOS代码比较容易遇到的，还有其他一些就不一一举例了，只要理解了data race的含义都不难分析这些race导致的具体问题。</p>    <h3>BOOL是否多线程安全？</h3>    <p>在之前那篇iOS多线程安全的文章中，我提到对于BOOL类型的property来说，声明为atomic并没有意义，nonatmoic对于BOOL的get，set也是安全的。</p>    <pre>  <code class="language-objectivec">@property (nonatomic, assign) BOOL isValid;</code></pre>    <p>原理我也简单解释了一下，但之后有一些朋友私底下和我交流，还是对这一观点存疑。</p>    <p>实际上，上面的WWDC视频中，苹果的工程师也提到了这一点： 有些人认为pointer sized的变量操作时是天然多线程安全的 。所谓的pointer size也就是我们指针变量的大小，64位系统为8字节。这位工程师提到，这种看法是问题的，理由如下：</p>    <p>On some architectures (ex., x86) reads and writes are atomic</p>    <p>But even a “benign” race is undefined behavior in C</p>    <p>May cause issues with new compilers or architectures</p>    <p>C标准对于这种行为定义是undefined behavior，意思是最后的结果是不确定的，不同的编译器针对不同的CPU架构所产生的最后执行文件，其执行结果是没有规定的，如果有哪个硬件平台上出现了crash，那么也没有违背C的标准，因为C没有规定其一定是原子操作。</p>    <p>同时，据我所知（扒过一些资料），以及我这么些年写iOS代码的经历，nonatomic修饰的BOOL确实是原子操作且多线程安全的，我也没找到什么样的CPU架构下，pointer sized的变量是非原子操作的。</p>    <p>所以，更准确更严格的说法应该是： 现阶段的iOS设备软硬件环境下，BOOL的读写是原子的，不过将来不一定，苹果官方和C标准都没有做任何保证 。</p>    <h3>如何使用Thread Sanitizer</h3>    <p>启用Thread Sanitizer的方式很简单，只需要在Xcode的schema中勾选Thread Sanitizer即可，如下图：</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/6ddb7771a9eb237a869e5d8f87953afb.png"></p>    <p>这里要注意的是，Thread Sanitizer现阶段只能在模拟器环境下执行，真机还不支持，而且我测试发现，只支持64位系统，也就是说iPhone 5及其更早的模拟器也不支持，iPhone 5s之后才是64位系统。</p>    <p>勾选之后，重新编译运行代码即可，我用下面一段代码做测试：</p>    <pre>  <code class="language-objectivec">__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 ++;  }</code></pre>    <p>运行之后会在Xcode中出现如下提示：</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/347c7a9ffd0e083386ce2edbf6775558.png"></p>    <p>很直观，Xcode直接提示你发生了data race的变量及其代码位置，同时还清晰的展示了函数当前的各线程调用栈，十分清晰，接下来你要做的就是增加同步操作，比如加锁，从而消除data race，再运行测试是否生效。</p>    <h3>原理</h3>    <p>Thread Sanitizer的工作原理在WWDC的视频中也介绍过了，大家可以仔细看下视频，大致原理是记录每个线程访问变量的信息来做分析，值得一提的是，现阶段的Thread Sanitizer最多只同时记录4个线程的访问信息，在复杂的场景下，可能出现偶尔检测不出data race的场景，所以需要长时间经常性的运行来尽可能多的发现data race，这也是为什么苹果建议默认开启Thread Sanitizer，而且Thread Sanitizer造成的额外性能损耗非常之小。</p>    <h3>结束语</h3>    <p>以上就是Xcode 8新增的多线程问题调试工具Thread Sanitizer，了解背后原理再去使用工具才更得心应手，赶紧拿公司项目跑一跑吧，发现一堆data race可能性一般来说是还是比较高的 :)</p>    <p> </p>    <p> </p>    <p>来自：http://mrpeak.cn/blog/thread-sanitizer/</p>    <p> </p>