std::stop_token是C++20引入的协作式线程取消机制核心，用于轻量、无锁地传递停止请求信号，解决传统布尔标志轮询遗漏检查点、阻塞调用无法响应中断等问题。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::stop_token 是什么，它能解决什么问题
std::stop_token 是 C++20 引入的协作式线程取消机制的核心组件，它本身不主动终止线程，而是提供一种轻量、无锁、可轮询的“停止请求”信号传递方式。它解决的是传统 std::thread::join() 阻塞等待、或用布尔标志 + volatile / std::atomic<bool></bool> 手动轮询时容易遗漏检查点、无法响应中断、或在阻塞调用（如 std::condition_variable::wait()）中卡死的问题。
关键在于：它必须配合 std::stop_source 和支持停用的等待函数（如 wait() 的重载版本）一起使用，不是“一键杀死”。
如何正确构造和传递 stop_token 到工作线程
工作线程需要拿到有效的 std::stop_token 实例才能感知停止请求。最常见且安全的做法是在线程启动前从 std::stop_source 获取，并通过值传递（std::stop_token 是可拷贝的轻量对象）：
std::stop_token 实例才能感知停止请求。最常见且安全的做法是在线程启动前从 std::stop_source 获取，并通过值传递（std::stop_token 是可拷贝的轻量对象）：
• 创建 std::stop_source 在主线程（例如作为局部变量或成员变量）
• 调用其 get_token() 得到 std::stop_token
• 将该 token 传给线程函数（推荐按值传，避免生命周期问题）
• 不要在线程内重新创建 std::stop_source 或试图从其他地方“获取” token —— 它必须与发起请求的 source 关联
std::stop_source ss;
std::thread t([token = ss.get_token()] {
while (!token.stop_requested()) {
// 工作逻辑
std::this_thread::sleep_for(100ms);
}
});
// … 后续可调用 ss.request_stop() 触发退出
在阻塞调用中响应 stop_token 的正确姿势
单纯轮询 stop_requested() 在忙等场景下浪费 CPU；而像 std::condition_variable::wait() 这类阻塞调用，若不支持 stop_token，线程就无法被及时唤醒。C++20 为此提供了带 std::stop_token 参数的重载：
• 使用 cv.wait(lock, pred, token) 替代 cv.wait(lock, pred)
• 使用 std::this_thread::sleep_for(dur, token) 替代 std::this_thread::sleep_for(dur)
• 这些重载会在收到停止请求时立即返回（通常抛出 std::stop_exception 或返回 false），无需额外唤醒逻辑
• 注意：不是所有标准库函数都支持 —— 比如 std::mutex::lock() 就没有 token 版本，此时仍需在外层轮询
std::condition_variable cv;
std::mutex mtx;
bool ready = false;
std::thread t([token = ss.get_token(), &cv, &mtx, &ready] {
std::unique_lock<std::mutex> lk(mtx);
cv.wait(lk, [&ready] { return ready; }, token); // 支持 token 的 wait
if (token.stop_requested()) return; // 显式检查退出
// 继续处理
});
request_stop() 调用时机与常见陷阱
ss.request_stop() 是触发整个协作链的起点，但它只发一次信号，且不可撤销。常见误用包括：
• 在 std::thread 对象已 join() 或 detach() 后再调用 —— 此时关联的 stop_state 可能已被销毁，行为未定义
• 多次调用 request_stop() —— 第二次及以后调用直接返回 false，但不会报错，容易让人误以为“没生效”
• 忽略 token 的有效性：std::stop_token 默认构造的对象（如 std::stop_token{}）stop_requested() 始终返回 false，且不响应任何 request
• 在析构函数中调用 request_stop() 时未确保 stop_source 生命周期长于所有持有其 token 的线程
request_stop()，线程也可能卡在某个系统调用里迟迟不退出。 
