红帽全球峰会7.2. solver 环境模式
通过 resolver 环境模式，您可以检测实施中的常见错误。它不会影响日志级别。
solver 有一个随机实例。有些解析器配置使用随机实例，很多超过其他实例。例如，Simulated Annealing 算法高度依赖于随机数字，而 Tabu Search 依赖于它来解决分数。环境模式会影响该随机实例的 seed。
您可以在 solver 配置 XML 文件中设置环境模式。以下示例设置 FAST_ASSERT 模式：
<solver xmlns="https://www.optaplanner.org/xsd/solver" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://www.optaplanner.org/xsd/solver https://www.optaplanner.org/xsd/solver/solver.xsd">
<environmentMode>FAST_ASSERT</environmentMode>
...
</solver>以下列表描述了您可以在 resolver 配置文件中使用的环境模式：
-
FULL_ASSERT模式打开所有断言，例如，增量分数计算在移动实施、约束、引擎本身等中不可修正的断言，对移动实施、约束、引擎本身等错误而造成故障。这个模式是可重复生成的。它还是入侵的，因为它调用方法computeScore （）比非 assert 模式更频繁。FULL_ASSERT模式非常慢，因为它不依赖于增量分数计算。
-
NON_INTRUSIVE_FULL_ASSERT模式开启几个断言，针对移动实施中的一个错误、约束、引擎本身等。这个模式是可重复生成的。它不是预期的，因为它不会调用方法 computeScore （），比非 assert 模式更频繁。NON_INTRUSIVE_FULL_ASSERT模式非常慢，因为它不依赖于增量分数计算。
-
FAST_ASSERT模式打开大多数断言，例如 undoMove 的分数与 Move 的分数相同，对移动实施、约束、引擎本身等中的一个错误进行故障。这个模式是可重复生成的。它还是入侵的，因为它调用方法computeScore （）比非 assert 模式更频繁。FAST_ASSERT模式较慢。编写一个测试问题单，使用FAST_ASSERT模式运行您的规划问题。
REHQUCIBLE模式是默认模式，因为在开发过程中建议使用它。在这个模式中，两个以同一 OptaPlanner 版本按相同的顺序执行相同的代码。这两个运行在每个步骤中都有相同的结果，除了以下备注除外。这可让您一致地重现错误。它还允许您对某些重构进行基准测试，如分数约束性能优化。注意尽管使用
REHQCIBLE模式，但因为以下原因，您的应用程序可能仍然无法完全可重复生成：-
使用
HashSet或其他集合，其顺序在 JVM 运行用于规划实体或规划值的集合，而不是常规问题事实，特别是在解决方案实施中。使用LinkedHashSet替换它。 - 合并一个耗时的依赖算法，最重要的是 Simulated Annealing 算法，以及花费的时间终止。分配的 CPU 时间有足够大的区别会影响时间 gradient 值。将 Simulated Annealing 算法替换为 Late Acceptance 算法，或使用步骤计数终止替换终止时间。
-
使用
-
REHQUCIBLE模式可能比NON_REHQUCIBLE模式稍慢。如果您的生产环境可从可重复生成的中受益，请在生产环境中使用此模式。在实践中，如果没有指定 seed，则REHQUCIBLE模式使用默认的固定随机 seed，而且会禁用某些并发优化，如工作窃取。
-
NON_REHQUCIBLE模式比REHQUCIBLE模式稍快。在开发过程中避免使用它，因为它使调试和程序错误修复变得困难。如果在生产环境中可重复生成性并不重要，则在生产环境中使用NON_REHQUCIBLE模式。实际上，如果没有指定 seed，则此模式不使用固定的随机 seed。
