Optaplanner中ProblemFactCollectionProperty事实顺序影响求解的问题咨询

问题分析 #

你遇到的核心问题是OptaPlanner的构造启发式算法对值范围的元素顺序敏感，导致在特定顺序下无法生成初始可行解，且后续启发式搜索无法从不可行状态跳转至可行状态——即便增加超时时间也无济于事。

具体解决方案 #

1. 确保Money类的equals()和hashCode()实现正确

Set依赖这两个方法来保证元素唯一性，若实现有误，会导致值范围中出现重复或丢失的Money实例，直接干扰规划变量的可选值池。正确的实现应基于货币类型和金额数值：

public class Money implements Serializable {
    private CurrencyUnit currency;
    private BigDecimal amount;

    // getter、setter等方法

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Money money = (Money) o;
        return Objects.equals(currency, money.currency) 
                && Objects.equals(amount, money.amount);
    }

    @Override
    public int hashCode() {
        return Objects.hash(currency, amount);
    }
}

2. 显式配置不依赖值顺序的构造启发式

默认构造启发式（如FIRST_FIT）会按值范围的迭代顺序选择值，一旦顺序导致初始解陷入硬约束冲突，后续搜索可能无法恢复。改用基于属性排序的启发式，彻底摆脱对值顺序的依赖：

@PlanningSolution
public class YourPlanningSolution {

    @ProblemFactCollectionProperty
    @ValueRangeProvider(id = "amountFacts")
    private Set<Money> amountFacts;

    // 其他规划实体、约束流等定义

    @ConstructionHeuristic(
            value = ConstructionHeuristicType.FIRST_FIT_DECREASING,
            entitySorter = EntitySorterType.DECREASING_DIFFICULTY,
            valueSorter = ValueSorterType.INCREASING_STRENGTH
    )
    public void configureConstructionHeuristic() {}
}

• FIRST_FIT_DECREASING：先处理约束难度高的实体，再依次分配合适的值
• INCREASING_STRENGTH：按值的“适配强度”排序选择，而非原始迭代顺序

3. 排查硬约束冲突的根源

启用OptaPlanner的DEBUG级日志（配置org.optaplanner包的日志级别为DEBUG），查看：

• 初始解生成阶段的约束违反详情
• 搜索过程中尝试的移动是否被硬约束阻断
  这能帮你定位是否存在某些Money值与实体的硬约束天然冲突，只是在特定顺序下被偶然避开了。

4. 确保值范围元素的唯一性与完整性

无论用Set还是List，都要保证值范围中没有重复的Money实例——重复元素会干扰启发式算法的决策逻辑，甚至导致规划器误判可选值池的大小。

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