应使用 std::mutex + std::condition_variable 而非自旋锁，因其避免忙等、CPU 友好、可移植且语义清晰；需用 while 循环配合 wait() 检查谓词防虚假唤醒，notify_one() 推荐在锁内调用。
为什么用 std::mutex + std::condition_variable 而不是自旋锁
环形缓冲区在多线程下必须保证读写互斥和空/满状态同步，std::mutex 提供排他访问，std::condition_variable 避免忙等——尤其当缓冲区长期空或满时，自旋锁会吃光 CPU。实际中只要吞吐量不卡在锁竞争上（比如单生产者单消费者且缓冲区够大），这套组合足够轻量、可移植、语义清晰。
常见错误是只加锁不等待条件，导致 pop() 在空时直接读脏数据，或 push() 在满时覆盖未消费项。必须配合 wait() 检查谓词。
- 始终用
while循环检查条件，而非if（防止虚假唤醒） - 把
notify_one()放在锁内还是锁外？推荐锁内：确保唤醒时被通知线程能立刻抢到锁并检查新状态 -
std::condition_variable::wait()会自动释放锁，并在唤醒后重新获取，无需手动 unlock/lock
环形索引怎么算才不出界又不溢出
用位运算替代取模是常见优化，但前提是缓冲区容量必须是 2 的整数次幂（如 1024、4096）。此时 index & (capacity - 1) 等价于 index % capacity，且无分支、无除法，CPU 友好。
如果硬要支持任意容量，必须用 %，但要注意负数取模在 C++ 中结果符号依赖被除数（如 -1 % 8 == -1），所以读写指针应始终用无符号类型（size_t）或显式归零处理：
立即学习“C++免费学习笔记（深入）”；
size_t mask = capacity - 1; size_t write_pos = (write_index & mask); // 安全 // 错误写法：int i = -1; i % 8 → -1，导致数组越界
- 初始化
read_index和write_index为 0，类型用size_t或std::atomic_size_t（若想免锁读写，需额外同步逻辑） - 判断空/满不能只比对两个索引：满状态是
(write_index - read_index) == capacity，空是write_index == read_index - 避免用
size()函数实时计算长度（需两次内存读+减法），直接存一个size_成员并原子更新更高效
如何让 push() 和 pop() 支持移动语义和异常安全
模板参数用 T&& 转发，内部用 std::move() 存入缓冲区，避免不必要的拷贝；同时构造对象前先检查空间是否充足，失败则立即返回 false，不修改缓冲区状态。
关键点在于：对象构造可能抛异常（比如 T 的拷贝/移动构造函数 throw），所以必须在持有锁期间完成构造和存储——否则解锁后异常会导致缓冲区处于不一致状态。
- 写操作流程：加锁 → 检查非满 → 在栈上构造临时对象 →
std::move到缓冲区 → 更新 write_index → notify → 解锁 - 读操作同理：加锁 → 检查非空 →
std::move出缓冲区 → 更新 read_index → notify → 解锁 - 不要在锁内调用用户定义的可能阻塞或慢的函数（如日志、IO），否则拖慢整个队列
单生产者单消费者场景下可以去掉锁吗
可以，但必须满足三个条件：缓冲区大小是 2 的幂、读写索引用 std::atomic_size_t、且严格单线程读/单线程写（无其他线程干扰）。此时可用 load(std::memory_order_acquire) 和 store(std::memory_order_release) 实现无锁环形队列。
不过，一旦引入多生产者或多个消费者，就必须加锁或更复杂的 CAS 逻辑。多数业务场景下，带锁版本更易验证正确性，性能差距也不明显——现代 mutex 在无竞争时开销极低（几纳秒），只有高争用（>100K ops/s）才值得投入无锁优化。
容易被忽略的是：即使单生产者单消费者，如果 T 析构函数可能抛异常，仍需 try/catch 包裹析构调用，否则 pop() 中的 std::move 后析构失败会导致缓冲区残留未清理对象。
