Tim.Guan

潜水好久。。。问题解决了吧。。。还有问题可以给我留言。。。

@lhaiq 要恢复的前提是要先做持久化，比如记录订单的当前状态；其实对于squirrel状态机创建的开销足够轻量，恢复的动作其实就是根据之前持久化的信息，重新初始化一个statemachine instance。这一点的设计和spring statemachine是不一样的，spring statemachine因为创建的过程过于heavy，不得不引入share statemachine instance（这个也引入了一堆问题，性能、deadlock、上下文清理等，spring statemachine 的作者也在思考这么做是否值得，希望能有个更好的解决方案）。从我个人角度看，我比较偏向squirrel这种方式，简单犯错的概率相对低，为啥我们要选择状态机不选择个臃肿的bpm，不就图个轻量么。

@lhaiq [状态机引擎选型](http://www.timguan.net/2017/06/19/%E7%8A%B6%E6%80%81%E6%9C%BA%E5%BC%95%E6%93%8E%E9%80%89%E5%9E%8B/) [squirrel-foundation状态机的使用细节](http://www.timguan.net/2017/06/21/squirrel-foundation%E7%8A%B6%E6%80%81%E6%9C%BA%E7%9A%84%E4%BD%BF%E7%94%A8%E7%BB%86%E8%8A%82/#more) 希望对你有帮助

@lhaiq 当然应该在创建实例的时候啊，先获取当前持久化的状态，再构造状态机实例，再fire ``` T stateMachine = stateMachineBuilder.newUntypedStateMachine( initialState, //暂时开启debug进行日志trace StateMachineConfiguration.create().enableDebugMode(true).enableAutoStart(true), //注入applicationContext applicationContext); ```

@SuperNoobTao 

嗯，squirrel我已经在生产核心项目中使用了一年，数据量都在百万千万级，暂未遇到大问题，感谢 @hekailiang 。一年前我在选型的时候，对比了spring-statemachine，当时spring-statemachine确实不成熟，而且过于复杂的设计难以维护。