std::atomic是最安全的开关变量类型，能保证原子性、禁止编译器优化和cpu乱序，避免子线程无法感知状态变化；必须显式初始化，用load()/store()操作，并配合休眠或condition_variable减少空转。
std::atomic 是最安全的开关变量类型
直接用 bool 全局变量控制子线程启停是危险的：编译器可能优化掉读取、CPU 可能乱序执行、多个线程读写未同步，导致子线程永远看不到变化。必须用 std::atomic<bool></bool>，它保证读写是原子的，且默认带 memory_order_seq_cst 内存序，避免重排。
常见错误现象：while (running) { /* do work */ } 循环在子线程里卡死，即使主线程已把 running = false，子线程仍不退出。
- 不要用
volatile bool—— 它只禁用编译器优化，不解决 CPU 乱序和缓存可见性问题 - 不要用普通
bool+std::mutex包裹读写 —— 开关变量本身不需要互斥，加锁反而引入不必要开销 - 初始化必须显式：用
std::atomic<bool> running{true}</bool>，而非std::atomic<bool> running;</bool>（后者值未定义）
子线程中正确轮询开关变量的写法
轮询本身没问题，但必须确保每次读都是“新鲜”的。用 load() 显式读取，并配合短休眠防 CPU 占满。
std::atomic<bool> running{true};
<p>void worker() {
while (running.load()) {
// 执行任务...
std::this_thread::sleep_for(std::chrono::milliseconds(10));
}
// 清理资源
}</p></bool>
为什么不用 while (running)？虽然语法上等价，但显式 load() 更清晰表达意图，也方便后续切换内存序（如改用 memory_order_acquire）。
- 休眠时间不宜过短（如
1ms），否则频繁唤醒仍会吃高 CPU - 如果任务本身有阻塞调用（如
cv.wait()或网络 I/O），可在阻塞前再检查一次running.load() - 避免在循环内做耗时计算后才检查开关，应尽早判断退出条件
主线程如何安全地关闭子线程
只需一次写入：running.store(false)，然后等待线程结束。关键点是：必须在 join() 前完成写入，且不能在子线程已退出后再写。
常见错误场景：thread.join() 被遗忘，导致主线程退出时子线程还在运行，程序崩溃或资源泄漏；或者 store(false) 写在 join() 之后，逻辑无效。
- 顺序必须是：
running.store(false); thread.join(); - 如果子线程可能长时间阻塞（如等待条件变量），需配合
cv.notify_all()唤醒它，让它有机会检查running - 不要用
detach()配合开关变量 —— 无法保证线程何时真正结束，running变成悬垂访问
比轮询更高效的唤醒机制：结合 condition_variable
纯轮询适合轻量、低频开关；若子线程大部分时间在等待事件（如队列有数据、定时器触发），应改用 std::condition_variable 配合 running 标志，避免空转。
std::atomic<bool> running{true};
std::mutex mtx;
std::condition_variable cv;
std::queue<int> data_q;
<p>void worker() {
std::unique_lock<:mutex> lck(mtx);
while (running.load()) {
cv.wait(lck, [&] { return !data_q.empty() || !running.load(); });
if (!running.load() && data_q.empty()) break;
// 处理 data_q.front()
data_q.pop();
}
}</:mutex></p></int></bool>
这里 cv.wait() 的谓词同时检查两个条件：有数据可处理，或开关已关闭。这样既响应及时，又不浪费 CPU。
容易被忽略的是：notify_one() 或 notify_all() 必须在持有同一把 mtx 的前提下调用，否则唤醒可能丢失；而 running.store(false) 本身不需要锁，但通知动作需要。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
