C++并发编程中std::async的异常安全陷阱与最佳实践

1. 项目概述：为什么我们需要关注std::async的异常安全？

在C++并发编程的世界里，std::async是一个让开发者又爱又恨的工具。爱它，是因为它用起来太方便了，几行代码就能把函数丢到后台去异步执行，仿佛给单线程程序插上了翅膀。恨它，是因为当程序出现异常时，这份“方便”背后隐藏的陷阱，足以让一个看似稳定的系统在深夜崩溃，而你却对着日志百思不得其解。

我见过太多项目，在开发测试阶段一切顺利，一旦上线承受真实负载，各种诡异的“僵尸任务”、“内存泄漏”和“未捕获异常导致进程退出”的问题就冒出来了。追根溯源，很多问题都出在对std::async异常安全性的忽视上。大家往往只关注它“启动任务”的功能，却忽略了它“管理任务生命周期和异常传播”的职责。这就像你只记得开车要踩油门，却忘了刹车和方向盘同样重要。

简单来说，std::async的异常安全性讨论的是：当一个异步任务内部抛出异常时，这个异常会被如何处理？调用std::future::get()的线程会不会被意外终止？任务所占用的资源（如线程、内存）能否被正确释放？程序的整体状态是否会因此被破坏？如果你在使用std::async时，从未考虑过这些问题，那么你的并发代码很可能建立在流沙之上。

2. std::async的工作机制与异常传播路径

要理解异常安全性，必须先吃透std::async的工作机制。它不仅仅是一个函数调用包装器，更是一个连接“异步执行”和“同步获取结果”的桥梁。

2.1 std::async的两种启动策略

当你调用std::async时，可以通过第一个参数指定启动策略，这直接决定了异常行为的底层逻辑：

1. std::launch::async： 系统会尝试（通常是必须）在一个新的线程中执行任务。这意味着任务函数体（包括其中可能抛出的异常）在一个独立的执行上下文中运行。这个策略下，任务的执行是真正并发的。
2. std::launch::deferred： 任务被延迟执行。它不会立即启动，而是被“惰性”地保存起来。只有当调用其返回的std::future对象的get()或wait()函数时，任务才会在调用者的线程中同步执行。这更像一个延迟计算，而非并发。

如果不指定策略，即使用默认参数std::async(func)，那么标准允许实现库在async和deferred之间自由选择。这是一个重要的“坑点”，因为不同的策略下，异常抛出的时机和位置完全不同，直接影响你的异常处理逻辑。

2.2 异常的“旅程”：从任务内部到future对象

当任务函数中抛出一个异常时，无论采用哪种启动策略，这个异常都不会像普通函数调用那样直接终止当前线程。std::async的底层机制会捕获这个异常，并将其存储在与该任务关联的std::future对象内部的一个特殊共享状态中。

你可以把这个共享状态想象成一个“异常盒子”。任务线程（对于async策略）或调用线程（对于deferred策略）负责把抛出的异常原封不动地放进这个盒子里。此后，当你在主线程（或其他任何线程）中调用future.get()时，get()函数会打开这个盒子。如果盒子里装的是一个异常，那么get()会立即在调用get()的线程中重新抛出这个异常。

这个过程就是异常从子执行上下文传播到主执行上下文的关键。理解这一点至关重要：异常是在get()调用点抛出的，而不是在原始任务抛出的那一刻。这给了调用者一个明确的、同步的时机来处理异步操作中发生的错误。

注意：这里有一个非常隐蔽的陷阱。对于std::launch::deferred策略，因为任务是在调用get()时才执行的，所以异常的产生和抛出完全发生在调用get()的线程栈上，其行为与直接调用一个普通函数并无二致。但对于std::launch::async，异常的产生和存储发生在新线程，而抛出发生在调用get()的线程，这是两个不同的线程栈。

3. 异常安全性的核心挑战与四大风险点

使用std::async时，如果对异常处理不当，会引发一系列连锁反应，我将其归纳为四大核心风险点。

3.1 风险一：异常被默默吞噬与资源泄漏

这是最常见也最危险的问题。看看下面这段代码：

