本文详解如何在 optaplanner（及继任者 timefold）中通过应用层设计实现多策略并行求解，应对硬约束不可满足的现实调度难题，并结合可空变量、分区搜索等机制保障超约束规划的稳定性与结果延续性。
本文详解如何在 optaplanner（及继任者 timefold）中通过应用层设计实现多策略并行求解，应对硬约束不可满足的现实调度难题，并结合可空变量、分区搜索等机制保障超约束规划的稳定性与结果延续性。
在实际业务调度系统中（如会议室分配、医护排班、云资源调度），常面临“无严格可行解”的困境：受限于固定资源、刚性时间窗或突发变更，OptaPlanner 默认求解器无法产出硬分（hard score）为 0 的可行解。此时，依赖单一求解配置往往陷入停滞——它不会自动放宽约束、重试或切换策略。但 OptaPlanner 的核心优势正在于高度可组合的架构设计：它不提供开箱即用的“自适应重配置”，却赋予开发者完全自主构建多策略协同优化流程的能力。
✅ 多策略并行求解：主动探索可行路径
关键在于利用 SolverManager 启动多个独立求解任务，每个任务对应一个语义清晰的问题变体：
// 构建基准问题（8小时工作日，5间会议室）
PlanningProblem baseProblem = buildBaseProblem();
// 变体1：延长可用时间 → 探索时间维度弹性
PlanningProblem extendedTimeProblem = buildProblemWithExtendedDay(baseProblem, 1); // +1h
// 变体2：增加资源 → 探索容量维度弹性
PlanningProblem moreRoomsProblem = buildProblemWithExtraRoom(baseProblem, 1); // +1 room
// 变体3：缩短单任务时长 → 探索粒度维度弹性
PlanningProblem shorterSlotsProblem = buildProblemWithReducedSlotDuration(baseProblem, 10); // -10min per slot
// 并行提交，异步获取结果
CompletableFuture<solution> baseFuture = solverManager.solve("base", baseProblem);
CompletableFuture<solution> timeFuture = solverManager.solve("extended-time", extendedTimeProblem);
CompletableFuture<solution> roomFuture = solverManager.solve("more-rooms", moreRoomsProblem);
CompletableFuture<solution> slotFuture = solverManager.solve("shorter-slots", shorterSlotsProblem);
// 择优选取：优先可行解（hard == 0），其次软分最高者
List<completablefuture>> allFutures = List.of(baseFuture, timeFuture, roomFuture, slotFuture);
Solution bestSolution = allFutures.stream()
.map(CompletableFuture::join)
.filter(Objects::nonNull)
.max(Comparator.comparing(Solution::getScore))
.orElse(null);</completablefuture></solution></solution></solution></solution>
⚠️ 注意事项：
- 所有变体必须基于同一份原始数据副本，避免共享状态导致竞态；
- SolverConfig 可统一复用，也可为不同变体定制终止条件（如对资源扩展类变体设更短超时）；
- 建议为每个 solve() 调用指定唯一 problemId，便于日志追踪与结果归因。
?️ 超约束规划（Overconstrained Planning）与可空变量的正确实践
当问题本质超约束（如10个任务仅7个可用资源），应启用可空规划变量（@PlanningVariable(nullable = true)），并定义明确的中等（medium）或软（soft）约束来惩罚未分配实体：
// 在 ConstraintProvider 中
Constraint unassignedLessonPenalty(ConstraintFactory factory) {
return factory.from(Lesson.class)
.filter(lesson -> lesson.getRoom() == null) // 未分配即罚分
.penalizeLong("Unassigned lesson", HardMediumSoftScore.ONE_MEDIUM);
}
此时需特别注意：分区搜索（Partitioned Search）中的构造阶段（Construction Heuristic）默认不触发全局分数更新——这是导致你观察到“分区结束分数归零”的根本原因。该行为源于 OptaPlanner 7.x 中一个已知缺陷（Timefold Issue #25），其本质是构造阶段完成后的解未被正确同步至主求解上下文，导致后续局部搜索从初始未分配状态重启。
✅ 解决方案：
- 升级至 Timefold 0.8.39+ 或 0.9.39+（OptaPlanner 的继任项目），该问题已被彻底修复；
- 若暂无法升级，可临时规避：将构造阶段替换为 ExhaustiveSearch（虽慢但保证分数持久化），或在分区阶段后显式调用 scoreDirector.calculateScore() 强制刷新；
- 始终启用 FULL_ASSERT 模式进行开发验证，确保分数计算逻辑在所有阶段均被严格校验。
? 总结：构建鲁棒调度系统的三层思维
| 层级 | 关键动作 | 工具/机制 |
|---|---|---|
| 策略层 | 主动设计多维弹性变体（时间/资源/粒度） | SolverManager.solve() + 问题克隆 |
| 建模层 | 显式支持超约束，用 nullable=true + 中等约束替代硬失败 | @PlanningVariable, HardMediumSoftScore |
| 执行层 | 避免分区搜索陷阱，优先使用 Timefold 新版本或强制分数同步 | TimefoldSolverManager, ScoreDirector |
OptaPlanner 的强大，不在于它替你做决策，而在于它为你提供了足够精细、可编程的“优化杠杆”。真正的智能调度系统，永远是业务逻辑与求解引擎深度协同的结果——而本文所展示的，并非黑盒技巧，而是可复用、可验证、可演进的工程范式。
