我一直在尝试从Optaplanner v7版本中测试新的分区搜索功能。我根据documentation中提供的示例实现了自定义SolutionPartitioner。
看起来工作得很好，因为我可以看到每个线程的分数都在提高（没有硬规则被破坏，软分数正在提高）...但是在主线程的每个合并/缩减步骤中它突然被一个大的线程击中来自硬约束的负面硬分数，我无法弄清楚它是如何发展的，而且很难调试。
这个硬约束类似于'requiredCpuPowerTotal＆＃39; CloudBalance示例中的规则 - 只需检查分配是否超出了容量。
这是2个线程的结尾输出：
- [OptaPool-1-PartThread-2] INFO本地搜索阶段（1）结束：时间
花费（120000），得分最高（0hard / -28317medium / 4671205soft），得分
计算速度（1544 /秒），步骤总数（60272）。
- [OptaPool-1-PartThread-1] INFO本地搜索阶段（1）结束：时间
花了（120000），得分最高（0hard / -16medium / 3362676soft），得分
计算速度（1807 /秒），步骤总计（112408）。
所以我期待主线程中的最终得分是这两个线程的总和，即0hard / -28333medium / 8033881soft。
但实际结果却截然不同：
- [主要] DEBUG PS步骤（229），花费的时间（120103），得分
（-3458hard / -159medium / 10503603soft），得分最高
（0hard / -7837556medium / 0soft），选择了移动
（org.optaplanner.core.impl.partitionedsearch.scope.PartitionChangeMove@5fe73332）。
- [主要] DEBUG PS步骤（230），花费的时间（120214），得分
（-3452hard / -160medium / 10511701soft），得分最高
（0hard / -7837556medium / 0soft），选择了移动
（org.optaplanner.core.impl.partitionedsearch.scope.PartitionChangeMove@5dd30a7d）。
- [main] INFO分区搜索阶段（0）结束：花费的时间（121216），
最佳得分（0hard / -7837556medium / 0soft），得分计算速度
（2 /秒），步骤总计（231），partCount（2），runnablePartThreadLimit
（2）。
正如你所看到的，当两个线程的结果减少到主线程时，有一个-3452硬，因此主线程必须选择开始分数作为最佳分数。
任何可能的想法都会发生，我应该如何调试它？感谢。