工业仿真引擎设计实战：从离散事件到双向链表的演进之路

1. 从零开始的抉择：为什么我们要自己造轮子？

大家好，我是老张，一个在工业软件领域摸爬滚打了十多年的老兵。今天想和大家聊聊，我们团队在开发一个工业仿真引擎时，踩过的那些坑，以及最终如何通过一个看似简单的数据结构——双向链表，解决了最核心的设备状态同步难题。整个过程，就像是在给一个复杂的工厂搭建神经系统，充满了挑战，也充满了乐趣。

故事得从几年前说起。当时我们接到一个需求，要为一家大型制造企业开发一个产线仿真系统，用来模拟和优化他们的生产流程。客户的要求很明确：要能真实反映产线上设备（比如加工站、传送带、缓存区）之间的协作，产品要能动态流转，设备状态（空闲、加工、阻塞、故障）要实时同步。听起来是不是很像一个“离散事件仿真”系统？没错，我们一开始也是这么想的。

我的第一反应是去找现成的轮子。市面上有没有成熟的、基于JavaScript的离散事件仿真库呢？我花了好几天时间调研，结果却有点失望。要么是那些库已经年久失修，文档和社区都停滞了；要么就是功能太单一，只能模拟简单的队列模型，根本无法支撑我们想要的、带复杂工艺流程和状态反馈的流水线仿真。举个例子，很多库只能处理“事件A发生，然后事件B发生”这种线性流程，但我们的产线里，一个产品加工完后，下一个该去哪个设备，是需要根据下游多个设备的实时状态来动态决定的。这种“动态寻路”的能力，当时的开源库基本都不支持。

所以，我们面临一个选择：是勉强用一个不合适的库修修补补，还是自己从头搭建一个仿真引擎的核心？考虑到项目的长期维护和功能扩展，我们一拍大腿：自己干！这第一步，就决定了我们后面所有的技术演进，都是从实际痛点出发，而不是纸上谈兵。

2. 初版架构的阵痛：单向通信的致命缺陷

既然决定自己开发，第一步就是确定整个仿真引擎的数据结构。这就像盖房子要先打地基。我们最初的思路很直接：模仿真实的产线。每个产品（Product）都有一个预设的加工流程（Process Flow），比如“先到机床A加工10秒，再到检测站B检查5秒”。每个设备（Station）都是一个独立的实体，我们给它一个状态属性，比如 idle（空闲）、processing（加工中）、block（阻塞）。

为了让产品能流动起来，我们给每个设备加了一个 nextStations 属性，这是一个数组，用来指明这个设备加工完的产品，可以流向哪些“下游设备”。仿真开始后，产品就按照自己的流程，一步一步往下走。当一个设备加工完产品，它就会遍历自己的 nextStations 列表，找到第一个状态是 idle 的设备，然后把产品“推”给它。

听起来很合理，对吧？我们很快用代码实现了这个逻辑，并兴奋地跑起了第一个仿真demo。然而，问题几乎立刻就暴露了。我们遇到了一个经典的“生产者-消费者”死锁问题，我把它称为“沉默的阻塞”。

让我用一个最简单的两条产线场景来说明：

• 设备A：正在加工产品。
• 设备B：是设备A的下游，也正在加工另一个产品。

现在，设备A先加工完了。它试图把产品发给设备B，但发现设备B的状态是 processing（忙），不是 idle（闲）。按照我们的逻辑，设备A无法发送产品，于是它将自己的状态改为 block（阻塞），然后……就停在那里了。它在等待设备B变空闲。

过了一会儿，设备B也加工完了。它变成了 idle 状态。但是，在我们的架构里，设备B只是一个被动的“消费者”。它不会主动去问：“嘿，我的上游谁有产品要给我吗？” 它只是安静地待着，等待下一个产品被推过来。

于是，讽刺的一幕出现了：设备A在等B空闲，设备B已经空闲了却在等A发货。两者都陷入了等待，仿真流程就此卡死。这就是单向通信的致命伤：信息流是单向的，只有上游向下游“推”产品，下游无法向上游“拉”产品。当上下游状态不匹配时，系统就失去了协调能力。

我们当时在日志里看到设备A不断打印“尝试派发产品...失败，下游忙”，而设备B则毫无动静，整个仿真时间停止了流逝。那一刻我们明白，这个地基打歪了。我们需要让设备之间能够“对话”，而不仅仅是“喊话”。

3. 灵光一闪：用双向链表重构设备关系网

怎么解决这个“沉默的阻塞”问题？我们团队讨论了很久。有人提议用集中式的调度器，每秒轮询所有设备状态，然后强行分配。但这效率太低，而且不够优雅，失去了离散事件仿真“事件驱动”的精髓。

有一天，我在复习数据结构时，突然看到了“双向链表”。脑子里灵光一闪：如果我们把产线上的设备，组织成一个双向链表呢？每个设备不仅知道自己的下游（nextStations），也知道自己的上游（prevStations）！

这个想法让我们豁然开朗。我们立刻对基础设备类 BaseStation 进行了改造：

abstract class BaseStation {
  id: string;
  name: string;
  // 关键的双向链接属性
  prevStations: BaseStation[] = []; // 上游设备列表
  nextStations: BaseStation[] = []; // 下游设备列表
  status: StationStatus = 'idle'; // 当前状态

  // ... 其他属性和方法

  // 设置下游设备
  setNextStations(stations: BaseStation[]) {
    this.nextStations = stations;
    // 同时，也需要建立反向链接（通常在模型构建时统一处理）
  }

  // 设置上游设备
  setPrevStations(stations: BaseStation[]) {
    this.prevStation