std::future::wait_for不能直接取消任务，因为它仅支持等待或超时，不提供通知线程停止的机制；线程必须主动检查外部取消标志（如std::atomic），否则任务会继续执行并导致资源失控。
std::future::wait_for 为什么不能直接取消任务
因为 std::future 本身不提供取消机制——它只能等待结果或超时，但无法通知正在运行的线程“停掉”。线程内部必须主动检查取消信号，否则 wait_for 超时后，任务仍在后台跑，资源和逻辑都失控。
常见错误是只写：
auto fut = std::async(std::launch::async, heavy_work);<br>fut.wait_for(std::chrono::seconds(3)); // ❌ 超时了，但 heavy_work 还在执行
- 超时后
fut.valid()仍为true，且后续调用fut.get()会阻塞直到完成 - 没有共享的取消标记，线程完全“听不到”外面的超时决定
-
std::async启动的任务无法被外部中断（C++20 之前无std::jthread的 stop_source 支持）
用 std::atomic + 循环检测实现协作式取消
这是最轻量、兼容 C++11 的做法：把取消标志做成全局可读的 std::atomic<bool></bool>，任务函数在关键循环点检查它。
示例场景：一个需要 5 秒才能完成的模拟计算，但只允许最多运行 2 秒：
std::atomic<bool> g_cancel_requested{false};<br><br>int compute_with_cancellation() {<br> for (int i = 0; i if (g_cancel_requested.load()) {<br> return -1; // 明确返回取消状态<br> }<br> // 模拟工作<br> std::this_thread::sleep_for(std::chrono::microseconds(2000));<br> }<br> return 42;<br>}<br><br>// 主线程<br>auto thread = std::thread([&]() {<br> compute_with_cancellation();<br>});<br>if (thread.joinable()) {<br> if (std::future_status::timeout ==<br> std::async(std::launch::deferred, []{}).wait_for(std::chrono::seconds(2))) {<br> g_cancel_requested.store(true); // 触发取消<br> thread.join();<br> }<br>}</bool>
- 必须在耗时操作中**频繁检查**
g_cancel_requested，否则响应延迟高 - 避免在临界区、锁内或系统调用（如
read()）中检查——可能卡住无法响应 - 不要用普通
bool，非原子访问在多线程下有未定义行为
C++20 std::jthread 和 std::stop_token 怎么用
这是标准给出的原生取消支持，比手动原子变量更安全、语义更清晰，但要求编译器支持 C++20（GCC 10+/Clang 12+）。
核心是 std::jthread 自带 std::stop_source，可通过 get_stop_token() 传入任务函数：
int compute_with_stop_token(std::stop_token stoken) {<br> for (int i = 0; i if (stoken.stop_requested()) {<br> return -1;<br> }<br> std::this_thread::sleep_for(std::chrono::microseconds(2000));<br> }<br> return 42;<br>}<br><br>// 使用<br>std::jthread t{compute_with_stop_token};<br>std::this_thread::sleep_for(std::chrono::seconds(2));<br>t.request_stop(); // 安全触发取消<br>t.join();
-
std::stop_token是轻量值类型，可拷贝、可传参，比捕获std::stop_source*更自然 -
request_stop()是线程安全的，多次调用无副作用 - 注意：
std::jthread析构时自动join()，若不想阻塞，需提前调用detach()
超时取消和异常安全怎么兼顾
如果任务中抛出异常，而主线程同时在超时后调用 request_stop() 或置原子标志，容易遗漏清理。关键在于：取消响应点必须能覆盖异常路径。
- 用 RAII 封装取消注册（例如构造时 add_observer，析构时 remove），但 C++ 标准库没提供 stop_callback 的自动管理，需自己 wrap
- 更实用的做法是在每个可能 throw 的操作前后都检查取消标志，或把主逻辑包在
try/catch内，并在 catch 块末尾再查一次stop_requested() - 避免在析构函数里做耗时取消等待——可能引发
std::terminate - 如果使用
std::async，别依赖其 future 的生命周期来控制线程；它可能延迟启动或转为 deferred，行为不可控
真正难的不是加个超时判断，而是让每个子任务都理解“取消不是中断，是协商退出”。漏掉一次检查，就可能让整个流程卡死或资源泄漏。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
