Optaplanner未为PlanningVariable使用不同值的作业车间调度问题

我之前基于OptaPlanner做作业车间调度时，也踩过类似的坑，结合你用Fisher & Thompson mt10数据集、修改Taskassigning示例的场景，给你梳理几个大概率的排查方向和解决办法：

1. 先确认PlanningVariable的基础配置是否合规 #

你用@PlanningVariable标注机器分配字段的话，得确保这几点：

• 注解的valueRangeProviderRefs指向的数据源，是不是经过技能过滤后的机器列表？毕竟你保留了技能匹配要求，不能让工序随便选机器。可以用filter属性来做实时过滤：

@PlanningVariable(valueRangeProviderRefs = "machineRange", 
                  filter = MachineSkillMatchFilter.class)
private Machine assignedMachine;

这里的MachineSkillMatchFilter要实现PlanningVariableFilter，核心逻辑就是判断当前工序要求的技能，和机器具备的技能是否匹配。如果过滤逻辑写错了，要么可选机器范围不对，要么导致所有工序都只能选同一台机器，自然会出现“未使用不同值”的情况。

2. 检查Predecessor依赖约束是否生效 #

你引入了前序工序依赖，这个是作业车间调度的核心硬约束，要是没写对，OptaPlanner根本不会按工序顺序来分配资源。
正确的约束应该确保同一作业的前序工序完成后，当前工序才能开始，用ConstraintStream实现的话大概是这样：

@Override
public Constraint[] defineConstraints(ConstraintFactory constraintFactory) {
    return new Constraint[] {
        // 前序工序完成约束
        constraintFactory.from(Task.class)
            .filter(task -> task.getPredecessor() != null)
            .join(Task.class, Joiners.equal(Task::getPredecessor))
            .penalize("Predecessor must finish before current task starts",
                      HardSoftScore.ONE_HARD,
                      (currentTask, predecessorTask) -> {
                          long delay = Duration.between(predecessorTask.getEndTime(), currentTask.getStartTime()).toMinutes();
                          return delay < 0 ? -delay : 0; // 惩罚延迟的时长
                      }),
        // 其他约束...
    };
}

要是这个约束没注册到ConstraintProvider里，或者逻辑写错了，OptaPlanner就会无视工序依赖，分配结果自然混乱。

3. 别漏掉机器工序不重叠的硬约束 #

作业车间调度里，同一台机器上的工序绝对不能时间重叠，这个约束是必须的！你可能因为移除了原示例的速度、优先级，不小心漏掉了这个核心约束。
添加这个约束的代码示例：

constraintFactory.from(Task.class)
    .join(Task.class, 
          Joiners.equal(Task::getAssignedMachine), // 同一机器
          Joiners.lessThan(Task::getId)) // 避免重复检查同一对工序
    .filter((taskA, taskB) -> {
        // 判断两个工序时间是否重叠
        return taskA.getStartTime().isBefore(taskB.getEndTime()) 
            && taskB.getStartTime().isBefore(taskA.getEndTime());
    })
    .penalize("Tasks on same machine must not overlap",
              HardSoftScore.ONE_HARD,
              (taskA, taskB) -> {
                  // 计算重叠时长作为惩罚值
                  LocalDateTime overlapStart = taskA.getStartTime().isAfter(taskB.getStartTime()) ? taskA.getStartTime() : taskB.getStartTime();
                  LocalDateTime overlapEnd = taskA.getEndTime().isBefore(taskB.getEndTime()) ? taskA.getEndTime() : taskB.getEndTime();
                  return Duration.between(overlapStart, overlapEnd).toMinutes();
              });

没有这个约束的话，OptaPlanner可能会把一堆工序都塞到同一台机器上，看起来就像是“没给PlanningVariable用不同值”，但本质是约束缺失。

4. 校验PlanningEntity和Solution的配置 #

• 确保你的Task类正确标注了@PlanningEntity，如果startTime也是需要优化的变量（作业车间调度通常要同时优化机器分配和开始时间），也要给它加上@PlanningVariable，并配置合理的时间范围。
• 你的PlanningSolution类里，要正确标注：
  • @PlanningEntityCollectionProperty：指向所有待分配的Task集合
  • @ValueRangeProvider：指向所有可用的Machine集合（如果用了技能过滤，这个就是全局机器列表，过滤交给前面的PlanningVariableFilter）

5. 开启调试日志定位问题 #

要是上面的检查都没问题，可以开启OptaPlanner的调试日志，看看求解过程中PlanningVariable的选择逻辑和约束满足情况：
在配置文件里加一行：

logging.level.org.optaplanner=DEBUG

通过日志你能看到每一步OptaPlanner尝试了哪些机器分配，哪些约束被违反了，很快就能定位到问题所在。

另外，mt10是标准作业车间调度数据集，你可以参考OptaPlanner自带的JobShopScheduler示例，对比下你的实体配置、约束逻辑和标准示例的差异，大概率能找到问题点。

内容的提问来源于stack exchange，提问作者j-dimension