跨线程的话，一般推荐用原子变量来做标志，内存序可以用 relaxed.

volatile 基本留给硬件寄存器读写和 sig_atomic_t 了.

简单来说就是你没用任何同步手段，例如原子变量，内存屏障，volatile 。你这种情况下有可能会遇到
指令重排，例如把你这个判断的代码重排到后面。
从缓存中读取，例如把你这个 flags 放到寄存器里，然后从寄存器里读出。
操作拆分，例如把你这个读取操作在汇编的实现中拆分成两次内存操作。

相关的东西你还是去了解下内存序什么的吧。

这个不是多线程的 bug ，这个是 C/C++编译器的"特性"。
相当于有这样一段代码：
```c++
int flag;

while (flag == 0) {
}
```
编译器在不进行优化(-O0)的情况下，每次 while 循环都会从内存中读 flag 的值，并和 0 进行判断。
当使用了编译器优化的情况下，编译器就会发现"这个程序员真 SB ，为什么每次都要从内存中读 flag 的值呢，我直接读一次，放到寄存器里面，之后访问速度就更快了，判断也可以优化成一次"，于是代码就变成这样了：
```c++
register eax = flag;
if (eax == 0) {
while (true) {
}
}
```
你会发现这个优化在单线程的情况下是完全没有问题的，在多线程情况下就出问题了。
而使用 volatile int flag 就是告诉编译器"不要偷懒，我让你从内存读 flag 你就从内存读，让你写到内存就写到内存"。

不过如上面所说，建议多线程通信使用 atomic ，因为 atomic 还解决了多线程情况下的内存序的问题。

信息量太少，估计你这都不一定是 volatile 的问题。记得在哪里看到过类似的 warning ，找了一下原文：

One notable exception is Visual Studio, where, with default settings, every volatile write has release semantics and every volatile read has acquire semantics (Microsoft Docs), and thus volatiles may be used for inter-thread synchronization.

Standard volatile semantics are not applicable to multi-threaded programming, although they are sufficient for e.g. communication with a signal handler that runs in the same thread when applied to sig_atomic_t variables. The compiler option /volatile:iso can be used to restore behavior consistent with the standard, which is the default setting when the target platform is ARM.

这就需要传教 Rust 了 :)

这里的核心问题是：编译器在做“单线程视角”的激进优化。

主线程中有一个死循环，编译器在分析上下文时发现：“在这个循环内部，没有任何指令修改了 flags_1”。既然没人改，那它就是个常量，于是编译器直接把逻辑优化成了死循环指令（ jmp ），不再去内存里读值。

问题的关键在于：如何打破编译器的“单线程假设”，明确告诉它“这个变量会被其他线程修改”？

在 C 语言中：volatile 是这一场景下的补丁。它强制编译器对该变量的每次访问都必须从内存读取，禁止将其缓存到寄存器或优化掉。这确实间接实现了“告诉编译器别乱优化”的目的。

在 Rust 中： 这种 Bug 甚至无法通过编译。因为这个标识属于 Cross-thread shared state （跨线程共享状态）。Rust 的编译器（借用检查器）会强制要求你必须使用线程安全的包装类型——比如 Mutex<T> 或者 AtomicBool 。

一旦你用了这些类型，就等于在类型系统层面告诉了编译器：“这里涉及多线程并发”。编译器和底层硬件就会自动处理好优化屏障，完全不需要程序员去操心“要不要加 volatile”这种容易遗漏的细节。

今天又刷到，可以看下 Linux 内核文档关于并发的内存屏障的那块。
编译器只对语言规则负责，并发语义必须由程序员明确表达。C 语言并发模型是你不显式声明并发语义，编译器就按单线程世界优化给你看。不要让编译器猜测。这种一律按 BUG 处理。

编译器也是按标准优化，这锅甩不到编译器上面。。
这是一个多线程 bug ，bug 正是通过编译器的“合法特性”表现出来的。两者并不矛盾。