void risky_task() { std::vector<int> data = fetch_data_from_network(); // 可能抛异常 process(data); // 也可能抛异常 } int main() { // 启动异步任务，但不保存或等待其future std::async(std::launch::async, risky_task); // 或者保存了future但从未调用get()或wait() // auto fut = std::async(std::launch::async, risky_task); std::cout << "Main thread continues...\n"; std::this_thread::sleep_for(std::chrono::seconds(2)); return 0; }

这段代码的问题在于，std::async返回的future对象是一个临时量，在表达式结束后立即被析构。根据C++标准，std::future的析构函数会阻塞，直到与其关联的异步操作完成（对于async策略）。这听起来似乎保证了任务完成？但关键在于阻塞析构并不会处理存储的异常！

如果risky_task在执行中抛出异常，这个异常会被存储到future内部的共享状态。随后，当临时future对象析构时，它检测到共享状态中有一个“未被检索的异常”。此时，标准库的行为是：调用std::terminate()终止整个程序。你的程序会突然崩溃，你可能连一条错误日志都看不到。

更糟糕的情况是，如果任务中发生了资源泄漏（例如，new了内存但没delete，或者打开了文件没关闭），程序被terminate，这些资源将永远无法被释放。

实操心得：永远不要忽略std::async的返回值。即使你不关心任务的结果，也必须将返回的std::future对象保存到一个变量中，并在适当的时候调用get()或wait()，以确保异常能被显式处理，避免程序无声无息地崩溃。

3.2 风险二：future析构时的隐式阻塞与死锁

如上所述，std::future的析构函数可能阻塞。这一点经常被低估。考虑一个复杂场景：

std::future<void> launch_detached_task() { return std::async(std::launch::async, [] { std::this_thread::sleep_for(std::chrono::seconds(10)); std::cout << "Long task done.\n"; }); } int main() { { auto fut = launch_detached_task(); // 我们希望fut离开作用域时，不阻塞主线程。 // 但事实上，fut析构时会等待10秒！ } // 这里会阻塞10秒，直到后台任务完成 std::cout << "Scope exited.\n"; return 0; }

launch_detached_task返回的future在main函数的内部作用域结束时析构。因为它关联着一个尚未完成的async任务，所以析构函数会一直等待那个任务完成（睡眠10秒）。这完全违背了我们“发射后不管”的初衷，导致了意外的同步和阻塞。

如何实现真正的“发射后不管”？标准库提供了std::future的兄弟std::shared_future，但其析构行为类似。一个常见的、符合标准的做法是，将std::future移动到一个专门的后台管理线程或全局队列中，由这个管理器负责在其生命周期内持有这些future并在程序退出前统一处理。但这增加了架构复杂度。另一种非标准但实用的方法是，使用std::thread配合自定义的异常处理逻辑，但这失去了std::async和std::future的便利性。

3.3 风险三：异常类型丢失与错误信息模糊化

std::future存储和重新抛出的是任务中抛出的原始异常。这既是优点也是缺点。优点是信息完整；缺点是，如果你希望统一处理所有异步错误，将变得困难。

void task1() { throw std::runtime_error("Database connection failed"); } void task2() { throw std::invalid_argument("Input value is negative"); } int main() { auto f1 = std::async(task1); auto f2 = std::async(task2); try { f1.get(); f2.get(); } catch (const std::runtime_error& e) { std::cerr << "Task1 error: " << e.what() << std::endl; } catch (const std::invalid_argument& e) { std::cerr << "Task2 error: " << e.what() << std::endl; } catch (...) { std::cerr << "Unknown error from async task.\n"; } return 0; }

这段代码的异常处理是类型安全的，但前提是你知道所有可能抛出的异常类型。在大型项目中，异步任务可能来自不同的模块，抛出各种各样的异常。用一个catch(...)会丢失具体的异常类型信息，不利于精准恢复或记录。你需要在任务内部就将异常转换为某种统一的错误码或日志信息，但这又破坏了异常的灵活性。

3.4 风险四：与RAII和线程局部存储（TLS）的交互问题

这是更深层次的问题。如果一个任务使用了RAII对象（如锁std::lock_guard），并且在对象析构前抛出了异常，RAII机制能保证资源被释放吗？对于std::launch::async策略，答案是肯定的，因为异常是在任务线程内部抛出，栈回滚会触发该线程栈上所有局部对象的析构。但对于deferred策略，由于任务在调用get()的线程上运行，其RAII对象属于那个线程的栈，同样安全。

线程局部存储（Thread Local Storage, TLS）则更棘手。假设任务函数内部访问了一个thread_local变量，当任务以async策略执行时，它访问的是新线程的TLS实例。如果任务中修改了这个TLS变量，然后抛出异常，这个修改过的状态会随着该线程的结束而消失。调用get()的线程无法感知到这个TLS状态的变化，因为它们是不同的线程。如果你的程序逻辑依赖于通过TLS传递上下文或状态，异步任务中的异常可能会使这种依赖关系断裂，导致上下文丢失。

4. 构建异常安全的std::async使用模式

知道了风险，我们来看看如何构建健壮的使用模式。核心思想是：显式管理future生命周期，集中处理异常，并利用现代C++特性增强安全性。

4.1 基础模式：必选的future保存与get调用

这是最基本的防线。对于每一个std::async调用，你必须处理其返回的future。

// 安全模式示例 std::future<ResultType> safe_async_operation() { // 可能的话，明确指定启动策略，避免不确定性 return std::async(std::launch::async, []() -> ResultType { // ... 执行可能抛出异常的工作 ... if (error_condition) { throw MyCustomException("Something went wrong"); } return result; }); } int main() { try { auto fut = safe_async_operation(); // ... 主线程可以同时做其他工作 ... // 最终，必须尝试获取结果以触发异常传播 auto result = fut.get(); // 异常可能在此处抛出 use(result); } catch (const MyCustomException& e) { // 集中处理来自异步任务的特定异常 std::cerr << "Async operation failed: " << e.what() << std::endl; // 执行恢复逻辑，如重试、回滚、使用默认值等 handle_failure(); } catch (...) { // 兜底处理，至少记录日志，避免程序被std::terminate std::cerr << "Unknown exception from async task.\n"; log_error(); } return 0; }

4.2 进阶模式：使用std::packaged_task与自定义线程池

对于需要更精细控制或避免future析构阻塞的场景，可以降级使用std::packaged_task。std::async可以看作是std::packaged_task加上一个默认启动策略的快捷方式。

#include <future> #include <thread> #include <queue> #include <mutex> #include <condition_variable> #include <vector> #include <iostream> class SimpleThreadPool { public: SimpleThreadPool(size_t num_threads) : stop(false) { for(size_t i = 0; i < num_threads; ++i) { workers.emplace_back([this] { for(;;) { std::function<void()> task; { std::unique_lock<std::mutex> lock(this->queue_mutex); this->condition.wait(lock, [this]{ return this->stop || !this->tasks.empty(); }); if(this->stop && this->tasks.empty()) return; task = std::move(this->tasks.front()); this->tasks.pop(); } task(); // 在这里执行任务，异常会被packaged_task内部捕获并存储到future } }); } } template<class F, class... Args> std::future<typename std::result_of<F(Args...)>::type> enqueue(F&& f, Args&&... args) { using return_type = typename std::result_of<F(Args...)>::type; auto task = std::make_shared<std::packaged_task<return_type()>>( std::bind(std::forward<F>(f), std::forward<Args>(args)...) ); std::future<return_type> res = task->get_future(); { std::unique_lock<std::mutex> lock(queue_mutex); if(stop) throw std::runtime_error("enqueue on stopped ThreadPool"); tasks.emplace([task](){ (*task)(); }); } condition.notify_one(); return res; } ~SimpleThreadPool() { { std::unique_lock<std::mutex> lock(queue_mutex); stop = true; } condition.notify_all(); for(std::thread &worker: workers) worker.join(); } private: std::vector<std::thread> workers; std::queue<std::function<void()>> tasks; std::mutex queue_mutex; std::condition_variable condition; bool stop; }; // 使用示例 int main() { SimpleThreadPool pool(4); std::vector<std::future<int>> futures; for(int i = 0; i < 10; ++i) { futures.emplace_back(pool.enqueue([i] { std::this_thread::sleep_for(std::chrono::milliseconds(100)); if(i == 5) throw std::logic_error("Task 5 always fails!"); return i * i; })); } // 集中收集和处理结果与异常 for(auto& fut : futures) { try { int value = fut.get(); // 异常在此处被抛出 std::cout << "Result: " << value << std::endl; } catch (const std::exception& e) { std::cerr << "Task failed with exception: " << e.what() << std::endl; // 这里可以决定是继续处理其他future，还是终止循环 } } return 0; }

这种模式的优点：

1. 生命周期明确：future对象由用户显式保存在容器中，其析构发生在所有任务结果处理完毕之后，完全可控。
2. 避免隐式阻塞：线程池管理线程的生命周期，future的析构不再等待任务线程结束（因为任务在线程池的线程中执行，而线程池在程序最后才销毁）。
3. 资源可控：可以限制并发线程数量，避免无限制创建线程导致的系统资源耗尽。
4. 异常处理集中化：可以在一个循环里统一对所有future调用get()，进行集中的错误处理和日志记录。

4.3 使用std::future的扩展方法：valid()与share()

为了更安全地操作future，可以善用其成员函数。

• future.valid()：在调用get()或wait()之前，检查future是否关联着一个有效的共享状态。一个future在以下情况后会变为无效（valid() == false）：

  • 默认构造（未关联任务）。
  • 被移动赋值（资源转移给另一个future）。
  • 已经调用过get()（对于std::future，get()是消费型的，调用后共享状态被释放）。 在调用get()前检查valid()是一个好习惯，可以避免访问已释放状态导致的未定义行为。

• future.share()：将std::future转换为std::shared_future。shared_future可以被多次get()，并且可以被拷贝到多个地方。这在多个消费者等待同一个异步结果时很有用。但请注意，shared_future的析构行为与future类似，也可能阻塞。

auto fut = std::async(heavy_calculation); if (fut.valid()) { // 可以安全地等待或获取结果 auto shared_fut = fut.share(); // 转换为shared_future，fut变为无效 // 现在可以将shared_fut传递给多个处理函数 process_result_a(shared_fut); process_result_b(shared_fut); }

5. 实战：一个具备完整异常处理能力的异步任务管理器

让我们综合以上所有要点，设计一个用于生产环境的小型异步任务管理器。它需要具备以下功能：

1. 接收任何可调用对象作为任务。
2. 内部处理任务的执行和异常捕获。
3. 允许调用者查询任务状态、获取结果或异常。
4. 避免future析构导致的隐式阻塞。
5. 提供任务取消机制（简化版）。

#include <future> #include <functional> #include <memory> #include <mutex> #include <condition_variable> #include <thread> #include <queue> #include <vector> #include <atomic> #include <iostream> #include <stdexcept> class AsyncTaskResult { public: enum class Status { Pending, Running, Completed, Failed, Cancelled }; Status get_status() const { std::lock_guard<std::mutex> lock(mtx); return status; } // 等待任务完成（成功或失败） void wait() const { std::unique_lock<std::mutex> lock(mtx); cv.wait(lock, [this]{ return status != Status::Pending && status != Status::Running; }); } // 尝试获取结果。如果任务未完成则阻塞，如果失败则抛出存储的异常。 template<typename ResultType> ResultType get() { wait(); std::lock_guard<std::mutex> lock(mtx); if (status == Status::Failed && exception_ptr) { std::rethrow_exception(exception_ptr); } else if (status == Status::Cancelled) { throw std::runtime_error("Task was cancelled"); } else if (status == Status::Completed) { // 这里需要类型转换，实际实现可能需要类型擦除或模板特化，此处简化。 // 假设我们只处理返回int的任务作为示例。 return std::any_cast<ResultType>(result); } throw std::logic_error("Invalid task state"); } bool cancel() { std::lock_guard<std::mutex> lock(mtx); if (status == Status::Pending) { status = Status::Cancelled; cv.notify_all(); return true; } return false; // 任务已开始或结束，无法取消 } // ... 内部设置状态、结果、异常的方法（供任务管理器调用） ... private: mutable std::mutex mtx; mutable std::condition_variable cv; Status status = Status::Pending; std::any result; // C++17，用于存储任意类型结果 std::exception_ptr exception_ptr; }; class AsyncTaskManager { public: using TaskId = size_t; AsyncTaskManager(size_t num_workers = std::thread::hardware_concurrency()) : stop(false), next_id(0) { for (size_t i = 0; i < num_workers; ++i) { workers.emplace_back(&AsyncTaskManager::worker_loop, this); } } ~AsyncTaskManager() { { std::lock_guard<std::mutex> lock(queue_mtx); stop = true; } queue_cv.notify_all(); for (auto& w : workers) w.join(); } template<typename Func, typename... Args> std::shared_ptr<AsyncTaskResult> submit(Func&& func, Args&&... args) { auto task_result = std::make_shared<AsyncTaskResult>(); auto task_id = next_id++; { std::lock_guard<std::mutex> lock(queue_mtx); task_queue.emplace([task_result, func=std::forward<Func>(func), ...args=std::forward<Args>(args)]() mutable { execute_task(*task_result, std::move(func), std::move(args)...); }); } task_map[task_id] = task_result; queue_cv.notify_one(); return task_result; } // 查询、取消等管理函数... private: void worker_loop() { while (true) { std::function<void()> task; { std::unique_lock<std::mutex> lock(queue_mtx); queue_cv.wait(lock, [this]{ return stop || !task_queue.empty(); }); if (stop && task_queue.empty()) return; task = std::move(task_queue.front()); task_queue.pop(); } task(); // 执行包裹了execute_task的lambda } } template<typename Func, typename... Args> static void execute_task(AsyncTaskResult& result, Func func, Args... args) { // 实际执行用户函数，并捕获所有异常 try { auto ret = func(std::forward<Args>(args)...); result.set_result(std::move(ret)); // 假设有set_result方法 } catch (...) { result.set_exception(std::current_exception()); // 假设有set_exception方法 } } std::vector<std::thread> workers; std::queue<std::function<void()>> task_queue; std::mutex queue_mtx; std::condition_variable queue_cv; std::atomic<bool> stop; std::atomic<TaskId> next_id; std::unordered_map<TaskId, std::shared_ptr<AsyncTaskResult>> task_map; }; // 使用示例 int main() { AsyncTaskManager manager(2); auto task1 = manager.submit([]() -> int { std::this_thread::sleep_for(std::chrono::milliseconds(500)); throw std::runtime_error("Simulated failure in task 1"); return 42; }); auto task2 = manager.submit([]() -> int { std::this_thread::sleep_for(std::chrono::milliseconds(200)); return 100; }); // 非阻塞地等待并处理结果 std::thread result_handler([&] { try { int r2 = task2->get<int>(); std::cout << "Task2 succeeded: " << r2 << std::endl; } catch (const std::exception& e) { std::cerr << "Task2 error: " << e.what() << std::endl; } try { int r1 = task1->get<int>(); std::cout << "Task1 succeeded: " << r1 << std::endl; } catch (const std::runtime_error& e) { // 可以捕获特定异常 std::cerr << "Task1 runtime_error: " << e.what() << std::endl; } catch (const std::exception& e) { std::cerr << "Task1 general error: " << e.what() << std::endl; } }); result_handler.join(); return 0; }

这个管理器实现了核心目标：将std::async的易用性与std::packaged_task和线程池的可控性结合起来。它内部消化了future的生命周期管理，对外提供一个更安全的AsyncTaskResult句柄。异常被捕获并存储在exception_ptr中，直到用户调用get()时才重新抛出，给予了用户处理异常的完全控制权。

6. 常见陷阱排查与调试技巧

即使遵循了最佳实践，在实际调试中，与std::async异常相关的问题依然令人头疼。下面是一些我踩过坑后总结的排查技巧。

6.1 程序无声崩溃（std::terminate被调用）

现象：程序运行到一半突然退出，没有核心转储（core dump），控制台可能没有任何输出，或者只有简单的“terminate called”信息。

排查步骤：

1. 检查所有std::async调用：全局搜索代码中的std::async，确认每个调用返回的std::future对象都被保存到了变量中。临时future是首要嫌疑对象。
2. 检查future的析构时机：对于保存了的future，检查其生命周期。它是否在某个作用域结束时析构，而对应的异步任务还没有完成？如果是，析构的阻塞等待是正常的，但需要确认这是设计意图。如果任务抛异常且future在析构前未被get()，就会触发std::terminate。
3. 使用调试器或设置 terminate handler：可以设置自定义的std::terminate_handler来在程序终止前打印更多信息。

   #include <exception> #include <iostream> #include <cstdlib> void my_terminate_handler() { std::cerr << "std::terminate called!\n"; // 可以在这里打印堆栈信息（需要平台特定支持） std::abort(); // 或者直接退出 } int main() { std::set_terminate(my_terminate_handler); // ... 你的代码 ... }

4. 审查异常处理：确保在调用future.get()的代码外围有try...catch(...)块。即使你认为任务不会抛异常，加一个最外层的catch(...)记录日志也是好的防御性编程。

6.2 任务似乎未执行或结果丢失

现象：明明调用了std::async，但任务里的打印语句没输出，或者future.get()永远等不到结果。

可能原因及排查：

1. 启动策略为deferred：如果你没有指定策略或指定了std::launch::deferred，那么任务只有在调用future.get()或future.wait()时才会执行。检查你的启动策略。如果不确定，就在调用时显式指定std::launch::async。
2. 线程资源耗尽：当使用std::launch::async时，每次调用都可能创建一个新线程。如果短时间内发起大量调用，系统可能无法创建新线程，导致任务无法启动。标准规定，在这种情况下，实现库可以抛出std::system_error异常。因此，检查std::async调用本身是否被try...catch包围了。

   try { auto fut = std::async(std::launch::async, heavy_task); } catch (const std::system_error& e) { std::cerr << "Failed to launch async task: " << e.what() << std::endl; // 可能是资源不足，考虑使用线程池或排队机制 }

3. future对象被移动或无效：如果你将future移动给了另一个变量，原变量就失效了。对无效的future调用get()是未定义行为。养成在调用前用future.valid()检查的习惯。

6.3 性能问题：意外的同步点

现象：程序没有达到预期的并发加速效果，甚至比单线程还慢。

排查：

1. future析构阻塞：这是最大的性能杀手。在循环中大量创建临时future会导致严重的序列化。

   // 错误的做法：每次循环都会阻塞等待上一个任务完成 for (int i = 0; i < 1000; ++i) { auto result = std::async(std::launch::async, compute, i).get(); // 立即get，失去并发意义 } // 正确的做法：先启动所有任务，再收集结果 std::vector<std::future<Result>> futures; for (int i = 0; i < 1000; ++i) { futures.push_back(std::async(std::launch::async, compute, i)); } for (auto& f : futures) { auto result = f.get(); // 这里会按完成顺序或启动顺序等待 }

2. 任务粒度太细：创建和管理线程是有开销的。如果每个任务的计算量非常小（例如，只是做一次加法），那么线程创建和上下文切换的开销会远远超过计算本身。考虑将小任务批量处理。

6.4 调试工具与技巧

1. 给线程命名：在调试器中，一堆匿名线程很难区分。虽然C++标准没有提供线程命名，但大多数平台（如Linux的pthread，Windows的SetThreadDescription）有相关接口。可以在任务函数开头调用平台相关函数给线程命名，方便调试。
2. 输出线程ID：在任务中打印std::this_thread::get_id()，可以帮助你理解任务是在哪个线程上执行的，对于诊断deferred策略问题尤其有用。
3. 使用Future的wait_for/wait_until：在调试挂起问题时，不要盲目地调用get()阻塞。可以使用future.wait_for(std::chrono::seconds(1))来检查任务状态，如果超时仍未完成，可以输出警告日志，这有助于识别死锁或长时间运行的任务。
4. 记录异常上下文：当在catch块中处理来自异步任务的异常时，除了e.what()，尽量记录更多上下文信息，比如任务ID、发起时间、参数等。这能极大简化线上问题的排查。

7. 总结与最佳实践清单

回顾全文，确保std::async的异常安全性并非难事，关键在于转变思维，从“仅仅启动一个任务”转变为“管理一个带有生命周期的并发操作”。以下是我总结的、可以立刻应用到项目中的最佳实践清单：

1. 永远保存返回值：绝不忽略std::async的返回值。总是将其赋值给一个std::future变量。
2. 显式处理异常：在调用future.get()的地方，使用try...catch块。至少要用catch(...)兜底，防止异常逃逸导致std::terminate。
3. 明确启动策略：如果不希望任务被延迟执行，总是使用std::launch::async策略。避免依赖编译器的默认行为，这能消除不确定性。
4. 警惕future析构：理解std::future析构函数可能阻塞的行为。如果设计上需要“发射后不管”，请使用自定义的线程池和任务队列来管理生命周期，而不是依赖临时future。
5. 集中管理，避免散布：不要在整个代码库中随意使用std::async。考虑集中到一个“任务执行器”或“线程池”模块中。这有利于统一错误处理、资源控制和性能监控。
6. 超时与取消：对于可能长时间运行或挂起的任务，设计超时机制。可以使用future.wait_for()。虽然C++标准库没有提供直接的任务取消接口，但可以通过原子标志位（std::atomic<bool>）在任务函数内部定期检查来实现协作式取消。
7. 性能考量：对于大量、细粒度的任务，使用std::async创建线程的开销可能过大。此时，一个固定大小的线程池（如上面示例）是更好的选择。
8. 测试时模拟异常：在单元测试中，专门编写测试用例，模拟异步任务中抛出各种异常（标准异常、自定义异常、内存访问错误等），确保你的异常处理逻辑坚固可靠。

C++并发编程就像驾驶一辆高性能跑车，std::async给了你一脚强劲的油门，但异常安全性则是那套不可或缺的刹车和稳定系统。忽略它，你可能在直道上狂飙，但一个弯道或一点颠簸就足以让项目失控。花时间理解并处理好这些细节，你的并发代码才能真正做到既快又稳。