Erlang OTP: Distributed & Fault-Tolerant Systems Programming · 课时

使用 GenStatem 管理状态

掌握 GenStatem，构建健壮的有限状态机，管理复杂的状态转换并有效处理事件。

使用 GenStatem 管理状态 是 CoddyKit 上的免费 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课时。这是第 1 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Meet GenStatem

Welcome to GenStatem! It's an OTP behavior in Erlang used to build Finite State Machines (FSMs). If your system component needs to behave differently based on its current state, GenStatem is your friend.

Think of it as a specialized tool for managing complex state logic, offering more explicit control over state transitions than a regular GenServer.

FSM Fundamentals

A Finite State Machine (FSM) is a mathematical model of computation that describes the behavior of a system. It can only be in one state at any given time.

States: Distinct conditions a system can be in (e.g., "on", "off", "idle", "active").
Events: Inputs or occurrences that trigger a change in state (e.g., "button_press", "timeout").
Transitions: Rules that define how an event in a particular state causes a shift to a new state.

GenStatem Module Basics

Like other OTP behaviors, GenStatem requires a callback module. This module implements specific functions that define the FSM's behavior.

The most basic function is init/1, which sets up the initial state and data for your FSM. It returns {:ok, InitialState, InitialStateData}.

-module(my_fsm).
-behaviour(gen_statem).

-export([start_link/0]).
-export([init/1]).
-export([callback_mode/0]).

% Minimal init for a GenStatem
init(_Args) ->
    io:format("FSM initializing...~n"),
    InitialState = off, % Our first state
    InitialStateData = [], % Any data we want to carry
    {:ok, InitialState, InitialStateData}.

% Defines how events are handled (state-name based)
callback_mode() ->
    state_functions.

start_link() ->
    gen_statem:start_link({local, ?MODULE}, ?MODULE, [], []).

States and StateData

In GenStatem, a state is typically an atom (e.g., :on, :off). StateData is any Erlang term that holds the internal information associated with the current state, similar to a GenServer's state.

When you transition, you specify both the new state atom and the new state data. This allows you to carry context and information across different states of your FSM.

Responding to Events

GenStatem uses callback functions to react to events. For asynchronous events (like gen_statem:cast/2), the handle_event/4 callback is used.

The function signature is State(EventType, EventContent, StateData), where State is the current state atom and EventType indicates the type of message (e.g., :cast, :info).

% Example for 'off' state
off(cast, toggle, StateData) ->
    io:format("Switching to ON from OFF~n"),
    {:next_state, on, StateData}; % Transition to 'on' state

off(info, _Msg, StateData) ->
    io:format("Received info in OFF state~n"),
    {:next_state, off, StateData}.

Changing States

The return value of your event-handling functions dictates the FSM's next action. To change state, you return a tuple: {:next_state, NewState, NewStateData}.

NewState: The atom representing the next state.
NewStateData: The updated state data to be carried into the new state.

If you want to stay in the current state, you can return {:keep_state, NewStateData} or {:keep_state_and_data} if data doesn't change.

Sync vs. Async Events

GenStatem handles different types of events:

handle_call/4: For synchronous calls (gen_statem:call/3). The caller waits for a reply.
handle_event/4: For asynchronous casts (gen_statem:cast/2) and internal messages (gen_statem:info/2, or process messages). The caller does not wait.
handle_info/4: A specialized version of handle_event for process messages not originating from gen_statem:cast or gen_statem:call. Often less used with state_functions mode.

We'll focus on handle_call and handle_event in our example.

Light Switch Example

Let's build a classic FSM: a light switch! It will have two states: off and on.

We'll send a toggle event to change its state. We'll also add a way to check its current status.

Light Switch Code

Here's the full Erlang module for our light switch. Run it and try interacting with it!

-module(light_switch).
-behaviour(gen_statem).

-export([start_link/0, toggle/0, status/0]).
-export([init/1, callback_mode/0]).
-export([off/4, on/4]). % Export state functions

% -- Public API --
start_link() ->
    gen_statem:start_link({local, ?MODULE}, ?MODULE, [], []).

toggle() ->
    gen_statem:cast(?MODULE, toggle).

status() ->
    gen_statem:call(?MODULE, status).

% -- GenStatem Callbacks --
init(_Args) ->
    io:format("Light switch initializing to OFF~n"),
    {:ok, off, []}. % Initial state 'off', no specific data

callback_mode() ->
    state_functions.

% -- State 'off' callbacks --
off(cast, toggle, StateData) ->
    io:format("Switching from OFF to ON~n"),
    {:next_state, on, StateData};
off(call, status, From, StateData) ->
    gen_statem:reply(From, off),
    {:keep_state, StateData};
off(EventType, EventContent, StateData) ->
    io:format("OFF state received unhandled event: ~p, ~p~n", [EventType, EventContent]),
    {:keep_state, StateData}.

% -- State 'on' callbacks --
on(cast, toggle, StateData) ->
    io:format("Switching from ON to OFF~n"),
    {:next_state, off, StateData};
on(call, status, From, StateData) ->
    gen_statem:reply(From, on),
    {:keep_state, StateData};
on(EventType, EventContent, StateData) ->
    io:format("ON state received unhandled event: ~p, ~p~n", [EventType, EventContent]),
    {:keep_state, StateData}.

% --- How to run this code in Erlang shell: ---
% c(light_switch).
% light_switch:start_link().
% light_switch:status(). % Should be 'off'
% light_switch:toggle().
% light_switch:status(). % Should be 'on'
% light_switch:toggle().
% light_switch:status(). % Should be 'off'

GenStatem Challenge

Consider a GenStatem module representing a door with states :closed and :open. It receives :open_door and :close_door events.

If the door is :closed and receives :open_door, it transitions to :open. If it's :open and receives :close_door, it transitions to :closed.

What is the correct return value from the closed/4 state function when it receives an :open_door event via gen_statem:cast/2?

GenStatem Summary

Great job mastering GenStatem!

You've learned that GenStatem is ideal for implementing Finite State Machines, allowing you to manage complex state-dependent logic. Key takeaways:

FSMs have states, events, and transitions.
GenStatem uses callback modules and state functions (e.g., off/4, on/4).
You transition between states using {:next_state, NewState, NewStateData}.
Events can be asynchronous (cast, handled by handle_event/4) or synchronous (call, handled by handle_call/4).

This powerful behavior is a cornerstone for building robust, predictable systems in Erlang.

常见问题解答

「使用 GenStatem 管理状态」课时是免费的吗？

是的 — 「使用 GenStatem 管理状态」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程的其余内容，请升级到 CoddyKit PRO。 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程共包含 4 节课。

「使用 GenStatem 管理状态」这节课中我会学到什么？

掌握 GenStatem，构建健壮的有限状态机，管理复杂的状态转换并有效处理事件。你通过在浏览器中直接运行的动手代码来练习 Erlang OTP: Distributed & Fault-Tolerant Systems Programming，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 1 节课，共 4 节。

「使用 GenStatem 管理状态」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课中编写并运行代码吗？

能。每节 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Erlang OTP: Distributed & Fault-Tolerant Systems Programming