WWDC 2016 Thread Santizer and Static Analysis

一. Thread Santizer(TSAN) 线程竞态检测工具：可以在运行时发现线程竞态

竞态

两个线程同时访问同一个变量，而且其中至少一个线程要做的是写操作，这种情况就叫竞态。

使用场景

开发的App中存在的不能稳定重现的bug。

原因

这种bug通常是由多个线程访问同一块内存造成的。（俗称：线程冲突问题）

Demo

https://github.com/PigRiver/ThreadSantizerDemo

使用方法

target＝》Edit Scheme。在Diagnostics tab下勾选Thread Sanitizer。（可以选择 Pause on issues）

具体内容

http://www.jianshu.com/p/358535119e9b

使用Command-Line代码：

clang -fsanitize=thread source.c -o executable

xcodebuild -enableThreadSanitizer YES

TSAN_OPTIONS=halt_on_error=1 ./executable

注意：

1. 在 WWDC 演讲中，苹果推荐在所有的单元测试里都打开 thread sanitizer。Sanitizer 只在运行时有效，而且必须要代码运行到那儿才能检测出线程竞态。如果你的代码单元测试覆盖率很高，那么 Thread Sanitizer 能找出工程里绝大部分的线程竞态。

2. Tsan只会帮你在重现问题时精准地找到问题所在，而不会帮你重现问题。

3. 只支持64位的测试机调试。不支持真机。

原理：

图1

图1表明，Tsan是在生成exec时才绑定到程序中，所以:通用clang编绎的语言，都可以使用Tsan来定位线程冲突问题。

图2

当进行每一个内存访问时，都通过check、code对线程进行标记，记录读数据的时间。

在Shadow State中记录thread对数据的写操作。

每次thread写操作时，对比线程读数据的时间与Shadow State最近一次的写操作的时间。

二. Static Analysis:一个常见的 debug 的工具

Static Analyzer 能够检测出三种新的错误, 它们分别是:

Localizability

 本地化信息缺失的问题,目前能够检测出来两种类型的错误, 一种是没有使用 NSLocalizeString 这样的 API, 而直接给控件设置 Sting 的情况, 一种是使用了相应的 API, 但在 comment 信息里面赋值为 nil.

Instance Cleanup

在 MRC 的代码中, 尤其在 dealloc 中,我们不应该对 assign 类型的属性进行 release 操作,应该对 retain 或者 copy 类型的属性进行 release 操作, 如果不这样操作的话,会引发一些不必要的麻烦.

Nullability

2015 年的 WWDC 大会上, Objective-C 引入的一个新特性就叫做 Nullability, 用于表明一个东西到底可以为 nil 还是不可以为 nil .

一般什么时候会出现 nullability 方面的错误呢?

Objective-C 与 Swift 混编的场景

在代码中有一些逻辑错误

不正确的注释

为什么我们需要使用与 nullability 相关的关键字?

便于跟 Swift 的交互

方便使用者明白开发者的意图

能够将一些不必要的问题提前到编码阶段, 而不是到用户使用时才暴露。

三. 总结：

1. 我们可以通过Tsan来协助修复线程竞态问题。

2. Tsan的实现原理。

3. Static Analysis支持分析更多的问题。

参考：

http://www.jianshu.com/p/074072c33916

http://www.jianshu.com/p/358535119e9b