Java中状态机模式的两种实现方式详解

一、什么是状态机

先说说状态机这个概念。它本质上是一个数学模型，用来描述一个对象在其生命周期里，会经历哪些状态，以及在什么条件下从一个状态跳到另一个状态。说白了，就是给对象画一张“状态流转地图”。

理解状态机，抓住三个核心要素就够了：

• 状态（State）：对象当前处于什么情形。比如订单是“待支付”还是“已发货”。
• 事件（Event）：触发状态变化的动作或条件。比如用户点击了“支付”按钮。
• 转换（Transition）：从一个状态到另一个状态的过程。比如“待支付”遇到“支付”事件，就变成“已支付”。

用一句话概括：在某个状态下，发生了某个事件，对象转换到了另一个状态。就这么简单。

二、状态机的两种实现方式

1. 显式状态机

显式状态机，就是通过独立的状态机框架或代码结构来管理状态转换。所有状态流转规则都集中定义、显式声明，一目了然。

特点：

• 状态和转换规则集中配置
• 有明确的状态转换表或图
• 非法转换会被统一拦截
• 通常有框架支持（如 Spring StateMachine）

2. 隐式状态机

隐式状态机则相反——没有独立的状态机组件，状态值就存在数据库的一个字段里，流转逻辑分散在各个业务方法的 if/else 或 switch 中。你看代码的时候，得一个一个方法去翻，才知道哪些状态能转到哪些状态。

特点：

• 状态就是一个普通字段
• 转换逻辑散落在各处业务代码中
• 没有统一的规则校验
• 实现简单，但维护成本会随着业务增长而直线上升

三、隐式状态机的典型实现方式

这是大多数业务系统中最常见的做法。用一个订单状态的例子来说明：

数据库层面

CREATE TABLE orders (
    id INT PRIMARY KEY,
    status INT NOT NULL DEFAULT 0 COMMENT '0=待支付, 1=已支付, 2=已发货, 3=已完成, 4=已取消'
);

枚举定义

public enum OrderStatus {
    UNPAID(0, "待支付"),
    PAID(1, "已支付"),
    SHIPPED(2, "已发货"),
    COMPLETED(3, "已完成"),
    CANCELLED(4, "已取消");

    private Integer code;
    private String desc;
}

业务代码中的状态流转

public void payOrder(Integer orderId) {
    Order order = orderRepository.findById(orderId);
    // 隐式校验：只有待支付才能支付
    if (!OrderStatus.UNPAID.getCode().equals(order.getStatus())) {
        throw new BusinessException("当前状态不允许支付");
    }
    order.setStatus(OrderStatus.PAID.getCode());
    orderRepository.sa ve(order);
}

public void shipOrder(Integer orderId) {
    Order order = orderRepository.findById(orderId);
    // 隐式校验：只有已支付才能发货
    if (!OrderStatus.PAID.getCode().equals(order.getStatus())) {
        throw new BusinessException("当前状态不允许发货");
    }
    order.setStatus(OrderStatus.SHIPPED.getCode());
    orderRepository.sa ve(order);
}

public void cancelOrder(Integer orderId) {
    Order order = orderRepository.findById(orderId);
    // 隐式校验：已发货和已完成不能取消
    if (OrderStatus.SHIPPED.getCode().equals(order.getStatus())
        || OrderStatus.COMPLETED.getCode().equals(order.getStatus())) {
        throw new BusinessException("当前状态不允许取消");
    }
    order.setStatus(OrderStatus.CANCELLED.getCode());
    orderRepository.sa ve(order);
}

状态转换图：

UNPAID(0) ──[支付]──→ PAID(1) ──[发货]──→ SHIPPED(2) ──[确认收货]──→ COMPLETED(3)

│ │

└──[取消]──→ CANCELLED(4) ←──[取消]──┘

这就是隐式状态机——没有一个集中的地方定义“什么状态可以转到什么状态”，全靠每个业务方法里的 if 判断来保证。状态少的时候还能凑合，一旦状态多了，维护起来就头疼了。

四、显式状态机的实现方式

方式一：状态转换表

把所有合法的转换关系集中定义在一张表里，代码瞬间清晰：

public class OrderStateMachine {

    // 转换规则表：Map<当前状态, Map<事件, 目标状态>>
    private static final Map> TRANSITIONS = new HashMap<>();

    static {
        // 待支付状态下的合法转换
        Map unpaidTransitions = new HashMap<>();
        unpaidTransitions.put("PAY", 1);       // 支付 → 已支付
        unpaidTransitions.put("CANCEL", 4);    // 取消 → 已取消
        TRANSITIONS.put(0, unpaidTransitions);

        // 已支付状态下的合法转换
        Map paidTransitions = new HashMap<>();
        paidTransitions.put("SHIP", 2);        // 发货 → 已发货
        paidTransitions.put("CANCEL", 4);      // 取消 → 已取消
        TRANSITIONS.put(1, paidTransitions);

        // 已发货状态下的合法转换
        Map shippedTransitions = new HashMap<>();
        shippedTransitions.put("CONFIRM", 3);  // 确认 → 已完成
        TRANSITIONS.put(2, shippedTransitions);
    }

    /**
     * 执行状态转换.
     */
    public static Integer transition(Integer currentState, String event) {
        Map allowed = TRANSITIONS.get(currentState);
        if (allowed == null || !allowed.containsKey(event)) {
            throw new IllegalStateException(
                "非法状态转换: 状态=" + currentState + ", 事件=" + event);
        }
        return allowed.get(event);
    }
}

