一文详解Go语言中的有限状态机FSM（有限状态机vhdl）新鲜出炉

随心笔谈1年前发布编辑

140 0

🌐 经济型：买域名、轻量云服务器、用途：游戏网站等《腾讯云》特点：特价机便宜适合初学者用点我优惠购买

🚀 拓展型：买域名、轻量云服务器、用途：游戏网站等《阿里云》特点：中档服务器便宜域名备案事多点我优惠购买

🛡️ 稳定型：买域名、轻量云服务器、用途：游戏网站等《西部数码》特点：比上两家略贵但是稳定性超好事也少点我优惠购买

目录1、FSM简介1.1 有限状态机的定义1.2 Go中的FSM2、github.com/looplab/fsm 如何使用2.1 fsm 基础使用2.2 fsm 中 Action 何时执行2.3 较为完整的例子

有限状态机（Finite State Machine，FSM）是一种数学模型，用于描述系统在不同状态下的行为和转移条件。

状态机有三个组成部分：，事件（转移条件）触发状态的转移和动作的执行。动作的执行不是必须的，可以只转移状态，不指定任何动作。总体而言，状态机是一种用以表示有限个状态以及这些状态之间的转移和动作的执行等行为的数学模型。

状态机可以用公式表示，即在处于状态S的情况下，接收到了事件E，使得状态转移到了S’，同时伴随着动作A的执行。

是指触发状态转换的输入信号或条件。它可以是任何类型的输入，例如传感器数据、用户输入、网络消息等。在编程中，Event通常是一个枚举类型，每个枚举值代表一个特定的事件。

是指系统在某一时刻所处的状态，它是系统的一种抽象描述。在有限状态机中，状态是由一组状态变量来描述的，这些状态变量的取值决定了系统的状态。状态可以是离散的，也可以是连续的。在有限状态机中，状态通常用一个圆圈来表示，圆圈内部写上状态的名称。例如，一个简单的有限状态机可以有两个状态：开和关，它们可以用以下方式表示：

是指在状态转移时执行的操作或动作。当有限状态机从一个状态转移到另一个状态时，可以执行一个或多个action来改变系统的状态或执行某些操作。例如，当有限状态机从“待机”状态转移到“运行”状态时，可以执行一个action来启动系统。在实际应用中，action可以是任何有效的代码，例如函数调用、变量赋值、打印输出等。

FSM 通常用于编程中，用于实现状态转移和控制流程。

注意：

在任何时刻，FSM 只能处于一种状态。

通过上面关于有限状态机的定义，我们大概知道了状态机是个什么东西，那么Golang中是怎么实现的呢。不用慌，已经有大佬实现好了，只管用就好了。

安装：

go get github.com/looplab/fsm@v1.0.1

接下来一起看看是如何使用的。

注意：

不同版本的 fsm 使用方式，可能不太一样，最好是看下函数的注释，看下具体的细节。本篇文章以：为例。

这里把官方的例子改了下，感觉官方的例子不是很清晰。代码如下：

package main

import (
“context”
“fmt”

“github.com/looplab/fsm”
)

type Door struct {
Name string
FSM *fsm.FSM
}

func NewDoor(name string) *Door {
d :=&Door{
Name: name,
}

d.FSM=fsm.NewFSM(
“closed”,
fsm.Events{
{Name: “open”, Src: []string

执行结果：

fsm current state: closed

The door’s name:测试 , current state:open

fsm current state: open

The door’s name:测试 , current state:closed

fsm current state: closed

这里就通过改变FSM中的状态。转移公式为：。大意就是接受到了输入，状态机的由，并且执行了：d.enterState。

刚开始使用的时候，好奇是什么时候调用的，我们一起看看中的注释就清楚了。

// NewFSM constructs a FSM from events and callbacks.
//
// The events and transitions are specified as a slice of Event structs
// specified as Events. Each Event is mapped to one or more internal
// transitions from Event.Src to Event.Dst.
// Callbacks are added as a map specified as Callbacks where the key is parsed
// as the callback event as follows, and called in the same order:
//
// 1. before_<EVENT> – called before event named <EVENT>
//
// 2. before_event – called before all events
//
// 3. leave_<OLD_STATE> – called before leaving <OLD_STATE>
//
// 4. leave_state – called before leaving all states
//
// 5. enter_<NEW_STATE> – called after entering <NEW_STATE>
//
// 6. enter_state – called after entering all states
//
// 7. after_<EVENT> – called after event named <EVENT>
//
// 8. after_event – called after all events
//
// There are also two short form versions for the most commonly used callbacks.
// They are simply the name of the event or state:
//
// 1. <NEW_STATE> – called after entering <NEW_STATE>
//
// 2. <EVENT> – called after event named <EVENT>
//
// If both a shorthand version and a full version is specified it is undefined
// which version of the callback will end up in the internal map. This is due
// to the pseudo random nature of Go maps. No checking for multiple keys is
// currently performed.

从上面我们知道了，是在时执行的。

2.2.1 完整版书写的Callbacks执行顺序

从上面的注释能知道完整版书写的的执行顺序如下:

2.2.2 简写版的Callbacks执行顺序