c++26 标准中不存在 std::rcu，它既未被纳入草案也非标准库成员；所有相关说法均属误传，真实 rcu 实现仅见于 linux 内核、liburcu 或 folly::rcu 等第三方库。
std::rcu 在 C++26 中根本不存在
C++26 标准草案里没有 std::rcu，标准库从未定义过这个类型或命名空间。你搜到的可能是实验性提案（如 P1123R5 RCU for C++）、某个编译器私有扩展（如 GCC 的 __gnu_cxx::rcu），或是误把 Linux 内核的 rcu_read_lock() 当成了 C++ 标准设施。
常见错误现象：error: 'rcu' is not a member of 'std'、unknown type name 'rcu'，本质是头文件没包含、标准版本不对，或压根没这东西。
- C++ 标准库目前（至 C++23）不提供任何 RCU（Read-Copy-Update）原语
- 所有声称“C++26 引入 std::rcu”的信息均属误传或混淆了 TS（Technical Specification）与正式标准
- 真实可用的 RCU 实现只存在于特定场景：Linux 内核（C）、liburcu（C 库）、或极少数 C++ 封装（如 folly::RCU，非标准）
想在 C++ 里用 RCU，只能靠第三方库
RCU 是一种内存模型级同步机制，依赖底层内存屏障、宽限期（grace period）管理和对象生命周期控制，标准 C++ 的 std::atomic 和 std::memory_order 无法直接构造出安全、可移植的 RCU 行为。
使用场景：高频读 + 低频写的数据结构（如路由表、配置缓存），且对读端延迟极度敏感（不能容忍锁或原子操作开销）。
- liburcu 是最成熟的选择，提供 C 接口，C++ 可直接调用：
rcu_read_lock()/rcu_read_unlock()/synchronize_rcu() - folly::RCU（Facebook 开源）是 C++ 封装，但需链接
folly，且不保证 ABI 稳定 - 自己基于
std::atomic+ hazard pointer 模拟 RCU 极易出错，不推荐
示例（liburcu）：
#include <urcu.h> // … rcu_read_lock(); auto ptr = g_shared_data.load(std::memory_order_acquire); // use ptr safely within this RCU reader section rcu_read_unlock(); </urcu.h>
std::atomic + memory_order 不等于 RCU
有人试图用 std::atomic<t></t> 配合 std::memory_order_seq_cst 模拟 RCU 语义，这是危险的简化。
为什么这样做不行：
- RCU 要求写端等待所有已开始的读者完成（即“宽限期”），而
std::atomic无法感知线程是否处于读临界区 - 无自动对象回收机制：RCU 的核心是
call_rcu()延迟释放，标准库没有等价物 - 缺少内存屏障组合保障：比如
smp_mb__after_unlock_lock()这类架构相关屏障，C++ 标准内存序无法精确映射
性能影响：盲目套用 std::atomic 可能引入不必要的序列化（seq_cst 全局顺序），反而比简单读锁更慢；而真 RCU 的读端是零开销（无原子指令、无缓存行争用）。
如果你真需要 RCU，现在就得接受非标准现实
这意味着：
- 不能指望
#include <memory></memory>或<atomic></atomic>提供 RCU 支持 - 必须显式集成 liburcu（Linux）或 folly（跨平台但重依赖）
- 需要手动管理宽限期：调用
synchronize_rcu()或call_rcu()，不能依赖 RAII 自动触发 - 编译时得加
-lurcu，运行时需对应共享库，CI/CD 流水线要额外适配
RCU 不是“换个函数名就能用”的功能，它牵扯到整个程序的生命周期管理方式。最容易被忽略的一点：RCU 安全的前提是所有读者都明确进入和退出 RCU 读端临界区——漏掉一个 rcu_read_unlock()，就可能永久阻塞写端。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
