一、从“一团乱麻”到“井然有序”：为什么需要结构化并发？

想象一下，你正在管理一个项目。老派的做法可能是：你同时下达了十几个任务给不同的人，然后你就需要时刻盯着，谁做完了？谁出错了？出错的任务会不会影响到其他任务？如果项目中途要取消，你怎么通知所有人立刻停下？整个过程就像手里抓着一大把线头，很容易乱成一团。

传统的多线程编程（比如直接用 std::thread）就有点像这种“老派管理”。你创建（launch）了一堆线程，它们就像脱缰的野马一样跑出去。你需要自己用 join 来等待它们结束，用互斥锁（mutex）来防止它们打架，处理异常更是棘手——一个线程崩溃了，可能其他线程还在傻傻地运行，导致程序状态错乱。

“结构化并发”就是为了解决这种混乱而生的编程思想。它的核心理念很简单：并发任务的生命周期应该严格嵌套在其调用者的生命周期之内。就像在一个函数里，所有局部变量都会在函数退出时自动销毁一样，在结构化并发中，所有并发子任务都必须在父任务（比如一个函数）退出前完成。这样，并发就有了清晰、可预测的结构，就像乐高积木一样可以安全地组合和拆卸。

C++20 引入的 std::jthread 和 std::stop_token，以及第三方库如 libunifex（Sender/Receiver模型的基础），都是推动C++走向结构化并发的重要一步。但最直观、最“结构化”的体现，我们可以通过一个经典的模型来理解：async/await。虽然C++标准库还没有直接提供，但我们可以用现有的工具模拟其思想，或者展望未来。

二、核心武器库：C++20带来的关键工具

在深入模式之前，我们先看看C++20提供的几件关键“装备”，它们是构建结构化并发的基础。

技术栈声明：本文所有示例均使用 C++20 标准库。

1. std::jthread：更友好的线程 std::jthread 是 std::thread 的升级版。它有两个主要优点：一是会在析构时自动join（或request_stop），防止你忘记等待导致程序终止；二是内置了协作式中断机制。

#include <iostream>
#include <thread>
#include <chrono>

void simple_worker(std::stop_token stoken) {
    while (!stoken.stop_requested()) {
        std::cout << "Worker is running...\n";
        std::this_thread::sleep_for(std::chrono::seconds(1));
    }
    std::cout << "Worker received stop request, exiting gracefully.\n";
}

int main() {
    // 创建一个 jthread，传入可中断的工作函数
    std::jthread worker(simple_worker);

    // 主线程等待3秒
    std::this_thread::sleep_for(std::chrono::seconds(3));

    // 不需要显式调用 worker.join()，析构时会自动处理。
    // 但这里我们显式请求停止，以展示协作中断。
    worker.request_stop();

    // main函数结束，worker自动join，确保线程在作用域结束前完成。
    return 0;
}
// 注释：`std::jthread`的析构函数确保了线程资源的自动回收，这是迈向结构化生命周期管理的第一步。

2. std::stop_token / std::stop_source：优雅的停止信号 这一组对象实现了线程间的协作式停止请求。stop_source是信号的发送端，stop_token是接收端。父任务持有stop_source，并传递stop_token给子任务。当父任务想取消所有子任务时（比如超时或用户取消），只需调用stop_source.request_stop()，所有子任务通过检查自己的stop_token就能得知并安全退出。

三、模式解析：两种主流的结构化并发实现思路

## 3.1 基于 std::async 与 std::future 的“伪结构化”

C++11 的 std::async 和 std::future 提供了一种类似“异步函数调用”的体验。它通过返回一个future对象来代表异步操作的结果，并且通常与std::launch::async策略一起使用。虽然不完全符合最严格的结构化定义（因为它的生命周期控制不够强），但用得好，也能写出结构清晰的代码。

#include <iostream>
#include <future>
#include <numeric>
#include <vector>

// 一个计算密集型的任务：计算向量部分和
int compute_partial_sum(const std::vector<int>& data, int start, int end) {
    std::cout << "Computing sum from index " << start << " to " << end-1 << " on thread: "
              << std::this_thread::get_id() << std::endl;
    return std::accumulate(data.begin() + start, data.begin() + end, 0);
}

