1. 理解可空规划变量在过约束规划中的作用
在optaplanner中，过约束规划（overconstrained planning）是指在某些情况下，所有硬约束无法同时满足。为了处理这种情况，我们通常会引入一个机制，允许部分规划实体不被分配任何规划值。@planningvariable(nullable = true)就是实现这一目标的关键。当一个规划变量被标记为nullable = true时，optaplanner会在其可分配的值域中自动添加null，这意味着该变量可以被显式地设置为null，从而表示该实体未被分配。
这种机制在过约束场景下至关重要。当硬约束被严重违反时，我们期望OptaPlanner能够通过将某些实体的规划变量设为null来“解除分配”，以缓解硬约束的压力，即使这可能导致中等（Medium）或软（Soft）分数的损失。
2. ConstraintStreams API中forEachIncludingNullVars()的关键性
在使用OptaPlanner的ConstraintStreams API定义约束时，对于包含可空规划变量的场景，一个常见的陷阱是错误地使用了forEach()方法。forEach()方法默认会过滤掉那些规划变量为null的实体，这意味着任何依赖于null状态来计算分数的约束（例如，对未分配实体的惩罚）将无法被正确评估。
为了确保所有规划实体，无论其规划变量是否为null，都能被纳入约束评估，必须使用forEachIncludingNullVars()方法。这个方法会确保即使规划变量为null的实体也能被ConstraintStreams处理，从而允许我们编写针对这些“未分配”状态的约束。
示例代码：
假设我们有一个Task实体，它有一个可空的Employee规划变量。我们希望对未分配的Task进行惩罚。
import org.optaplanner.core.api.score.buildin.hardmediumsoft.HardMediumSoftScore;
import org.optaplanner.core.api.score.stream.Constraint;
import org.optaplanner.core.api.score.stream.ConstraintFactory;
import org.optaplanner.core.api.score.stream.ConstraintProvider;
public class MyConstraintProvider implements ConstraintProvider {
@Override
public Constraint[] defineConstraints(ConstraintFactory constraintFactory) {
return new Constraint[]{
penalizeUnassignedTasks(constraintFactory),
// 其他约束...
};
}
// 正确的约束定义：使用 forEachIncludingNullVars()
private Constraint penalizeUnassignedTasks(ConstraintFactory constraintFactory) {
return constraintFactory.forEachIncludingNullVars(Task.class)
.filter(task -> task.getEmployee() == null) // 筛选出未分配员工的任务
.penalizeConfigurable(HardMediumSoftScore.ONE_MEDIUM) // 对每个未分配任务施加中等分数惩罚
.asConstraint("Penalize unassigned tasks");
}
// 错误的约束定义示例（如果期望null被处理）：
// private Constraint penalizeUnassignedTasksIncorrect(ConstraintFactory constraintFactory) {
// return constraintFactory.forEach(Task.class) // 这里的 forEach() 会默认过滤掉 employee == null 的 Task
// .filter(task -> task.getEmployee() == null) // 此 filter 可能永远不会匹配
// .penalizeConfigurable(HardMediumSoftScore.ONE_MEDIUM)
// .asConstraint("Penalize unassigned tasks (incorrect)");
// }
}注意事项：
- 所有与可空规划变量相关的约束，无论是直接检查null状态，还是在计算中依赖于其非null值，都应考虑使用forEachIncludingNullVars()。
- 如果一个约束仅关心非null的规划变量（例如，员工冲突），那么在forEachIncludingNullVars()之后添加filter(entity -> entity.getPlanningValue() != null)是安全的，但如果直接使用forEach()则可能导致潜在的问题，因为forEach()本身可能已经过滤了null值，而这在某些OptaPlanner版本或配置下可能不符合预期。为了明确性，推荐始终使用forEachIncludingNullVars()，然后按需过滤。
3. 调试过约束规划行为的日志分析
当OptaPlanner在硬约束被严重违反时未能将规划值设回null，或者中等分数未按预期变化时，详细的日志分析是诊断问题的最有效手段。OptaPlanner提供了丰富的日志输出，可以帮助我们理解其内部决策过程。
建议的日志级别和关注点：
-
DEBUG 级别：
- 将org.optaplanner包的日志级别设置为DEBUG。
- 此级别可以显示每个局部搜索（Local Search）步骤的得分变化、选定的移动（move）以及一些关键的决策信息。
- 关注每次迭代中Score的变化，特别是硬分数（Hard Score）是否有所改善，以及中等分数（Medium Score）是否因“解除分配”而变得更负。
-
TRACE 级别：
- 对于更深入的分析，将特定包的日志级别设置为TRACE。
- 关注移动生成： org.optaplanner.core.impl.heuristic.selector.move.factory.MoveFactory 和 org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMoveSelector 等类在TRACE级别会显示所有生成的可能移动。检查是否有将规划变量设为null的ChangeMove被生成。
- 关注移动评估： org.optaplanner.core.impl.localsearch.decider.acceptor.step.StepAcceptor 和 org.optaplanner.core.impl.localsearch.decider.forager.LocalSearchForager 等类在TRACE级别会显示每个生成的移动及其评估后的得分。仔细检查那些将规划变量设为null的移动，看它们的得分是否被正确计算，以及它们是否被接受为下一步。
日志配置示例（以Logback为例，通常在logback.xml或application.properties中配置）：
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
通过分析这些日志，你可以确认以下几点：
- OptaPlanner是否确实生成了将规划变量设为null的移动。
- 这些“解除分配”移动的得分是否被正确计算（特别是硬约束的改善和中等约束的惩罚）。
- 在局部搜索阶段，这些移动是否被认为是有效的并且被选择执行。如果它们被生成但从未被选中，那可能是因为它们的得分提升不足以被接受，或者存在其他更好的移动。
总结
在OptaPlanner中实现基于可空规划变量的过约束规划，需要特别注意ConstraintStreams API的正确使用，即对所有相关约束采用forEachIncludingNullVars()方法。同时，当规划器的行为不符合预期时，利用DEBUG和TRACE级别的日志输出，深入分析移动的生成、评估和选择过程，是诊断和解决问题的关键。通过这些方法，可以确保OptaPlanner能够有效地处理硬约束冲突，并通过“解除分配”来找到最优的过约束解决方案。
