std::stop_token是c++20协作式线程取消机制的核心，用于安全响应停止请求而非强制终止；它需配合std::jthread使用，支持在阻塞调用中通过重载api或std::stop_callback及时中断并清理资源。
std::stop_token 是什么，它能解决什么问题
std::stop_token 是 C++20 引入的协作式线程取消机制的核心组件，用来替代裸 bool 标志或 std::atomic<bool></bool> 手动轮询。它不强制终止线程（那是危险且不可靠的），而是让子线程主动、安全地响应停止请求——比如在循环中检查、在阻塞点等待、或在关键资源释放前退出。
常见错误现象：用 std::atomic<bool></bool> 控制循环，但忘记在 sleep 或 wait 调用前检查；或者在 std::condition_variable::wait 中没配合 predicate，导致停止信号被错过；又或者在析构时未等待子线程结束，引发 std::thread::~thread 抛出 std::terminate。
如何正确构造和传递 stop_token 到子线程
子线程必须通过 std::jthread 启动（不是 std::thread），否则无法自动注册停止源并保证析构时 join：
-
std::jthread构造时自动生成std::stop_source，其get_stop_token()返回的std::stop_token可安全拷贝并传入线程函数 - 不要手动 new
std::stop_source或跨线程共享同一个std::stop_source实例（除非你明确需要多路触发） - 传参时建议按值传递
std::stop_token（轻量、可拷贝），不要用引用或指针
示例：
std::jthread worker([](std::stop_token stoken) {
while (!stoken.stop_requested()) {
do_work();
std::this_thread::sleep_for(100ms);
}
cleanup(); // 确保在退出前执行
}, std::stop_token{}); // 此处实际由 jthread 自动提供
在阻塞调用中响应 stop_token 的三种方式
纯忙等（while 循环 + stop_requested()）效率低且延迟高，真实场景应利用 C++20 提供的带 stop_token 的阻塞原语：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
std::condition_variable::wait和wait_for有重载接受std::stop_token，会在收到停止请求时立即返回std::cv_status::no_timeout或false（取决于 overload） -
std::this_thread::sleep_for和sleep_until也支持std::stop_token参数，被中断时抛出std::stop_token::stop_requested（实际是std::stop_callback触发的中断，但 API 层表现为异常） - 若使用第三方阻塞调用（如 socket
recv），需配合std::stop_callback注册清理逻辑，并在回调中设置标志+唤醒（例如 notify_one）
要点：
- 避免在
wait中只依赖 predicate 检查stop_requested()，应直接传入stoken让底层做中断 -
std::stop_callback构造时捕获的 lambda 在停止请求发出时执行，适合关闭文件描述符、取消 pending I/O 等异步清理 - 所有带
std::stop_token的阻塞函数都要求 token 有效（非 default-constructed），否则行为未定义
为什么不能在析构里直接调用 stop()，以及怎么避免竞态
std::jthread::request_stop() 是线程安全的，但调用时机很关键：
- 如果在
std::jthread对象析构前未显式调用request_stop()，jthread析构会自动调用它 —— 这没问题 - 但如果子线程正在执行耗时清理（比如写入日志文件），而主线程已离开作用域，
jthread析构会阻塞等待，可能卡住整个程序 - 更隐蔽的问题：多个地方同时调用
request_stop()没问题（幂等），但若子线程已自然退出，再调用不会报错，也不会唤醒已销毁的条件变量
建议做法：
- 显式调用
worker.request_stop()，然后根据需要决定是否join()或detach()（通常选前者） - 若子线程可能长时间阻塞在系统调用中（如无超时的
read），需额外机制（如 signalfd、eventfd 或 socketpair）配合stop_callback中断 - 不要依赖
stop_token的生命周期来控制资源，它只是信号载体；资源管理仍靠 RAII（比如用std::unique_ptr管理 socket）
真正容易被忽略的是：std::stop_token 本身不携带状态变更通知，它只是“查询接口”。所有响应逻辑必须由开发者在循环/阻塞点显式编写，C++ 不会自动注入中断点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