int main() {
    std::vector<int> big_data(1000);
    std::iota(big_data.begin(), big_data.end(), 1); // 填充1到1000

    // 结构化地启动两个异步任务
    std::future<int> future1 = std::async(std::launch::async,
                                          compute_partial_sum,
                                          std::cref(big_data), 0, 500);
    std::future<int> future2 = std::async(std::launch::async,
                                          compute_partial_sum,
                                          std::cref(big_data), 500, 1000);

    // 主线程可以在这里做其他事情...
    std::cout << "Main thread is doing other work...\n";

    // **关键点**：通过 .get() 等待结果。这确保了main函数在返回前，
    // 两个异步任务必定已经完成。任务的生命周期被限制在main函数内。
    int sum1 = future1.get(); // 等待第一个任务完成并获取结果
    int sum2 = future2.get(); // 等待第二个任务完成并获取结果

    int total_sum = sum1 + sum2;
    std::cout << "Total sum is: " << total_sum << std::endl;

    return 0; // 所有异步任务已完结，安全退出。
}
// 注释：`future.get()` 起到了“等待并获取”的作用，将异步操作同步化到当前控制流中，形成了类似“fork-join”的结构。

关联技术：std::packaged_task 如果你想更灵活地控制任务的执行（比如放到特定的线程池），std::packaged_task 是你的好帮手。它把可调用对象包装起来，允许你手动在某个线程执行它，但最终结果还是通过future来获取。

#include <iostream>
#include <future>
#include <thread>
#include <queue>
#include <mutex>
#include <functional>

// 一个简单的任务队列
std::queue<std::function<void()>> tasks;
std::mutex queue_mutex;

void worker_thread() {
    while (true) {
        std::function<void()> task;
        {
            std::lock_guard<std::mutex> lock(queue_mutex);
            if (tasks.empty()) break; // 简单示例，队列空则退出
            task = std::move(tasks.front());
            tasks.pop();
        }
        task(); // 执行任务
    }
}

int main() {
    // 创建一个 packaged_task，它计算 7*8
    std::packaged_task<int()> task([](){ return 7 * 8; });

    // 获取与这个任务关联的 future
    std::future<int> result = task.get_future();

    // 将任务（以可执行形式）放入队列
    {
        std::lock_guard<std::mutex> lock(queue_mutex);
        // 将task转换为void()，因为队列存储的是无参无返回的函数
        tasks.push([&task](){ task(); });
    }

    // 启动工作线程
    std::thread worker(worker_thread);
    worker.detach(); // 简单示例，使用detach

    // 主线程等待结果，结构依然清晰
    std::cout << "Waiting for the result from worker thread...\n";
    int value = result.get(); // 阻塞直到任务完成并返回值
    std::cout << "The result is: " << value << std::endl;

    return 0;
}
// 注释：`std::packaged_task` 分离了任务的“创建”、“执行”和“结果获取”，提供了比`std::async`更底层的控制，但依然通过`future`保持了结果获取的结构化。

## 3.2 基于“等待多个任务”的模式：std::when_all

真正的并发往往需要同时启动多个任务，然后等待它们全部完成。手动一个个get() future 很麻烦。C++20 为 std::future 和 std::shared_future 提供了 std::when_all 这个等待器（在 <future> 中），它可以等待一组future全部就绪，是构建复杂结构化工作流的关键。

#include <iostream>
#include <future>
#include <vector>
#include <chrono>
#include <random>

// 模拟一个耗时的网络请求
std::string fetch_data_from_server(const std::string& server_name, int delay_ms) {
    std::cout << "[" << server_name << "] Fetching data...\n";
    std::this_thread::sleep_for(std::chrono::milliseconds(delay_ms));
    return "Data from " + server_name;
}

int main() {
    // 模拟向三个不同的服务器发起请求
    auto future1 = std::async(std::launch::async,
                              fetch_data_from_server, "Server-A", 1200);
    auto future2 = std::async(std::launch::async,
                              fetch_data_from_server, "Server-B", 800);
    auto future3 = std::async(std::launch::async,
                              fetch_data_from_server, "Server-C", 1500);

    // 使用 std::when_all 创建一个 future，它代表“所有这三个future都完成”
    // when_all 返回一个 future<std::tuple<...>> 或 future<std::vector<...>>
    auto all_done = std::when_all(future1.share(), future2.share(), future3.share());
    // 注意：这里使用了 .share() 获取 shared_future，以便放入 tuple。

    std::cout << "Launched all requests. Waiting for all to complete...\n";

    // 等待所有任务完成
    auto results_tuple = all_done.get(); // 阻塞，直到三个请求都返回

    // 解包结果
    auto& [result1, result2, result3] = results_tuple;

    std::cout << "\nAll data received:\n";
    std::cout << "- " << result1.get() << std::endl; // shared_future 用 .get()
    std::cout << "- " << result2.get() << std::endl;
    std::cout << "- " << result3.get() << std::endl;

    std::cout << "Main process finished.\n";
    return 0;
}
// 注释：`std::when_all` 将多个异步操作组合成一个逻辑单元进行等待，极大地简化了“等待所有子任务完成”的代码，是结构化并发中“汇聚（Join）”模式的直接体现。

