简介：PIPE 4.3.0 是一款基于 Petri 网的图形化建模与仿真工具，面向软件工程、系统分析与流程验证等方向的学习者和研究者，用于构建含并发、同步与竞争特征的系统模型，并借助可达性图、覆盖测试及安全性与活性检查评估模型性质。压缩包共 2391 个文件，约 28.43MB，以 Java 字节码 class、SVN 元数据 svn-base、界面截图 png 及 SVG 图形为主，同时包含 htm/html 说明页、xml/xsd/xsl 配置、jar 依赖与 properties 参数文件，保留了较完整的工程目录与运行素材。已有约 1500 人学习下载。读者可从中获得可执行的建模仿真环境，结合图形化建模、动态仿真和互操作示例理解 Petri 网工作流，并参考目录中的查询编辑器、转换视图等模块组织方式，辅助课程实验、课题建模与工具二次开发。

1. 一台装着 JDK 17 的机器，和双击没反应的 PIPE 4.3.0

上周帮某实验室的同学排一个怪问题：PIPE 4.3.0 装好了，双击 jar 只闪一下，什么都不弹；换命令行跑，控制台丢出一行NoClassDefFoundError，然后就没了。机器上装的是最新一版 JDK，其他项目都跑得好好的，唯独这个 Petri 建模仿真工具起不来。这不是个例，做流程建模、并发逻辑验证、工作流可达性分析的人，十有八九都在这上面翻过车。PIPE 4.3.0 是套纯 Java 的 Petri 网建模软件，画网、触发变迁、跑状态空间分析全靠 Swing 界面，它对运行时的要求不新，但对“跑在哪个 JDK 上”很挑。装不好不是报个错就完事，是你画完一整张网、准备点仿真按钮的时候，才发现 token 根本不动，前面的活全白干。这篇就按我实际装机的顺序写：先定 JDK，再装环境，再配启动参数，最后拿一个最小模型把 Petri 建模仿真跑通。

2. 装前把环境条件列清楚：JDK 档位、图形依赖、目录规划

动手之前先别急着双击安装包。PIPE 4.3.0 这类老牌 Java 桌面工具，装崩的原因九成不在软件本身，而在环境没对上。我一般会花十分钟把三件事确认掉：JDK 大版本、图形显示环境、磁盘上的目录结构。这三样确认完，后面基本不会返工。

2.1 版本对照：PIPE 4.3.0 吃哪一档 JDK

PIPE 4.3.0 的代码年代偏早，编译目标和依赖库都停留在 Java 8 之前的生态里，所以它最舒服的落点是 JDK 8。不是“越新越好”，而是越新越容易缺东西——高版本 JDK 把一批老的扩展包从标准库里挪走了，PIPE 启动时引用的类找不到，就直接躺平。

选 JDK 8 还有个隐性好处：它的sun.java2d.uiScale参数在高分屏上还能用，这对 PIPE 这种固定像素布局的老界面很重要。至于 JDK 8 从哪来，常见做法是装一个长期维护的 8u 发行版，别去下那种来路不明的精简包——我见过有人用裁剪过的运行时，结果javax.swing里的类被删了一半，怎么排查都查不出来。

提示：如果机器上已经有 JDK 17 并且是别的项目在用，不用卸载，装一个 JDK 8 并存就行，靠JAVA_HOME或者启动脚本指定，别去动系统默认的那一套。

2.2 依赖清单与图形环境自检

PIPE 4.3.0 的运行时依赖其实很短：一个完整的 JRE/JDK、一套能用的图形显示、以及足够的堆内存。短归短，每一条都能卡人。

Windows 这边，确认显卡驱动正常、系统缩放别开到 200% 以上，剩下基本没坑。Linux 这边麻烦得多，因为它要 X11。在一台纯命令行的服务器上跑，你会拿到java.awt.HeadlessException，这个错跟软件无关，是根本没有窗口系统。先跑两条命令确认：

# 确认当前会话有没有挂到图形显示上，输出类似 :0 才算有 echo $DISPLAY # 确认 X11 服务真的在响应，没装的话这条命令会提示找不到 xdpyinfo | head -n 5 # 查看本机可用内存，状态空间分析吃内存，低于 4G 要提前留个心眼 free -h

