90%的std::async阻塞源于future析构时隐式等待或默认策略误选：未显式指定std::launch::async时可能延迟执行，而future离开作用域会阻塞等待任务完成。
std::async 造成的阻塞，90% 是 future 析构时隐式等待或策略误选导致的，不是线程卡死，而是你没管好它的生命周期。
std::async 默认策略不保证异步执行
不显式指定 std::launch::async，就等于把执行时机交给实现：它可能选 std::launch::deferred，也可能混合策略。这意味着你调用完 std::async 后，任务根本没启动，直到你调用 future.get() 或 future.wait() 才在当前线程同步跑——表面看是“阻塞”，其实是“压根没异步”。
- 现象：
std::cout << "before"; std::async([]{ std::this_thread::sleep_for(2s); }); std::cout << "after";输出立刻是beforeafter，但你以为的“后台睡 2 秒”根本没发生 - 解决：强制指定策略：
std::async(std::launch::async, ...)，至少能确保系统尝试开新线程（资源允许前提下） - 注意：即使写了
std::launch::async，若系统线程数已达上限，部分标准库实现（如旧版 libstdc++）仍可能静默 fallback 到 deferred，建议用future.wait_for(1ms) == std::future_status::timeout快速验证是否真在异步跑
std::future 析构时阻塞等待完成
这是最隐蔽也最常被忽略的阻塞源：当 std::future 对象离开作用域（比如函数返回、大括号结束），且它关联的是 std::launch::async 任务，其析构函数会**阻塞主线程，直到任务结束**——哪怕你从没调用过 get() 或 wait()。
- 现象：函数末尾无输出、程序退出前卡住几秒、Valgrind 报告“still reachable”线程栈
- 示例：
{ auto f = std::async(std::launch::async, []{ std::this_thread::sleep_for(3s); }); }—— 这里f析构会等满 3 秒 - 对策：显式控制生命周期，三选一：
• 立即f.get()（适合必须等结果的场景）
• 显式f.wait()+ 后续再get()（避免拷贝结果）
• 把future移出作用域，比如存入std::vector<std::future<void>>或传给其他对象管理
std::async 频繁调用引发线程爆炸与调度延迟
每次用 std::launch::async 调用 std::async，标准库通常创建一个新线程（尤其 GCC/libstdc++ 早期版本）。线程创建开销大（默认栈 1MB+），频繁调用会导致：
• std::system_error（resource unavailable）
• 线程切换抖动，实际吞吐反而下降
• 任务看似“不执行”，实则是排队等线程资源
立即学习“C++免费学习笔记（深入）”；
- 典型错误：循环中写
for (int i = 0; i < 1000; ++i) std::async(std::launch::async, process, i); - 替代方案：
• 改用线程池（如boost::asio::thread_pool或自建）
• 用std::packaged_task+ 复用线程
• 若只是 I/O 等待，考虑std::launch::deferred+ 主动触发，避免线程开销 - 验证方法：Linux 下用
ps -T -p $(pidof your_program) | wc -l查看线程数是否异常增长
异常未捕获导致的“静默崩溃”和析构阻塞叠加
异步任务抛出异常时，std::async 会把异常存进共享状态；但若你一直没调用 get()，异常就“卡”在那里——既不传播，也不释放资源。而当 future 析构时，它仍要等任务“完成”（包括异常退出），于是又触发一次阻塞等待。
- 现象：程序直接 abort，gdb 停在
std::future<...>::~future，堆栈显示std::thread::join - 关键点：
get()不仅取值，更是异常传播的唯一出口；不调get()= 放任异常滞留 + 强制析构阻塞 - 安全写法：
• 总用try { f.get(); } catch (...) { /* 处理 */ }
• 或至少确保每个future在析构前被消费（哪怕只调f.wait()）
真正难处理的从来不是“怎么让 async 跑起来”，而是“怎么让它跑完后不拖住你”。策略选错还能改，生命周期失控却会让阻塞出现在完全想不到的位置——比如某个临时 future 在 lambda 捕获后随外层作用域一起销毁。
