漫谈 C++ 的各种检查

为什么代码中需要各种检查？在 C++ 中调用一个函数、使用一个类、实例化一个模板时，对传入的参数、使用的时机，往往会有很多限制 (constraint/restriction)。本文主要分享 Chromium/base 库中使用的一些限制检查。
作者：BOTMan，来源于BOTManJL
来源：腾讯技术工程微信号

What you don't use you don't pay for. (zero-overhead principle)
—— Bjarne Stroustrup

背景阅读

在学习了Chromium/base库（笔记）后，我体会到了一般人和优秀工程师的差距 —— 拥有较高的个人素质固然重要，但更重要的是能降低开发门槛，让其他人更快的融入团队，一起协作（尤其像 Chromium 开源项目由社区维护，开发者水平参差不齐）。

没吃过猪肉，但见过猪跑。🙃

项目中，降低开发门槛的方法有很多：除了制定代码规范、划分功能模块、完善单元测试 (unit test)、推行代码审查 (code review)、整理相关文档之外，针对强类型的编译语言 C++，Chromium/base 库加入了大量的检查 (check)。

为什么代码中需要各种检查？在C++中调用一个函数、使用一个类、实例化一个模板时，对传入的参数、使用的时机，往往会有很多限制 (constraint/restriction)（例如，数值参数不能传入负数、对象的访问不是线程安全的、函数调用不能重入）；而处理限制的方法有很多：

口口相传：在代码审查时，有经验的开发者向新手开发者传授经验（很容易失传）
文档说明：在相关文档中，提示使用者功能模块的各种隐含限制（很容易被忽略）
检查限制：在合理划分功能模块的前提下，对模块的隐含限制进行检查，并加入针对检查的单元测试（最安全的保障，单元测试即文档）

本文主要分享 Chromium/base 库中使用的一些限制检查。

1 编译时检查

编译时静态检查，主要依靠C++语言提供的语法支持/静态断言和编译器扩展实现 —— 在检查失败的情况下，编译失败。

1.1 测试设施

如何确保代码中添加的检查有效呢？最高效的方法是：为 “检查” 添加单元测试。但对于编译时检查遇到了一个难点 —— 如果检查失败，那么编译就无法通过。

为此，Chromium支持编译失败测试 (no-compile test)：

单元测试文件中，每个用例通过 #ifdef 切割
每个用例中，标明编译失败后期望的报错细节
通过 #define 运行各个用例
在编译失败后，检查报错细节是否和预期一致

对应的单元测试文件后缀为 *_unittest.nc，通过 nocompile.gni 加入单元测试工程。

1.2 可拷贝性检查

C++ 语言本身有很多编译时检查（例如类的成员访问控制(member access control)、const关键字在编译成汇编语言后，不能反编译还原），但C++对象默认是可拷贝的，从而带来了许多问题（参考资源管理小记）。

尤其是多态 (polymorphic) 类的默认拷贝行为，一般都不符合预期：

为此，Chromium 提供了两个常用的宏：

DISALLOW_COPY_AND_ASSIGN 用于禁用类的拷贝构造函数和拷贝赋值函数
DISALLOW_IMPLICIT_CONSTRUCTORS 用于禁用类的默认构造函数和拷贝行为

由于 Chromium 大量使用了 C++ 的多态特性，这些宏随处可见。

1.3 参数类型检查

Chromium还基于现代C++元编程技术，通过static_assert进行静态断言。

在之前写的深入C++回调中分析了：

Chromium 的base::Callback <> +

base::Bind() 回调机制，提到了相关的静态断言检查。

base::Bind 为了处理失效的（弱引用）上下文，针对弱引用指针base::WeakPtr扩展了base::IsWeakReceiver检查，判断弱引用的上下文是否有效；并通过静态断言检查传入参数，强制要求使用者遵循弱引用检查的规范：

base::Bind 不允许直接将 this 指针绑定到类的成员函数上，因为 this 裸指针可能失效变成野指针
base::Bind 不允许绑定lambda表达式，因为 base::Bind 无法检查 lambda 表达式捕获的弱引用的有效性
base::Bind 只允许将 base::WeakPtr 指针绑定到没有返回值的（返回 void）类的成员函数上，因为当弱引用失效时不调用回调，也没有返回值

base::Callback区分回调只能执行一次还是可以多次，通过引用限定符 (reference qualifier) && / const &，区分在对象处于非 const 右值 / 其他状态时的 Run 成员函数，只允许一次回调 base::OnceCallback 在非 const 右值状态下调用 Run 函数，保证严谨的资源管理语义：

base::OnceClosure cb; std::move(cb).Run();        // OK
base::OnceClosure cb; cb.Run();                   // not compile
const base::OnceClosure cb; cb.Run();             // not compile
const base::OnceClosure cb; std::move(cb).Run();  // not compile

