简介围绕SimJava2离散事件驱动仿真整理的学习资料包面向云计算、网格计算方向的学生、研究者与仿真开发者用于理解事件调度、模块化建模、统计分析和可视化控制等核心机制并借助SimTest示例快速开展资源调度、服务性能评估、故障恢复与网格任务调度实验。压缩包共465个文件约4.68MB以227个class、110个java源码和97个html文档为主辅以txt说明、gif图示、python脚本与jar库兼顾源码阅读、示例运行和文档查阅。已有311人学习下载。读者可从中梳理优先级队列调度、实体状态演进和统计报告生成思路对照示例修改仿真模板观察虚拟机分配、负载均衡及容错策略的运行结果适合作为课程实验、课题原型与算法验证的参考材料。1. 单机跑 10 万事件的 Java 仿真simjava2 值不值得放进工具箱排队、流水线节拍、库存周转这类问题用解析公式推只能覆盖最理想的假设一旦加上优先级、设备故障、批次到达公式就推不动了。这时候要么上商业仿真软件要么自己写离散事件仿真内核。simjava2 属于后者的省事版本一个几百 KB 的 Java 包把事件队列、仿真时钟、实体调度、随机分布都封好了你只需要写每个实体的body()。我在一个产线节拍评估的小工具里用过它改一行参数就能重跑一轮比在表格软件里搭模型靠谱得多。这篇就把它的核心机制、能直接抄的代码和几个真会翻车的地方讲清楚。2. 实体、端口、事件把 simjava2 的三件套拼成能跑的模型离散事件仿真DES的内核其实只有三样东西一个按时间排序的事件队列、一个可推进的仿真时钟、一组能挂起和唤醒的执行单元。simjava2 把这套东西包装成三个类Sim_entity实体、Sim_port端口、Sim_event事件外加一个全局的Sim_system负责调度。它的设计取舍比较激进每个实体对应一个真实的 Java 线程。2.1 线程即实体simjava2 用 Java 线程换掉了状态机自己写 DES 内核最麻烦的地方在状态机。一个服务台实体在“空闲”和“忙碌”之间切换忙碌时还要记住当前处理的是哪个事件、已经处理了多久、剩余多少时间。用事件循环框架写这些都得摊成有限状态机模型一复杂switch分支能写到你怀疑人生。simjava2 把这件事反过来了实体内部就是一个阻塞式的顺序流程。sim_get_next(ev)拿下一个事件拿不到就挂起sim_process(d)表示占用处理机 d 个时间单位期间不接收任何新事件sim_schedule(port, delay, tag)往对端投递事件。整个body()写起来和普通业务代码没有区别状态全在局部变量里。代价也很明确。一个实体一个线程实体数量上千以后线程栈内存和上下文切换都开始肉疼另外实体之间共享可变状态时得自己加锁因为本质上还是多线程。所以选型上我的判断是实体数量在几百到几千的量级、模型逻辑复杂、需要频繁改需求simjava2 很合适如果要做十万级对象的微观仿真还是自己写一个优先队列加状态机的内核别跟线程过不去。提示实体线程是受Sim_system用信号量统一节流的同一时刻只会有一个实体在跑所以仿真逻辑本身是确定的。但如果你在body()里读写静态变量仍然要按多线程的规矩来。2.2 从零跑通一个三级流水编译、连接、启动先把手弄脏。下面这个模型是一条“到达源 → 单服务台 → 汇”的流水线用 M/M/1 的假设到达间隔负指数分布服务时间负指数分布。先把 jar 放进lib/目录目录结构保持src/和out/编译和运行这样走# 目录约定lib/simjava2.jar 放依赖src/ 放源码out/ 放 class mkdir -p lib out javac -encoding UTF-8 -cp lib/simjava2.jar -d out src/*.java # Linux / macOS 用冒号Windows 用分号分隔 classpath java -cp lib/simjava2.jar:out Demo 2.0 2.5 100000三个命令行参数分别是到达率 λ、服务率 μ 和总到达数。λ2.0、μ2.5 意味着利用率 ρ0.8这是个能明显看到排队的点但又不至于把队列撑爆。先写一个统计收集器让三个实体共享同一个实例避免去反查实体内部字段// src/Stats.java import java.util.ArrayList; import java.util.List; public class Stats { private final ListDouble waits new ArrayList(); private long arrived 0; private long finished 0; // 记录一次排队等待时长 public synchronized void recordWait(double w) { waits.add(w); } public synchronized void incArrived() { arrived; } public synchronized void incFinished() { finished; } public synchronized void report() { double sum 0.0, max 0.0; for (double w : waits) { sum w; if (w max) max w; } double mean waits.isEmpty() ? 0.0 : sum / waits.size(); waits.sort(Double::compareTo); double p95 waits.isEmpty() ? 0.0 : waits.get((int) Math.min(waits.size() - 1, Math.floor(waits.size() * 0.95))); System.out.printf(到达%d 完成%d 平均等待%.4f P95%.4f 最大等待%.4f%n, arrived, finished, mean, p95, max); } }waits用ArrayList存全量样本十万条 double 大概几 MB完全扛得住这样能算分位数如果要跑百万级样本改成固定宽度的直方图桶更省内存。接下来是三个实体。源实体负责按间隔发事件发完以后补一个tag -1的终止信号// src/Source.java import eduni.simjava.*; import eduni.simjava.distributions.*; public class Source extends Sim_entity { private final Sim_port out; private final Sim_negexp_obj iat; // 到达间隔 private final int total; private final Stats stats; public Source(String name, double meanIat, long seed, int total, Stats stats) { super(name); // 实体名必须全局唯一 this.total total; this.stats stats; out new Sim_port(out); add_port(out); // 端口必须注册否则 link_ports 找不到 iat new Sim_negexp_obj(iat, meanIat, seed); add_generator(iat); // 把随机流挂到实体上便于统一管理 } Override public void body() { for (int i 0; i total; i) { sim_hold(iat.sample()); // 等到下一次到达时刻 stats.incArrived(); sim_schedule(out, 0.0, 0); // 立即投递给下游 } sim_schedule(out, 0.0, -1); // 终止信号必须沿链路传下去 } }服务台实体的骨架如下。关键在ev.get_sched_time()事件自带被调度的时间戳用它减去当前仿真时钟就是这条请求在队列里待了多久不需要自己维护任何到达时间变量// src/Server.java import eduni.simjava.*; import eduni.simjava.distributions.*; public class Server extends Sim_entity { private final Sim_port in; private final Sim_port out; private final Sim_negexp_obj svc; private final Stats stats; public Server(String name, double meanSvc, long seed, Stats stats) { super(name); this.stats stats; in new Sim_port(in); out new Sim_port(out); add_port(in); add_port(out); svc new Sim_negexp_obj(svc, meanSvc, seed); add_generator(svc); } Override public void body() { while (true) { Sim_event ev new Sim_event(); sim_get_next(ev); // 阻塞直到有事件到达 if (ev.get_tag() -1) { // 收到终止信号向下游转发后退出 sim_schedule(out, 0.0, -1); return; } stats.recordWait(Sim_system.clock() - ev.get_sched_time()); sim_process(svc.sample()); // 服务时长期间不再收事件 sim_completed(ev); // 必须调用否则在制品数不清零 sim_schedule(out, 0.0, 0); } } }汇实体只负责收尾和打印// src/Sink.java import eduni.simjava.*; public class Sink extends Sim_entity { private final Sim_port in; private final Stats stats; public Sink(String name, Stats stats) { super(name); this.stats stats; in new Sim_port(in); add_port(in); } Override public void body() { while (true) { Sim_event ev new Sim_event(); sim_get_next(ev); if (ev.get_tag() -1) { // 全链路结束 stats.report(); return; } stats.incFinished(); } } }主程序负责装配。装配顺序是有讲究的initialise→ 构造实体 →add→link_ports→run中间不要插别的// src/Demo.java import eduni.simjava.*; public class Demo { public static void main(String[] args) { double lambda Double.parseDouble(args[0]); // 到达率 λ double mu Double.parseDouble(args[1]); // 服务率 μ int total Integer.parseInt(args[2]); // 总到达数 Sim_system.initialise(); // 清空上一轮残留 Sim_system.set_trace_level(Sim_system.SIM_NONE); Stats stats new Stats(); Sim_system.add(new Source(source, 1.0 / lambda, 11L, total, stats)); Sim_system.add(new Server(server, 1.0 / mu, 23L, stats)); Sim_system.add(new Sink(sink, stats)); Sim_system.link_ports(source, out, server, in); Sim_system.link_ports(server, out, sink, in); Sim_system.run(); // 阻塞直到所有实体 body 返回 System.out.printf(仿真结束时钟%.2f%n, Sim_system.clock()); } }跑通以后控制台会输出平均等待、P95 和最大等待Sim_system.clock()打印的是仿真时钟而不是实际耗时这两个数在十万事件规模下能差好几个数量级第一次跑容易被吓一跳。2.3 端口方向的字符串约定与 link_ports 的报错定位Sim_port最有迷惑性的地方是它声明的时候没有方向。new Sim_port(in)里的in只是个人类可读的标签真正决定方向的是link_ports(源实体, 源端口, 目标实体, 目标端口)这一行。同一个端口名在前一条连接里当出口在后一条连接里当入口语法上都不报错但运行时事件会投到意料之外的地方。我的习惯是把端口名抽成常量并且让add和link挨着写// 推荐端口名集中定义避免字符串拼写错误散落在几百行之外 static final String P_OUT out; static final String P_IN in;link_ports常见的失败有三种。第一种是实体名写错报错信息会直接告诉你找不到实体这类最好排查。第二种是端口名写错或者忘了add_port异常信息通常只说某个端口不存在不会告诉你是在哪个实体上找的所以实体一多就得逐个比对。第三种最隐蔽端口被重复用作输入第一次连接成功第二次静默覆盖或者行为异常表现是事件全跑到一个实体上去了。注意link_ports必须在所有实体add之后、run之前调用。放到run之后没有任何效果也不会报错只会让你对着“事件一条都没到”的输出发呆。3. 时间推进的三种写法sim_process、sim_hold 与 sim_schedule 的边界模型能跑起来只是第一步。仿真结果对不对八成取决于你有没有搞清楚这三个方法各自把仿真时钟推到了哪里。我见过不止一个模型因为把服务时间写进了sim_schedule的 delay 参数最后算出来的等待时间全是零。3.1 全局事件队列与实体线程的挂起/唤醒Sim_system内部维护一个按时间排序的全局事件队列。每个实体线程平时阻塞在自己的信号量上只有当队列头部那条事件的目的事实体是自己时才会被唤醒。唤醒后实体处理事件、可能产生新事件插回队列、可能消耗一段处理时间然后再次阻塞。这里有个关键点sim_process(d)期间实体是“不可打断”的。时钟推进 d 之后实体才回到可接收状态。这符合大多数服务台的物理直觉——柜员在服务一个客户时不会中途跑去处理别人。但如果你的场景需要抢占比如高优先级任务可以打断低优先级就得把服务过程拆成若干小段每段之间重新检查队列用sim_get_next配合非阻塞的探测逻辑实现。simjava2 没有现成的抢占原语这是它的能力边界。另一个容易忽略的是同一时刻的事件顺序。当多个事件的调度时间完全相等时队列按入队顺序处理。因为实体线程被严格节流入队顺序是确定的所以同一份代码、同一个种子跑多少遍结果都一样。这个确定性是做对拍验证的前提。3.2 sim_process、sim_hold、sim_schedule 各自动了什么把三者的语义摊开对比比看文档快得多调用推进仿真时钟实体是否可收事件是否计入处理时间统计典型用途sim_process(d)是推进 d否是服务台加工、机器占用sim_hold(d)是推进 d否否源端等待下一个到达间隔sim_schedule(port, d, tag)否只是把事件排到 td立即返回实体继续执行否投递消息、传递终止信号sim_get_next(ev)否阻塞到事件到达是否取事件sim_completed(ev)否是否标记事件处理完毕最容易翻车的是把服务时间塞进sim_schedule的 delay// 错误服务时间被当成了传输延迟服务台本身零耗时 sim_schedule(out, svc.sample(), 0); // 正确服务台先占用处理机处理完再零延迟转发 sim_process(svc.sample()); sim_completed(ev); sim_schedule(out, 0.0, 0);前一种写法下服务台瞬间完成所有请求队列长度为 0平均等待接近 0你会得到一个“性能完美”的结论然后拿着它去汇报。这不是玄学纯粹是语义搞混了。sim_hold和sim_process的行为在调度上完全一样区别只在统计口径。源端用sim_hold更贴切因为它不占用任何资源只是在等时间流逝。3.3 用事件自带的调度时间戳算等待时延很多人算排队时延的习惯是在源端把Sim_system.clock()存进一个 map服务端再取出来相减。这做法能work但引入了额外状态实体一多就很难维护。更干净的做法是用事件自带的调度时间。sim_schedule(port, delay, tag)在投递时会把当前时钟 delay记进事件里服务端用ev.get_sched_time()就能拿到。等待时延 当前时钟 − 调度时间一行搞定double wait Sim_system.clock() - ev.get_sched_time(); stats.recordWait(wait);这里有个前提事件在队列里排队的这段时间确实是“等待”而不是“处理中”。如果你的链路里有多级队列比如先进一个缓冲区再进服务台每一级都要重新调度一次get_sched_time()反映的是最近一次投递的时间跨级的总时延需要各级累加。这一点在建模时就要想清楚别等跑完发现总时延比端到端时间还短。提示如果你的版本里Sim_event没有get_sched_time()先用javap看一眼编译出来的方法列表再决定是用自建时间戳队列还是升级 jar。sim_completed(ev)也值得单独说一句。它不推进时钟作用是把事件归还给调度器让实体内部的“在途事件计数”归零。漏掉它不会让模型直接崩但 trace 输出里那条事件会一直挂着在制品数量统计会持续偏高。这类偏差在小规模试跑时看不出来等到跑十万事件再回头查成本就高了。4. 随机分布与种子让 10 万次实验可复现仿真结果的说服力一半来自模型结构另一半来自随机流的可控性。一个跑三次给出三个结论的模型没法用来做决策。simjava2 把随机分布拆成了独立的生成器对象这是它设计上比较讲究的地方但也正是种子管理最容易出问题的地方。4.1 分布类的参数表均值、标准差、种子分布类都在eduni.simjava.distributions包里命名基本是Sim_xxx_obj的形式。常用的几个类名构造参数适用场景参数注意Sim_negexp_objname, mean, seed到达间隔、服务时间参数是均值不是率传 1/λSim_normal_objname, mean, stddev, seed加工时间、测量误差会产生负值需要截断Sim_uniform_objname, min, max, seed无偏好的区间取值端点是否包含要看实现Sim_poisson_objname, mean, seed单位时间到达数返回整数注意别当时间用最容易错的是Sim_negexp_obj的参数。业务上我们习惯说“每小时到达 30 个”这是率构造函数要的是均值也就是 2 分钟。传错这一个数整个模型的负载会翻几十倍。我一般会在参数入口处强制转换并打印一行日志// 用率作为外部输入内部统一转成均值打印出来便于复核 double meanIat 1.0 / lambda; System.out.printf(λ%.3f → 平均间隔%.4f%n, lambda, meanIat);正态分布那个坑也要提一句Sim_normal_obj会生成负值而时间不可能为负。直接拿它当服务时间偶尔会得到一个负的sim_process参数行为未定义。稳妥做法是采样后截断到一个小正数double s Math.max(0.01, normal.sample()); // 截断下界避免负的服务时间这会轻微抬高均值如果对均值精度敏感改用对数正态或者伽马分布更合适。4.2 种子怎么分同一个 seed 会造出两条相同的随机流这是我在一个两级串联模型上栽过的跟头。第一版代码里两个服务台的分布对象都传了42L跑出来的排队曲线同步起伏两条队列几乎同时涨同时落看起来像是系统里有某种隐藏的耦合。排查了大半天才反应过来同一个种子同样的分布参数生成的是完全相同的样本序列。验证方法很简单写个不依赖仿真时钟的小程序把两条流的前几个样本打出来对比import eduni.simjava.distributions.*; public class SeedProbe { public static void main(String[] args) { // 同一个种子、同样的参数两条流会输出完全一样的序列 Sim_negexp_obj a new Sim_negexp_obj(a, 5.0, 42L); Sim_negexp_obj b new Sim_negexp_obj(b, 5.0, 42L); // 不同种子序列不相关 Sim_negexp_obj c new Sim_negexp_obj(c, 5.0, 7L); for (int i 0; i 5; i) { System.out.printf(a%.4f b%.4f c%.4f%n, a.sample(), b.sample(), c.sample()); } } }a和b两列会一模一样c才是独立的那条。这个现象在单服务台模型里完全无害一旦实体多起来、要做方差分析或者置信区间两条相关的流会把方差估小结论看起来比实际更“确定”。我的做法是给每个实体分配一个从基础种子派生的种子派生规则写死在一个地方// 基础种子 实体序号 * 一个大素数避免相邻种子产生相关序列 private static final long BASE_SEED 20240501L; static long seedFor(int entityIndex) { return BASE_SEED entityIndex * 1000003L; }选个大素数做步长是为了避免某些线性同余发生器在相邻种子下产生的序列相关性。这不是理论洁癖实测里相邻种子确实会让方差估计偏乐观。还有一点做参数扫描时每一轮实验要不要换种子我的经验是固定种子扫参数这样不同参数点之间的差异完全来自参数本身不会被随机波动掩盖确认趋势之后再换一批种子跑重复实验评估置信区间。两件事分开做比一次性混在一起强。4.3 统计量自己攒再拿 Little 定律验一遍simjava2 自带了直方图和累加器之类的统计类但接口在不同小版本之间有些出入而且输出格式未必合你的报表需求。十万条样本的量级自己用ArrayList攒起来算分位数反而更灵活代码前面已经给过了。真正值钱的是跑完之后做一次交叉校验。排队论里的 Little 定律说平均在制品数 L 等于到达率 λ 乘以平均逗留时间 W。这个关系对任何满足稳态的排队系统都成立与分布假设无关所以是个很好用的“体检指标”。具体做法是在模型里再记两个量系统内的瞬时数量到达 1、离开 -1用Sim_system.clock()做时间加权积分以及每个请求的端到端逗留时间。跑完之后算L和λW两者偏差在 5% 以内算是正常超过 10% 基本可以断定模型有问题——要么漏了sim_completed要么某个实体的时间推进语义写错了。// 时间加权积分每次系统内数量变化时把上一段的时间 × 数量累加进去 double area 0.0; int inSystem 0; double lastChange 0.0; void onEnter(double now) { area inSystem * (now - lastChange); inSystem; lastChange now; } void onLeave(double now) { area inSystem * (now - lastChange); inSystem--; lastChange now; } double meanInSystem(double simEnd) { return area / simEnd; }这个校验我在每个新模型上都会跑一遍往往比盯着 trace 输出看半天有效。5. 避坑清单五个把仿真结果带偏的常见错误下面这五条都是真踩过的按“现象 → 原因 → 解决”的顺序写遇到类似症状可以直接对号入座。5.1 两条随机流共用一个种子现象两级串联的服务台两条队列的长度曲线高度同步相关系数算出来 0.9 以上怎么看都不像独立系统。原因两个Sim_negexp_obj构造时传了同一个seed生成的样本序列完全相同。上游处理快的时候下游也快人为制造了一个强相关。解决给每个实体分配派生种子规则集中在一个方法里别散落在各处new的时候随手写。改完重跑相关系数应该回落到接近 0。5.2 漏掉 sim_completed在制品数永远不清零现象打开 trace 之后事件只有调度记录没有完成记录自己统计的系统内数量单调上升跑得越久偏得越多。原因sim_completed(ev)没调用或者只在部分分支上调用了。终止信号那条路径上尤其容易漏因为很多人觉得“反正要退出了无所谓”。解决把sim_completed放在每个非终止分支的固定位置紧跟在sim_process之后。代码评审时专门搜一遍sim_get_next的出现次数和sim_completed的出现次数是否对得上。5.3 body() 提前 return仿真进程挂着不退现象命令行没有输出进程不结束CPU 占用接近 0等十分钟还是那样只能 CtrlC。原因上游实体body()里的循环条件写错比如while (Sim_system.running())在某个时点求值为 false提前返回下游实体还阻塞在sim_get_next上等一个永远不来的事件。所有实体都阻塞Sim_system.run()自然不返回。解决终止信号必须显式沿链路逐级传递每个实体收到tag -1后转发给所有下游再返回。另外在开发期给实体加个“最大事件数”保护超过就直接抛异常别让它默默挂死。5.4 端口名写错报错信息只告诉你“找不到”现象本文还有配套的精品资源点击获取