2015 年 9 月，AWS 的工程师在一篇广为流传的论文中写道：「TLA+ 帮助我们在 DynamoDB 的复制协议中发现了一处极端情况下的 bug——这个 bug 在任何正常测试中都不可能触发，但在足够大的规模下，它一定会发生。」五年后，这篇论文的作者 Chris Newcombe 在 re:Invent 上补充了一个细节：那个 bug 的触发条件需要 7 个事件以特定顺序交错，测试永远跑不出这个组合。

本文讨论的问题只有一个：怎样在代码落地之前，用数学方法证明一个系统设计没有逻辑错误。

一、测试的边界

先看一个简单的问题：一个全局计数器 counter，两个线程各自执行 100 次递增。最终 counter 的值是多少？

学过并发编程的人知道答案：不一定是 200。counter += 1 不是原子操作——它包含读、加、写三步。两个线程同时读到同一个值，各自加 1 后写回，结果相当于丢失了一次递增。

这是并发编程中最基础的竞态条件。常规对策是加锁、用原子指令、或者按并发模型重新设计。

但这里有一个更根本的问题：你怎么确认你的对策是正确的？

测试可以让你更自信，但无法穷举。两个线程各执行 100 步——不考虑更复杂的交错，仅指令级的交错组合就已经是天文数字。线程数更多、步骤稍复杂之后，状态空间急剧膨胀，任何基于采样的验证手段都碰不到边界。

这不是测试方法论的问题，也不是工程师不够认真。这是一个组合数学问题：

系统的状态空间随并发组件的数量呈指数增长——这叫状态空间爆炸（state space explosion）。

2014 年，MongoDB 3.0 引入了一套基于 Raft 的复制协议。核心设计经过了代码审查、单元测试、集成测试和长达数月的 QA。但上线后在特定网络分区场景下，协议出现了脑裂——两个节点同时认为自己是 Primary。事后复盘发现，触发条件需要 4 个事件按照一种极为罕见的顺序发生，在测试环境中从未出现过。

另一个更著名的案例是 Therac-25 放射治疗机（1985-1987）：软件中的竞态条件导致 6 名患者接受了超过百倍剂量的辐射，其中 3 人死亡。事后调查发现，触发条件依赖于操作员在特定时间窗口内按下特定按键组合——在测试期间从未被复现。

这些事故有一个共同特征：不是代码写错了，是设计本身存在逻辑漏洞。代码忠实地执行了设计，但设计没有覆盖所有可能的状态交错。

形式化验证要解决的就是这个问题。

二、形式化验证：用数学描述行为

2.1 定义

形式化验证（formal verification）是指用数学语言严格描述一个系统的行为规范（specification），然后通过数学证明或穷举搜索，验证系统的行为是否满足规范。

拆成两步理解：

1. 写规范（specification）：用精确的数学语言定义「什么行为是合法的」。
2. 做验证（verification）：检查系统的所有可能执行路径是否都满足这个规范。

这与测试有本质区别。测试只能检查有限个具体执行路径。形式化验证检查所有路径。

2.2 安全性与活性

形式化验证中，属性分为两类。这个分类来自 Leslie Lamport 在 1977 年的一篇论文。