另外，静态断言检查还广泛应用在 Chromium/base 的容器、智能指针模板的实现中，用于生成可读性更好的实例化错误信息。

1.4 线程标记检查

最新的 Chromium 使用了 Clang 编译，通过扩展线程标记 (thread annotation)，静态分析线程安全问题。（参考：Thread Safety Annotations for Clang - DeLesley Hutchins）

Chromium/base 的单元测试文件：

thread_annotations_unittest.nc 描述了一些锁的错误使用场景（假设数据 data 被锁 lock 保护，定义标记为 Type data GUARDED_BY(lock);）：

访问 data 之前，忘记获取 lock
获取 lock 之后，忘记释放 lock

这些错误能在编译时被 Clang 检查到，从而编译失败。

2 运行时检查

运行时动态检查，主要基于 Chromium/base 库提供的断言 DCHECK/CHECK 实现 —— 如果断言失败，运行着的程序会立即终止。

其中，DCHECK 只对调试版 (debug) 有效，而 CHECK 也可用于发布版 (release) —— 从而避免在发布版进行无用的检查。

2.1 测试设施

检查的方法很直观 —— 构造一个检查失败的场景，期望断言失败。

Chromium/base 基础设施中的EXPECT_DCHECK_DEATH提供了这个功能，对应的单元测试文件后缀为 *_unittest.cc。

2.2 数值溢出检查

C++ 的数值类型，都是固定大小的标量类型 —— 如果存储数值超出范围，会导致溢出 (overflow)。

例如，尝试通过使用无符号数避免出现负数，往往是一个典型的徒劳之举。（比如 unsigned(0) - unsigned(1) == UINT_MAX，参考 ES.106: Don’t try to avoid negative values by using unsigned）

为此，Chromium 的 base/numerics 提供了一个无依赖 (dependency-free)、仅头文件 (header-only) 的模板库，处理数值溢出问题：

base::StrictNumeric/base::strict_cast<>() 编译时阻止溢出 —— 如果类型转换有溢出的可能性，通过静态断言报错
base::CheckedNumeric/base::checked_cast<>() 运行时检查溢出 —— 如果数值运算/类型转换出现溢出，立即终止程序
base::ClampedNumeric/base::saturated_cast<>() 运行时截断运算 —— 如果数值运算/类型转换出现溢出，对计算结果截断 (non-sticky saturating) 处理

2.3 线程相关检查

最新的 Chromium/base 线程模型引入了线程池，并支持了序列 (sequence) 的概念 —— 相对于线程池中的普通任务乱序调度，同一序列的任务能保证被顺序调度 —— 因此，推荐使用逻辑序列而不是物理线程：

同一物理线程只能同时运行一个逻辑序列，使得序列模型等效于单线程模型
同一物理线程可以用于运行多个逻辑序列，提高物理线程的利用率

线程/序列相关的检查主要依赖于线程/序列本地存储：

每个线程有独立的 base::ThreadLocalStorage

线程本地存储 (thread local storage, TLS)

每个序列有独立的 base::SequenceLocalStorageSlot

序列本地存储 (sequence local storage, SLS)

当逻辑序列被放到物理线程上执行时，把当前序列的SLS关联到执行线程的 TLS

2.3.1 线程安全检查

很多时候，某个对象只会在同一线程/序列中创建/访问/销毁：

正常情况下，无竞争 (contention-free) 模型没必要保证线程安全 (thread-safety)，因为线程同步操作/原子操作会带来不必要的开销
异常情况下，一旦被多线程同时使用，访问冲突导致数据竞争 (data race)，可能出现未定义行为

为此，Chromium 借助：

base::ThreadChecker/base::SequenceChecker

检查对象是否只在同一线程/序列中使用：

[THREAD|SEQUENCE]_CHECKER(checker) 创建并关联线程/序列 checker
DCHECK_CALLED_ON_VALID_THREAD|SEQUENCE 检查或关联 checker 和当前执行环境的线程/序列
DETACH_FROM_THREAD|SEQUENCE 解除 checker 和线程/序列的关联
另外，发布版的检查实现为空对象，即总能通过检查

实现的核心思想非常简单：

线程/序列创建时，通过 TLS/SLS 记录当前线程/序列的 ID（例如线程 ID、序列 ID）
checker 构造时，记录当前线程/序列的 ID
checker 检查时，读取当前线程/序列的 ID，和 checker 记录的 ID 比较
checker 析构时，先执行检查（可以提前解除关联）
另外，checker 读写数据成员时，需要进行互斥的线程同步操作（锁）

在[sec|通知迭代检查] 提到，base::ObserverList借助 iteration_sequence_checker_ 在迭代时检查对象操作是否线程/序列安全。

2.3.2 线程限制检查

程序中常常会有一些特殊用途的线程（例如客户端 UI 主线程），而这些线程往往有着特殊的限制（例如，UI 线程要求保持响应性 (responsive)，实时响应用户输入）。

为此，Chromium 借助：

