不能直接用 std::queue 配合 std::mutex，因其本质是阻塞式锁保护，违反非阻塞“不等待、不切换上下文”语义；单线程下应采用 std::atomic + 环形缓冲区实现真正无锁 FIFO。
为什么不能直接用 std::queue 配合 std::mutex？
单线程非阻塞队列的核心诉求是：不加锁、不等待、不切换上下文。一旦引入 std::mutex，哪怕只在单线程里调用，也违反了“非阻塞”语义——lock() 仍可能触发内核态检查（尤其在 debug 模式或带 sanitizer 的构建中），且破坏了无锁（lock-free）的可预测性。更关键的是，多生产者/单消费者（MPSC）场景下，std::queue 本身不是无锁结构，插入和删除无法原子协同。
std::atomic + 环形缓冲区是最小可行方案
用固定大小的数组 + 两个 std::atomic_size_t（head 和 tail）模拟环形队列，所有操作仅依赖 fetch_add 和内存序控制。这是 C++11 起真正可移植的单线程非阻塞 FIFO 基础。
- 容量必须是 2 的幂（便于用位掩码代替取模，避免分支和除法）
-
head指向下一次出队位置，tail指向下一次入队位置；空状态为head == tail，满状态为(tail + 1) & mask == head - 入队/出队都用
memory_order_relaxed即可——单线程下无需同步，仅需保证读写不被乱序重排破坏逻辑 - 任务对象需满足 trivially copyable（如
std::function<void></void>不行，但void(*)()或自定义轻量 task struct 可以）
struct TaskQueue {
static constexpr size_t CAPACITY = 1024;
std::atomic_size_t head{0}, tail{0};
alignas(std::max_align_t) char buffer[CAPACITY * sizeof(Task)];
<pre class='brush:php;toolbar:false;'>bool try_push(const Task& t) {
const auto mask = CAPACITY - 1;
const auto pos = tail.load(std::memory_order_relaxed);
if ((pos + 1) & mask == head.load(std::memory_order_relaxed)) return false;
new (buffer + (pos & mask) * sizeof(Task)) Task(t);
tail.store(pos + 1, std::memory_order_relaxed);
return true;
}
bool try_pop(Task* out) {
const auto mask = CAPACITY - 1;
const auto pos = head.load(std::memory_order_relaxed);
if (pos == tail.load(std::memory_order_relaxed)) return false;
*out = std::move(*reinterpret_cast<Task*>(buffer + (pos & mask) * sizeof(Task)));
reinterpret_cast<Task*>(buffer + (pos & mask) * sizeof(Task))->~Task();
head.store(pos + 1, std::memory_order_relaxed);
return true;
}};
如何安全支持 std::function<void></void> 类型任务？
直接存储 std::function 会破坏 trivially copyable 要求，导致 placement new 和析构行为未定义。必须绕过其内部堆分配和虚表调用机制。
立即学习“C++免费学习笔记（深入）”；
- 改用类型擦除的栈内函数对象：定义一个 32 字节对齐、含函数指针 + void* 上下文的
SmallFun结构 - 所有任务封装成
SmallFun后入队，避免动态分配和虚调用开销 - 若必须兼容
std::function输入，提供wrap()工具函数，在入队前将其 move 到栈上并捕获地址（注意：不能捕获局部变量地址，仅适用于静态/全局/堆对象） - 禁止在队列生命周期外持有
SmallFun中的上下文指针——出队即调用，调用后上下文可立即释放
单线程下还要考虑 ABA 问题吗？
不需要。ABA 本质是多线程中某个线程看到相同值就误判状态未变，而单线程中 head 和 tail 的修改永远串行发生，不存在中间被其他线程篡改的可能。因此可放心使用 fetch_add 而不必升级到 compare_exchange_weak。
但要注意：如果未来扩展为多线程（比如增加一个工作线程消费），这个队列不能直接复用——单线程无锁设计不等于多线程安全，差的不只是锁，还有内存序约束和状态竞争逻辑。
