前面两篇文章所描述的状态机，思维的基础是：对一个订单施加动作，将委托回报或成交回报归纳为若干对此订单施加动作后的回馈，在等待动作回馈时设置此订单状态。因此，我们跟踪状态的对象是一个订单。也就是当这个订单从委托开始，对可能发生的各种情况加以跟踪和控制。这样的话，我们在各个状态就只能对一个订单的状态加以维护，然后根据这一个订单的状态变化用程序控制状态的流转。在交易信号出现频率比较低的时候，我们可以处理完一个订单，比如开仓报单之后，再等待其平仓信号的出现，然后做平仓报单的操作。然而，在交易信号出现频率比较高的情况下，往往在一个订单还没有处理完的时候，又需要下新的订单，这时候按照这种思路的状态机就难以处理了。此时，状态机就不能严格的将开平各个状态分开，比如，在单合约状态机的示例中，当订单处于可平状态时又出现了开仓信号，程序会丢失掉这个信号。
那么，在信号出现频率较高的时候，单合约的状态机应该是这样的：
也就是说，处于“可交易”状态时，不论是出现开仓条件开仓，平仓条件平仓，还是超时撤单的情况，状态都流转到自己，以便接收新的信号做出相应动作。
不过，在这样的状态机下面，同一个状态要处理的逻辑就相当多。比如，平仓信号出现时，到底有没有持仓可平？到底是开仓报单正在等待成交还是已经撤单？不同的情况，程序的控制完全不一样；没有持仓，则平仓动作要忽略；开仓报单在等待成交，则要先撤单，再平仓；开仓报单已经撤单且有成交或者完全成交的情况，则直接平仓。更重要的是，当前一个订单还没有撤单或者完全成交的时候，新的报单必须要根据前一个报单当时的具体情况，才能决定其操作，所以还需要维护前一个报单的状态。所有的程序控制都写到这个状态里，可读性会变得相当差，并且极易出错。
为了解决上述问题，可以将这部分订单处理的工作抽离出来，把所有的开仓平仓撤单的工作，以及处理的逻辑单独用一个线程来处理，这就是所谓的订单管理线程；这样，和策略管理线程分离开来，使策略管理线程的着眼点在合约上，让其状态机仅仅按照对合约持仓操作的业务逻辑来处理，而不去管业务操作下订单的具体实现。如下图：
策略管理线程按照业务逻辑给订单管理线程两个参数，一个是目标仓位，一个是达到这个目标仓位所需要的时间；订单管理线程给策略管理线程两个回馈，一个是合约的持仓情况，一个是操作完结的提示，操作完结分两种情况：一是在操作时间限制内完成了操作，二是超过了操作时间限制而撤销了操作。而至于要怎么完成业务操作，完全交给订单管理线程去做。这样的话，高频交易下的合约状态机的代码控制就变得很简单。
