状态机基础：有限状态机（FSM）的定义、组成要素与状态图表示

在嵌入式系统、通信协议、用户界面逻辑以及复杂业务编排中，我们经常需要让系统在多个“稳定状态”之间切换，并对外部事件做出确定性响应。有限状态机（Finite State Machine, FSM）正是描述这种行为的经典数学模型。它之所以被称为“有限”，是因为其状态集合是有限且可枚举的；而“状态机”则强调系统行为由当前状态和输入事件共同决定。理解FSM不仅是编写健壮代码的前提，更是后续学习层次状态机（HSM）、状态模式（State Pattern）以及形式化验证的基础。本章将深入剖析FSM的定义、四大组成要素，并重点讲解状态图的规范画法，帮助读者建立从抽象模型到工程实现的完整认知。

上图展示了FSM的核心概念：系统在有限个状态（S1、S2、S3）之间，依据事件（A/B/C/D）触发转移，并在转移过程中执行相应动作。这张图是后续所有讨论的视觉锚点，下面我们将逐一拆解其数学定义与工程含义。

2.1 有限状态机的形式化定义

从数学角度看，一个确定型有限状态机（DFA）可以用五元组 M = (S, Σ, δ, s₀, F) 来描述。其中：S 是有限状态集合，Σ 是有限输入事件字母表，δ: S × Σ → S 是状态转移函数，s₀ ∈ S 是初始状态，F ⊆ S 是接受状态（或终止状态）集合。在嵌入式或软件工程中，我们通常还会引入“动作”的概念，将FSM扩展为米利型（Mealy）或摩尔型（Moore）状态机。米利型的输出依赖于当前状态和输入事件，而摩尔型的输出仅依赖于当前状态。理解这一区别对代码实现至关重要——摩尔型通常更容易测试，因为输出与输入时序解耦。

2.2 四大组成要素深度拆解

FSM的四个基本要素是状态（State）、事件（Event）、转移（Transition）和动作（Action）。它们之间的关系可以类比为“状态是房间，事件是门铃，转移是走廊，动作是开门时顺手开灯”。下面逐一展开。

要素	定义	工程示例（以TCP连接为例）	常见错误
状态	系统在某一时刻的稳定存在形式，由内部变量或外部可见行为定义	LISTEN（监听）、SYN_SENT（已发送同步）、ESTABLISHED（已建立）	状态粒度过粗或过细，导致状态爆炸或无法区分关键行为
事件	触发状态转移的外部输入或内部信号，是转移的必要条件	收到SYN包、收到ACK包、超时计时器到期	事件定义不完整，遗漏边界事件（如超时、异常）
转移	从当前状态到下一状态的定向关系，通常表示为“状态A --事件--> 状态B”	LISTEN --收到SYN--> SYN_RCVD	转移条件不唯一，同一事件在不同状态下产生歧义
动作	转移发生时执行的具体操作，可以是进入动作、退出动作或转移动作	发送SYN+ACK包、启动重传计时器、记录日志	在动作中执行耗时操作（如IO阻塞），阻塞状态机主循环

2.2.1 状态：系统的“记忆”

状态是FSM的核心，它代表了系统在特定时刻的“记忆”。设计状态时，应遵循“高内聚、低耦合”原则：每个状态应具有明确的语义边界，且状态之间应尽量互斥。例如，在电梯控制系统中，“上行”和“下行”是两个状态，而“门开”和“门关”是另外两个状态，它们可以组合成四个复合状态。但若将“上行且门开”作为一个独立状态，则会导致状态数量呈指数级增长。工程上常用状态枚举或状态编码（如格雷码）来减少状态切换时的毛刺。

2.2.2 事件：外部刺激的“触发器”

事件是FSM的输入，它可以是硬件中断、消息队列中的报文、定时器超时或用户操作。事件通常分为同步事件（在状态机处理循环内同步产生）和异步事件（由中断或独立线程产生）。设计事件时，必须考虑事件的优先级和丢失问题。例如，在通信协议栈中，收到数据帧和收到断开连接请求可能同时发生，此时需要定义事件优先级或使用事件队列缓存。一个经典误区是：在状态机内部直接调用阻塞式API等待事件，这会导致状态机无法响应其他事件。

2.2.3 转移：状态间的“路径”

转移定义了状态间的合法路径。一个完整的转移包含三个要素：源状态、触发事件、目标状态。转移可以是外部转移（离开源状态再进入目标状态）或内部转移（不离开源状态，仅执行动作）。在UML状态图中，内部转移用“事件/动作”标注在状态内部，而外部转移用箭头表示。设计转移时，要特别注意转移的完备性——即每个状态对每个可能事件都必须有明确的响应（要么转移到新状态，要么忽略并停留在原状态）。忽略事件也是一种合法的转移，但必须显式声明，否则容易产生未定义行为。

2.2.4 动作：转移的“副作用”

动作是状态机对外部世界的影响，包括变量赋值、硬件操作、消息发送等。动作可以发生在三个时机：进入状态时（entry action）、退出状态时（exit action）和转移过程中（transition action）。摩尔型状态机通常将动作绑定在进入状态时执行，而米利型状态机将动作绑定在转移过程中。工程建议：动作应尽量短小且无阻塞，如果必须执行耗时操作（如写Flash），应将其放入异步任务队列，避免阻塞状态机主循环。此外，动作的原子性也很重要——如果动作执行到一半发生异常，状态机应能回滚到一致状态。

2.3 状态图表示方法：从UML到工程实践