四、应用场景、优缺点、注意事项与总结

## 4.1 典型应用场景

  • 并行计算与数据处理：如图像处理、科学计算中，将数据分块，用多个async任务并行处理，最后用when_all汇总。
  • 高性能服务器：同时处理多个客户端请求，每个请求可能涉及多个独立的I/O操作（如查询多个数据库），使用结构化并发可以清晰管理这些操作的生命周期。
  • UI/游戏开发：将耗时的计算（如资源加载、路径查找）放到后台线程，通过future在完成后更新UI，避免界面卡顿。同时，利用stop_token可以响应用户取消操作。
  • 流水线（Pipeline）：虽然更复杂，但结合future链式调用（.then在C++标准中尚未支持，但第三方库或自己实现类似概念），可以构建结构化的数据处理流水线。

## 4.2 技术优缺点

优点：

  1. 生命周期清晰：任务不会泄露，父作用域结束前子任务必然完成，避免资源泄漏和悬空引用。
  2. 错误传播自然：子任务中的异常可以通过future.get()传播到父任务，便于集中错误处理。
  3. 可读性与可维护性高：代码顺序与执行逻辑更接近，降低了理解并行代码的脑力负担。
  4. 易于组合：像when_all这样的组合器，使得将简单并发任务组合成复杂工作流变得容易。

缺点与局限：

  1. C++标准库支持仍在演进：真正的async/await语法糖、更丰富的调度器和组合器（如when_any, schedule）在标准库中还不完善，需要依赖第三方库（如 Facebook 的 folly::Future 或 libunifex）。
  2. 性能开销：std::async 可能使用线程池也可能创建新线程，存在一定开销。对于极高性能的场景，可能需要更底层的控制。
  3. 灵活性相对受限：相比直接操作线程，结构化模式为了安全牺牲了一些底层灵活性（比如直接操作线程局部存储）。

## 4.3 注意事项

  1. 避免在 std::async 中默认启动策略：std::async(func) 的默认启动策略是 std::launch::async | std::launch::deferred，这意味着函数可能被延迟执行（同步），破坏并发假设。务必显式指定 std::launch::async。
  2. 小心 future 的析构阻塞：对于由 std::async 启动的、未延迟的任务，其返回的 future 在析构时会隐式等待任务结束。这有时会导致意料之外的阻塞点。最好显式管理 future 的生命周期。
  3. stop_token 是协作式的：线程函数必须主动定期检查 stop_token 才能响应停止请求。对于不包含循环的短任务或阻塞在无法中断的调用上的任务，此机制无效。
  4. 死锁风险依然存在：结构化并发降低了数据竞争和生命周期错误的风险，但如果在并发任务间存在复杂的互斥锁依赖，死锁风险依然存在。

## 4.4 总结

现代C++的结构化并发编程模式，通过 std::jthread、std::stop_token、std::future 和 std::when_all 等工具，为我们提供了从“线程管理泥潭”中脱身的有力武器。它强调将并发任务的执行流像搭积木一样嵌入到现有的函数调用结构中，使得并发的代码具有与顺序代码相似的可读性和可维护性。

虽然C++标准库目前提供的还不是最完美的“结构化并发”终极形态（比如像C#或Python中那样直观的async/await），但现有的工具已经足以让我们编写出更安全、更清晰的并发程序。其核心思想——“并发单元的寿命不应超过创建它的作用域”——是每一位C++开发者在处理多线程问题时都应该牢记的黄金法则。随着标准的发展（C++23/26对Executors和Senders/Receivers模型的引入），C++的结构化并发支持将会越来越强大和易用。现在就开始实践这些模式，无疑是面向未来高性能C++开发的明智之举。