腾讯技术工程 · 2020年02月14日

漫谈 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 库中使用的一些限制检查。

漫谈 C++ 的各种检查

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) 的概念 —— 相对于线程池中的普通任务乱序调度,同一序列的任务 能保证被顺序调度 —— 因此,推荐使用逻辑序列而不是物理线程

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

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

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

序列本地存储 (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::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::LinkedList 存储 base::ObserverList 所有的迭代器;在 base::ObserverList 析构时,将迭代器 标记为无效(自动停止迭代),并 移除、销毁

  • 线程安全问题

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

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

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

写在最后

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

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

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



推荐阅读:


更多腾讯AI相关技术干货,请关注专栏腾讯技术工程
推荐阅读
关注数
8122
内容数
209
腾讯AI,物联网等相关技术干货,欢迎关注
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息