base::ThreadRestrictions 检查可能涉及线程限制的函数在当前执行的线程上是否允许：

阻塞 (blocking) 操作
- 主要包括文件 I/O 操作（有可能被系统缓存，从而不阻塞）
- 可能导致线程交出 CPU 执行机会，进入 wait 状态
同步原语 (sync primitive)
- 执行线程同步操作
- 可能导致程序死锁 (deadlock)/卡顿 (jank)
CPU 密集工作 (CPU intensive work)
- 超过 100ms CPU 时间的操作
- 可能导致程序卡顿 (jank)
单例 (singleton) 操作
- 对于非泄露型 base::Singleton，会在 base::AtExitManager 注册 “退出时销毁单例对象”
- 如果主线程先退出，在 base::AtExitManager 中销毁单例，导致仍在运行的 non-joinable 线程再访问单例时，出现野指针崩溃

实现的 核心思想 也很简单：

通过TLS记录当前线程的限制情况（每种限制用一个 TLS bool 存储）
对于可能涉及限制的函数，调用前先检查当前线程是否允许某个限制

在最新的Chromium/base 中，线程限制检查被进一步封装为:

base::ScopedBlockingCall，并应用于大量文件 I/O 相关函数中。

2.3.3 死锁检查

Chromium 通过 base::internal::CheckedLock检查死锁 (deadlock)。

实现的 核心思想 非常简单 —— 检查等待链是否成环：

维护一个全局的 <从每个 lock 到其 predecessor lock> 映射表（创建时添加，销毁时移除）
维护一个当前线程的 <已获取 lock> 列表（TLS 存储；获取时记录，释放时移除）
创建时，断言 predecessor 已创建（如果 predecessor 不存在，可能顺序错误）
获取时，断言 predecessor 是当前线程最近获取的 lock（若不是，可能顺序错误）

2.4 观察者模式检查

在之前写的令人抓狂的观察者模式中，介绍了如何通过：

Chromium/base 提供的base::ObserverList，检查观察者模式的一些潜在问题。

2.4.1 生命周期检查

由于观察者和被观察者的生命周期往往是解耦的，所以总会出现一些阴差阳错的问题：

观察者先销毁
- 问题：若 base::ObserverList 通知时不检查观察者是否有效，可能导致野指针崩溃
- 解决：观察者继承于 base::CheckedObserver

在通知前 base::ObserverList 检查观察者弱引用 base::WeakPtr 的有效性

被观察者先销毁
- 问题：若 base::ObserverList 销毁时不检查观察者列表是否为空，可能导致被观察者销毁后，观察者不能再移除（野指针崩溃）
- 解决：模板参数 check_empty 若为 true，在析构时断言 “观察者已被全部移除”

2.4.2 通知迭代检查

观察者可能在 base::ObserverList 通知时，再访问同一个 base::ObserverList 对象：

添加观察者
- 问题：是否需要在本次迭代中，继续通知新加入的观察者
- 解决：被观察者参数 base::ObserverListPolicy
决定迭代过程中，是否通知新加入的观察者
移除观察者
- 问题：循环内（间接）删除节点，导致迭代器失效（崩溃）for(auto it = c.begin(); it != c.end(); ++it) c.erase(it);
- 解决：观察者节点 MarkForRemoval() 标记为 “待移除”，然后等迭代结束后移除
通知迭代重入
- 问题：许多情况下，若不考虑重入情况，可能会导致死循环问题
- 解决：模板参数 allow_reentrancy 若为 false，在迭代时断言 “正在通知迭代时不允许重入”
销毁被观察者
- 问题：需要立即停止迭代过程，让所有迭代器全部失效
- 解决：通过特殊的 base::internal::WeakLinkNode +

双向链表 base::LinkedList 存储 base::ObserverList 所有的迭代器；在 base::ObserverList 析构时，将迭代器标记为无效（自动停止迭代），并移除、销毁

线程安全问题
- 问题：由于 base::ObserverList 不是线程安全的，在通知迭代时，需要保证其他操作在同一线程/序列
- 解决：被观察者成员 iteration_sequence_checker_

在迭代开始时关联序列，在结束时解除关联，在迭代过程中检查移除观察者/通知重入/销毁被观察者操作是否序列安全（参考 [sec|线程安全检查]）

和 base::Singleton 一样，Chromium/base 的设计模式实现堪称 C++ 里的典范 —— 无论是功能上，还是性能上，均为 “人无我有，人有我优”。

写在最后

站在巨人的肩膀上。—— 艾萨克·牛顿

Chromium/base 库一直在 迭代、优化，学习、借鉴 许多其他优秀的开源项目。例如，[sec|线程标记检查] 使用的标记就来源于 abseil。

由于 Chromium/base 改动频繁，本文某些细节可能会过期。如果有什么新发现，欢迎补充~ 😉

漫谈 C++ 的各种检查

背景阅读