状态图（State Diagram）是FSM的可视化表示，UML定义了标准的图形符号。一个规范的状态图包含：圆角矩形表示状态，实心圆表示初始状态，牛眼符号（同心圆）表示终止状态，带箭头的连线表示转移，连线上标注“事件[守卫条件]/动作”。守卫条件（Guard Condition）是转移的附加布尔条件，只有事件发生且守卫条件为真时，转移才生效。例如，在自动售货机中，“投币”事件发生后，若“金额≥2元”守卫条件满足，则转移到“可购买”状态。

// 状态图对应的伪代码示例（自动售货机）
enum State { IDLE, COIN_INSERTED, DISPENSING };
State currentState = IDLE;

void handleEvent(Event e) {
    switch (currentState) {
        case IDLE:
            if (e == COIN) {
                currentState = COIN_INSERTED;
                action_showBalance();
            }
            break;
        case COIN_INSERTED:
            if (e == COIN) {
                action_addBalance();
            } else if (e == SELECT_ITEM && balance >= 2) {
                currentState = DISPENSING;
                action_dispenseItem();
            }
            break;
        case DISPENSING:
            if (e == DISPENSE_DONE) {
                currentState = IDLE;
                action_resetBalance();
            }
            break;
    }
}

在绘制状态图时，应遵循以下规范：第一，每个状态必须有唯一的名称，避免使用模糊词汇如“处理中”；第二，转移箭头必须标注触发事件，若存在多个事件，用逗号分隔；第三，守卫条件用方括号括起来，放在事件之后；第四，动作用斜杠“/”分隔，放在事件和守卫条件之后。对于复杂系统，建议将状态图分层绘制——先画高层状态图，再细化每个状态的子状态图。

2.4 案例拆解：TCP连接建立的状态机实现

为了将上述理论落地，我们以TCP三次握手协议为例，完整拆解一个FSM的设计与实现过程。TCP连接建立涉及三个核心状态：LISTEN（服务器等待连接）、SYN_SENT（客户端已发送SYN）、ESTABLISHED（连接已建立）。事件包括：收到SYN、收到ACK、超时、应用层主动连接。

背景与约束：假设我们正在为一个轻量级嵌入式TCP/IP协议栈编写状态机模块。硬件资源有限（RAM仅32KB），不能使用动态内存分配；要求状态机主循环响应时间不超过1ms；需要支持同时管理多个连接（最多16个）。

初始现象与目标：初版代码使用多个布尔变量（synReceived、ackReceived）和散落的if-else逻辑，导致状态判断混乱。例如，当同时收到SYN和ACK时，代码无法确定当前处于哪个阶段。目标是用标准FSM重构，使状态转移清晰可测。

关键输入参数：每个连接控制块（TCB）包含：state（枚举类型）、timer（重传计时器）、seqNum（序列号）。事件由网络驱动层通过函数指针回调注入。

分析判断过程：我们首先绘制状态图，识别出三个状态和五个关键事件。然后定义转移表：

当前状态	事件	守卫条件	下一状态	动作
LISTEN	收到SYN	无	SYN_RCVD	发送SYN+ACK，启动计时器
SYN_SENT	收到SYN+ACK	ACK序号正确	ESTABLISHED	发送ACK，停止计时器
SYN_SENT	超时	重传次数<3	SYN_SENT	重发SYN，重置计时器
SYN_RCVD	收到ACK	ACK序号正确	ESTABLISHED	停止计时器
SYN_RCVD	超时	重传次数≥3	CLOSED	释放连接，通知应用层

实际操作步骤：第一步，定义状态枚举和事件枚举；第二步，实现转移表驱动的状态机核心函数 fsm_process_event(tcb, event)；第三步，将网络驱动层的中断处理改为仅向事件队列写入事件，由主循环统一调用状态机处理。重构后，代码行数从原来的200行减少到80行，且每个状态转移都有明确的日志输出。

结果对比：重构前，并发处理16个连接时，偶发出现状态错乱（概率约0.1%），排查困难；重构后，连续运行72小时压测，未出现状态错乱。内存占用从每连接48字节降至32字节（因为不再需要多个布尔标志）。

风险与代价：状态机重构引入了事件队列的额外内存开销（每个连接8字节），且要求所有事件必须通过队列注入，不能直接在中断上下文中调用状态机函数。这增加了中断延迟（从1μs增加到5μs），但仍在系统容忍范围内。

复盘经验：第一，状态图必须与代码同步维护，我们使用脚本从状态图生成转移表，避免手工维护不一致；第二，守卫条件应尽量简单，复杂的条件判断应封装为独立的谓词函数；第三，为每个状态定义进入动作和退出动作，便于调试时打印状态切换轨迹。

2.5 常见误区与设计复盘

在FSM设计实践中，以下误区最为常见，需要特别警惕：

• 状态遗漏或状态冗余：遗漏状态会导致系统在特定输入下行为未定义；冗余状态则增加维护成本。建议使用状态覆盖矩阵，确保每个状态-事件组合都有明确的转移。
• 事件处理不完整：只关注正常事件，忽略异常事件（如超时、数据校验失败）。在工程中，异常路径往往占代码量的60%以上。
• 动作与转移耦合过紧：在转移函数中直接执行耗时操作，导致状态机无法及时响应新事件。应使用“动作后置”策略，将耗时操作放入工作队列。
• 忽视状态机的可测试性：状态机应支持“状态注入”和“事件注入”，以便在单元测试中直接设置当前状态并触发事件，而不必通过外部接口模拟完整时序。