Ortools CP-SAT 求解器在 v9.11.4210 版本中存在一个已知缺陷：当 num_search_workers 设置为 8 或更高时，求解器会在预处理完成后、搜索启动前无限挂起；该问题已在后续版本中修复，升级至新版即可恢复正常并行求解。
ortools cp-sat 求解器在 v9.11.4210 版本中存在一个已知缺陷：当 num_search_workers 设置为 8 或更高时，求解器会在预处理完成后、搜索启动前无限挂起；该问题已在后续版本中修复，升级至新版即可恢复正常并行求解。
在使用 OR-Tools 的 CP-SAT 求解器进行大规模约束满足问题（如 N 皇后）求解时，启用多线程可显著提升性能。然而，部分用户反馈：当设置 solver.parameters.num_search_workers = 8（或更高）时，程序在日志输出 #Model 0.11s var:59/60 constraints:114/114 后便完全冻结，不再推进搜索，CPU 占用停滞，且无超时或报错。
这一现象并非模型建模错误所致——同一份代码在 num_search_workers ≤ 7 时运行正常，且单线程/低并发下逻辑完全正确。经验证，该问题是 CP-SAT v9.11.4210 版本中的一个已确认线程调度缺陷，根源在于多工作线程初始化阶段的同步机制存在竞态条件，导致主搜索线程无法正确唤醒或协调子任务。
✅ 根本解决方案：升级 OR-Tools 至最新稳定版
该问题已在后续版本（如 v9.12+）中修复。升级后，8 工作线程可正常启动并行搜索，日志将清晰显示各子求解器（如 default_lp, fj, no_lp, quick_restart_no_lp 等）的调度与执行统计，且求解状态迅速返回 OPTIMAL。
pip install --upgrade ortools
验证是否生效，可运行以下最小复现脚本（N=8 皇后）：
from ortools.sat.python import cp_model
n = 8
model = cp_model.CpModel()
queens = [model.NewIntVar(0, n - 1, f"queen_{i}") for i in range(n)]
model.AddAllDifferent(queens)
for i in range(n):
for j in range(i + 1, n):
model.Add(queens[i] - queens[j] != i - j)
model.Add(queens[i] - queens[j] != j - i)
solver = cp_model.CpSolver()
solver.parameters.max_time_in_seconds = 5
solver.parameters.log_search_progress = True
solver.parameters.num_search_workers = 8 # ✅ 现在可安全使用
status = solver.Solve(model)
print(f"Status: {solver.StatusName(status)}")
if status == cp_model.OPTIMAL:
print([solver.Value(q) for q in queens])⚠️ 临时规避方案（仅限无法升级环境时）
- 将
num_search_workers限制在1–7范围内（推荐4或6，兼顾利用率与稳定性）； - 禁用对称性检测（
solver.parameters.cp_model_probing_level = 0），有时可缓解部分版本的初始化阻塞； - 避免在
max_time_in_seconds过短（如
? 注意事项：
- 并非所有硬件都从高 worker 数获益——实际加速比受模型结构、约束密度及 CPU 核心数影响，建议通过
log_search_progress=True对比不同配置下的walltime和branches统计； - 多线程模式下内存占用会线性增长，请确保系统有足够 RAM（尤其对大规模整数变量模型）；
- 若仍遇冻结，检查是否混用多个
CpSolver实例或在多进程环境中未正确隔离模型（CP-SAT 模型对象不可跨进程共享）。
总之，该冻结问题属于特定版本的底层实现缺陷，升级 OR-Tools 是最直接、最可靠的解决方式。保持工具链更新不仅能规避此类已知问题，还可获得新启发式算法、更优剪枝策略及持续的性能改进。
