咱就拿一个常见的订单业务来说吧。订单有创建、支付、发货、收货、取消、退款等等状态。一开始，咱可能想着，这不简单嘛，用 if-else 来判断当前状态，然后根据不同的事件，比如用户支付、商家发货等，来更新订单状态。于是代码里就出现了这样的场景：
if (order.getStatus() == OrderStatus.CREATED) {
if (event == Event.PAY) {
// 处理支付逻辑
order.setStatus(OrderStatus.PAID);
} else if (event == Event.CANCEL) {
// 处理取消逻辑
order.setStatus(OrderStatus.CANCELED);
}
} else if (order.getStatus() == OrderStatus.PAID) {
if (event == Event.SHIP) {
// 处理发货逻辑
order.setStatus(OrderStatus.SHIPPED);
} else if (event == Event.REFUND) {
// 处理退款逻辑
order.setStatus(OrderStatus.REFUNDED);
}
}
// 后面还有一堆类似的判断...
随着业务的不断扩展，状态越来越多，事件也越来越复杂，这样的代码简直就是一场灾难。维护起来难不说，要是新增一个状态或者修改一个状态转换规则，那得把整个代码翻个底朝天，还生怕漏掉某个地方，导致出现奇怪的 bug。这时候，咱心里是不是在想，有没有一种更优雅的方式来处理状态逻辑呢？别急，今天咱就来聊聊 Spring 状态机，用了它，保准让你的代码优雅到发光，再也不用为状态逻辑处理而发愁。
一、啥是状态机？先把概念搞明白
在说 Spring 状态机之前，咱得先弄清楚啥是状态机。其实状态机这玩意儿，在咱们日常生活中随处可见。比如说自动售货机，它有不同的状态，比如等待投币、等待选择商品、出货、找零等。当我们投入硬币（这就是一个事件），自动售货机就会从等待投币状态转换到等待选择商品状态；当我们选择了一个商品（又是一个事件），它就会根据商品价格和我们投入的硬币金额进行判断，如果金额足够，就会转换到出货状态，同时可能还会找零。
再比如说电梯，它有停止、运行、开门、关门等状态。当我们在某一层按了电梯按钮（事件），电梯如果在运行状态，可能会继续运行到目标楼层，然后停止并开门；如果电梯在停止状态，就会开门让我们进去，然后关门运行到我们选择的楼层。
从计算机科学的角度来说，状态机（State Machine）是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。简单来说，它由状态（State）、事件（Event）、转换（Transition）、动作（Action）和守卫条件（Guard）组成。
- 状态（State）：对象在其生命周期中的一种条件，比如订单的创建状态、支付状态等。
- 事件（Event）：触发状态转换的消息，比如用户支付订单、商家发货等。
- 转换（Transition）：从一个状态到另一个状态的迁移，通常由事件触发，并且可能需要满足一定的守卫条件。
- 动作（Action）：在状态转换过程中执行的操作，比如更新订单状态、发送通知等。
- 守卫条件（Guard）：一个布尔表达式，用于判断事件是否能够触发状态转换，比如只有当订单金额大于 0 时，才能进行支付操作。
状态机的好处可太多了。它能让我们清晰地描述对象的状态变化过程，代码结构更加清晰，易于维护和扩展。而且，它能够有效地避免状态判断的遗漏和错误，提高代码的健壮性。
二、Spring 状态机：Java 开发者的状态管理神器
Spring 状态机是 Spring 框架提供的一个用于构建状态机的模块，它基于状态模式和责任链模式，能够方便地在 Java 应用中实现状态机。Spring 状态机支持多种状态机模型，包括 UML 状态机和简单状态机，我们可以根据具体的业务需求选择合适的模型。
（一）Spring 状态机的核心概念
状态（State）
在 Spring 状态机中，状态可以分为简单状态和复合状态。简单状态就是一个独立的状态，比如订单的创建状态；复合状态可以包含子状态，比如订单的处理中状态可以包含支付中、发货中等子状态。我们可以通过枚举类型来定义状态，例如：
public enum OrderState {
CREATED, PAID, SHIPPED, DELIVERED, CANCELED, REFUNDED
}
事件（Event）
事件是触发状态转换的原因，同样可以用枚举类型来定义，例如：
public enum OrderEvent {
PAY, SHIP, DELIVER, CANCEL, REFUND
}
转换（Transition）
转换定义了从源状态到目标状态的映射，以及触发转换的事件和可能的守卫条件、动作。在 Spring 状态机中，我们可以通过配置来定义转换规则。
动作（Action）
动作可以在状态转换的不同阶段执行，比如在事件触发时、状态转换前、状态转换后等。我们可以自定义动作类，实现 Action 接口，然后在配置中指定动作的执行时机。
守卫条件（Guard）
守卫条件用于判断事件是否能够触发状态转换，它是一个实现了 Guard 接口的类，返回一个布尔值。例如，只有当订单未被取消时，才能进行发货操作。
（二）Spring 状态机的优势
代码结构清晰
使用 Spring 状态机，我们可以将状态逻辑从业务代码中分离出来，通过配置的方式定义状态转换规则，使得代码更加简洁明了，易于理解和维护。
易于扩展
当业务需求发生变化，需要新增状态或修改状态转换规则时，只需修改状态机的配置，而无需修改大量的业务代码，降低了代码的修改成本。
支持复杂状态逻辑
Spring 状态机支持复合状态、子状态机等高级特性，能够处理复杂的业务状态逻辑，比如工作流、有限状态自动机等。
与 Spring 生态集成良好
作为 Spring 框架的一部分，Spring 状态机可以无缝集成 Spring 的其他模块，比如 Spring Boot、Spring Data 等，方便我们构建完整的应用系统。
三、手把手教你用 Spring 状态机玩转订单状态管理
接下来，咱就以订单状态管理为例，一步步教你如何使用 Spring 状态机来实现优雅的状态逻辑处理。
（一）引入依赖
首先，我们需要在项目中引入 Spring 状态机的依赖。如果使用 Spring Boot，只需在 pom.xml 中添加以下依赖：
<dependency>
<groupId>org.springframework.statemachine</groupId>
<artifactId>spring-statemachine-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.statemachine</groupId>
<artifactId>spring-statemachine-config</artifactId>
</dependency>
（二）定义状态和事件
我们已经在前面定义了订单的状态枚举 OrderState 和事件枚举 OrderEvent，这里就不再重复了。
（三）配置状态机
Spring 状态机的配置可以通过 Java 配置类来实现，我们需要创建一个配置类，继承 StateMachineConfigurerAdapter，并覆盖相关的方法来定义状态机的状态、转换、动作和守卫条件等。
@Configuration
@EnableStateMachine
public class OrderStateMachineConfig extends StateMachineConfigurerAdapter<OrderState, OrderEvent> {
// 定义状态
@Override
public void configure(StateMachineStateConfigurer<OrderState, OrderEvent> states) throws Exception {
states
.withStates()
.initial(OrderState.CREATED) // 初始状态
.states(EnumSet.allOf(OrderState.class));
}
// 定义转换
@Override
public void configure(StateMachineTransitionConfigurer<OrderState, OrderEvent> transitions) throws Exception {
transitions
.withExternal() // 外部转换，会改变状态
.source(OrderState.CREATED) // 源状态
.target(OrderState.PAID) // 目标状态
.event(OrderEvent.PAY) // 触发事件
.action(payAction()) // 执行的动作
.guard(payGuard()) // 守卫条件
.and()
.withExternal()
.source(OrderState.PAID)
.target(OrderState.SHIPPED)
.event(OrderEvent.SHIP)
.action(shipAction())
.and()
.withExternal()
.source(OrderState.SHIPPED)
.target(OrderState.DELIVERED)
.event(OrderEvent.DELIVER)
.action(deliverAction())
.and()
.withExternal()
.source(OrderState.CREATED)
.target(OrderState.CANCELED)
.event(OrderEvent.CANCEL)
.action(cancelAction())
.and()
.withExternal()
.source(OrderState.PAID)
.target(OrderState.REFUNDED)
.event(OrderEvent.REFUND)
.action(refundAction());
}
// 定义动作
@Bean
public Action<OrderState, OrderEvent> payAction() {
return new Action<OrderState, OrderEvent>() {
@Override
public void execute(StateContext<OrderState, OrderEvent> context) {
// 处理支付动作，比如更新订单支付时间、调用支付接口等
System.out.println("执行支付动作");
Order order = context.getMessage().getHeaders().get("order", Order.class);
order.setStatus(OrderState.PAID);
order.setPaymentTime(new Date());
// 这里可以添加具体的业务逻辑
}
};
}
@Bean
public Action<OrderState, OrderEvent> shipAction() {
return context -> {
// 处理发货动作，比如生成物流单号、更新发货时间等
System.out.println("执行发货动作");
Order order = context.getMessage().getHeaders().get("order", Order.class);
order.setStatus(OrderState.SHIPPED);
order.setShipTime(new Date());
// 这里可以添加具体的业务逻辑
};
}
// 定义守卫条件
@Bean
public Guard<OrderState, OrderEvent> payGuard() {
return context -> {
// 判断订单金额是否大于 0，只有金额大于 0 才能支付
Order order = context.getMessage().getHeaders().get("order", Order.class);
return order.getAmount() > 0;
};
}
}
在上面的配置中，我们首先定义了状态，指定了初始状态为 CREATED，并包含了所有的订单状态。然后定义了转换规则，每个转换都指定了源状态、目标状态、触发事件、动作和守卫条件（可选）。动作和守卫条件通过 Bean 的方式定义，方便重用和测试。
（四）使用状态机
配置好状态机之后，我们就可以在业务代码中使用它了。首先，需要注入 StateMachine 对象：
@Autowired
private StateMachine<OrderState, OrderEvent> orderStateMachine;
然后，在处理事件时，创建消息对象，并将订单对象作为参数传递给状态机：
public void processEvent(Order order, OrderEvent event) {
// 创建消息，将订单对象作为参数
Message<OrderEvent> message = MessageBuilder.withPayload(event)
.setHeader("order", order)
.build();
// 发送事件给状态机
orderStateMachine.sendEvent(message);
}
当状态机接收到事件后，会根据配置的转换规则进行状态转换，并执行相应的动作和守卫条件。
（五）状态机监听器
为了更好地监控状态机的状态变化，我们可以添加监听器，监听状态的进入、退出和转换等事件。例如：
@Configuration
public class OrderStateMachineListenerConfig {
@Autowired
public void configure(StateMachineFactory<OrderState, OrderEvent> factory) {
factory.getStateMachine().addStateListener(new StateListener<OrderState, OrderEvent>() {
@Override
public void stateChanged(State<OrderState, OrderEvent> from, State<OrderState, OrderEvent> to) {
// 状态发生变化时触发
System.out.println("状态从 " + from.getId() + " 转换到 " + to.getId());
}
});
factory.getStateMachine().addTransitionListener(new TransitionListener<OrderState, OrderEvent>() {
@Override
public void transitionStarted(Transition<OrderState, OrderEvent> transition) {
// 转换开始时触发
System.out.println("转换开始：" + transition.getSource().getId() + " -> " + transition.getTarget().getId());
}
@Override
public void transitionEnded(Transition<OrderState, OrderEvent> transition) {
// 转换结束时触发
System.out.println("转换结束：" + transition.getSource().getId() + " -> " + transition.getTarget().getId());
}
});
}
}
通过监听器，我们可以在状态转换的各个阶段执行一些额外的操作，比如记录日志、发送通知等。
四、Spring 状态机进阶：处理复杂业务场景
（一）复合状态和子状态机
当业务场景比较复杂，状态之间存在层次关系时，我们可以使用复合状态和子状态机。例如，订单在支付过程中可能有支付中、支付成功、支付失败等子状态，我们可以将支付过程定义为一个复合状态，其中包含这些子状态。
public enum OrderState {
CREATED,
PAYING(CompositeState.PAYMENT), // 复合状态
PAID,
PAYMENT_FAILED,
SHIPPED,
DELIVERED,
CANCELED,
REFUNDED
}
// 复合状态枚举
publicenum CompositeState {
PAYMENT
}
在配置状态机时，我们可以定义复合状态及其子状态：
@Override
public void configure(StateMachineStateConfigurer<OrderState, OrderEvent> states) throws Exception {
states
.withStates()
.initial(OrderState.CREATED)
.states(EnumSet.allOf(OrderState.class))
.and()
.withCompositeStates()
.withState(OrderState.PAYING, CompositeState.PAYMENT)
.withStates(CompositeState.PAYMENT)
.initial(OrderState.PAYING)
.states(EnumSet.of(OrderState.PAYING, OrderState.PAID, OrderState.PAYMENT_FAILED));
}
（二）持久化状态机上下文
在实际应用中，我们可能需要将状态机的上下文（比如订单对象）持久化，以便在应用重启后能够恢复状态机的状态。Spring 状态机支持将状态机的上下文持久化到数据库或其他存储介质中，我们可以通过实现 StateMachinePersist 接口来实现自定义的持久化逻辑。
（三）与外部系统交互
在状态转换过程中，可能需要与外部系统进行交互，比如调用支付接口、物流接口等。这时候，我们可以在动作中使用 Spring 的 RestTemplate 或其他客户端来发起远程调用，并处理调用结果。
@Bean
public Action<OrderState, OrderEvent> payAction() {
return context -> {
Order order = context.getMessage().getHeaders().get("order", Order.class);
// 调用支付接口
PaymentResponse response = restTemplate.postForObject(paymentUrl, order, PaymentResponse.class);
if (response.isSuccess()) {
order.setStatus(OrderState.PAID);
order.setPaymentTime(new Date());
} else {
// 处理支付失败，转换到支付失败状态
context.getStateMachine().transition(OrderEvent.PAYMENT_FAILED);
}
};
}
五、踩坑指南：使用 Spring 状态机常见问题及解决办法
（一）状态转换不生效
如果发现发送事件后状态没有转换，首先要检查配置的转换规则是否正确，源状态、目标状态和事件是否匹配。其次，检查守卫条件是否返回 true，如果守卫条件不满足，转换不会发生。另外，还要注意状态机是否已经启动，在 Spring Boot 中，状态机默认是自动启动的，但如果在配置中关闭了自动启动，需要手动调用 stateMachine.start() 方法。
（二）动作执行顺序问题
有时候，我们可能需要在状态转换的不同阶段执行不同的动作，比如在状态转换前执行一些准备工作，在转换后执行一些清理工作。Spring 状态机支持在转换中定义多个动作，动作的执行顺序按照定义的顺序进行。如果需要更精细地控制动作的执行时机，可以使用 Action 接口的不同实现，或者在配置中使用 beforeAction 和 afterAction 方法。
（三）状态机上下文丢失
在使用状态机时，上下文对象（比如订单对象）通常是通过消息的头部传递的。如果在状态转换过程中，上下文对象没有正确传递，可能会导致动作或守卫条件无法获取到所需的数据。因此，在发送消息时，一定要确保上下文对象被正确设置到消息的头部，并且在动作和守卫条件中正确获取。
（四）复杂状态机调试困难
当状态机配置比较复杂时，调试可能会比较困难。这时候，我们可以利用 Spring 状态机提供的调试工具，比如打印状态机的状态和转换信息，或者使用断点调试来跟踪状态转换的过程。另外，合理使用监听器来记录状态转换的日志，也能帮助我们快速定位问题。
六、总结：早用早受益，代码优雅不是梦
说了这么多，相信大家对 Spring 状态机已经有了一个比较清晰的认识了。使用 Spring 状态机，我们可以将复杂的状态逻辑从业务代码中分离出来，通过配置的方式进行管理，让代码更加简洁、优雅、易维护。再也不用为了处理状态逻辑而写一堆恶心人的 if-else 了，妈妈再也不用担心我的代码会因为状态判断而出现 bug 了。
当然，Spring 状态机还有很多高级特性和应用场景等待我们去探索，比如工作流引擎、有限状态自动机等。只要我们合理运用，它就能成为我们开发过程中的得力助手，让我们的代码质量更上一层楼。
