多线程环境下bool标志的线程安全检查正确实现方式

首先明确核心前提：跨线程读写普通bool变量如果没有任何同步措施，属于C++标准定义的未定义行为——不是响应延迟高的问题，是可能出现编译器把读操作优化成常量、CPU缓存不可见、程序崩溃等任意结果，和你要不要即时响应修改没有关系，不存在“不要求即时就能裸用普通bool”的说法。

需要即时停止（for循环执行中也能响应退出）的最优方案 #

直接用std::atomic<bool>，不要用volatile：

• volatile是为硬件寄存器访问、信号处理函数设计的，不保证线程间内存序，也不阻止CPU指令重排，跨线程用volatile属于历史遗留的错误用法，没有标准层面的可靠性保证。
• std::atomic<bool>是C++11之后标准规定的跨线程原子访问方案，绝大多数硬件平台上的实现就是单条内存读写指令，没有锁开销，性能和普通bool几乎一致，同时保证修改对其他线程的可见性。
• 你现有的代码逻辑几乎不需要改动，只需要把m_flag的类型替换掉即可，甚至可以通过指定内存序进一步压缩开销：

// test.h
#include <atomic>

class Test {
    void threadFunc_run();
    void change(bool _set) { 
        // 仅修改标志位无其他同步需求时，用relaxed序即可，无额外内存屏障开销
        m_flag.store(_set, std::memory_order_relaxed); 
    }

    // ... 其他成员
    std::atomic<bool> m_flag;
};


// test.cpp
void Test::threadFunc_run()
{
    // called "Playing"
    while(m_flag.load(std::memory_order_relaxed)) {
        for(int i = 0; i < 99999999 && m_flag.load(std::memory_order_relaxed); i++) {
            // do something .. 1
        }

        for(int i = 0; i < 111111111 && m_flag.load(std::memory_order_relaxed); i++) {
            // do something .. 2
        }
    }
}

只要循环内的业务逻辑不需要和m_flag的修改做其他共享数据的同步，用std::memory_order_relaxed就足够，性能和读写普通bool完全持平，调用change(false)之后，下一次循环判断标志位时立刻就能感知到修改，哪怕是在两层for循环的执行过程中也可以及时退出。

不需要即时响应场景的普通bool实现 #

如果确实不需要中途打断for循环、可以等整轮业务逻辑跑完再检查退出，可以用普通bool，但必须加同步机制保证跨线程的happens-before关系，没有任何“无开销裸用”的可能，可选方案只有两类：

• 互斥锁保护：所有读写m_flag的代码段都必须持有同一个std::mutex，读的时候加锁拷贝值、写的时候加锁修改。这种方案开销远高于atomic，尤其是像你代码里这样在循环条件里高频检查标志位时，锁的争抢会带来明显的性能损耗，仅适合本身循环逻辑就需要持有锁操作其他共享数据的场景。
• 条件变量配合：用std::condition_variable绑定互斥锁和普通bool标志位，工作线程跑完一段业务逻辑后阻塞在条件变量上等待通知，change函数修改标志位后发送notify唤醒工作线程退出。这种方案不需要轮询占CPU，但无法做到for循环执行中途响应退出，必须等当前执行段跑到阻塞等待点才会检查标志位，不符合即时停止的需求。

不要尝试靠关闭编译器优化、加内存屏障汇编这类野路子规避同步，这类写法没有标准保证，换编译器、换CPU架构（比如从x86换到ARM）就会出现难以排查的并发问题。

性能优先级排序：

1. 需要高频检查、即时退出：std::atomic<bool>（relaxed序）是唯一最优解，没有额外开销
2. 不需要高频检查、可以延迟退出：条件变量 > 互斥锁轮询

内容的提问来源于stack exchange，提问作者mystes