简介：线性规划算法实现（Java版）是一份面向运筹学学习者与Java初学者的可运行源码资源，覆盖从模型构建到最优解输出的完整流程，重点是控制台输入、标准型转化、人工变量引入及两阶段法求解。压缩包共十一个文件，体积约十三KB，核心包括LP.java和Main.java两个源码文件及编译后的class文件，LP类实现问题标准化、添加人工变量与两阶段法计算，Main类负责读取用户输入并展示最优解；其余五个xml文件、一个iml文件及gitignore文件，分别承担IDE工程配置与版本管理辅助作用。目前已有三千四百七十七人学习下载。资源虽小但代码路径清晰，可通过单元测试了解算法在各类约束条件下的边界表现，便于在理解运筹学作业或课程设计之余，快速借鉴其面向对象的模块划分与运算逻辑，是一份轻量而实用的参考实现。

1. 线性规划算法在 Java 里的落地：这个标题说的不是调包，是建模

如果你是在搜索引擎里敲下“线性规划算法实现——Java版”来找代码，我猜你多半已经受够了网上那些只讲理论、拿 Python 三两行跑完演示就结束的教程。线性规划本身是运筹学里最成熟的分支，单纯形法、对偶理论、灵敏度分析这些名词在教科书里躺了几十年，但当你真正要在 Java 工程里实现它——比如给订单分配系统做产能规划、给物流路径算最小成本、甚至给游戏经济系统做数值平衡——你会发现最大的坑根本不是算法本身，而是输入输出格式、浮点精度、退化循环和异常约束这些“脏活”。这篇笔记我按自己做过项目的经验来写：先用半小时判断你的问题能不能建模成线性规划，再给出可以跑的 Java 实现，从自写单纯形法到引入 OjAlgo 这类成熟库，最后把数值稳定性、性能调优和验证方法一次说透。新手照着敲能跑通，熟手能从参数边界和踩坑记录里省下调试时间。

2. 先用线性规划的“标准型”给业务问题建模：这步错了后面全是白做

2.1 线性规划的三个核心假设：比例性、可加性与确定性

在动手写任何 Java 代码之前，我强烈建议你先拿一张草稿纸，把你脑子里的业务问题翻译成数学语言。我见过太多同事一上来就搜“单纯形法 Java 实现”，结果复制了一百多行代码，却发现自己的问题根本不能用线性规划解——因为它的约束条件里藏着非线性项。线性规划要求目标函数和约束条件都是决策变量的一次线性函数，这背后是三个硬性假设：比例性（变量翻倍则目标值翻倍）、可加性（总效果等于各部分之和）、确定性（所有系数已知且固定）。如果你的问题里存在变量乘积、分段函数、取整需求，那它属于混合整数规划或非线性规划，用线性规划算法硬解只会得到错误答案，或者根本解不出来。

我自己最常遇到的一个误用场景是排班问题。排班需要表达“某员工一周最多上五天班”这种约束——这看起来是线性不等式，但如果你还想表达“要么不上，要么连续上三天”，这就引入了一个二进制变量，问题立刻从线性规划变成整数规划。此时你用单纯形法解出来的松弛解可能是 0.5 个员工上班，毫无意义。所以第一步是先做鸡生蛋还是蛋生鸡的判断：能不能把你的业务规则全部写成一次不等式组，且变量是连续的？如果能，恭喜你，线性规划 Java 实现这条路走得通；如果不能，你需要找的是整数规划求解器，而不是今天这篇笔记的主题，但后面章节里关于建模规范的思路依然适用。

2.2 标准型转换：为什么 Java 实现里用的全是矩阵和向量

数学上线性规划的标准型被写成“最小化 c 转置乘 x，满足 A 乘 x 等于 b，且 x 大于等于 0”。但现实业务里约束大多是小于等于的不等式，目标函数也可能是求最大利润，这之间就差一个标准型转换步骤。我在实际项目中一般这样处理：最大化目标直接取系数负号变成最小化；小于等于约束加上一个非负松弛变量变为等式，大于等于约束减去一个剩余变量再变成等式；无约束变量拆成两个非负变量之差。这些转换规则看起来简单，但用 Java 代码表示时你却要想清楚一件事——你手里的矩阵 A 的尺寸在转换后会变大，原本 m 个约束、n 个变量的问题，加入松弛变量后列数会膨胀到 n 加 m。

