转载

如何用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对 countcountFinished 这两个变量的赋值顺序有依赖,所以基于优化的目的,有可能会调整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的schema中勾选Thread Sanitizer即可,如下图:

如何用Xcode8解决多线程问题

这里要注意的是,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中出现如下提示:

如何用Xcode8解决多线程问题

很直观,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可能性一般来说是还是比较高的 :)

欢迎关注公众号:MrPeakTech

如何用Xcode8解决多线程问题

原文  http://mrpeak.cn/blog/thread-sanitizer/
正文到此结束
Loading...