$DISPLAY为空就是没挂上，别急着怪 PIPE。有桌面的机器上正常登录图形会话后它自然有值；远程连过去的话，得用带 X11 转发的方式，或者干脆在有桌面的机器上装。xdpyinfo报command not found，说明 X11 客户端工具没装，装上再验一次。最后那条free -h是给后面跑状态空间分析留的余量参考，可达图一爆炸，内存就是第一道墙。

2.3 目录规划：安装包、工作区、日志三分离

这条是我踩过坑之后养成的习惯。PIPE 默认会把东西往用户主目录和安装目录里塞，一旦你要换版本、清缓存、或者把工程挪到另一台机器，全都搅在一起。我一般这么分：

Linux 下对应换成/opt/pipe/4.3.0、/opt/jdk8、~/petri。关键是路径里不要有空格和中文——这条不是洁癖，PIPE 的启动脚本和一些资源加载对空格路径处理得不干净，我后面避坑章节会专门讲这个。

3. 装 JDK 8 并切好默认版本：三条命令走通

环境确认完就进入实际安装。这一章的做法是“装一套独立的、不打扰系统的 JDK 8”，好处是随时能切回去，出问题也不影响机器上其他项目。三个平台的路子略有差别，我按 Windows、Linux、多版本切换分开写。

3.1 Windows：安装 JDK 8 与设置 JAVA_HOME

Windows 上最稳的是用免安装的压缩包版本，解压到D:\tools\jdk\8，然后用setx写环境变量。别用图形界面一层层点“系统属性”，那种改法经常出现“改了没生效”的玄学，尤其是已经打开的终端。

:: 设置 JDK 根目录，路径按你实际解压位置改 setx JAVA_HOME "D:\tools\jdk\8" :: 把 JDK 的 bin 目录顶到 PATH 最前面，保证优先命中 8 而不是系统里其他版本 setx PATH "D:\tools\jdk\8\bin;%PATH%" :: 新开一个命令行窗口验证，注意必须是新窗口，旧窗口读不到新变量 java -version

setx写的是用户级或系统级的持久变量，当前窗口不生效，这是最常见的“我明明设了却不生效”。PATH里把 JDK 的bin放在最前面是关键，系统里如果还有别的 JDK，java.exe的查找顺序决定一切。java -version的输出应该是1.8.0_xxx，看到17或者21就说明 PATH 顺序没弄对，回去检查有没有更靠前的条目。

还有一个细节：JAVA_HOME的路径不要带尾部分号，也不要写成D:\tools\jdk\8\bin。有些启动脚本会拼%JAVA_HOME%\bin\java.exe，你多写一层bin就变成bin\bin\java.exe，直接找不到。

3.2 Linux：解压安装与 alternatives 注册

Linux 下我用update-alternatives管理，好处是切换有记录、可回滚，不像手动改~/.bashrc那样改着改着就忘了自己改过什么。

# 解压到 /opt，目录名带版本，方便以后并存第二个 sudo mkdir -p /opt/jdk8 sudo tar -xzf jdk8uXXX-linux-x64.tar.gz -C /opt/jdk8 --strip-components=1 # 注册到 alternatives，优先级给 800，数字越大越优先 sudo update-alternatives --install /usr/bin/java java /opt/jdk8/bin/java 800 sudo update-alternatives --install /usr/bin/javac javac /opt/jdk8/bin/javac 800 # 交互式选择当前用哪个，装过多版本时这里会列出全部 sudo update-alternatives --config java # 写进全局环境变量，供启动脚本读取 echo 'export JAVA_HOME=/opt/jdk8' | sudo tee /etc/profile.d/jdk8.sh

--strip-components=1是剥掉压缩包自带的顶层目录，不然解出来会变成/opt/jdk8/jdk1.8.0_xxx/bin，JAVA_HOME就指错了。--install后面那个800是优先级，只有在这台机器同时挂了多个 JDK 时才有意义，数字大的默认被选中。--config java是后悔药，切错了随时能切回来。最后写/etc/profile.d/而不是直接改/etc/profile，是因为这个目录下的脚本按文件名顺序加载，卸载时删一个文件就干净了。

3.3 多版本共存：切回去又能切回来

