上图就是一个最简单的状态机，一个初态，一个流转状态，一个终态，初态到流状态是不需要任何操作的，State1当发生了Event1事件时，执行Action1到达了终态。（我们最终实现的状态机，会把初态和终态都当做一个流状态来对待）。

说了这么多，状态机能干什么？状态机主要的应用场景就是流程控制。一个状态机定义以后，在某个状态下就只接收固定的Event，也就是执行指定的操作，这样流程就能按照预期定义的那样流转，不会出现乱入的情况，执行了一些在某状态下不允许执行的操作。一个很典型的应用就是工作流引擎：以工作流中典型的审批流程为例，审批流程按照预先定义的流程流转的固定的某些人手里，只有这一批固定的人才能审批，当审批后（可能是一个人审批，也可能是多个人审批）才会流转到下个节点，由下个节点的审批人继续审批，一直流转到最后一个节点。状态机的流转可以人工干预，也可以自动流转。定义为自动流转后，把业务流程定义完成后，只要添加一个定时任务，整个流程的运转就都由状态机来完成了。此外，当状态机加入了持久化操作后，所有的状态流转都会落地，当业务出现异常，方便定位问题，当流程定义的足够细粒度的话，还可以通过驱动状态机来实现重入，恢复异常的节点。

状态模式

在实现状态机之前，我们顺便简单的看一下设计模式中的状态模式，这个模式跟我们实现状态机的代码结构还是有一定的关系的。

状态模式：封装基于状态的行为，并将行为委托到当前的状态。

试想一下，现在有一种业务场景存在多个状态，比如一个要遭受攻击的游戏人物，当人物遭受攻击后我们要减少人物的血量，而当前人物可能处于的状态有如下（游戏中常见的一些场景）：刚复活（对一切攻击免疫），正常状态，物理攻击免疫，魔法攻击免疫，攻击随机无效，各种叠加态。当攻击来了，人物该怎么掉血。在非使用状态模式的情况下，一种常见的写法，人物接受攻击，然后开始各种判断现在人物所处于的状态，各种if...else，当新的需求来额时候，就修改这些if...else。而采用状态模式，行为委托类保存着当前人物所处的状态，当攻击来了，委托类会把该攻击交由持有的状态来处理，实现了对修改关闭，对扩展开放。类图如下（具体就不上代码了，感兴趣的可以自己研究一下）：