1. 一个结果，多个线程都要用：std::future 的尴尬处境
先讲一个我实际遇过的场景。前阵子写一个数据处理管线，上游有个耗时三秒左右的初始化任务，负责加载模型权重和配置文件。下游有三个独立模块要消费这份初始化结果，一个做数据校验，一个做特征提取，还有一个负责日志统计。最开始我图省事，直接用std::async返回一个std::future传给调用方，后面三个模块按顺序各自调用future.get()。
结果第二个模块第一次调用get()就抛异常，程序直接崩了。查了半天，问题出在std::future的语义上——它的get()会移动结果，把一个异步结果“消费”掉，第二个消费者根本拿不到东西。后来换用std::shared_future才彻底解决。
这就是std::shared_future存在的根本理由：当你需要一个异步结果被多个线程、多个模块或多次调用共享消费时，它允许每一个调用者都拿到一份完整的结果，而不是像std::future那样一次性转移所有权。
很多人第一次接触std::shared_future时会觉得它不过是“能在多个线程里用的future”，但实际用下来会发现，它的使用逻辑、底层状态管理、甚至异常传播规则都和std::future有微妙差别。这篇文章我会从一个完整的多线程消费场景入手，把std::shared_future的构造方式、底层机制、接口细节、异常处理，以及我在实际工程里踩过的坑一并梳理清楚。
适合谁看？正在写多线程程序的 C++ 开发者，尤其是对std::async、std::promise有一定了解但还没深入使用过共享future的人。如果你只是偶尔用一次std::future，这篇文章也能帮你把异步结果的生命周期理解得更透彻。
2. 从 std::future 迁移到 std::shared_future：核心使用逻辑
2.1 一次 get() 和多次 get() 的本质差别
std::future的设计哲学是“所有权独占”。你调用get()时，标准库实现会把共享状态里存的结果直接移动到返回值里，同时清空内部状态，所以第二次get()必然触发std::future_error。我特意写了个最小复现场景，帮你直观感受这种差异：
#include <iostream> #include <future> #include <stdexcept> int main() { std::future<int> fut = std::async(std::launch::async, []() { return 42; }); std::cout << "第一次 get: " << fut.get() << std::endl; try { std::cout << "第二次 get: " << fut.get() << std::endl; } catch (const std::future_error& e) { std::cerr << "捕获到 future_error: " << e.what() << std::endl; } return 0; }你可以自己跑一下，第二次get()抛出的异常信息通常是std::future_error: No state或者类似描述，意思就是结果已经被转移走了。
std::shared_future则完全不同。它的get()内部返回的是const引用，也就是说只是把共享状态里的结果读出，不移动所有权。同一个shared_future对象，不管调用多少次get()，都能正常返回。它天然就支持“一结果、多消费”的语义。
这里有一个非常关键但容易忽略的点：std::shared_future这个名字里的shared指的是共享状态所有权，而不是指结果本身被多个shared_future对象共同引用。如果把一个shared_future拷贝给多个线程，每个线程持有的是不同对象，但它们指向同一个底层共享状态，所以get()时拉取的是同一份结果。
2.2 三种构造/获取方式，以及各自的使用注意点
我实际用下来，std::shared_future的来源有三种。
方式一：从std::future移动构造
这是最直接、语法成本最低的方式：
std::future<int> fut = std::async(std::launch::async, []() { return 100; }); std::shared_future<int> shared_fut(std::move(fut)); // 后面就可以让多个线程使用 shared_fut 的副本需要注意，移动之后原来的fut.valid()返回false，不能再用了。这是 C++ 移动语义的标准行为，但容易在重构时被遗忘——我之前就在一段代码里移动构造shared_future之后又顺手调用了原future的wait()，结果自然是未定义行为。
方式二：使用std::future::share()
这是我最推荐的方式，语义表达最清晰：
auto shared_fut = std::async(std::launch::async, []() { return 3.14; }).share();share()方法内部会构造一个std::shared_future<T>，然后把自己（原future）移动到新对象里，并清空原对象。注意 C++11 以后这个接口是标准成员函数，不需要额外传参。代码读起来一目了然，很符合“我要共享这个结果”的意图。
方式三：通过std::promise::get_future()拿
如果你是用std::promise手动管理异步任务，那么：
std::promise<std::string> prom; std::shared_future<std::string> shared = prom.get_future().share(); // 或者 std::shared_future<std::string> shared2(prom.get_future()); // 移动构造上面两种写法等价，都要求从get_future()获得的临时 future 转移到shared_future。不管用哪种，核心逻辑都一样：shared_future和原始 future 共享同一个异步状态，只是所有权由独占转为了共享。
2.3 一个最小多线程共享示例
下面这个例子虽然简单，但很能说明问题。我开四个线程，共同等待一个shared_future的结果，每个线程都执行get()，结果谁都不会抛出异常：
#include <iostream> #include <future> #include <thread> #include <vector> int main() { auto shared_fut = std::async(std::launch::async, []() { std::this_thread::sleep_for(std::chrono::milliseconds(100)); return 42; }).share(); std::vector<std::thread> threads; for (int i = 0; i < 4; ++i) { threads.emplace_back([index = i, sf = shared_fut]() mutable { int value = sf.get(); std::cout << "线程 " << index << " 拿到结果: " << value << std::endl; }); } for (auto& t : threads) { t.join(); } return 0; }注意这段代码里我给每个线程拷贝了一份shared_future，而不是让多个线程共享同一个对象。这是有意为之：shared_future本身虽然提供并发安全的get()和wait()，但同一个shared_future对象的并发成员函数调用并没有问题（标准库保证这些操作是同步的），真正要避免的是多个线程同时调用同一个对象上非线程安全的成员，比如valid()。不过从逻辑清晰度和可维护性出发，每线程持有一个副本是更稳妥、也更符合直觉的写法。
3. 底层机制：共享状态与引用计数到底怎么回事
3.1 “共享状态”这个抽象概念
你不需要去读标准库里shared_future的源码就能理解它，但有一个抽象概念必须掰扯清楚：共享状态。
std::future、std::shared_future、std::promise、std::packaged_task这些组件，本质上都是围绕同一个“共享状态”在包装。这个共享状态里存了三样东西：
- 异步任务的返回值（或者异常对象）
- 一个是否就绪的标记
- 一个引用计数
在std::future的语境下，当它和std::promise配对时，二者共同持有这个共享状态。为了简化，标准库假定这个状态是在堆上分配的，由promise和future一起维护生命周期。std::future被移动后，源对象不再指向该状态，目标对象接管。get()后结果被移出，状态本身理论上还在，但已经不再保存结果了。
而std::shared_future的语义相当于把共享状态的持有方式从“独占所有权”变成了“共享所有权”。它内部存有指向共享状态的指针，shared_future之间可以互相拷贝，拷贝后多个对象指向同一个共享状态。引用计数随之增加，最后一个shared_future被销毁时状态才真正释放。这和std::unique_ptr与std::shared_ptr的关系非常像——一个独占、一个共享，只是shared_future操作的是异步结果状态。
3.2 为什么get()的返回值是 const 引用
我最初在学习shared_future::get()时有个疑惑：为什么它的返回类型不是T而是const T&？
看标准库的定义就清楚了。std::future::get()是右值语义，它把结果从共享状态中移动到调用处，所以返回T。而std::shared_future::get()为了保持结果可以被多次读取，必须保留结果在共享状态中，因此只能返回const T&。
这带来一个非常实际的后果：如果你的异步结果是std::unique_ptr这类不可拷贝的移动独占类型，那么shared_future就基本帮不上忙了。因为get()只能给你一个 const 引用，你没办法把unique_ptr从共享状态里弄出来。我见过有人硬要跨线程共享返回unique_ptr的 future，结果卡在类型推导上，最后只能用shared_ptr替代，才绕开这个问题。
所以在设计异步任务时，如果确定要使用shared_future，请提前确认返回类型是可拷贝的。如果是自定义类型，最好提供拷贝构造函数，否则所有线程拿到的都是 const 引用，只能读不能取走。
3.3 引用计数自动管理，但别依赖它在实践中节省内存
shared_future的引用计数是自动处理的：拷贝构造增加计数，析构减少计数。当计数归零时，共享状态整体释放，包括里面存的结果对象。
但我要说的是另一个容易被误解的点——共享状态本身是堆上的独立对象，它与异步任务的执行线程并没有绑定关系。即使运行任务的线程早就退出了，只要还有任何shared_future活着，状态就一直存在。这保证了get()在任意时刻调用都能拿到结果。反过来，如果所有shared_future都被销毁，即使promise还在，共享状态也可能被释放（这取决于promise是否还引用这同一个状态）。
这里有一处危险操作要警惕：不要让promise在其生命周期内已经设置过值或异常之后，又试图通过shared_future再次访问结果时产生冲突。实际测试中常见的问题是：promise被析构了，但shared_future还活着，它的get()可能只能获得broken_promise异常。更安全的做法是保证异步任务的promise生命周期覆盖所有消费者的等待时间，或者干脆使用std::async一把梭——它会自动生成内部状态，开发者不太需要手动管理promise生命周期。
4. 实战：多个工作线程消费同一个异步结果
这一段我会用一个更接近工程的例子：模拟服务启动时异步加载配置，加载完成后多个工作线程同时开始处理，每一个线程都要用这份配置。代码是能编译运行的，我也把关键设计原因放出来。
#include <iostream> #include <future> #include <thread> #include <vector> #include <string> #include <chrono> struct AppConfig { std::string database_url; int pool_size; bool enable_cache; // 为了让 std::shared_future 能正常使用，需要可以拷贝 AppConfig() = default; AppConfig(const AppConfig&) = default; AppConfig& operator=(const AppConfig&) = default; }; // 异步加载配置，模拟耗时操作 AppConfig load_config() { std::this_thread::sleep_for(std::chrono::milliseconds(500)); return AppConfig{"127.0.0.1:3306", 16, true}; } void worker_thread(int worker_id, std::shared_future<AppConfig> config_future) { // 所有线程阻塞在这里等待配置加载完成 AppConfig cfg = config_future.get(); std::cout << "Worker " << worker_id << " 使用配置: " << cfg.database_url << ", pool_size=" << cfg.pool_size << ", cache=" << std::boolalpha << cfg.enable_cache << std::endl; // 实际工作... } int main() { // 使用 async + share() 一步到位 std::shared_future<AppConfig> cfg_fut = std::async(std::launch::async, load_config).share(); constexpr int kWorkerCount = 5; std::vector<std::thread> workers; workers.reserve(kWorkerCount); for (int i = 0; i < kWorkerCount; ++i) { // 每个线程拷贝一份 shared_future，大家共享同一个异步结果 workers.emplace_back(worker_thread, i, cfg_fut); } for (auto& w : workers) { w.join(); } return 0; }运行结果会显示五个 worker 线程都成功get()到同一份AppConfig对象。你自己跑一下就能验证，没有任何一个线程因为重复get()而崩溃。
这里我想强调三个设计决策的“为什么”。
为什么要每线程拷贝一份shared_future？因为 Lambda 捕获或函数传参时，如果传的是同一个shared_future对象的引用，虽然get()和wait()是线程安全的，但任何关于这个对象本身的拷贝、赋值等操作都必须加锁。为了避免脑细胞死在并发边界上，我选择直接拷贝。shared_future的拷贝开销极低——只是复制一个指针和递增引用计数，完全不用顾虑性能。这也是标准库设计者的意图：鼓励拷贝使用。
为什么async用std::launch::async？为了强制异步执行，避免因策略不确定导致shared_future的等待状态没有真正进入异步计算。当然你也可以不传参数，让系统自行选择，但在需要共享结果的场景下，显式指定异步策略更符合预期。
为什么AppConfig需要可拷贝？正如第 3.2 节所说，shared_future::get()返回 const 引用，而我在 worker 里用了AppConfig cfg = config_future.get();，这行代码实际上发生了拷贝构造。如果AppConfig是不可拷贝的，这里就得改用const AppConfig&引用来避免编译错误，同时还得保证不会在 worker 里修改它。从工程实践看，把传给多线程消费的配置类设计成可拷贝的struct是最省心的方案。
5. 异常传播与状态检查：比想象中更需要留意
shared_future还有一个特性容易被忽略：它和std::future一样支持异常传播，而且异常也能被所有shared_future消费者分别捕获。什么意思？如果一个异步函数抛出了异常，那么所有对这个结果执行get()的线程，都会收到这个异常，每个线程各自处理各自的。
写个示例：
#include <iostream> #include <future> #include <thread> #include <vector> #include <stdexcept> int main() { auto shared_fut = std::async(std::launch::async, []() -> int { throw std::runtime_error("异步任务中发生了严重错误"); }).share(); std::vector<std::thread> threads; for (int i = 0; i < 3; ++i) { threads.emplace_back([index = i, sf = shared_fut]() { try { sf.get(); } catch (const std::exception& e) { std::cout << "线程 " << index << " 捕获异常: " << e.what() << std::endl; } }); } for (auto& t : threads) threads.join(); return 0; }三个线程都会进入 catch 分支，各自打印一次“捕获异常”。这就是shared_future和std::future异常传播的核心区别：std::future::get()只能让一个线程捕获异常（谁先get()谁捕获，后续线程get()直接抛future_error），而shared_future的每一次get()都能重新抛出同样的异常对象，相当于异常被“复制分发”给了所有消费者。
这个机制在实际工程里极其有用。比如一个后台任务执行失败，多个依赖它的模块需要同时进入降级逻辑或回滚流程。如果逐个把异常传过去，还得自己维护状态；用shared_future直接在各模块的异常捕获点get()，每个模块都能收到同样的失败信号，代码会简洁很多。
再说状态检查。shared_future提供valid()、wait()、wait_for()、wait_until()这些接口，和std::future保持一致。但我要提醒一个细节：wait_for()返回的是std::future_status，枚举值有三种：
future_status::ready：异步操作已完成，可以安全get()future_status::timeout：等待超时，结果尚未就绪future_status::deferred：异步任务还未被启动（通常因为你用了默认启动策略且未触发计算）
我在代码里经常这么写：
if (shared_fut.wait_for(std::chrono::milliseconds(200)) == std::future_status::ready) { // 结果可用，直接取值 auto value = shared_fut.get(); } else { // 超时或仍处于延迟状态，执行别的逻辑 }不过要注意，wait_for()返回ready不代表后续get()一定不会抛异常——如果异步任务是在完成后才抛异常，那么wait_for(ready)一样会成功返回，但get()仍然会抛。所以异常捕获的 try-catch 始终不能省。
另外，valid()只能告诉你这个shared_future是否关联到共享状态，valid() == false时调用wait()或get()是未定义行为。有一个很坑的场景：把shared_future从一个函数返回时，如果函数内部因提前 return 没有正确拷贝，返回值会成为无效状态。所以最好在函数返回前加一个if (!fut.valid()) throw std::logic_error(...)，把隐患提前暴露。
6. 实测中容易踩的坑与性能注意点
6.1 坑一：误解shared_future的并发安全性边界
很多人一看到“shared_future”这个名字就想当然觉得它对所有操作都线程安全，比如多个线程同时对一个shared_future调用拷贝赋值。然而标准库只保证同一个shared_future对象的成员函数在并发访问下的安全性，具体来说是wait()和get()。对于拷贝构造、赋值、析构这些，标准库并没有做额外同步保证。
我自己踩过一次：三个线程同时向一个std::vector<std::shared_future<int>>尾部 push_back，然后 crash 了。原因是push_back会调用拷贝构造和潜在的内存重分配，多个线程同时做这个必然有数据竞争。正确做法是在构造 vector 时就一次性把每个线程需要的shared_future副本准备好，之后线程只读这些副本，不要做拷贝或赋值操作。
6.2 坑二：get()的返回值类型让你无法 move 出结果
前面已经提过shared_future::get()返回const T&，我再展开讲一个具体痛点。假设你写了一个返回std::vector<int>的异步任务，想让某个线程接管这个 vector，直接修改它。用std::future很容易：
std::vector<int> data = fut.get(); // move 出来，可以修改但换成shared_future：
auto sf = std::async(...).share(); const std::vector<int>& const_data = sf.get(); // 只能拿到 const 引用 std::vector<int> data = const_data; // 这是拷贝，不是移动如果你只是读取，没问题；但如果你要移动走，这份结果就要被拷贝一遍。数据量大时会有明显的性能开销。解决方案有两个：把shared_future内部存的对象设计成类似std::shared_ptr<const std::vector<int>>的结构，还是老实用std::future独占转移。
在实际业务中，我会对结果做“能不能拷贝”的分级。如果结果只是被多个模块只读消费，就用shared_future；如果某个模块需要独占并且要修改，还是用std::future加队列或消息传递来处理。
6.3 坑三：不要在shared_future上使用条件变量逻辑
在多线程等待异步结果时，新手常想把shared_future和std::condition_variable配合使用——比如先 wait，然后被唤醒后检查结果。但shared_future::wait()本身就支持线程阻塞，底层通常就是条件变量的封装（不同库实现略有差异），你不需要再引入一个条件变量来“第二次等待”。如果你非要在wait()之后再加一个复杂的notify_one通知逻辑，多半是你把并发模型设计复杂了。
更好的做法是：消费者直接调用wait()阻塞，直到就绪后get()。如果确实需要“当结果就绪时同时通知多个模块”，直接在各自模块线程里wait()即可，这比统一发通知再挨个轮询要简洁可靠得多。
6.4 性能注意点：拷贝开销 vs 引用绑定
std::shared_future的底层共享状态通常是一次性分配，你拷贝多少个shared_future对象，都只是拷贝指针和增加计数，这个开销可以忽略不计。但前面提到的get()返回 const 引用，如果你在每次get()后都要拷贝一份结果到本地变量，开销就不可忽略了。
最佳实践是：如果消费者只需要只读访问，就尽量使用 const 引用绑定结果，避免拷贝：
const auto& cfg = shared_fut.get(); // 所有线程都引用同一个配置对象 // 然后只读 cfg 的字段这样即使AppConfig内部有较大的字符串或者容器，也不会因为多线程消费而产生额外的内存拷贝。前提是你要保证没有线程修改cfg。我在一个高并发场景里就因为这个细节拿到了明显的性能收益——原来每个线程拷贝一份配置，流量一大内存和 CPU 双双飙升，改成 const 引用后就稳了。
6.5 与std::when_all/when_any的配合
C++17 之后，如果你使用std::experimental::when_all或某些扩展库，shared_future可以配合它实现“等待一批异步任务全部完成”的效果。这种方式适合批量并行任务编排。我现在的项目里就有这样一个场景：十个数据源同时拉取数据，只要其中任意一个成功就触发某个模块启动，就用when_any加shared_future来做。注意这些接口目前还在实验性阶段，不同编译器的支持程度不同，迁移到生产环境前先确认编译器版本。
如果编译器不支持这些扩展，退而求其次的办法就是用一个std::promise<void>作为“全部完成”信号，让各个任务完成后set_value()，消费者主线程wait()这个 promise 对应的shared_future<void>。这个方案跨平台兼容性最好，我常常就地实现这类编排逻辑。
7. 结尾：一点经验之谈
把shared_future放进我的工具库之后，处理多线程共享结果这类问题确实省心不少。现在写异步代码，只要判断出“结果要派发给多个消费者”，我就会默认用shared_future，而不是先写std::future然后等 crash 了再改。一个简单的判断口诀：结果只被一个人拿走用std::future，结果要被多人共享读取用std::shared_future，结果既共享又要有人独占修改时，重新设计数据结构。
最后分享一个小技巧：团队协作时，我要在函数签名里暴露异步结果，一定会写std::shared_future<Result>而不是std::future<Result>。原因是shared_future在传递时天然支持拷贝，调用方想等结果就 wait，想直接拿结果就 get，还可以把它存到容器里批量管理，灵活性直接拉满。而且从代码评审角度看，看到shared_future对方会立刻明白“这个结果会被多个模块消费”，比在注释里解释半天std::future只能消费一次要直观得多。如果你们项目里也有“结果需要广播”的异步流程，不妨把std::shared_future纳入首选方案。
