
在 Timefold(或 OptaPlanner)中,若需在同一应用中管理多个独立的规划问题(如不同业务场景的排班、装箱、路径规划),必须为每个解决方案类单独配置 Solver,并确保每个类都标注 @PlanningSolution;直接省略该注解并依赖 XML 或编程式配置会导致初始化失败。
在 timefold(或 optaplanner)中,若需在同一应用中管理多个独立的规划问题(如不同业务场景的排班、装箱、路径规划),必须为每个解决方案类单独配置 solver,并确保每个类都标注 `@planningsolution`;直接省略该注解并依赖 xml 或编程式配置会导致初始化失败。
Timefold(OptaPlanner 的演进分支)严格遵循“一个解决方案类 → 一个求解器配置”的契约。即使你通过 SolverConfig.withSolutionClass() 显式指定类,框架仍会在启动时强制校验该类是否带有 @PlanningSolution 注解——这是元数据提取、实体扫描与约束绑定的前提,不可绕过。
✅ 正确做法:为每个规划问题定义专属的 @PlanningSolution 类,并分别构建独立的 SolverConfig:
// Sol1.java
@PlanningSolution
public class Sol1 {
@PlanningEntityCollectionProperty
private List<task> taskList;
@PlanningScore
private HardSoftScore score;
// ... getters/setters, problem facts, etc.
}
// Sol2.java
@PlanningSolution
public class Sol2 {
@PlanningEntityCollectionProperty
private List<vehicleroute> routeList;
@PlanningScore
private BendableScore score;
// ...
}</vehicleroute></task>
随后在运行时分别创建隔离的求解器配置与管理器:
SolverConfig config1 = new SolverConfig()
.withSolutionClass(Sol1.class)
.withEntityClasses(Task.class)
.withConstraintProviderClass(Sol1ConstraintProvider.class)
.withTerminationSpentLimit(Duration.ofSeconds(30));
SolverConfig config2 = new SolverConfig()
.withSolutionClass(Sol2.class)
.withEntityClasses(VehicleRoute.class)
.withConstraintProviderClass(Sol2ConstraintProvider.class)
.withTerminationSpentLimit(Duration.ofSeconds(60));
SolverManager<sol1 long> solverManager1 = SolverManager.create(config1);
SolverManager<sol2 long> solverManager2 = SolverManager.create(config2);</sol2></sol1>
⚠️ 注意事项:
- 所有
@PlanningSolution类必须满足规范:包含@PlanningScore字段、至少一个@PlanningEntityCollectionProperty或@PlanningEntityProperty,且不可继承自其他@PlanningSolution类; - Spring Boot 或 Quarkus 自动配置目前不支持多
@PlanningSolution场景——它们默认只扫描并注册单个主SolverFactory,因此必须弃用@SolverConfig或optaplanner.solver.config配置项,改用纯编程式配置; - 若需统一调度或多租户能力,建议封装
SolverManager实例为命名 Bean(如@Bean @Qualifier("schedulingSolver")),并在业务层按需注入; - Timefold 社区已意识到该限制,欢迎在 GitHub Issues 提交增强请求(例如支持
@Named("scheduling") @PlanningSolution),以推动未来版本原生集成。
总结:多解决方案不是反模式,而是企业级规划系统的常见需求。关键在于放弃“全局单一配置”的思维,转而采用配置隔离 + 注解合规 + 运行时解耦的设计原则——每个 @PlanningSolution 是一个自治的规划域,各自拥有专属的约束逻辑、终止策略与求解生命周期。