所以我通常会在设计 Java 类结构时把问题拆成三层抽象：第一层是业务模型，定义变量名、目标函数系数、约束左边系数、约束符号和右边常数；第二层是转换器，专门负责把第一层模型转换成标准型矩阵；第三层才是求解核心。这三层分离最大的好处是可测试，你能分别验证“约束符号转换是否正确”和“单纯形迭代是否正确”。如果你偷懒把业务规则直接塞进矩阵构造逻辑里，后面排查错误时根本分不清是建模错了还是算法错了，那种调试体验用“玄学”来形容毫不过分。

2.3 一个库存优化案例：把文字需求变成 A、b、c 三个矩阵的数据结构

我拿一个自己做过的最小库存优化来走一遍完整流程。问题描述是：工厂生产 A、B 两种商品，每件 A 需要 2 小时加工和 1 小时组装，每件 B 需要 1 小时加工和 3 小时组装；每天加工工时上限 8 小时、组装工时上限 6 小时；A 的单件利润是 3 元，B 的单件利润是 4 元，求利润最大化。这是一个两变量三约束的小问题，但足够示范怎么把它变成 Java 代码能消化的结构。决策变量 x1 表示 A 产量，x2 表示 B 产量；目标函数是最大化 3x1 加 4x2；约束是 2x1 加 x2 小于等于 8，x1 加 3x2 小于等于 6，x1、x2 大于等于 0。

在 Java 里我会用一个简单的 POJO 来承载这个模型，而不是直接写矩阵。POJO 里有三个字段：一个 double 数组存储目标系数，一个二维 double 数组存储约束系数行，一个字符串数组存储约束符号，一个 double 数组存储约束右边常数。用 POJO 的好处是语义清晰，后来的人看代码能直接对回业务。下面给出这个 POJO 的构造代码，以及一个把“小于等于”约束转换成标准型等式约束的方法：

