Optaplanner自定义Move引发步骤停滞及移动选择异常问题咨询

一、选中移动数量庞大的核心原因 #

• 局部搜索的迭代逻辑：OptaPlanner的局部搜索（LS）在每一步会持续评估候选Move，直到找到符合接受策略的Move才会执行。当算法陷入局部最优解时，当前所有候选Move都无法有效提升分数，就会反复遍历所有可能的Move，导致selected move count（评估过的Move数量）飙升。哪怕你的自定义Move工厂生成的Move数量不多，只要没有找到可接受的Move，算法就会不断循环评估。
• Move评估的统计规则：日志里的selected move count是指算法在该步骤中评估过的所有候选Move总数，而非仅自定义Move的数量。UnionSelector中的所有Move类型都会被纳入评估统计，只是大部分评估后不符合接受条件，所以只有20个被接受。

二、UnionSelector中其他Move未被接受的可能因素 #

• 分数无提升或恶化：如果其他大尺寸Move执行后，分数没有得到改进（甚至变差），而你使用的接受策略（比如AcceptBestStepAcceptor）只接受能提升分数的Move，这些Move自然不会被接受。
• 选择权重配置失衡：若UnionSelector给自定义Move设置了过高的selectionProbabilityWeight，算法会优先、高频评估自定义Move，其他Move被选中评估的次数极少，几乎没机会碰到能提升分数的情况，也就不会被接受。
• 自定义Move的副作用：自定义Move如果没有正确实现回滚逻辑（undoMove方法），执行后会破坏解决方案的原始状态，导致后续其他Move的分数计算异常，看起来无法提升分数，进而不被接受。

三、多线程环境下自定义Move的Bug排查点 #

• 线程安全问题：自定义Move必须保证线程安全。如果Move内部使用了非线程安全的共享状态，或者doMove/undoMove方法没有处理并发修改，会导致分数计算错误，算法误以为没有更优Move，从而持续重复评估。
• Move克隆失效：多线程模式下，OptaPlanner会克隆解决方案进行并行评估。如果自定义Move没有正确实现clone()方法，克隆后的Move状态与原Move不一致，会导致评估结果失真，影响Move的接受判断。
• 分数计算器的并发问题：如果自定义Move触发的分数计算依赖非线程安全的组件，会导致分数混乱，算法无法正确识别Move的价值。确保你的ScoreCalculator是线程安全的，或使用默认线程安全的EasyScoreCalculator。

四、实用排查建议 #

• 开启详细日志：将OptaPlanner日志级别调到DEBUG或TRACE，查看每一步评估的Move类型、分数变化，确认其他Move是否被评估，以及评估后的分数表现。
• 单线程隔离测试：先切换到单线程模式测试自定义Move，验证其能否正确修改方案并提升分数，排除多线程干扰后确认Move本身的正确性。
• 调整选择器配置：暂时降低自定义Move的选择权重，或单独启用其他Move类型，观察算法是否能接受这些Move，判断是配置问题还是Move本身的Bug。
• 校验回滚逻辑：手动验证自定义Move的undoMove方法，确保执行后解决方案完全恢复到执行前的状态，避免影响后续Move的评估。

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