令牌桶应使用std::chrono::steady_clock按需计算时间差补令牌，用std::atomic_int或mutex保护状态；避免system_clock和shared_mutex；try_consume须cas扣减并先补满再截断；本地模拟需加jitter逼近分布式时钟偏差。
令牌桶怎么用 std::chrono 做线程安全的本地限速
本地模拟分布式限流，核心不是“分布”，而是“桶的行为要准”：令牌补充不能靠定时器硬等，得按需计算流逝时间。直接用 std::chrono::steady_clock 记录上次更新时间，每次请求来时算差值、补令牌，比 sleep 或 timer 更精准也更轻量。
容易踩的坑是没加锁还读写共享状态——哪怕只是 int 类型的令牌数，多线程下自增/自减也会撕裂。必须用 std::atomic_int 或互斥锁保护。
-
std::atomic_int足够，但要注意fetch_sub是原子减，返回旧值，得判断是否 ≥0 才算取成功 - 补令牌逻辑必须在锁内完成（或用原子操作+CAS重试），否则可能漏补、多补
- 别用
system_clock，它可能跳变；steady_clock才保证单调递增
为什么不用 std::mutex 而选 std::shared_mutex 会更糟
std::shared_mutex 看似适合“读多写少”，但令牌桶里“补令牌”和“取令牌”本质都是写操作：补要改计数和时间戳，取要改计数。所谓“只读查询剩余令牌”对限流没意义——你不可能先查再决定要不要发请求，那会破坏原子性。
所以实际只有两种操作：尝试取（写），以及按时间补（写）。这时候 shared_mutex 不仅没收益，反而因升级锁逻辑增加开销，还容易写出死锁（比如先 shared_lock 再 try_upgrade_to_unique_lock）。
立即学习“C++免费学习笔记（深入）”；
- 一律用
std::mutex或std::atomic+ CAS，别被“共享读”误导 - 如果真要用
std::shared_mutex，得确认你的场景里有大量不修改状态的只读监控调用——但限流器本身不需要这种接口 - 实测在高并发下，
std::atomic_int配合无锁补令牌（用compare_exchange_weak循环）比 mutex 快 2–3 倍
try_consume 函数怎么避免“超发”和“饥饿”
典型错误是把“取 1 个令牌”写成 if (tokens > 0) --tokens; —— 这在多线程下必然超发。正确做法是用原子操作一次性完成“检查并扣减”，失败就立刻返回 false。
另一个问题是“饥饿”：长时间没请求时，令牌堆满后新请求进来，本该允许，但若补令牌逻辑有缺陷（比如只在取时补、且补之前不校验上限），就可能卡住。必须确保每次取之前，先按时间补足，再截断到最大容量。
- 补令牌公式：
new_tokens = min(capacity, old_tokens + elapsed_seconds * rate)，rate 单位是 token/s，注意换算成毫秒或微秒精度 - 用
std::atomic_int::compare_exchange_weak实现 CAS 补令牌，失败说明别人刚更新过，重读重算 - 不要在
try_consume外暴露get_remaining()接口——它返回的瞬间就过期了，还破坏封装
本地模拟分布式时，clock_gettime(CLOCK_MONOTONIC) 比 std::chrono 更稳？
在 Linux 上，std::chrono::steady_clock 底层通常就是 CLOCK_MONOTONIC，所以一般没差别。但如果你看到性能抖动或测试结果不稳定，可能是编译器/标准库实现把 steady_clock 绑到了低精度源（比如某些嵌入式 libc++）。这时直接调 clock_gettime 可绕过抽象层，也方便后续迁移到真正分布式环境（比如对接 Redis 的 TIME 命令做全局时钟对齐）。
- 用
clock_gettime(CLOCK_MONOTONIC, &ts)获取纳秒级时间，比std::chrono少一次封装开销 - 但跨平台代码里别硬写，可以用宏或 traits 封装，Linux 走
clock_gettime，Windows 走QueryPerformanceCounter - 真正要注意的是：本地模拟永远无法复现网络延迟和时钟漂移，所以压测时得额外加随机 jitter（比如 ±50ms）来逼近真实分布式行为
事情说清了就结束。真正的难点不在桶的逻辑，而在你怎么让多个进程/机器的“流逝时间”感知一致——本地模拟时最容易忽略这点，以为只要算法对就万事大吉。