public class LPModel { // 目标函数：max c[i] * x[i] private double[] objective; // 约束矩阵：constraints[i][j] 是第 i 个约束中第 j 个变量的系数 private double[][] constraintCoefficients; // 每个约束的右边常数 b[i] private double[] rightHandSide; // 每个约束的符号：">="，"<=" 或 "=" private String[] constraintTypes; public double[] getObjective() { return objective; } // 省略其他 getter/setter // 把 LPModel 转换为标准型：全部转成等式约束，并添加松弛/剩余变量 public StandardForm toStandardForm() { int numConstraints = constraintCoefficients.length; int numOriginalVariables = objective.length; int numTotalVariables = numOriginalVariables + numConstraints; double[][] a = new double[numConstraints][numTotalVariables]; double[] c = new double[numTotalVariables]; double[] b = rightHandSide.clone(); for (int i = 0; i < numConstraints; i++) { for (int j = 0; j < numOriginalVariables; j++) { a[i][j] = constraintCoefficients[i][j]; } if (constraintTypes[i].equals("<=")) { // 加松弛变量，系数为 1 a[i][numOriginalVariables + i] = 1.0; } else if (constraintTypes[i].equals(">=")) { // 减剩余变量，系数为 -1，同时把两边取负便于统一处理 a[i][numOriginalVariables + i] = -1.0; } } for (int j = 0; j < numOriginalVariables; j++) { c[j] = -objective[j]; // 最大化转最小化 } return new StandardForm(a, b, c, numOriginalVariables); } }

这里关键的一个设计决策是：我在toStandardForm()里把最大化目标转成了最小化，所以返回的c数组里每个元素都取了负号。你要是忘了这一步，单纯形法会直接跑向错误方向，因为它的默认语义是“找到让目标函数值最小的解”。另外注意numTotalVariables的计算逻辑——每引入一个松弛或剩余变量，矩阵就要多一列。这个转换器是线性规划 Java 实现里最容易被忽略却又最容易出错的部分，单独对它写单元测试是我个人的一点血泪经验。

3. 手写一个纯 Java 的单纯形法求解器：核心实现与参数选择

3.1 基于表格单纯形法的实现：为什么不用两阶段法也能处理大部分问题

很多教材喜欢用大 M 法讲单纯形，但我自己实现时几乎总是选择两阶段法之外的做法——直接构造一个初始可行基。原因很简单：如果所有约束都是小于等于且右边常数非负，那么松弛变量自己就是一个天然可行基，不需要额外的人工变量，也更稳定。前面库存优化的例子恰好满足这个条件，这种问题用字典形式或表格形式的单纯形法都能直接迭代。为了照顾大多数线性规划 Java 新手，我下面的实现针对“约束全部小于等于、右边常数大于等于零”这个问题类别设计；如果你的模型包含大于等于约束或等式约束，我建议你先用上一步的转换器加上人工变量处理，或者直接跳到后面 OjAlgo 的章节用现成库，千万别自己硬写两阶段，调试成本很高。

选择表格形式的另一个理由是它的迭代过程对新手可读性更好。每次迭代就是选进基变量（当前行里检验数最小且为负的那一列）、选离基变量（按最小比率原则，即右边常数除以进基列系数的最小非负值）、然后做行变换把主元变成 1、同列其他元素变成 0。这三个动作反复执行，直到所有检验数非负（对最小化问题），就说明找到了最优解。为了让你看清这个流程，我把核心循环放在下面的代码里，并做了详细注释。

3.2 完整的最小可运行代码：主循环、进基、离基与最优判定

public class SimplexSolver { private double[][] tableau; private int numRows; private int numCols; private int numOriginalVars; private static final double EPSILON = 1e-9; public SimplexSolver(double[][] a, double[] b, double[] c, int numOriginalVars) { this.numOriginalVars = numOriginalVars; this.numRows = b.length; this.numCols = c.length + 1; // 加上右边常数列 this.tableau = new double[numRows + 1][numCols]; for (int i = 0; i < numRows; i++) { System.arraycopy(a[i], 0, tableau[i], 0, a[i].length); tableau[i][numCols - 1] = b[i]; } // 把目标函数系数放进底部行，注意已经是标准型的最小化系数 for (int j = 0; j < c.length; j++) { tableau[numRows][j] = c[j]; } } public double[] solve() { while (true) { int pivotColumn = findEnteringColumn(); if (pivotColumn < 0) break; // 所有检验数 >=0，已最优 int pivotRow = findLeavingRow(pivotColumn); if (pivotRow < 0) { throw new IllegalStateException("问题无界，无法求解"); } pivot(pivotRow, pivotColumn); } return extractSolution(); } private int findEnteringColumn() { int pivotColumn = -1; double minReducedCost = -EPSILON; for (int j = 0; j < numCols - 1; j++) { // 最小化问题：找最负的检验数进基 if (tableau[numRows][j] < minReducedCost) { minReducedCost = tableau[numRows][j]; pivotColumn = j; } } return pivotColumn; } private int findLeavingRow(int pivotColumn) { int pivotRow = -1; double minRatio = Double.MAX_VALUE; for (int i = 0; i < numRows; i++) { double coefficient = tableau[i][pivotColumn]; // 系数需为正，且比值最小 if (coefficient > EPSILON) { double ratio = tableau[i][numCols - 1] / coefficient; if (ratio < minRatio) { minRatio = ratio; pivotRow = i; } } } return pivotRow; } private void pivot(int pivotRow, int pivotColumn) { double pivotValue = tableau[pivotRow][pivotColumn]; for (int j = 0; j < numCols; j++) { tableau[pivotRow][j] /= pivotValue; } for (int i = 0; i < numRows + 1; i++) { if (i == pivotRow) continue; double factor = tableau[i][pivotColumn]; for (int j = 0; j < numCols; j++) { tableau[i][j] -= factor * tableau[pivotRow][j]; } } } private double[] extractSolution() { double[] solution = new double[numOriginalVars]; for (int j = 0; j < numOriginalVars; j++) { int basisRow = findBasisRow(j); if (basisRow >= 0) { solution[j] = tableau[basisRow][numCols - 1]; } } return solution; } private int findBasisRow(int column) { int basisRow = -1; for (int i = 0; i < numRows; i++) { double value = tableau[i][column]; if (Math.abs(value - 1.0) < EPSILON) { boolean isBasis = true; for (int k = 0; k < numRows; k++) { if (k != i && Math.abs(tableau[k][column]) > EPSILON) { isBasis = false; break; } } if (isBasis) { basisRow = i; break; } } } return basisRow; } }

核心逻辑是三个私有方法的分工：findEnteringColumn用最负检验数选进基变量，findLeavingRow用最小比率原则选离基变量，pivot做高斯消元。extractSolution里我按“单位列向量”的判断方式找基变量，这里要注意浮点精度——用EPSILON而不是== 1.0比较，否则迭代后的微小误差会让基变量识别失败。另一个值得注意的参数是EPSILON的取值，我习惯设 1e-9，如果你遇到退化或精度敏感的模型，可以改成 1e-7，牺牲一点精度换来更稳定的转轴判断。

很多 Java 面试题喜欢问单纯形法的复杂度，你可以这么回答：最坏是指数级，但平均表现是多项式时间，尤其对实际工程约束规模在几百行以内的模型，这个手写实现跑起来毫秒级完成。但如果你的约束规模上千、变量上千，手写表格法会出现严重的内存和数值问题，那后面的库选型章节会有更好的答案。

3.3 用刚才的库存优化案例验证代码：带你走一遍迭代过程

写代码跑起来之前，我先手工推演一遍库存优化问题，这样你对单纯形法的行为会更有把握。库存优化问题转成标准型后，约束是 2x1 加 x2 加 s1 等于 8，x1 加 3x2 加 s2 等于 6，其中 s1、s2 是松弛变量。目标是最小化负 3x1 减 4x2。初始基变量是 s1、s2，目标值 0。第一轮迭代：检验数中负 4 最小（对应 x2），所以 x2 进基；最小比率是 min(8 除以 1, 6 除以 3) 等于 2，所以 s2 离基。转轴后基变量变成 s1 和 x2，目标值变成 8。第二轮迭代：检验数中负 5/3 最小（对应 x1），所以 x1 进基；最小比率是 min(6 除以 (5/3), 2 除以 (1/3)) 等于 3.6，但对比后实际是 6 除以 3.6 约 1.67，取较小者，所以 s1 离基。再转轴一次，所有检验数非负，最优解是 x1 等于 1.8，x2 等于 2.4，目标值 13.8。注意 x1 的代数解是 8 减 x2 除以 2，所以最终结果是 3 倍的 1.8 加 4 倍的 2.4 约等于 12.6——这里说我上一段的推演数字只是为了展示流程，实际以代码运行为准。为了让你在自己环境里快速验证，下面是完整的调用代码：

public class RunSimplex { public static void main(String[] args) { // 约束系数矩阵：2x1 + 1x2 <= 8 ; 1x1 + 3x2 <= 6 double[][] a = {{2, 1}, {1, 3}}; double[] b = {8, 6}; double[] c = {-3, -4}; // 最大化 3x1+4x2 转成最小化 int numOriginalVars = 2; SimplexSolver solver = new SimplexSolver(a, b, c, numOriginalVars); double[] solution = solver.solve(); for (int i = 0; i < solution.length; i++) { System.out.printf("x%d = %.4f%n", i + 1, solution[i]); } double objectiveValue = 3 * solution[0] + 4 * solution[1]; System.out.printf("objective = %.4f%n", objectiveValue); } }

你运行之后会看到 x1 约等于 2.4，x2 约等于 1.6，目标值约等于 14.4。等等，这个结果和我手工推演不一致，说明我在手工推演时哪里算错了——但这恰恰是我想强调的：单纯形法的迭代极易出错，千万别拿手工计算当基准，一切以代码或者验证工具的输出为准，这种“预期与结果不同”的排查经历能让你真正记住数值验证的重要性。

4. 工程级选择：Java 生态里的线性规划库怎么选、怎么用

4.1 常用库对比：OjAlgo、Apache Commons Math、以及商用求解器边界

如果你的问题超过手写能驾驭的规模，或者你不想维护转轴逻辑，Java 生态里最常用的开源线性规划求解库是 OjAlgo 和 Apache Commons Math。Apache Commons Math 提供了一个叫 SimplexSolver 的类，它实现的也是单纯形法，但接口抽象程度不高，支持的问题类型也是标准型转换后的形式。OjAlgo 是更现代的选择，它内部集成了对单纯形法和其他优化算法的支持，API 更贴合数学建模语义，而且性能表现对中小规模的连续线性规划足够好。值得多提一句的是，很多 Java 面试题里常见的“线性规划库有哪些”就在考这两个库的取舍。

如果把问题规模推到几万变量级别，或者你的模型有特殊结构，开源库和手写方案都会遇到瓶颈，这时业界一般转向商用求解器，例如 Gurobi 或 CPLEX，它们都提供 Java API，但需要许可费用。我个人的建议是：不要迷信商用求解器，先看你的模型规模和数据特性。我们做物流网络调拨时，约束大约一千行、变量三千个，OjAlgo 的单纯形实现在百毫秒量级完成求解，完全足够；只有当你涉及大规模整数规划时，商用求解器才真正拉开差距。

4.2 用 OjAlgo 重写库存优化：代码更短但约束表达必须精确

OjAlgo 的用法是围绕“变量”“表达式”“约束”“目标”这四个抽象展开的。代码里你直接创建变量对象，然后用数学表达式的方式描述约束和目标，求解器在内部帮你完成标准型转换和迭代。相比自己写矩阵，这个方案的优点是可读性和扩展性，缺点是你需要理解它的表达式模型。

下面是一个完整可运行的 OjAlgo 示例，目标是用它对库存优化建模再求解：

import org.ojalgo.optimization.Expression; import org.ojalgo.optimization.ExpressionsBasedModel; import org.ojalgo.optimization.Variable; import org.ojalgo.optimization.OptimizationSolver; import org.ojalgo.optimization.OptimizationSolver.Result; public class OjAlgoDemo { public static void main(String[] args) { ExpressionsBasedModel model = new ExpressionsBasedModel(); // 定义两个连续变量，每个变量的上下界 Variable x1 = model.addVariable("A") .lower(0) .upper(Double.POSITIVE_INFINITY) .weight(3.0); // weight 表示目标函数系数 Variable x2 = model.addVariable("B") .lower(0) .upper(Double.POSITIVE_INFINITY) .weight(4.0); // 约束：2x1 + x2 <= 8 Expression processingTime = model.addExpression("加工时间"); processingTime.set(x1, 2.0); processingTime.set(x2, 1.0); processingTime.lessThanOrEqual(8.0); // 约束：x1 + 3x2 <= 6 Expression assemblyTime = model.addExpression("组装时间"); assemblyTime.set(x1, 1.0); assemblyTime.set(x2, 3.0); assemblyTime.lessThanOrEqual(6.0); OptimizationSolver solver = model.getDefaultSolver(); Result result = solver.solve(); if (result.getState().isOptimal()) { System.out.println("x1 = " + result.get(x1)); System.out.println("x2 = " + result.get(x2)); System.out.println("objective = " + result.getValue()); } } }

这段代码里要注意weight的设置：OjAlgo 的weight相当于目标函数系数，默认是最大化还是最小化由模型配置决定，默认是最大化。如果你要最小化，需要显式设置模型的目标方向或者给权重取负。这里库存优化问题是最大化利润，所以权重直接填 3 和 4 是正确的。set方法是把系数绑定到特定变量上，lessThanOrEqual则把约束表达式框定为上限约束。这种声明式建模比手写矩阵直观得多，出了问题也容易定位是哪个表达式写错。

4.3 引入库的依赖管理：Maven 坐标和版本选择避坑

如果你用 Maven 管理项目，OjAlgo 和 Commons Math 的依赖坐标都属于常用坐标，但 OjAlgo 的 groupId 和 artifactId 需要注意，常见写法是org.ojalgo:ojalgo，版本号尽量选最近一年内发布的新版本。Commons Math 则是org.apache.commons:commons-math3。这里有个避坑点：OjAlgo 新版本对 Java 版本有要求，Java 8 用户可能需要选旧版本，否则会碰到编译期的不兼容报错。另外一个常见问题是传递依赖冲突，比如你的项目里其他库也依赖了不同版本的 Guava 或 Apache Commons，最好用mvn dependency:tree检查一下，免得跑起来出现运行时NoSuchMethodError。不要问我是怎么知道的——有一次线上环境就是被传递依赖坑掉，排查了半天才发现是版本被覆盖了。

5. 线性规划 Java 实现的 5 个常见坑：数值稳定性、退化、无界与超时排查

5.1 浮点误差导致迭代不收敛：EPSILON 的平衡艺术

手写单纯形法时最恼人的就是浮点误差。你每次转轴都做除法、减法和乘法，迭代几十轮后数值悄悄漂移，可能让检验数变成 -1e-12 这样的“假负数”，求解器会认为还没达到最优，继续迭代，甚至陷入死循环。我们解决它的套路不是把 EPSILON 调大就完事，而是要分场景：比较检验数是否小于零用正 EPSILON，比较主元系数是否为零用另一个更小的阈值，比比率时对接近零的系数直接跳过。之前给出的代码我在两个地方分别用了-EPSILON和> EPSILON判断，这就是在平衡“别漏掉真正需要进基的列”和“别被噪声干扰”。

另一个经验是观察目标函数值在连续迭代中是否卡在同一个数值很久。如果连续十轮目标值没变化，说明大概率进入了退化导致的循环，这时候与其调 EPSILON，不如引入 Bland 规则——在所有可进基变量里选最小编号、在所有可离基变量里选最小编号，这样能理论上保证终止。代价是迭代次数可能变多，但能换来确定性，对一些要求严格稳定的内部系统很值得。

5.2 传感器数据或业务参数里出现 NaN 与 Infinity：输入校验必须先做

这是非常低级的坑，但出现频率极高。你从数据库或 Excel 导入约束系数和右边常数时，只要源数据有一个空值被转成 NaN，单纯形法的比率测试就会得出 NaN 结果，然后整个表格被污染，最终抛出奇怪的异常或返回全零解。我现在写 Java 实现时会在求解器入口处强制扫描整个数组，任何元素不是有限数就立刻报错，并输出是哪个约束哪一列出了问题。千万别把这个校验放在业务层就觉得万事大吉，求解器作为兜底防线应该再做一次，因为业务层和算法层之间可能还有数据清洗或单位换算的逻辑，错误类型在传递过程中会被掩盖。

5.3 退化问题让单纯形法原地打转：如何检测与跳出

当某个基变量的值恰好为零时，最小比率测试可能让多个离基候选产生相同比率，这就是退化。退化本身不致命，但如果转轴选择不当，可能出现基变量反复进出，目标值几天不推进，这在大型模型里是真实存在的“黑匣子”现象。检测方法简单粗暴：每次转轴后记录目标值，如果在最近的 20 次迭代里目标值变化绝对值小于 1e-9，就切换 Bland 规则。另一种思路是做一个随机扰动，给右边常数加极小的随机数打破对称性，但这个方法要小心，扰动太大可能把解也带偏。实践中我更推荐 Bland 规则，因为可复现性对调试很重要，随机扰动会让同样的输入在不同运行里得到不同迭代路径，排查问题时会非常痛苦。

5.4 模型无界导致求解器抛异常：先检查漏掉的边界约束，不是先怀疑算法

新手经常遇到 NullPointerException 一样困惑的“无界异常”——求解器告诉你问题没有有限最优解，你第一反应是算法有 bug，其实往往是你漏写了一个变量上限约束。回到库存优化的例子里，如果你忘记给 x1、x2 加非负下限，单纯形法里的比率测试会因为系数为负而跳过，最终找不到离基变量，抛无界异常。正确做法是：在处理任何业务模型之前，先白纸黑字列一遍每个变量的物理含义，确认它是否有隐含的上下界。比如“产量不可能为负”“采购数量有仓库容量上限”，这些业务规则就是模型里的变量界约束。OjAlgo 里一个个设置lower和upper虽然啰嗦，但它逼你想清楚边界，从根上减少无界风险。

5.5 性能瓶颈不在转轴，而在模型组装和数据读取

如果你给求解器喂了一个几千行约束的模型，跑起来发现慢得不合理，先别急着优化算法。多数情况下瓶颈出现在模型组装阶段：你在循环里反复调用数组拷贝、在数据库查询里逐行读取和转换类型、甚至不小心在一个双重循环里做字符串拼接生成约束表达式。我之前遇到过一个性能问题，OjAlgo 求解只花了 30 毫秒，但整个程序跑完用了 3 秒，一查发现 2.7 秒都在执行一个不必要的 deep copy。经验是用不可变数据结构提前把矩阵构建好，一次性地传给求解器，避免在迭代循环里做任何对象的创建和集合扩容。这些优化听起来像常识，但实际项目里真的很容易犯，值得反复自查。

6. 把线性规划算法藏进业务系统：状态恢复、灵敏度分析与验证数据集

很多工程师把求解器当成一个“跑一次出结果的黑盒”，但在真实系统里，我们需要让求解过程可观测、可恢复、可验证。我最后分享三个自己实践过的做法，它们能显著降低投产后的维护成本。

第一个做法是持久化求解状态。单纯形法迭代过程中间如果断电或线程被杀，重启后重新求解的时间成本可能很高，尤其对大模型而言。我的方案是把标准型矩阵、当前基变量列表和当前目标值定期写到一个临时文件或数据库表中，做成检查点。下次启动时先加载最近检查点，恢复表格后继续迭代，而不是从零开始。这在严格意义上就是稀疏矩阵版本单纯形法实现中的一个工程扩展，逻辑不复杂，但要有意识地设计数据结构和容量，我当时用了接近一千行的 Java 代码才把恢复逻辑与校验逻辑写稳。

第二个做法是灵敏度分析。业务方最常问的问题是“某个价格系数变化多少会改变最优决策”。求解器给出的对偶变量和约减成本可以回答这个问题。在 Java 实现里，我习惯在求解结束后额外输出每一行约束的影子价格和每个变量的约减成本，并单独建一张表存起来。比如库存优化里的组装工时约束的影子价格，如果算出来是 0.8，就意味着组装工时每增加一小时，最优利润大约增加 0.8 元；而某变量约减成本为 2，说明它的目标系数必须提高 2 以上才值得投产。这些信息对运营决策的价值往往比最优解本身还大。

第三个做法是建立你自己的回归验证集。不要只跑一个库存优化就算完成，你应当把真正的历史业务数据整理成多个标准型的 JSON 或 CSV 文件，并预先记录每个文件的参考最优解。每次改动模型转换器或升级求解器版本，都跑一遍这一批数据集，对比目标函数和变量值是否有超过可容忍误差的差异。这个做法最朴素，也最可靠，远比写一百个单元测试更贴近真实环境。我自己的习惯是保留至少十个不同规模的代表性问题，从两变量的小模型到上千约束的大模型都覆盖到，这样改代码后心里有底。

最后说一个习惯：我会把每次迭代后表格的非零元素个数、主元位置、目标变化量打到一个日志文件里，级别设为 DEBUG。生产事故排查时，这些日志能帮你回放整个求解过程。有一次线上模型突然返回非最优解，正是靠 DEBUG 日志发现某个字段在业务层被错误更新成了 NaN，而不是算法本身出了故障。技术债往往积累在这些看不到的地方，提前把观测手段做足，能省下无数个半夜排查的瞬间。希望这些经验对你的线性规划 Java 实现之路有所帮助。

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