使用起来也很简单：

public void payOrder(Integer orderId) {
    Order order = orderRepository.findById(orderId);
    // 由状态机统一校验和转换
    Integer newStatus = OrderStateMachine.transition(order.getStatus(), "PAY");
    order.setStatus(newStatus);
    orderRepository.sa ve(order);
}

方式二：枚举 + 方法

还有一种更优雅的方式——把状态转换逻辑直接写在枚举里：

public enum OrderStatus {
    UNPAID(0) {
        @Override
        public OrderStatus onPay() { return PAID; }
        @Override
        public OrderStatus onCancel() { return CANCELLED; }
    },
    PAID(1) {
        @Override
        public OrderStatus onShip() { return SHIPPED; }
        @Override
        public OrderStatus onCancel() { return CANCELLED; }
    },
    SHIPPED(2) {
        @Override
        public OrderStatus onConfirm() { return COMPLETED; }
    },
    COMPLETED(3),
    CANCELLED(4);

    private Integer code;

    // 默认实现：抛异常表示不允许该操作
    public OrderStatus onPay() { throw new IllegalStateException("当前状态不允许支付"); }
    public OrderStatus onShip() { throw new IllegalStateException("当前状态不允许发货"); }
    public OrderStatus onConfirm() { throw new IllegalStateException("当前状态不允许确认"); }
    public OrderStatus onCancel() { throw new IllegalStateException("当前状态不允许取消"); }
}

这样每个状态自己就知道哪些操作是合法的，调用方不需要关心具体规则，直接调方法就行。

五、两种方式的对比

从这张表可以看出来，选择哪种方式取决于你的业务复杂度。如果只有两三个状态，用隐式完全够用；一旦状态超过五个，或者转换规则频繁变动，显式状态机才是长久之计。

六、状态机中的常见概念

守卫条件（Guard）

在实际业务中，状态转换往往不是“事件触发就转”这么简单，还需要额外的校验。比如，订单要发货，前提是库存充足。这种校验就叫守卫条件：

// 事件是"发货"，但还需要守卫条件：库存充足
public Integer transition(Integer currentState, String event, Order order) {
    if ("SHIP".equals(event) && order.getStock() <= 0) {
        throw new BusinessException("库存不足，无法发货");
    }
    return TRANSITIONS.get(currentState).get(event);
}

转换动作（Action）

状态转换时，通常还需要附带执行一些业务操作。比如订单取消时，要自动退款、发通知：

// 转换到"已取消"时，自动执行退款
public void cancelOrder(Order order) {
    Integer newStatus = OrderStateMachine.transition(order.getStatus(), "CANCEL");
    order.setStatus(newStatus);
    // 转换动作
    refundService.refund(order.getPaymentId());
    notificationService.notifyUser(order.getUserId(), "订单已取消");
}

入口动作 / 出口动作（Entry/Exit Action）

有些动作与触发事件无关，只要进入某个状态就固定执行。比如无论从哪个状态进入“已取消”，都要发通知并释放库存：

// 无论从哪里进入"已取消"状态，都发通知
private void onEnterCancelled(Order order) {
    notificationService.notifyUser(order.getUserId(), "订单已取消");
    inventoryService.releaseStock(order.getItems());
}

状态回退（Rollback）

有时候业务需要回退，比如物流拦截成功，需要从“已发货”回退到“已支付”。回退不只是改状态字段，还要撤销之前执行的动作：

// 从已发货回退到已支付（例如物流拦截成功）
public void rollbackShipment(Order order) {
    if (!OrderStatus.SHIPPED.getCode().equals(order.getStatus())) {
        throw new BusinessException("只有已发货状态才能回退");
    }
    order.setStatus(OrderStatus.PAID.getCode());
    // 撤销动作：取消物流单、恢复库存
    logisticsService.cancelShipment(order.getLogisticsNo());
    inventoryService.restoreStock(order.getItems());
}

七、涉及多字段联动的复合状态

实际业务中，一个对象往往有多个状态维度，形成复合状态。比如一个订单既有“签章状态”，又有“同步状态”：

// 两个独立的状态维度
private Integer signStatus;    // 签章状态
private Integer syncYcStatus;  // 同步状态

// 复合状态：只有签章完成且已同步才算"流程结束"
// 回退时两个维度可能都需要回退

这种场景下，有几个关键点要特别注意：

• 两个状态之间是否有依赖关系（比如同步必须在签章完成之后才能进行）
• 回退时是否需要联动回退（签章回退了，同步状态是不是也要跟着回退）
• 是否有外部系统已经接收了数据（如果是不可逆操作，比如已经发送给第三方，回退就要特别谨慎）

八、总结

状态机本质上解决的是对象生命周期管理的问题。不管用哪种方式实现，核心关注点就那么几个：

1. 有哪些状态 → 用枚举定义清楚，别漏掉
2. 什么事件触发什么转换 → 转换规则要集中管理，别散落在各处
3. 转换时要做什么 → 把动作和转换绑定，别漏掉重要的业务操作
4. 非法转换怎么办 → 统一校验拦截，别等出bug了再补
5. 需要回退怎么办 → 设计好逆向转换和补偿动作，别让回退变成新的麻烦

把这五点想清楚，状态机这关就算过了。