Optaplanner链式变量模型出现变量损坏问题求助

问题核心 #

在OptaPlanner的链式配送路由模型中，影子变量Delivery.deliveryTime出现异常损坏：某实体的影子变量值被错误设置为2022-10-03T17:10，但在所有变量监听器执行完成后，无需修改真实变量就自动恢复为正常值2022-10-03T17:12。调试器断点运行时无此问题，移除监听器中遍历nextDelivery的内层while循环后问题消失，但会导致deliveryTime计算逻辑失效。

根本原因分析 #

1. 嵌套遍历的状态冲突：外层循环遍历当前及后续Delivery节点，内层循环又从当前节点再次遍历所有后续节点，导致同一Delivery实例的deliveryTime被多次触发beforeVariableChanged/afterVariableChanged操作。OptaPlanner的ScoreDirector对影子变量的跟踪依赖严格的状态变更顺序，重复操作会破坏其内部状态一致性，引发影子变量值异常。
2. 线程调度掩盖问题：调试时断点暂停会改变线程执行时序，避免了并发状态下的冲突，但生产环境中线程快速执行会暴露状态不一致问题。
3. 反向遍历的逻辑误区：从当前节点向前遍历所有后续节点计算总任务时间，这种逻辑会导致链中每个节点都重新计算一次后续所有节点的时间，不仅冗余，还会引发重复修改影子变量的冲突。

修复方案 #

1. 调整计算逻辑：从链起点一次性计算所有节点时间 #

避免嵌套遍历，改为先找到链式结构的起点（即前驱为Shift的Delivery），然后从起点开始依次累加任务时间，一次性完成所有后续节点的deliveryTime计算。这种方式确保每个影子变量只被修改一次，不会触发重复的状态变更操作。

修改后的代码示例：

private void updateDeliveryTime(
      ScoreDirector<DeliveryRoutingSolution> scoreDirector, Delivery triggerDelivery) {
    // 定位到当前链的起点（前驱为Shift的Delivery）
    Delivery chainStart = triggerDelivery;
    while (chainStart != null) {
        PreviousDeliveryOrShift prev = chainStart.getPreviousDeliveryOrShift();
        if (prev == null || prev.getType() == PreviousDeliveryOrShift.Type.SHIFT) {
            break;
        }
        // 前驱是Delivery，继续向上找起点
        chainStart = prev.getDelivery();
    }

    if (chainStart == null) {
        return;
    }

    // 从链起点开始，依次计算每个Delivery的deliveryTime
    PreviousDeliveryOrShift shiftPrev = chainStart.getPreviousDeliveryOrShift();
    LocalDateTime currentTime = shiftPrev.getStartTime();
    Delivery currentDelivery = chainStart;

    while (currentDelivery != null) {
        // 累加当前Delivery的任务时间
        currentTime = currentTime.plus(currentDelivery.getTaskTime());
        
        // 安全更新影子变量
        scoreDirector.beforeVariableChanged(currentDelivery, "deliveryTime");
        currentDelivery.setDeliveryTime(currentTime);
        scoreDirector.afterVariableChanged(currentDelivery, "deliveryTime");

        currentDelivery = currentDelivery.getNextDelivery();
    }
}

2. 额外排查与优化点 #

• 严格控制监听器触发条件：确保updateDeliveryTime只在previousDeliveryOrShift变量变更时触发，避免不必要的重复调用。
• 启用Full Assert模式并增加日志：在配置中开启FULL_ASSERT，同时在监听器中添加日志，记录每次变量修改的前后值和调用栈，进一步定位潜在的状态冲突点。
• 校验链式关系一致性：确保previousDeliveryOrShift和nextDelivery的双向关联在任何修改操作中都同步更新，避免出现单向引用不一致的情况。

内容的提问来源于stack exchange，提问作者Jon Sørensen