真正干活的时候往往是“这个项目要 8，那个项目要 17”，所以切换能力比装本身更重要。除了alternatives，我还会准备一个脚本级的兜底方案：不改全局，直接在启动 PIPE 的命令里写死 java 的绝对路径。

# 临时会话内切换，关掉终端就失效，适合只想跑一次的场景 export JAVA_HOME=/opt/jdk8 export PATH="$JAVA_HOME/bin:$PATH" # 验证当前会话实际用的是哪个 which java java -version 2>&1 | head -n 1 # macOS 上对应的是这条，注意输出的是完整路径，直接拿去用 /usr/libexec/java_home -v 1.8

export只影响当前 shell 会话，这是它最大的优点也是最大的缺点——跑完关掉窗口就还原，不会留下“昨天还好好的今天怎么又坏了”的悬案。which java配合java -version两条一起看，能确认路径和版本一致，光看版本号有时会被 shell 的哈希缓存骗过去，必要时hash -r清一下。

注意：Windows 上如果你在 PowerShell 里操作，setx的语法和cmd一致，但$env:JAVA_HOME只在当前会话生效，两者要分清，别混着用。

4. 安装 PIPE 4.3.0：安装包版和 jar 版两条路

JDK 就位之后，PIPE 本身的安装其实只有几分钟。真正需要花心思的是启动方式和启动参数——同一个软件，双击启动和脚本启动的稳定性完全不是一个量级。我下面按“安装包 → jar 直启 → 参数调优”的顺序写，你可以按手上拿到的文件形态选一条路走。

4.1 安装包方式：图形安装器走一遍

如果拿到的是带安装向导的版本，流程很直白：双击，选安装目录，一路下一步。但有两处要停一下手动改。

第一处是安装目录。默认会装到Program Files下面，那个路径带空格，后面如果要用脚本调它，引号一漏就出事。我一般改成D:\tools\pipe\4.3.0，短、无空格、带版本号。

第二处是“是否关联 .jar 文件”。这一项在有些系统上会顺手把系统里所有 jar 的打开方式都改掉，影响其他 Java 程序。我通常取消勾选，改成自己写启动脚本，可控性高得多。

装完之后先去安装目录看一眼结构，确认这几个东西在：

D:\tools\pipe\4.3.0\ ├── PIPE4.3.0.jar # 主程序，实际文件名可能略有差异 ├── lib\ # 依赖库目录，缺了会报 NoClassDefFoundError ├── examples\ # 示例网模型，验证阶段能派上用场 └── docs\ # 使用说明，参数含义可以在这里核对

lib目录尤其要看一眼。有些精简分发版把依赖库合进了主 jar，有些则是分离的，如果lib是空的但主 jar 又不大，那大概率是被裁剪过，启动会缺类。examples目录在验证阶段很有用，里面通常有几个现成的网模型，可以直接打开看 token 怎么流动。

4.2 jar 方式：写一个固定 JDK 的启动脚本

这是我最推荐的方式。核心思路一句话：不管系统默认 java 是几，启动脚本里写死 JDK 8 的绝对路径。Windows 和 Linux 各给一份。

@echo off :: 写死 JDK 8 的路径，绕开系统默认版本 set JAVA_EXE=D:\tools\jdk\8\bin\java.exe set PIPE_JAR=D:\tools\pipe\4.3.0\PIPE4.3.0.jar set LOG_DIR=D:\work\petri\logs :: 日志重定向，出问题时不用靠猜 if not exist "%LOG_DIR%" mkdir "%LOG_DIR%" :: 堆内存、编码、缩放三个参数一次性给全 "%JAVA_EXE%" -Xms256m -Xmx1024m -Dfile.encoding=UTF-8 -Dsun.java2d.uiScale=1.25 ^ -jar "%PIPE_JAR%" >> "%LOG_DIR%\pipe-start.log" 2>&1 :: 记录退出码，非 0 说明启动过程有问题 echo exit code: %ERRORLEVEL% >> "%LOG_DIR%\pipe-start.log"

#!/usr/bin/env bash set -euo pipefail # 三个路径集中定义，换机器只改这一段 JAVA_BIN=/opt/jdk8/bin/java PIPE_JAR=/opt/pipe/4.3.0/PIPE4.3.0.jar LOG_DIR="$HOME/petri/logs" mkdir -p "$LOG_DIR" # exec 让 java 进程取代当前 shell，关窗口时信号能正确传到 JVM exec "$JAVA_BIN" \ -Xms256m -Xmx1024m \ -Dfile.encoding=UTF-8 \ -jar "$PIPE_JAR" >> "$LOG_DIR/pipe-start.log" 2>&1

