简介：PlatEMO v2.0（2019-3）是一款面向多目标优化研究与教学的开源平台，专为求解多个相互冲突目标的决策问题而设计，适用于科研人员、工程师和高校师生。该资源包共593个文件，以MATLAB的m脚本、md说明文档、txt配置、mat数据文件和pdf手册为主，压缩包大小约1.45MB。平台内置NSGA-II、NSGA-III、MOEA/D、SMS-EMOA等经典与前沿算法，提供可视化、实验管理、可扩展算法接口和标准测试问题库，支持用户自定义新算法并与现有方法对比。已有697人学习下载。借助其中模块化实验脚本和文档，可快速掌握算法实现、完成参数调整、性能评估和教学演示，是多目标优化研究和算法测试的高效工具。
1. PlatEMO v2.0：一个装了就能跑进化多目标实验的 Java 平台
如果你正在做进化多目标优化方向的实验，大概率经历过这种场景：算法代码写了一堆，跑完一批数据之后还要自己写脚本算 IGD、HV，再调 matplotlib 画帕累托前沿图，中间任何一步出了问题，前面几十个小时的算力就白费了。PlatEMO v2.0 就是冲着这个痛点来的——一个基于 Java 的进化多目标优化实验平台，把算法库、问题库、性能指标、可视化面板全部集成到同一个 GUI 里，装上 JDK 就能直接跑。它内置了 NSGA-II、MOEA/D、SPEA2 等一批经典算法和 ZDT、DTLZ、WFG 等标准测试问题，你要做的只是选算法、选问题、点运行，平台自动把指标算好、图给你画好。适合两类人：一是刚入门多目标优化、想快速对比经典算法表现的学生，二是需要批量做实验、又不想每次重写评估流程的科研开发者。
2. 模块架构拆解：算法、问题、指标三大抽象类如何互相配合
PlatEMO 的核心设计思路是"面向抽象类编程"。整个平台被拆成算法、问题、指标、工具、GUI 五个逻辑模块，模块之间通过少量抽象基类通信，几乎每个功能都可以替换实现而不影响其他模块。
2.1 顶层目录与五个包
下载解压后的工程目录大致如下，我按源码包路径来说：
platemo/algorithm：存放所有多目标进化算法，NSGA-II、MOEA/D、IBEA、HypE 等都在这里。每个算法一个子包，包内是算法主类和配套算子。platemo/problem：存放测试问题，ZDT、DTLZ、WFG、LZ09 等系列以及部分真实工程问题。每个问题实现统一的Calculate接口。platemo/indicator：性能指标计算模块，IGD、HV、GD、SPREAD、EP 等常见指标都封装成独立类。platemo/gui：JavaFX 图形界面，负责参数表、运行按钮、结果图表的展示。platemo/core：核心抽象类，包括Algorithm、Problem、Solution、Population，以及工具类如FileUtils、MetricsUtils。
这个分层的核心原则是：算法只认识Problem和Solution，不关心 GUI 怎么显示；问题只负责给定一个决策变量算出目标值；指标只接收一组解集和真实前沿文件，返回一个数值。三层互相隔离，所以你可以单独替换任何一层。
2.2 Algorithm 抽象类：调度器与迭代器的两种身份
Algorithm是整个平台最关键的抽象类。它负责管理优化流程：生成初始种群、迭代进化、收集每代的结果、输出最终种群。从设计模式角度看，它既是"模板方法"的调用者（定义 run 流程骨架），又是"策略"的载体（具体的进化操作由子类实现）。
核心方法有三个：initialize（初始化，通常用于随机生成初始种群）、run（主循环，驱动迭代直到满足终止条件）、getResult（返回最终种群，供指标计算和绘图使用）。run是模板方法，典型流程如下：
@Override public void run() { // 初始化种群，populationSize 是算法参数，问题维度从 problem 获取 Population population = initialize(problem, populationSize); // 主循环：未达到最大评估次数时持续迭代 while (evaluations < maxEvaluations) { // 1. 选择父代 Population parents = selection(population); // 2. 交叉变异生成子代 Population offspring = crossoverAndMutation(parents); // 3. 环境选择，保留优秀个体 population = environmentalSelection(population, offspring); // 4. 更新评估计数 evaluations += offspring.size(); } // 运行结束，保存结果供指标计算使用 outputResult(population); }这段模板方法的价值在于：你新写一个算法只需要实现selection、crossoverAndMutation、environmentalSelection三个算子，平台调度、终止判断、结果收集都由父类完成。参数populationSize和maxEvaluations是算法配置，在 GUI 参数面板里就能调，不需要改代码。
2.3 Problem 与 Solution：目标函数计算是平台的"黑匣子"
Problem是所有测试问题的父类。它有一组描述问题特征的方法：getNumberOfVariables返回决策变量个数，getNumberOfObjectives返回目标个数，getLowerBound和getUpperBound返回变量取值范围。真正核心的是一个抽象方法Calculate：
public abstract void Calculate(Solution solution) throws Exception;这个方法的语义是：把 solution 中的决策变量解码成真实变量值，然后计算出各个目标值，写回 solution 对象里。平台不关心你内部是用了数学公式、仿真程序还是外部调用，只要最终把目标值填进solution.getObjective(i)就行。对于 ZDT1 这类数学测试问题，实现就是几行公式；如果你想接入自己的工程仿真程序，也只需要在Calculate里写调用逻辑。
Solution是一个数据载体，保存三部分信息：决策变量数组、目标函数值数组、约束违反度数组。算法在做进化操作时只动决策变量，真正求值要通过problem.Calculate(solution)，这样设计的好处是算法代码里不会出现任何问题相关的数学细节，替换问题零成本。
2.4 一次完整执行链路：从点击按钮到指标输出
把上面几个类的协作串起来看，一次实验的执行链路是这样的：
- GUI 层接收用户选择的算法、问题、参数，创建
Algorithm实例和Problem实例。 - 调用
algorithm.run()启动优化。 run内部不断调用problem.Calculate(solution)给种群个体求值。- 达到终止条件后，
algorithm.getResult()返回最终的非支配解集。 - 平台把解集传给指标模块：
Indicator读取真实帕累托前沿文件（如 ZDT1.pf），计算 IGD、HV 等指标。 - 最后 GUI 把解集和真实前沿绘制到图表中，同时把指标值写入结果表格。
这个链路把实验流程中"跑算法、算指标、出图"三件事串成了流水线，比手写脚本逐个环节调用要省事得多。理解了这个链路，后面做二次开发时你就能知道该改哪一环。
3. 把平台跑起来：环境准备、GUI 操作与第一个 NSGA-II 实验
PlatEMO 是纯 Java 项目，运行环境相对简单。但正因为简单，踩坑往往出在环境细节上。这一章从零开始讲怎么把它跑起来。
3.1 JDK 环境与内存参数
v2.0 版本使用 JavaFX 做界面，建议用 JDK 8 或 JDK 11 运行。JDK 8 自带 JavaFX 组件，JDK 11+ 需要单独引入 JavaFX 依赖，配置成本略高。我个人习惯用 JDK 8，一方面兼容性最稳，另一方面大部分 Linux 服务器上默认就是它。
内存参数方面，多目标优化实验的种群规模通常在 100~500，迭代几千代，单个解的内存占用不大。但如果你的测试问题维度较高（决策变量上百个），或者同时跑多个实验窗口，默认堆内存可能不够。我一般会这样设置：
# 设置堆内存上限为 4GB，预留足够空间给种群和解集存储 java -Xms512m -Xmx4g -jar PlatEMO.jar-Xms是初始堆大小，-Xmx是最大堆大小。如果实验规模特别大，比如种群 1000、迭代 10000 代，建议-Xmx8g。跑批量的命令行实验时，这个参数尤为重要，否则跑一段时间就 OOM 那就真叫一个崩溃。
3.2 三种运行方式：GUI、命令行批量与直接调用
第一种方式是双击启动 GUI，适合交互式探索。界面左侧是算法列表，中间是参数配置区，右侧是绘图区。点开任一算法，参数表自动加载，改完点运行即可。
第二种是命令行批量实验方式。PlatEMO 提供了实验模块，你可以先配置好要运行的算法集合、问题集合和独立运行次数，然后后台批量执行，适合挂机跑一晚上。在platemo/gui/Main里可以用Experiment类指定实验配置，也可以在配置文件中写好参数后通过java -cp PlatEMO.jar platemo.experiment.ExperimentMain启动。
第三种方式是 IDE 中直接运行。导入源码到 Eclipse 或 IDEA，定位到platemo/gui/Main类，右键 Run 就行。这种方式适合后面要打断点调试算法逻辑的场景。三种方式的核心区别只在于入口不同，底层走的都是同样的算法管道。
3.3 第一个实验：在 ZDT1 上跑 NSGA-II
打开 GUI 后，在算法列表里选NSGA-II，问题列表里选ZDT1，你会发现参数面板自动更新。默认参数一般是种群大小 100，最大评估次数 10000。这两个参数对 ZDT1 这种双目标问题来说是够用的。
点击运行后，你会看到绘图区实时画出帕累托前沿，散点逐步逼近真实前沿曲线。跑完后结果表格里会出现本次运行的指标值，包括 IGD、HV 等。整个过程十几秒就结束，这应该是你第一次感受到"平台化"实验的爽快：不用自己写循环迭代代码，不用担心画图坐标轴范围，一切都已经包装好了。
# 如果你想不打开界面直接跑一个最小的 NSGA-II + ZDT1 实验，可以这样： java -cp PlatEMO.jar platemo.experiment.ExperimentMain -algorithm NSGA-II -problem ZDT1 -runs 1 -evaluation 10000参数-runs 1表示只独立运行一次，-evaluation 10000表示最大评估次数。实际做实验时建议-runs 30甚至更多，才能让指标统计有意义。
4. 实验设计实操：批量对比、指标解读与结果导出
平台跑通只是起点，真正做实验设计时你需要理解一批参数和指标口径。这章讲透怎么用 PlatEMO 做一组可发表级别的实验配置。
4.1 参数设置与独立运行次数的意义
PlatEMO 参数面板里有几个关键参数：populationSize（种群大小）、maxEvaluations（最大评估次数）、runs（在批量实验里的独立运行次数）。种群大小决定了每代保留多少个体，评估次数决定总计算预算。这两个参数在不同论文里口径不同，有的用最大代数，有的用最大评估次数，PlatEMO 用的是评估次数，因为不同算法每代产生的子代数量不一样，用评估次数做终止条件更公平。
独立运行次数是另一个容易忽略的点。多目标进化算法是随机算法，一次运行的结果只是随机过程的一个样本，跑一次就下结论纯属玄学。规范做法是同一配置独立运行 20~30 次，取均值和标准差。PlatEMO 的批量实验模块会记录每一次运行的指标值，最后汇总成均值±方差的表格，这正是论文里常见的报告格式。
4.2 IGD、HV、GD、Spread 指标怎么选、怎么读
PlatEMO 内置了多个指标，最常用的是 IGD 和 HV。
IGD（反世代距离）衡量算法得到的解集与真实帕累托前沿之间的平均距离。数值越小，说明解集越接近真实前沿，既兼顾收敛性也兼顾分布性。画图时通常画 log 坐标，因为不同算法的 IGD 可能差几个数量级。
HV（超体积）衡量解集在目标空间里覆盖的体积，数值越大越好。HV 的优势是不需要知道真实前沿，只需要一个参考点，因此适合真实前沿未知的问题。PlatEMO 内部默认用 wfg 平台的参考点生成方式，一般不需要手动干预。
GD 只衡量收敛性不看分布性，Spread 只衡量分布性不看收敛性，这两个指标单独用时需要谨慎，因为它们可能给出片面的结论。比如一个算法所有解都挤在真实前沿的某个局部区域，GD 可能很小，但 Spread 会很大，这种时候你就要结合两个指标一起判断。
4.3 结果导出与绘图：数据表怎么变成论文图
跑完批量实验后，PlatEMO 会在结果目录下生成.xlsx文件，里面按算法、按问题、按运行次数记录了每个指标值。这个 Excel 文件就是论文数据表的数据源。我一般会进一步用 Python 脚本读取这个 xlsx，然后做显著性检验，比如 Wilcoxon 秩和检验，比较两个算法是否有统计差异。
绘图方面，GUI 的绘图区支持保存当前画出的帕累托前沿图，输出为 png 或 eps 格式。做论文时我通常还会导出一份解集数据，用 matplotlib 重新画图，因为 PlatEMO 默认配色和线型不太符合期刊要求。导出的方式是在结果目录里找到对应运行次数的解集文件，每一行是一个解，格式为"决策变量 + 目标值"，这样你可以用任何工具重新可视化。
5. 避坑与排查：跑 PlatEMO 时最常见的五个问题
任何平台都有它的脾气，PlatEMO 也不例外。这里把我在使用过程中真实遇到过的五类问题整理出来，每条都按"现象 → 原因 → 解决"的顺序写，你可以直接对号入座。
5.1 内存溢出：实验跑了一半突然 OOM
现象：批量实验挂机跑了两三个小时，控制台突然报OutOfMemoryError: Java heap space，之前的进度全丢。
原因：PlatEMO 的默认堆内存较小，批量实验时每个算法每次运行都保留解集快照，累积在内存里，几小时后堆就满了。
解决：启动时显式指定大堆内存，-Xmx8g或更高。同时注意，如果问题维度高或种群大，单次实验的内存开销也会明显上升。还有一个排查手段是在 GUI 的help菜单里看当前 JVM 的可用内存，确认设置是否生效。
5.2 算法不出图：进度条走完，绘图区空白
现象：运行结束后绘图区没有任何点，但指标表格里某些指标显示 NaN 或者无穷大。
原因：最可能是算法生成的解集全是不可行解，目标值没有被正确填充。常见于自带约束的问题，或者你在自定义问题里Calculate方法写错了，目标值没写入Solution对象。
解决：先切到真实前沿显示，确认是前沿文件路径问题还是解集本身异常。如果是自定义问题，在Calculate里加一行临时打印输出，把solution.getObjective(0)打出来看一眼，通常能立刻发现问题。
5.3 跨平台路径分隔符导致测试问题加载失败
现象：在 Windows 上跑得好好的实验，拷到 Linux 服务器上跑，提示找不到ZDT1.pf文件，指标计算全是 NaN。
原因：代码里如果用了硬编码的\路径分隔符，Windows 下没问题，Linux 下就找不到文件了。PlatEMO 内部大部分路径处理用的是File.separator，但自定义脚本或外部调用容易踩这个坑。
解决：检查你添加的自定义问题或指标类，统一用System.getProperty("file.separator")或者Paths.get()拼接路径。第三方库或脚本里的硬编码路径也一并检查。
5.4 JDK 9+ 运行报 ClassNotFoundException: javafx
现象：用 JDK 11 或更高版本启动 GUI，直接报java.lang.NoClassDefFoundError: javafx/application/Application。
原因：JDK 9 以后 JavaFX 从 JDK 中拆出来成为独立模块，不再随 JDK 分发。PlatEMO 的 GUI 入口依赖 JavaFX，因此运行环境里没有它就是启动不了。
解决：两个方案，要么装 JDK 8，要么给 IDE 或命令行增加 JavaFX 模块依赖。我个人的建议是做实验时统一用 JDK 8，省心，避免 JavaFX 版本差异带来的后续兼容问题。
5.5 自定义算法类没有出现在算法列表里
现象：自己写了个算法类放进algorithm包，编译成功，但打开 GUI 算法列表里看不到它。
原因：PlatEMO 扫描算法列表依赖注解或者类扫描机制。如果你新加的类没有加对应的@Algorithm注解，或者 IDE 没有把新类编译到输出目录，GUI 根本发现不了它。
解决：确认你的类注解写法正确，然后 rebuild 整个项目，切记不是只编译当前文件。IDE 的增量编译经常漏掉新文件，手动 clean 后重新编译基本能解决。
6. 二次开发实战：把自定义算法接入平台并验证
平台最有价值的部分就是扩展机制。这章带你写一个最简算法并接进 PlatEMO，跑完整个验证流程。
6.1 注册机制：算法如何被平台扫描到
PlatEMO 的算法列表是从algorithm包下通过反射自动扫描的。具体来说，你写的算法类需要继承Algorithm抽象类，并加上平台约定的注解。注解里填写算法名称和描述，GUI 就会把这个名字加到下拉列表里。
@Algorithm(name = "RandomSearchMO", description = "随机搜索多目标版本，用于演示扩展") public class RandomSearchMO extends Algorithm { // 算法体实现见下节 }扫描机制决定了两个约束：类必须是public，必须有无参构造或者接受Problem的构造方法。GUI 创建算法实例时，会把当前选中的Problem对象传给你。
6.2 手写一个最简算法：随机搜索并输出非支配解
下面这个类是我实际写过的演示版本，去掉复杂算子，只保留随机生成和求值逻辑。代码结构完全符合 PlatEMO v2.0 的接口要求：
@Algorithm(name = "RandomSearchMO", description = "随机搜索多目标版") public class RandomSearchMO extends Algorithm { // 种群大小作为公开字段，GUI 参数面板可以直接配置 public int populationSize = 100; public RandomSearchMO(Problem problem) { super(problem); } @Override public void run() { // 创建种群对象，size 为本算法参数，problem 来自父类 Population population = new Population(populationSize); Problem problem = getProblem(); // 循环采集随机个体 for (int i = 0; i < populationSize; i++) { // 生成随机决策变量，变量个数由问题决定 double[] vars = problem.getBoundsSampling(i); Solution solution = new Solution(problem, vars); // 关键一步：调用问题类的求值方法，填充目标值 problem.Calculate(solution); population.add(solution); } // 把这一代作为最终结果输出，供指标计算使用 outputResult(population); } }代码逻辑说明：getBoundsSampling是Problem提供的随机采样方法，按照每个决策变量的上下界生成随机值；Solution构造时把决策变量数组传入，创建了一个未求值的解；problem.Calculate(solution)是关键调用，它触发问题类计算目标值并写回 solution 对象。全部个体求值完成后，调用outputResult把种群交给平台进行非支配排序和指标计算。
参数说明：populationSize是唯一可控参数，GUI 参数面板通过反射扫描 public 字段自动显示出来。你可以直接在面板里把它改成 200、500，而不需要修改代码。要注意的是，随机搜索没有真实的选择、交叉、变异算子，所以它不会收敛到前沿，只是用于验证平台接口。你在这个骨架里加上选择、交叉、变异过程，就演化成了真正的进化算法。
6.3 验证流程与后续扩展方向
算法类写完后，在 IDE 里 rebuild 项目，重新打开 GUI，你会看到算法列表里多了一项RandomSearchMO。选 ZDT1 问题跑一次，观察绘图区有没有点出现——只要有解，就说明你的算法接入成功，平台作图、指标计算都工作了。
接下来你可以做的扩展有这几个方向：一是替换求值逻辑，比如接入自己的仿真器，这只需要修改Calculate里调用外部程序的代码；二是增加指标，继承Indicator类实现getIndicatorValue方法，平台会自动把它加入指标列表；三是接入真实工程问题，把决策变量映射到实际设计参数，目标值换成仿真返回结果。我自己的经验是，从最简随机搜索开始，跑通了整个链路之后再往里面加真实算子，比一上来就写完整算法要顺手得多。从那以后我每次做新算法，都强制先跑一遍这个最小接入流程，确保环境没有问题，省得后面写了几百行代码才发现是接口没对上。希望帮到你。
本文还有配套的精品资源，点击获取
