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("当前状态不允许取消"); }
}

每个状态自身知道哪些操作是合法的，调用方无需关心具体规则，直接调用方法即可。

五、两种方式的对比

维度	隐式状态机	显式状态机
实现成本	低，直接写 if/else	中等，需要定义转换规则
可读性	差，状态规则分散在各方法中	好，规则集中一目了然
维护成本	状态少时低，状态多时急剧上升	稳定，新增状态只需加规则
安全性	容易遗漏校验导致非法转换	统一拦截非法转换
适用场景	状态少（3-5个）且变化少	状态多或流转规则复杂

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

六、状态机中的常见概念

守卫条件（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. 非法转换怎么办 → 统一校验拦截，避免问题出现后再补救
5. 需要回退怎么办 → 设计好逆向转换和补偿动作，避免回退引发新问题

理清这五点，状态机的设计与实现便不再困难。