OptaPlanner基于变量决策动态约束选择的约束传播方案咨询

首先明确OptaPlanner核心运行机制前提：求解器的移动生成、评分计算是完全分离的两个阶段，ValueRangeProvider的计算结果默认仅在求解启动、问题事实变更时刷新，不会随规划变量取值变化动态更新。

三个方案的适用性逐一判断 #

• 方案1：依赖其他规划变量的动态ValueRangeProvider
  完全不可用。OptaPlanner的实体级/全局值范围，仅支持依赖问题事实（即没有@PlanningVariable注解的固定属性，比如你代码里的forceBid）做静态收窄。如果在值范围逻辑里引用其他规划变量，求解器修改被依赖的bidFinal取值时，不会同步刷新bidNow的合法值列表，后续生成bidNow的移动时会大量出现「取值不在合法范围」的运行时异常，求解根本无法稳定运行。就算通过自定义扩展强行刷新值范围，每次变量变更都要全量重算所有实体的值域，性能开销远高于硬约束方案，大规模问题下完全不可行。

• 方案2：ConstraintStreams硬约束
  这是官方推荐的标准实现路径，你遇到的性能问题基本是约束写法不当导致的，不是方案本身的缺陷。
  这类单实体字段校验的硬约束，只要写法正确，在增量评分机制下的开销是O(1)级别——也就是只有当前实体的bidFinal或bidNow取值变化时，才会重算这一条约束的罚分，不会遍历全量实体。正确的约束写法参考如下：

  fun bidNowConsistencyConstraint(constraintFactory: ConstraintFactory): Constraint {
      return constraintFactory.forEach(AuctionBid::class.java)
          .filter { bid -> bid.bidFinal == true && bid.bidNow == false }
          .penalize(HardSoftScore.ONE_HARD)
          .asConstraint("Final bid selected but current bid not placed")
  }
  

  注意不要在约束里写不必要的跨实体join、不要调用有副作用的非纯函数，确保增量评分缓存正常生效即可，性能完全可以支撑大规模问题。如果还想进一步提速，可以配合自定义移动工厂：在生成bidFinal从false切换为true的移动时，同步把同实体的bidNow置为true，从移动生成源头就避免非法解，减少无效的罚分计算。

• 方案3：Shadow变量实现
  完全不适配当前场景。Shadow变量是完全由其他规划变量/事实单向推导出来的派生变量，求解器不会把Shadow变量纳入决策空间，不会主动修改它的取值。你的场景里当bidFinal=false时，bidNow可以自由选择true/false，属于需要求解器权衡决策的普通规划变量，如果强行把bidNow改成Shadow变量，这部分决策空间会直接丢失，求解结果完全不符合业务要求。

最终建议 #

直接使用优化后的ConstraintStreams硬约束实现即可，这是稳定性、性能、可维护性最优的方案，不要尝试用动态值域、Shadow变量等特性硬套不匹配的场景。

内容的提问来源于stack exchange，提问作者TheDarkSaint