哭了！為什么沒早用 Spring 狀態機？現在代碼優雅到發光
兄弟們，有沒有那么一瞬間，看著自己寫的那些處理狀態邏輯的代碼，恨不得給自己來兩拳？明明需求看起來挺簡單，就是處理個狀態轉換，結果寫著寫著，代碼里全是各種 if-else 或者 switch，層層嵌套，跟迷宮似的。不僅自己看著頭疼，同事接手的時候，估計心里也在默默問候咱的祖宗十八代。而且最要命的是，稍微不注意，狀態判斷錯了，bug 就跟雨后春筍似的冒出來，debug 都能讓人 debug 到懷疑人生。
咱就拿一個常見的訂單業務來說吧。訂單有創建、支付、發貨、收貨、取消、退款等等狀態。一開始，咱可能想著，這不簡單嘛，用 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 狀態機還有很多高級特性和應用場景等待我們去探索，比如工作流引擎、有限狀態自動機等。只要我們合理運用，它就能成為我們開發過程中的得力助手，讓我們的代碼質量更上一層樓。