Windows 那份里^是续行符，注意后面不能有空格，有空格就会把空格当成参数的一部分传进去，症状是莫名其妙的“找不到主类”。%ERRORLEVEL%这一行是给自动化排查用的，退出码 1 通常是参数问题，退出码 0 但界面没出来，那问题在图形环境。

Linux 那份的set -euo pipefail三件套：-e遇错即停，-u引用未定义变量直接报错（防止$JAVA_BIN拼错还静默执行），-o pipefail让管道里任一环失败都算失败。exec的作用是进程替换，不套一层 shell，好处是关终端时 JVM 能收到信号正常退出，不会留下僵尸进程占着内存。

4.3 启动参数：堆内存、编码、缩放三件套

参数不用多，三个够用。但每个都有取舍，配错了会出现“界面能开、一分析就崩”或者“字全糊了”这种半死不活的状态。

-Xmx这个值要看你怎么用。只画网、手动触发变迁，512m 足够；一旦点状态空间分析，尤其是网里带循环结构、并发度高的时候，可达状态数是指数级涨的，1G 都可能不够。我的习惯是先给 1024m，跑分析时看日志有没有OutOfMemoryError，有就翻倍重来。

-Dfile.encoding配错的症状很隐蔽：界面一切正常，保存模型之后再打开，中文注释变成一串问号。这个坑我在跨平台迁移工程文件时遇到过，Windows 默认编码和 Linux 不一致，同一个文件两边打开内容不同，最后统一成 UTF-8 才消停。

提示：sun.java2d.uiScale是 JDK 8 内部参数，不是所有 8u 小版本都支持。设了不起作用的话，退回去调系统的显示缩放，别在这个参数上死磕。

5. 避坑与排查：PIPE 4.3.0 启动阶段的五个高频问题

前面按正常流程走完，多数机器已经能开了。剩下这部分是我实际遇到过、并且每次都有人来问的几类问题，按“现象 → 原因 → 解决”记下来，遇到时直接对号入座，别从头猜。

5.1 双击 jar 一闪而过，命令行也没输出

现象：双击 jar 文件，鼠标转一圈就没下文了；用命令行跑，偶尔能看到一行报错，但窗口瞬间关闭，根本来不及看。

原因：Windows 默认把.jar关联给了某个编辑器或者旧版 java，双击实际执行的不是java -jar；而命令行窗口关闭是因为错误输出被吞了，控制台一闪就退。

解决：别双击，一律用 4.2 的启动脚本，把2>&1重定向到日志文件。日志里能看到完整的异常栈，第一行通常就是答案。如果日志里是Unable to access jarfile，那是路径写错或者文件名对不上，注意实际文件名可能和PIPE4.3.0.jar差几个字符。

5.2 报 NoClassDefFoundError 或 javax/xml/bind 找不到

现象：启动时报java.lang.NoClassDefFoundError: javax/xml/bind/...或者com/sun/java/swing/...，栈顶指向 PIPE 的某个类。

原因：跑在 JDK 11 及以上。Java 从 9 开始模块化，一批老的扩展包从标准库里移出去了，PIPE 4.3.0 依赖它们，自然找不到。

解决：最省事的是改用 JDK 8，按第 3 章重新指一遍JAVA_HOME。如果实在不能降版本，JDK 9/10 可以试--add-modules java.xml.bind，11 以后就得手动把 JAXB 的 jar 丢进lib目录，折腾程度和收益完全不成正比。我的建议很直接：为这个工具单独留一个 JDK 8，别硬刚。

5.3 Linux 上启动即抛 HeadlessException

现象：命令行跑起来立刻退出，日志里是java.awt.HeadlessException，一行都不多。

原因：当前会话没有可用的图形显示。可能是纯命令行的服务器，也可能是JAVA_TOOL_OPTIONS里被人设了-Djava.awt.headless=true。

