告别排班与调度难题：Timefold Solver 实战踩坑与性能调优心得
在处理企业级应用时，我们经常会遇到一类让人头疼的问题：规划与调度（Planning and Scheduling）。不管是员工排班、车辆路径规划（VRP）、还是会议室分配，这类问题在数学上通常属于 NP-Hard 问题。靠人工写 if-else 和贪心算法，不仅代码难以维护，而且很难找到最优解。
最近在项目中，我引入了 Timefold Solver（OptaPlanner 的继任者），它真的是解决这类资源分配问题的“降维打击”工具。今天不仅复盘一下我的使用心得，还会深入聊聊约束分级策略，以及一个极其容易踩中的性能大坑。
一、 核心概念：捅破窗户纸的“顿悟”时刻
Timefold 的核心逻辑其实就是三个词：Domain（领域模型）、Score（分数） 和 Solver（求解器）。理清以下三个角色就豁然开朗了：
- Planning Entity（规划实体）：业务里需要被分配的对象。比如“值班任务”。
- Planning Variable（规划变量）：实体中需要被求解器填入的属性。比如值班任务里的“员工”。
- Planning Solution（规划方案）：整个问题的全局视图，包含所有实体和资源，以及计算出来的总得分。
二、 深入理解分数体系：Hard、Medium 与 Soft
在复杂的业务场景中，非黑即白的“硬约束”和“软约束”往往不够用。Timefold 提供了多级分数机制（如 HardMediumSoftScore），帮助求解器在不同的业务维度上权衡利弊。求解器的比较逻辑是严格向下压制的：只有在 Hard 分数相同时，才会去比较 Medium 分数；Medium 相同时，再去比较 Soft 分数。
1. Hard Score（硬约束）：不可逾越的红线
硬约束代表了物理限制、法律合规或绝对的业务底线。任何破坏硬约束的方案都是不可行解（Infeasible Solution）。
- 场景举例：一个医生不能在同一时间段主刀两台手术；一辆卡车的装载量不能超过它的最大载重。
- 求解器行为：Solver 会拼尽全力把 Hard 分数提升到 0（或 0 以上）。
2. Medium Score（中等约束）：核心业务 KPI
当我们满足了所有硬约束，得到了可行解后，往往会有多个方案摆在面前。Medium 约束通常用来衡量方案的核心业务价值，比如总成本、总利润或整体的公平性。
- 场景举例：在物流配送中，所有包裹都装上车了（Hard 满足），此时需要最小化所有车辆的总行驶里程；在排班中，保证各个团队分配到的资深员工数量大致均衡。
- 求解器行为：在确保 Hard 分数不下降的前提下，努力优化 Medium 分数。
3. Soft Score（软约束）：锦上添花的偏好
这是优先级最低的约束，通常涉及用户体验或个人偏好。
- 场景举例：员工 A 希望周五能排早班以便提早回家；尽量把会议安排在带有白板的会议室。
- 求解器行为：在 Hard 和 Medium 都锁定的情况下，顺手做个人情，尽量满足这些条件。
三、 性能避坑指南：为什么千万别用 BigDecimal 当分数？
在编写 Java 领域模型时，由于经常涉及金额（如计算超时加班费、物流成本），很多开发者会本能地使用 BigDecimal，并在 Timefold 中配置对应的 BendableBigDecimalScore。这是一个极其致命的性能陷阱！
Timefold 的底层是一个启发式搜索殷勤，它在寻找最优解时，每秒钟需要进行数万次甚至数十万次的分数计算（Score Calculation）。
- 对象创建开销：
BigDecimal是不可变对象。在每秒数万次的运算循环中，频繁进行加减乘除会产生海量的短生命周期对象。这会导致 Java 的垃圾回收器（GC）压力骤增，频繁触发 GC 停顿，直接将求解速度拖慢几个数量级。 - 正确的优化姿势：永远优先使用基本数据类型！ 采用
int（对应HardSoftScore）或long（对应HardSoftLongScore）。 - 如何处理小数？：使用整数放大法。如果成本精确到分，直接把金额乘以 100 存为
long参与计算；如果需要三位小数精度，就乘以 1000。在最终向前端展示结果时，再除以对应的倍数还原即可。
四、 给新手的几条实践建议
- 从小数据集开始验证：千万不要一开始就把生产环境几万条数据扔进去跑。先搞一个极小的数据集（比如 5个任务，3个员工），验证你的
ConstraintProvider写得对不对。 - 善用 ConstraintVerifier：这是 Timefold 提供的单元测试工具。一定要为每一条约束写单元测试！ 否则当你有 20 条约束混合在一起时，你根本不知道为什么求解器给出了一个奇怪的结果。
- 监控分数计算速度（Score Calculation Speed）：观察日志，如果每秒计算次数只有几百次，说明你的约束流写得太重了，或者误用了类似
BigDecimal这样高开销的类型。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！
