C++中实现可重入且线程安全的FSM，核心是分离状态迁移逻辑与状态数据，用原子操作+RAII封装访问；异构状态优先用std::variant+std::visit而非继承，避免虚函数开销和内存不连续问题。
直接说结论：C++ 里实现可重入且线程安全的 FSM，核心不是加一把大锁，而是分离状态迁移逻辑与状态数据，并用原子操作 + RAII 封装状态访问；异构状态封装的关键在于避免虚函数表带来的缓存不友好和不可预测跳转，优先用 std::variant + std::visit，而非继承体系。
为什么 std::mutex 保护整个 handle_event() 会破坏可重入性
可重入（reentrant）要求同一对象的成员函数能被同一线程多次进入（比如状态处理中又触发新事件），而普通互斥锁会死锁。更隐蔽的问题是：若状态处理函数内部调用 handle_event()（常见于嵌套事件、自触发场景），std::mutex 无法递归锁定（除非用 std::recursive_mutex，但那只是掩盖设计缺陷）。
实操建议：
- 把状态值本身（如当前状态 ID 或
std::variant实例）声明为std::atomic可能的类型（如std::atomic<int></int>或配合std::atomic_flag手动 CAS），但注意std::variant不可直接原子化 —— 需用std::atomic_flag+ 双缓冲或 RCU 风格读写分离 - 真正推荐的做法：状态迁移逻辑（即“判断能否转移、转移到哪”）是纯函数、无副作用、无共享数据访问；实际状态更新只发生在无竞争的临界段，且该段极短（仅更新一个原子整数或交换指针）
- 避免在状态处理回调里做耗时操作（如 I/O、锁等待），否则会阻塞整个 FSM 线程，也违背可重入前提
用 std::variant 封装异构状态比 class 继承更合适
继承式 FSM（每个状态一个子类）看似自然，但在多线程下易出问题：虚函数调用需查 vtable，不同状态对象内存布局分散，CPU 缓存行利用率低；更严重的是，若状态对象生命周期由 FSM 管理（如 std::unique_ptr<State>），则每次状态切换都要 new/delete，引入堆分配和潜在锁争用（malloc 实现常带锁）。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 定义统一状态容器：
std::variant<IdleState, RunningState, PausedState>，所有状态数据为struct，不含虚函数、不含指针成员（或确保其线程安全） - 状态处理逻辑收拢到独立函数对象或
std::visit的 lambda 中，例如：std::visit([](auto& s) { s.on_entry(); }, current_state_); - 若某状态需持有资源（如文件描述符、socket），在对应
struct中用int或std::shared_ptr（注意引用计数原子性），不要用裸指针
如何让 handle_event() 同时满足可重入、线程安全、无锁（lock-free）倾向
完全 lock-free 的 FSM 在通用场景下得不偿失（CAS 失败重试可能饥饿），但可以做到「无阻塞」（non-blocking）：即不因锁导致线程挂起。关键在把共享变量最小化，并用原子操作隔离读/写路径。
实操建议：
- 用
std::atomic<int>存当前状态码（如 enum class StateID { Idle=0, Running=1, Paused=2 }），迁移前先load()，再用compare_exchange_weak()尝试更新 —— 失败说明其他线程已抢先改写，此时应重新评估事件是否仍有效 - 事件处理函数（如
on_input_ready()）不直接修改状态，只返回目标状态码和是否需要触发退出/进入动作，由顶层原子更新后统一派发 - 若需记录历史状态或调试信息，写入
thread_local缓冲区，而非全局日志对象，避免日志锁拖慢主路径
容易被忽略的边界：状态迁移中的异常安全与内存顺序
当状态切换涉及资源释放（如关闭 socket）和新资源获取（如绑定新端口），若中间抛异常，std::variant 的赋值可能处于半更新状态 —— 老状态析构了，新状态没构造完。
实操建议：
- 所有状态
struct的构造函数必须是noexcept，尤其避免在构造中做可能失败的系统调用；资源获取提前到迁移决策前，用 guard 对象管理（如std::unique_ptr<Resource>先创建好，再原子替换状态） - 原子操作必须指定内存序：
compare_exchange_weak()用std::memory_order_acq_rel，load()用std::memory_order_acquire，防止编译器/CPU 重排导致看到部分更新的状态 - 不要依赖
std::variant::index()判断状态 —— 它非原子；始终用原子变量存状态码，std::variant仅作数据载体，二者通过严格约定同步（如只在 CAS 成功后才更新std::variant）