解决：先echo $JAVA_TOOL_OPTIONS看有没有这个变量在捣鬼，有就清掉。确实是没桌面的机器，要么在有图形界面的机器上装，要么用一个虚拟显示环境把界面跑起来。还有一种情况是DISPLAY变量指向了一个已经关掉的会话，值还在但端口死了，重新登录图形会话即可。

5.4 状态空间分析跑到一半卡死或内存溢出

现象：画网、手动触发变迁都没问题，一点状态空间分析，进度条走到一半不动了，日志里最后一行是OutOfMemoryError: Java heap space。

原因：可达图状态爆炸。网里的并发分支一多，marking 数量是组合增长的，1G 堆很容易撑不住；也可能是模型本身有循环结构，分析器在穷举。

解决：先把-Xmx加到 2048m 或 4096m，看能不能跑完，同时用jconsole或者任务管理器观察内存曲线是否一路顶到上限。能跑完但很慢的，回头检查模型里有没有不必要的自环或者永远不触发的变迁，把网化简之后再分析。这个场景下，一个结构干净的 Petri 网比堆内存值钱得多。

5.5 路径里有空格或中文，启动直接失败

现象：安装目录改成D:\Program Files\...或者放在中文目录下，脚本启动报找不到主类，甚至日志文件都建不出来。

原因：启动脚本和部分资源加载对路径中的空格、非 ASCII 字符处理不干净，参数没有正确加引号就会被拆成两段。

解决：安装路径和工作区路径全部改成纯英文无空格。这条没有技术上的优雅解法，就是别给自己找麻烦。我在 Linux 上见过目录名带空格导致exec那一行直接裂开的案例，排查了半小时才发现问题在路径上。

6. 装完怎么验证：拿一个两库所一变迁的模型跑通仿真

装完不等于跑通。很多人的“装好了”其实只是窗口开出来了，真正点仿真的时候才发现变迁触发不了、token 不动。我用一个最小模型做验证，两条库所、一个变迁、一个 token，五分钟能走完，但能把建模、触发、状态空间三件事全串起来。

6.1 建最小模型并确认 token 真的在流动

新建一张网，画两个库所 P1、P2 和一个变迁 T1，从 P1 到 T1 画一条弧，从 T1 到 P2 再画一条弧。给 P1 加一个 token。这个结构在 Petri 网里叫顺序执行，语义很清楚：T1 满足触发条件后，token 从 P1 迁到 P2。

按下面的顺序核对，每一步都要对得上：

第 2 步如果 T1 一直不可触发，回头检查弧的方向有没有画反——从 T1 指向 P1 是输入弧，方向反了语义就变了，token 永远进不来。第 3 步如果 token 数量对不上（比如两边各一个），那是触发时同时做了新旧 token 的复制，检查一下是不是把弧重复画了两条。

6.2 用可达图和不变式交叉验证

单步触发只能证明界面活着，还得让分析器跑一次。对刚才那个模型执行状态空间分析，预期能拿到两个可达状态：M0 = (1, 0)和M1 = (0, 1)，两条状态之间有一条迁移边。如果分析器返回的状态数不是 2，说明网的结构和你以为的不一样——最常见的是多画了一条弧，或者 token 初始值给错。

再补一个交叉检查：算一下这个网的 P 不变式。对 P1、P2 来说，M(P1) + M(P2) = 1恒成立，token 总数守恒。分析结果里如果出现2或者0，那就不是守恒网，回头查弧。

# 想省事的话，启动时挂一份日志，把分析过程中的关键输出都留下来 # 每次验证完看一眼有没有报错，比事后翻旧账强 tail -n 50 ~/petri/logs/pipe-start.log | grep -iE "error|exception|outofmemory"

这条命令是我每次验证完必跑的一步。没有输出就是干净，有输出就顺着栈往下看，比在图形界面里瞎点强。

从那以后我每次装这类老牌 Java 桌面工具，都强制走一遍“最小模型验证”——不看到 token 真的从 P1 挪到 P2，我就不认为环境装完了。软件能启动和软件能干活是两回事，中间隔着的往往就是一个 JDK 版本、一个路径空格、或者一个没配的堆内存参数。那份 PIPE 4.3.0 的安装包我放在常用的工具目录里，配好的启动脚本和这份最小模型也一起留着，换机器的时候直接拷过去改三个路径就能用。希望帮到你。

本文还有配套的精品资源，点击获取