音频场景必须用无锁ringbuffer，因std::queue加mutex会导致线程挂起、缓存抖动和爆音；而2的幂容量环形缓冲区配合atomic读写索引可实现零阻塞spsc通信。
为什么音频场景下必须用无锁 ringbuffer
音频采集/播放线程对延迟极度敏感，std::queue 加 std::mutex 会导致线程挂起、缓存抖动甚至爆音。环形缓冲区（ringbuffer）配合原子指针（如 std::atomic<size_t></size_t>）能实现真正无锁——生产者和消费者各自推进读写位置，不阻塞、不竞争临界区。
关键前提是：缓冲区大小为 2 的幂次（如 1024、4096），这样可用位运算替代取模，避免分支和除法开销；同时读写索引必须用 std::atomic<size_t></size_t> 且内存序设为 memory_order_acquire/memory_order_release，防止编译器或 CPU 重排破坏顺序。
如何手写一个线程安全的 ringbuffer\_c++（非模板版）
以下是一个适用于 1 生产者 / 1 消费者的轻量 ringbuffer 实现，专为 PCM 音频帧设计（假设每帧 4 字节，采样率 48kHz，单声道）：
class RingBuffer {
static constexpr size_t CAPACITY = 4096; // 必须是 2 的幂
std::array<int32_t, CAPACITY> buffer_;
std::atomic<size_t> write_pos_{0};
std::atomic<size_t> read_pos_{0};
<p>public:
bool try_push(int32_t sample) {
const size_t w = write<em>pos</em>.load(std::memory_order_acquire);
const size_t r = read<em>pos</em>.load(std::memory_order_acquire);
const size<em>t avail = (r - w - 1 + CAPACITY) & (CAPACITY - 1); // 空闲空间
if (avail == 0) return false;
buffer</em>[w & (CAPACITY - 1)] = sample;
write<em>pos</em>.store(w + 1, std::memory_order_release);
return true;
}</p><pre class='brush:php;toolbar:false;'>bool try_pop(int32_t& out) {
const size_t r = read_pos_.load(std::memory_order_acquire);
const size_t w = write_pos_.load(std::memory_order_acquire);
if (r == w) return false;
out = buffer_[r & (CAPACITY - 1)];
read_pos_.store(r + 1, std::memory_order_release);
return true;
}
size_t available_read() const {
const size_t w = write_pos_.load(std::memory_order_acquire);
const size_t r = read_pos_.load(std::memory_order_acquire);
return (w - r) & (CAPACITY - 1);
}};
立即学习“C++免费学习笔记（深入）”；
注意点：
-
CAPACITY必须是 2 的幂，否则& (CAPACITY - 1)会越界或逻辑错误 -
try_push中先读read_pos_再读write_pos_，并用memory_order_acquire保证可见性 - 不支持多生产者或多消费者——若需 MPSC，得用
std::atomic_fetch_add+ CAS 循环；但音频通常只需 SPSC - 没做异常安全包装，实际项目中建议用 RAII 封装生命周期（如构造时 malloc 对齐内存供 SIMD 使用）
与 boost::lockfree::spsc_queue 对比时要注意什么
很多人直接上 boost::lockfree::spsc_queue<int32_t></int32_t>，但它默认使用动态内存分配，而音频线程严禁 malloc/free——可能触发 glibc 锁或 GC 延迟。此外：
-
boost::lockfree::spsc_queue的push()在满时返回false，但不会告诉你“差几个元素才满”，调试音频 underflow/overflow 时不如自定义 ringbuffer 的available_read()直观 - 它内部仍用位运算做索引映射，但封装过深，无法控制缓存行对齐（
alignas(64)）——而音频 buffer 若跨缓存行，会显著增加 load-hit-store 延迟 - 某些嵌入式平台（如 ARM Cortex-A7）对
std::atomic的 full barrier 支持不完整，boost 版本可能隐含mfence指令，导致性能陡降；手写版本可按需降级为memory_order_relaxed（仅当确认无乱序风险时）
实测音频缓存抖动的关键检查项
即使 ringbuffer 逻辑正确，音频仍可能卡顿。排查顺序如下：
- 确认音频回调函数（如 ALSA 的
snd_pcm_sframes_t callback(snd_pcm_t*, void*, snd_pcm_uframes_t)）中只调用try_pop或try_push，**绝不调用 new / printf / std::cout / std::chrono::now()** - 用
perf record -e cycles,instructions,cache-misses抓热点，重点看 ringbuffer 的write_pos_和read_pos_是否频繁 cache line bouncing（即两个核心反复改同一缓存行）——解决办法是把两个std::atomic变量用alignas(64)隔开 - 检查采样率匹配：若采集端写入 44.1kHz 数据，播放端按 48kHz 拉取，即使 ringbuffer 不溢出，也会因速率失配导致周期性 underflow
- Linux 上启用实时调度：
sched_setscheduler(0, SCHED_FIFO, ¶m)，否则普通线程可能被内核调度器抢占 10ms+，远超音频容忍阈值（通常
环形缓冲区本身不难，难的是让它在中断上下文、实时线程、不同架构间都稳定交付——每个 memory_order 选型、每字节对齐、每次 memcpy 替代，都得有明确依据。
