前言
前段时间,我们处理了一则Java线程池配置不当导致的线上问题(参见 好端端的线程池,怎么就卡死了?),本文将以此为案例,使用形式化语言,从数学角度进行证明。
形式化证明简介
首先需要搞清楚一个概念,形式化证明,也是通过编程的形式进行的,只不过这段代码使用形式化编程语言进行表达,从数理层面来看更为严谨,常见的形式化语言有:
- Coq:广泛用于学术研究和软件形式化验证,历史悠久。
- Lean4:最近在数学界引起了广泛关注,适合开发严格的数学证明。
- Dafny:与C#和Java有相似的语法,适合编程语言内置规范。
- ACSL:基于C语言的注释,适合进行语法和语义检查。
- TLA+:用于建模算法和程序的形式语言,特别适合并发和分布式系统。
某些领域也有特定的工具,比如 Java Pathfinder (JPF) 用于Java程序的形式化验证,支持线程和并发的验证。
鉴于Lean4使用最为广泛,本次首先使用Lean4进行尝试。
Lean4 的安装
Lean4 可以在 vscode 中安装使用,也需要安装 Mathlib 数学库(类似于我们常用的三方依赖库)。本节将介绍其安装和使用方法。
Lean4 也有网页版 https://live.lean-lang.org/,但实测网站响应速度较差,推荐本地安装使用。
- 安装 vscode,我们使用这个 IDE 创建和运行 Lean 工程。
- 安装 Lean4 插件:打开 vscode 中的插件市场,搜索 Lean4,点击安装。
- 安装 elan:它是Lean4版本管理工具,类似于node里面的nvm。到官方网站 https://github.com/leanprover/elan?tab=readme-ov-file#elan-lean-version-manager 参考即可:
- 配置 mathlib:创建项目时使用 lean 的项目构建工具,指定 mathlib4,会自动安装 mathlib 依赖包:
- lake +leanprover-community/mathlib4:lean-toolchain new <your_project_name> math
复制代码 到这里,就可以开始编写 Lean 代码了(vscode会启动lean4服务器,允许即可)。
常用功能:
形式化证明
前面我们遇到的问题是:当任务数量大于线程池的核心线程数量后,由于任务间的依赖关系导致线程无法释放,最终导致新提交的任务被放到无界阻塞队列中,无法得到处理,最终系统处于假死状态。
为验证线程池资源是否存在资源耗尽的漏洞,可以参考如下Prompt(比较粗糙,作为示例已经够用了),让AI编写一段 Lean4 形式化代码:- 你是形式化证明专家,也是各种语言编程专家,尤其精通Java和Lean4。
- 我想用一段Lean4脚本验证:
- 配置场景:定义了一个线程池,其核心线程数为5、配置了无界阻塞队列、最大线程数为 Integer.MAX_VALUE(约21亿)
- 验证场景:当任务数量大于线程池的数量时,任务就会卡死,因为后续的节点已经没有线程可用了,对应的任务始终无法完成,因此已经被占用的线程无法释放(因为属于同一个任务)。此后继续提交的新任务会被放到无界阻塞队列中,表现出来就是系统处于假死状态。
- 请写一段Lean4程序。务必保持简洁。
复制代码为降低理解难度,做了一定程度的简化。
- import Mathlib.Data.Real.Basic
- structure ThreadPool where
- corePoolSize : ℕ
- maxPoolSize : ℕ
- unboundedQueue : Bool := true -- true 表示无界队列
- def isDeadlocked (pool : ThreadPool) (tasks : ℕ) : Prop :=
- pool.corePoolSize < tasks ∧
- pool.unboundedQueue ∧
- pool.maxPoolSize >= pool.corePoolSize
- theorem unbounded_queue_causes_deadlock :
- ∃ (pool : ThreadPool) (tasks : ℕ),
- pool.corePoolSize = 5 ∧
- pool.maxPoolSize = 2147483647 ∧
- pool.unboundedQueue = true ∧
- tasks > 5 ∧
- isDeadlocked pool tasks :=
- by
- let pool : ThreadPool := { corePoolSize := 5, maxPoolSize := 2147483647, unboundedQueue := true }
- use pool, 6
- simp [isDeadlocked]
- constructor <;> trivial
复制代码 解释一下:
1. import Mathlib.Data.Real.Basic:导入数学库(本例会使用实数定义,因此需要导入);
2. structure定义线程池结构:- structure ThreadPool where
- corePoolSize : ℕ
- maxPoolSize : ℕ
- unboundedQueue : Bool := true -- true 表示无界队列
复制代码 3. 定义死锁条件(符号∧表示 “与”):- def isDeadlocked (pool : ThreadPool) (tasks : ℕ) : Prop :=
- pool.corePoolSize < tasks ∧
- pool.unboundedQueue ∧
- pool.maxPoolSize > pool.corePoolSize
复制代码 4. 声明定理和证明
先了解一下声明定理的语法,属于三段式结构:theorem name : Prop := proof:
Prop 在我们的代码中对应:- ∃ (pool : ThreadPool) (tasks : ℕ),
- pool.corePoolSize = 5 ∧
- pool.maxPoolSize = 2147483647 ∧
- pool.unboundedQueue = true ∧
- tasks > 5 ∧
- isDeadlocked pool tasks
复制代码 其中的符号∃表示存在性命题,翻译成人话就是:- 存在一个线程池 pool 和任务数 tasks,满足以下所有条件时,会导致死锁(isDeadlocked):
- 1. 核心线程数 = 5
- 2. 最大线程数 = Integer.MAX_VALUE
- 3. 使用无界队列
- 4. 任务数 > 5
复制代码 然后构造具体例子,证明命题成立。对应的代码:- let pool : ThreadPool := { corePoolSize := 5, maxPoolSize := 2147483647, unboundedQueue := true }
- use pool, 6
复制代码 其中,let 定义具体线程池实例参数,use pool, 6提供例子(核心线程5时,提交6个任务),就可以准备证明了。
在随后的证明过程中,使用simp [isDeadlocked]把 isDeadlocked 的定义展开(类似于内联的概念),并自动把能计算出来的部分(比如 5 < 6)直接化简成 True,让证明变简单。
最后constructor trivial的意思是:把目标拆成多个小条件(constructor),然后逐个()用“自动验证”(trivial,表示显然会成立的命题)解决。在我们的场景中:
- 目标是 5 < 6 ∧ true ∧ 2147483647 > 5。
- constructor 将其拆成 3 个子目标:5 < 6、true、2147483647 > 5。
- trivial 自动验证这些显然成立的子目标。
最终可以看到,我们定义的定理 unbounded_queue_causes_deadlock ,被成功地证明了:
Lean4 与 Rust
大家可能已经发现,Lean4 与 Rust 这两种编程语言的语法非常相似,其实不仅如此,他们的工具链也很相似:比如 Lean 的版本管理工具elan,类似于 Rust 的 rustup; Lean 的包管理器和构建工具lake ,类似于 Rust 的 cargo)。熟悉 Rust 的同学狂喜,哈哈。
后记
2025年,随着大模型能力的提升,多家模型引入了形式化证明,用来验证大模型解决数学问题的能力,比较常见的训练方法是提供一段形式化代码,并挖去某些内容(或本身就存在待证明的部分),让大模型进行补充,然后验证它补充的内容是否能使得形式化证明通过(参见 DeepSeek又在节前放大招!以及 DeepSeek-Prover-V2:让 AI 学会严谨证明)。这与我们的场景略有差异(我们是直接用大模型生成形式化验证代码,并且想办法用在工程领域)。
在当下的 AI 浪潮中,我们可以借助大模型的能力,在实践过程中不断学习 Lean4 语法,不断构建工程领域的各种“定理”库,并进行开放复用。随着这个库的不断丰富,我们对业务领域的抽象和构建能力也会有所提升。
需要说明的是,本文中的例子非常简单,大家可以作为入门材料参考。在实际的应用中,若要验证某个领域的执行逻辑是否符合预期(如状态机中的状态变化),需要精确理解领域含义和各种动作条件,才能做出明确的抽象,这个过程是比较费力的。不过恰恰在这个过程中,我们能够有机会从具体的业务实现中抽离出来,更为严谨地描述系统行为(从这个角度看,形式化证明与单元测试、集成测试等概念有相似之处)。
另外,单纯靠 AI 写形式化代码会很痛苦,因为很难确认写出来的形式化代码是否正确,导致需要反复修改。因此,有必要熟悉特定形式化语言的语法和编写规范,就好比使用 AI 生成业务代码,需要具备一定的 Java/GoLang 等语言功底。
说了这么多,好像还没提到形式化语言在工程领域的特定落地场景(因为还没完全想清楚)。先别急,我会继续探索 TLA+、Dafny、Coq 等形式化编程语言,看看哪种更适合软件领域的工程化落地,边实践边想。
若有探索形式化方法应用落地的同学,欢迎交流。
学习资源
一些 Lean4 学习资源,包括一些博客文章,以及官方的参考手册。
- 写给一般CS人的 Lean4 安利
- The Lean Language Reference
- Functional Programming in Lean
- Lean 4 定理证明
- Learning Lean 4
- mathlib4_docs
来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作! |