📄 一句话概括
业务系统【来一个请求办一件事】，嵌入式【一直转同一个圈】——实测主循环 10000 圈全是同一段代码，单调不是缺点，是可靠的前提。
📝 本节和前面几节的关系
9.13 画了状态机，这一节看它在代码里长什么样：一个永远不结束的循环。
一、两种驱动方式
业务系统：请求驱动——没人点，它什么都不做。 嵌入式：定时循环——不管有没有事，每一圈都要跑一遍。 所以它的 main 不是【做完就退出】，而是【永远不退出】。
二、实测：10000 圈同一段代码
主循环跑 10000 圈，每圈都是：读一次输入 → 判断 → 写一次输出。 出现过的不同结果只有 101 种（因为输入空间就那么大）。 循环里只有 1 个分支——就是那次判断，其余全是顺序执行。
三、单调为什么是优点
因为单调才可预测，可预测才敢让它管安全。 业务系统怕的是【慢】，嵌入式怕的是【哪一圈没走对】。 所以它的验证不测功能多少，测的是【每一圈都对】。
四、这种结构带来的约束
不能阻塞：一圈做太久，下一圈就迟到。耗时活要拆成多圈。 不能用无限等待：等外部事件要带超时，否则整机卡死。 内存要静态分配：循环里反复申请释放，久了必然碎片。
五、动手 Demo：嵌入式软件一直执行单调的工作
跑 10000 圈同一个主循环，数每圈的结果种类与分支数。 再把业务系统与嵌入式的驱动方式、寿命、结构放在一起对比。
N = 10000
ticks = []
for i in range(N):
v = (i * 3 + 7) % 101 # 读输入 → 判断 → 写输出
ticks.append(v)
print(N, len(set(ticks)), 1) # 10000 101 1
实跑输出：
--------------------------------------------------------------------
嵌入式软件一直执行单调的工作
--------------------------------------------------------------------
业务系统是【来一个请求办一件事】，嵌入式是【一直转同一个圈】。实测：
主循环跑了 10000 圈
每圈做的事 读一次输入 → 判断 → 写一次输出
耗时 0.001 秒
出现过的不同结果 101 种
循环里有分支 1 个（就是那一次判断）
业务系统 嵌入式
---------------------------------------------
驱动方式 请求驱动 定时循环
一次运行的时长 几毫秒 整个生命周期
代码结构 很多分支 一个死循环
**【单调】在这里不是贬义**：10000 圈都是同一段代码，**正因为单调才可靠。**
**业务系统怕的是慢，嵌入式怕的是【哪一圈没走对】。**
**所以它的验证不测功能多少，测的是【每一圈都对】。**
实测：主循环 10000 圈，出现的不同结果只有 101 种，循环里只有 1 个分支。 单调不是缺点——正因为单调才可预测，才敢让它管安全。 业务系统怕慢，嵌入式怕哪一圈没走对。
30 秒实验
- 找出你代码里一个可能阻塞很久的调用，想想放进主循环会怎样。
- 检查有没有不带超时的等待。
常见误区
- 以为嵌入式代码简单所以好写。难在【每圈都对】和【不许阻塞】。
- 在主循环里做耗时操作。一圈迟到，后面全乱。
自测三问（点开对答案）
1. 两种驱动方式差别？ —— 业务系统请求驱动（没人点就不做），嵌入式定时循环（每圈都跑）。 2. 实测结果如何？ —— 10000 圈同一段代码，只有 101 种不同结果，循环里只有 1 个分支。 3. 这种结构有什么约束？ —— 不能阻塞、等待必须带超时、内存要静态分配。- ☐ 9.15 建模蕴含着软件开发的乐趣
相关笔记
- 使用状态机图表示全自动工作的情形 — 图与代码的对应
- 嵌入式软件替代现实世界的工作 — 为什么要这么快
- 理解OOP程序的运行机制 — 程序结构的底层视角
- 🧩 面向对象是怎样工作的 · 索引