rcu在c++中无标准实现，需基于原子操作、内存序和生命周期管理手动构建，核心是确保读端不访问已释放内存、写端延迟回收旧对象。
RCU 在 C++ 里没有标准库实现，得自己搭骨架
标准 C++ 没有 rcu_read_lock、synchronize_rcu 这类原语，也不能直接复用 Linux kernel 的 RCU。你得基于原子操作 + 内存序 + 对象生命周期管理，手动模拟“读不阻塞、写延迟释放”这个核心契约。
关键不是写得多像 kernel，而是守住两条线：读端绝不能访问已释放内存；写端必须等所有可能正在读的线程完成再回收旧对象。否则就是 use-after-free，而且极难复现。
用 std::atomic + memory_order_acquire/release 控制读写可见性
读侧要保证看到最新发布的指针值，且后续访问不被重排到读指针之前；写侧发布新指针时，要确保构造已完成、且旧指针的替换对读端可见。
- 读端用
load(std::memory_order_acquire)读指针，之后所有对所指对象的访问都受 acquire 约束 - 写端用
store(new_ptr, std::memory_order_release)发布新指针，之前所有对该对象的初始化操作不会被重排到 store 之后 - 千万别用
memory_order_relaxed—— 它会让编译器或 CPU 把读/写乱序到完全不可控的位置
示例片段：
std::atomic<data> current_data{nullptr};
// 读
Data* d = current_data.load(std::memory_order_acquire);
if (d) {
use(*d); // 安全：d 所指内容已对当前线程可见
}
// 写（假设已构造好 new_d）
current_data.store(new_d, std::memory_order_release); // 旧指针被覆盖，但旧对象还不能删
</data>
写端如何安全回收旧对象？不能直接 delete
RCU 最难的部分不是读，是“等所有老读者退场”。C++ 没有内核级的 grace period 检测机制，你得自己建一套轻量协作模型。
- 常见做法是引入全局 epoch 计数器 + 每个线程注册本地 epoch —— 读开始前记下当前 epoch，结束时更新；写端推进 epoch 并等待两轮，确保跨 epoch 的读已结束
- 更简单但适用场景受限的做法：用
std::shared_ptr+ 弱引用计数，把“谁还在读”交给 RAII 管理，但会带来引用计数开销和循环引用风险 - 绝对禁止在写端
delete后立刻复用内存 —— 即使用了std::atomic，只要有一个线程还在 dereference 旧指针，就是未定义行为
最简可行路径：用线程局部标记 + 全局 barrier，比如每个线程进入读区前调用 rcu_read_lock()（仅设一个 per-thread flag），写端广播 barrier 并轮询所有线程 flag 清零 —— 这适合可控线程数、低频更新的场景。
别忽略内存屏障之外的真实约束
RCU 不是万能锁替代品。它只适用于“读多写少、读操作本身很快、写不修改原对象而是替换整个结构”的场景。
- 如果读逻辑包含长耗时计算或系统调用，会拖慢 grace period，导致写端回收延迟暴涨
- 如果写操作需要原子更新多个相关指针（比如链表插入），RCU 单指针模型无法保证多节点间一致性，得结合其他同步手段
- 在 NUMA 架构上，频繁跨 socket 读取全局 epoch 或 barrier 状态会显著增加延迟，这时 per-node epoch 更合适
真正容易被忽略的点：RCU 的正确性极度依赖程序员对“读临界区边界”的精确控制。漏掉一个 rcu_read_unlock() 或在临界区内抛异常没处理，整个回收逻辑就失效了 —— 而这种 bug 往往只在高负载压力下才暴露。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
