缓存失效时不抛异常、不卡住而返回旧值，核心是读写解耦与线程安全：用双缓冲+std::shared_ptr实现零阻塞读，std::shared_mutex保护指针交换，配合loading_in_progress和failure_count实现智能降级。
缓存失效时怎么不抛异常、不卡住，直接返回旧值？
核心是「读缓存失败时不中断业务流」，而不是等重载或报错。C++ 没有现成的 cache.get_or_stale()，得自己兜底——关键在把「获取新值」和「返回旧值」解耦，且保证线程安全。
常见错误现象：std::shared_mutex 锁住整个读+更新流程，导致并发请求全堵在失效重载上；或者用 std::atomic 存指针但忘了旧值析构时机，造成 use-after-free。
- 用双缓冲结构：一个
std::shared_ptr指向当前有效数据，另一个后台线程异步加载新数据 - 读操作只读
std::shared_ptr，不加锁（std::atomic_load或 relaxed load 即可） - 写操作用
std::shared_mutex保护指针交换，但绝不阻塞读——交换瞬间完成，旧值由引用计数自动回收
std::shared_mutex 和 atomic 哪个更适合降级读？
std::shared_mutex 更稳妥。虽然 std::atomic<:shared_ptr>></:shared_ptr> 在 C++20 才完全支持（之前只能靠 std::atomic<void></void> + reinterpret_cast），而且原子指针无法表达「正在加载中」的状态，容易让多个线程重复触发加载。
使用场景：高读低写、容忍短暂 stale 数据（比如配置、元信息）。性能影响在于写端要升级为独占锁，但读端零开销——比每次查 std::map + try_lock 快得多。
立即学习“C++免费学习笔记（深入）”；
- 别用
std::atomic<t></t>直接存裸指针：生命周期管理失控，极易内存泄漏或崩溃 - 如果必须用原子操作，选
std::atomic<:shared_ptr>></:shared_ptr>（C++20 起标准支持），并配合std::weak_ptr做加载状态判断 -
std::shared_mutex的lock_shared()在读多写少时吞吐更高，比std::mutex适合这里
怎么判断“该不该降级”？失效检测不能只看时间戳
单纯比对 std::chrono::steady_clock::now() > expire_time 不够：网络抖动、系统时间跳变、NTP 同步都可能误判。真正要防的是「加载新值失败」，不是「刚好过期」。
正确做法是把「加载逻辑」和「过期逻辑」分开：缓存项带一个 std::atomic<bool> loading_in_progress</bool>，再加一个 std::atomic<int> failure_count</int>。只有连续几次加载失败，才启用降级阈值（比如允许最多 30 秒 stale）。
- 不要在读路径里调用
curl_easy_perform()或数据库查询——这些必须进后台线程池 - 过期时间建议用「滑动窗口」：每次成功加载后，设置
expire_time = now() + base_ttl * (1 + jitter)，避免雪崩 - 降级开关本身也要持久化到本地文件或共享内存，防止进程重启后全部回源
std::shared_ptr 的引用计数会不会成为性能瓶颈？
不会。现代 libstdc++/libc++ 对 std::shared_ptr 的引用计数做了无锁优化（基于 std::atomic 的 fetch_add），单次拷贝开销约 1–2 ns。比起一次 Redis 网络往返（~100 μs 起），可以忽略。
真正要注意的是对象大小：如果缓存值本身很大（比如几 MB 的 protobuf），频繁拷贝 std::shared_ptr 没问题，但别在每次读时都 make_copy() 整个对象——降级策略的意义就在于复用旧副本。
- 避免在 lambda 捕获中隐式拷贝
std::shared_ptr多次，用const auto& ptr = cache_ptr;显式引用 - 如果值类型支持 move（比如
std::string、std::vector），后台加载成功后用std::move()传入新值，减少内存分配 - 别给缓存值加虚函数或 RTTI：增加对象体积，间接抬高 cache line miss 率
降级不是兜底的偷懒方案，而是要把「数据新鲜度」和「服务可用性」拆成两个正交维度来控制——最易被忽略的是 failure_count 的衰减机制：它不能永久累积，得按时间滑动清零，否则一次网络分区就让服务永远不敢更新。
