企业官网建设流程全解析

volatile 这个关键字，我在面试场上见过两种极端。一种是候选人四个字收尾——“防止优化”，然后就没有下文了；另一种是规则能背三条，一让他写代码，volatile就加到了指针的错误一侧。前段时间帮一个团队做模拟面试，六个人里四个在volatile int* p和int* volatile p上翻了车，还有一位非常笃定地说双检锁定单例只要加个volatile就万事大吉。这些都不是记性问题，是没搞清楚这个关键字究竟在约束谁——它约束的是编译器对某一类访问的处理方式，而不是给变量贴一张“我很重要别动我”的标签。

这是 C/C++ 关键字系列的第二篇，上一篇把 volatile 的基本语义和常见误解过了一遍，这一篇往下挖三层：编译器视角下它到底改了什么、那些看起来像语法错误却完全合法的写法（volatile int volatile p(2)就是典型代表）、以及它在多线程和嵌入式两个战场上能打和不能打的边界。读者对象是有一定 C/C++ 基础、正在准备面试、或者刚接手寄存器操作与驱动代码的人。无论你目前是在背八股还是在改一个跑飞了的中断标志位，下面这些内容都能直接拿去用。

1. 编译器眼里的 volatile：它到底在约束谁

1.1 三条硬性规则：不能省、不能合、不能挪

标准给 volatile 的语义抽象成一句话就是：对 volatile 修饰对象的访问，必须严格按照抽象机的规则发生。落到编译器实现上，体现为三条可操作的约束。

第一条是不能省。你写了一次读，就必须真的读一次；你写了一次写，就必须真的写一次。哪怕这次读出来的值根本没被使用，编译器也得保留这条访存指令。第二条是不能合。连续两次写同一个变量，中间没有任何其他操作，普通变量会被优化成只写最后一次；volatile 变量不行，两次写都得留下。第三条是不能挪，这一点要小心表述：volatile 访问之间的相对顺序不能被打乱，但编译器和 CPU 依然可以把非 volatile 的操作提到 volatile 访问的前面或者后面去。很多人把第三条理解成“volatile 会建立一道屏障，前后所有代码都不能越界”，这是错的，后面第 3 章会专门拆这个误区。

这三条规则组合起来，实际效果就是“这次访问有外部可观察的副作用”。外部是谁？可能是同一块内存映射的硬件外设、可能是中断服务程序、可能是另一颗核。编译器不知道也不关心，它只知道这个变量不能当普通内存来对待。

1.2 用一份反汇编验证“关优化”到底关掉了什么

光讲规则容易飘，直接看代码。下面两段函数除了变量的限定符以外完全一样，放在 GCC 的-O2下编译，结果差别很大。

int g_normal; volatile int g_vol; void write_twice_normal() { g_normal = 1; g_normal = 2; } void write_twice_vol() { g_vol = 1; g_vol = 2; } int read_then_discard_vol() { int a = g_vol; // 读出来的值没用 return 0; }

write_twice_normal在-O2下大概率会被优化成一条movl $2, g_normal(%rip)，第一次赋值直接被抹掉，因为它对程序的可观察行为没有影响。write_twice_vol则老老实实保留两条存储指令，顺序也不变。read_then_discard_vol更有意思，普通变量那次读会被整个删掉，volatile 那次读哪怕结果被丢弃，编译器仍然要生成加载指令。

这段实验的价值在于：面试时你说“volatile 关闭优化”，这是一个含糊的说法；你说“volatile 保证每一次访问都真实发生、不被合并、不被删除、顺序相对固定”，这才是可验证的描述。前者一追问就露馅，后者能直接对上代码。

顺带说一个容易混淆的点。volatile并不等于把整个函数的优化关掉。-O0是全局不做优化，volatile只作用于被它修饰的那个对象的访问。同一个函数里其他普通变量照样会被优化、被放进寄存器、被重排。有人写驱动时在关键函数上加了一堆volatile局部变量，以为这样就获得了类似-O0的效果，实际上函数里的其他计算早就被折叠完了。

1.3 一个常被忽略的事实：volatile 不约束非 volatile 访问

这条单独拎出来讲，因为它是绝大多数“volatile 到底管不管内存序”争论的根源。

看这段代码：

volatile int flag; int payload; void producer() { payload = 42; // 非 volatile 写 flag = 1; // volatile 写 }

很多人认为flag = 1一定发生在payload = 42之后。在编译器这一层，这个结论大体成立，因为 volatile 写不能跨越前面的语句向前移动，同时也因为编译器一般不会把一个普通写移动到 volatile 写之后（除非它能证明没有别名，而多数时候它证不出来）。但在硬件这一层，这就完全不保证了。处理器有自己的存储缓冲，payload的写可能还在缓冲区里没落到内存，flag的写已经出去了。另一颗核看到flag == 1，去读payload，读到的可能是旧值。

这就是为什么我在讲解 volatile 时会把“编译器层面”和“硬件层面”分成两件事说。volatile 管的是前者，后者需要内存屏障或者原子操作。C++11 之后标准提供的工具是std::atomic配合内存序，而不是volatile加上一些平台相关的屏障指令拼凑出来。

1.4 别拿 volatile 当“优化开关”用

我在实际项目里见过一种反模式：为了“防止编译器乱优化”，给某个结构体的每个字段都加上volatile，结果这条路径的性能掉了将近四成，问题最后也没解决。原因很简单，那个 bug 的真正来源是另一个线程读取了非原子共享数据，加了volatile只是让读写真的发生了，并没有解决数据竞争。

判断要不要加volatile，问自己一个问题就够了：这个对象的值是否可能在编译器看不见的地方发生变化。可能变化，加。比如硬件寄存器、信号处理函数修改的标志、setjmp之后可能被longjmp修改的局部变量。如果仅仅是“多个线程都会访问”，那答案是std::atomic或者锁，跟volatile没关系。

2.volatile int volatile p(2)逐字拆解：那些看起来像错误的合法写法

2.1 重复的 volatile 为什么编译器不报错

标题里这一行，第一次看到的人基本都会怀疑是不是打错了。volatile int volatile p(2);里出现了两个volatile，一个是类型说明符序列里的，一个夹在int和变量名中间，位置还不太常规。

结论先说：这是完全合法的 C 和 C++ 代码。两个标准都明确规定，同一个 cv 限定符在同一个限定符序列里重复出现，效果等同于只出现一次。GCC、Clang、MSVC 实测都接受这行，最多给你一个“冗余限定符”的提示（多数编译器连提示都不会给）。所以它的等价写法就是volatile int p(2);，p是一个被 volatile 修饰的int，用圆括号做直接初始化，初值 2。

那为什么有人这么写？因为在 C 的声明语法里，volatile既可以是类型说明符的一部分，也可以出现在声明符里靠近变量名的位置。volatile int p和int volatile p表达的是同一个类型，写成volatile int volatile p就是把两个位置都占了。这种写法在老代码里偶尔能看到，多数是为了强调，实际没有任何额外语义。

这里要分清两件事：冗余合法和推荐写法。面试时你可以指出它合法，但同时也该说明团队规范里通常只保留一个，避免让人误以为有特殊含义。能把这两层同时说清楚，比单纯答“合法”要高一个档次。

2.2 指针场景下的三个位置，语义差出三条街

volatile和指针的组合才是真正的分水岭，也是面试最爱设置陷阱的地方。三个位置对应三种完全不同的类型，我用一张表把它们摆开。

记忆方法用的是“从右往左读”规则。volatile int* p从右读是“p 是一个指针，指向 volatile int”；int* volatile p从右读是“p 是一个 volatile 的指针，指向 int”。这个规则对const同样适用，const int*和int* const的区分逻辑一模一样。

坑通常出在第二种。有个场景特别典型：一个指针变量会在中断服务程序里被重新赋值，主循环通过它访问数据。如果写成volatile int* p，那保护的是*p，指针变量p本身的读写仍然是普通访问，编译器完全可能把p缓存进寄存器，中断里改了主循环也看不见。正确写法是把volatile贴在*和变量名中间。

第三种写法在真实工程里出现频率比想象中高，比如一个指向 DMA 缓冲区的全局指针，缓冲区内容由硬件写入（目标 volatile），指针本身可能被重新配置（指针 volatile）。两个都加，一次到位。

2.3 括号初始化与最令人头疼的解析

p(2)这一截用的是直接初始化语法，volatile int p(2);和volatile int p = 2;在 C++ 里效果基本一致。为什么这行不会像传言那样被解析成函数声明？

因为括号里放的是表达式。2是字面量，不是类型名，所以编译器没有第二种解释路径，它只能是变量定义。所谓 most vexing parse 发生在括号里出现了类型名的时候，比如：

struct Timer { }; struct TimeKeeper { TimeKeeper(const Timer&); }; TimeKeeper tk(Timer()); // 不是定义对象，是声明了一个返回 TimeKeeper、参数为函数指针的函数

Timer()里的Timer是类型名，编译器优先把它解释成“无参、返回 Timer 的函数类型”，整行就变成了函数声明。这才是真正会让人抓狂的解析歧义。回到volatile int p(2)，它避开了这个坑，但如果你把它写进模板或者参数位置，比如T(T())这种形式，风险立刻回来。

面试官如果拿volatile int volatile p(2)问你，真正想验证的是三件事：你知不知道重复 cv 限定符合法、你分不分得清指针那三个位置、你理不理解括号初始化什么时候会被当成函数声明。单独一个点答对不难，三个连起来还能说清楚，就说明是真的读过标准也写过代码。

2.4 面试官挑这行的真实意图

这行的价值不在于它难，而在于它同时踩到了“cv 限定符组合”和“声明语法歧义”两个区域。面试是一个采样过程，对方用一行代码同时采两个样，效率很高。

我在准备这类题的答案时会按这个顺序走：先给结论——合法，等价于volatile int p(2)；再拆构成——第一个volatile在类型说明符序列里，第二个在声明符里，重复等价于一次；再讲影响——p的每次访问都是 volatile 访问，不要因为它长得奇怪就以为有什么隐藏语义；最后补一句工程建议——真实项目里只写一个，另一个位置留给真正需要区分的东西，比如const和volatile的组合。四句话讲完，对方一般不会再往下追。

顺便说一个相关的加分点：volatile是可以修饰成员函数的。写成void refresh() volatile;，其效果是成员函数内部的this类型变成volatile T*，函数里访问的所有成员都当作 volatile 对象处理。这个语法在做硬件抽象层的类封装时会用到，知道它存在的人不多。

3. volatile 的能力边界：原子性、内存序它一个都不管

3.1counter++为什么天生不是一次访问

这是面试中出现频率最高的追问：volatile int counter; counter++;多线程下安全吗？

答案是不安全，原因藏在汇编里。counter++至少对应三条指令：把内存值加载到寄存器、寄存器加一、写回内存。三步中间任何一步都可能被切换出去。

volatile int counter = 0; void worker() { for (int i = 0; i < 100000; ++i) { ++counter; // 加载、自增、写回，三步不是原子 } }

两个线程各跑十万次，最终结果常常小于二十万。volatile保证了每次加载和每次写回都真实发生，但它管不了“加载到写回之间这段时间不能被别人插入”。这个空窗期才是竞态的根源。

更直白地说，volatile 保证的是单次访问的可见性，不保证访问序列的原子性。++是一个序列，不是一个访问。同理，counter += n、flag = !flag、ptr = ptr->next，只要涉及读改写三步，volatile 都顶不住。

有人会追问：那在只有一颗核、没有多线程、只有中断的场景下呢？这时候++counter确实可能出问题，因为主循环执行到“加载完还没写回”的时候中断来了，中断里也改了这个变量，返回后主循环用旧值写回，中断那次修改就丢了。正确做法是在临界区里关中断，或者用原子操作。这个细节在嵌入式面试里问得很多。

3.2 volatile 与 std::atomic 的能力对照

这两者的关系是很多人的知识盲区。我用一张表把能力边界摊开。

选择逻辑很清晰：跟硬件或信号打交道，用 volatile；跟其他线程打交道，用 atomic。两者不是替代关系，是两个不同问题的答案。

需要提醒一句，std::atomic在某些平台上对某些类型并不是无锁的，内部可能退化成加锁实现。如果这段代码在同一条中断路径里被调用，加锁实现可能带来死锁风险，这种情况下需要用is_always_lock_free在编译期做静态断言。这个坑我在做跨平台代码时踩过一次，表现是中断频率一高就卡死，查了很久才定位到原子类型在目标平台上走了内部锁。

3.3 双检锁的历史包袱：为什么它在标准 C++ 里站不住

单例的双检锁写法是 volatile 最著名的翻车现场，值得单独讲。

// 这段代码在标准 C++ 下是错误的 class Singleton { public: static Singleton* instance() { if (ptr_ == nullptr) { std::lock_guard<std::mutex> lk(mtx_); if (ptr_ == nullptr) { ptr_ = new Singleton(); } } return ptr_; } private: static Singleton* volatile ptr_; // 加 volatile 也救不了 static std::mutex mtx_; };

问题出在new Singleton()这个表达式。它拆成三步：分配内存、在内存上构造对象、把地址赋给指针。编译器和处理器都可能把第三步提到第二步之前。这时候另一个线程在第一次检查时看到指针非空，直接返回，拿到的却是一块构造还没完成的内存，访问成员就是未定义行为。

那为什么有人觉得加volatile能解决？因为在某些编译器上，volatile被赋予了额外的读写屏障语义。比如 MSVC 的/volatile:ms模式会给 volatile 访问附加 acquire/release 效果，在这个模式下这段代码“看起来能跑”。但这属于实现扩展，不是标准保证，换个编译器或者换个编译选项就崩。C++11 之后正确写法是用std::atomic<Singleton*>配合memory_order_acquire和memory_order_release，或者更省事地用函数内静态局部变量——C++11 起局部静态变量的初始化本身是线程安全的。

这个案例的教学价值在于：它精确展示了 volatile 缺了什么。缺的不是“让访问真实发生”，而是“建立跨线程的顺序约束”。把这一条讲清楚，比背十条规则都管用。

3.4 C++20 之后 volatile 的收缩地带

近几年的标准演进里，volatile 的适用范围在收窄。C++20 弃用了一批用法，包括：用 volatile 修饰函数返回值、修饰函数参数、限定的结构化绑定、以及对内建类型的 volatile 复合赋值和自增自减运算。

volatile int v = 0; v++; // C++20 起弃用 v += 1; // C++20 起弃用

注意这是弃用不是删除，代码还能编译，但开高警告等级会报出来，未来某个版本可能真正移除。保留下来的是最核心的那部分：volatile 局部变量、全局变量、成员变量，以及指向 volatile 的指针。也就是说，硬件寄存器访问这个主用途依然完好。

面试里如果能主动提到这条标准演进，通常是个加分项，说明你不是只背了十年前的资料。但别把它当成主要论点，重点还是语义本身。

4. 寄存器、中断与 DMA：volatile 真正的主战场

4.1 寄存器映射的三种写法与各自的坑

抛开面试，volatile 在真实工程里最不可替代的地方就是内存映射寄存器。芯片手册给你一个地址，硬件会在这个地址上改数据，编译器对此一无所知，只能用 volatile 告诉它“别缓存、别合并、别删”。

最常见的写法是宏：

#define UART_DR (*(volatile unsigned int *)0x4000C000u) #define UART_SR (*(volatile unsigned int *)0x4000C004u) void putc_raw(char c) { while ((UART_SR & 0x20u) == 0u) { /* 等待发送缓冲空 */ } UART_DR = (unsigned int)c; }

这里有两个细节值得展开。第一，while循环里的读必须每次都真的发生，如果UART_SR不是 volatile，编译器会认为循环体没有修改它，直接优化成要么死循环要么一次都不循环。第二，UART_DR = ...这个写不能和前面的读合并，也不能被挪到循环外面。

第二种写法是用结构体把一组寄存器包起来：

typedef struct { volatile unsigned int SR; volatile unsigned int DR; volatile unsigned int CR; } UartRegs; #define UART0 ((UartRegs *)0x4000C000u)

这种写法可读性好，但要注意结构体成员的布局必须和手册里的偏移完全一致，中间如果有保留位必须显式补reserved字段，否则指针算错位置，写到别的寄存器上去。我在一个项目里见过因为漏了一个保留字，配置寄存器被写成了状态寄存器，现象是设备偶尔能初始化成功、偶尔失败，查了两天才定位到。

第三种是 C++ 里常见的手法，用reinterpret_cast加constexpr地址常量，配合static_assert校验偏移，比宏安全一些，但本质一样。

不管哪种写法，有一条铁律：寄存器地址只能通过 volatile 指针访问，绝不允许先把值读进普通变量再循环判断。有人图省事写unsigned int sr = UART_SR; while (!(sr & 0x20)) {}，这样写循环里判断的是寄存器快照，跟硬件彻底脱钩，直接死循环。

4.2 中断标志位：最经典的 volatile 用例

中断服务程序和主循环共享的标志位，是 volatile 在教科书之外最实在的应用。核心矛盾是：主循环里等标志位，中断里置标志位，而编译器看不到中断。

static volatile int g_rx_done = 0; static unsigned char g_buf[64]; void UART_IRQHandler(void) { /* 硬件已经把数据搬进 g_buf */ g_rx_done = 1; } int wait_for_rx(void) { int timeout = 1000000; while (!g_rx_done && timeout-- > 0) { } return g_rx_done; }

g_rx_done不加 volatile 的后果很直接：编译器在wait_for_rx里把g_rx_done读一次放进寄存器，之后循环里一直用这个寄存器值判断，中断改的那次内存写永远进不来，函数要么立刻返回错误结果，要么在超时前一直空转。这类 bug 的可怕之处在于它在-O0下一切正常，一开优化就复现，很多人第一次遇到会以为是优化器有 bug。

信号处理函数里也有对应的标准做法。C 标准专门为此定义了一个类型：

#include <signal.h> static volatile sig_atomic_t g_stop = 0; void on_sigint(int sig) { (void)sig; g_stop = 1; }

sig_atomic_t保证在信号处理函数和主程序之间的读写是原子的，配合volatile保证访问真实发生。这两个条件缺一不可，只写volatile int在某些平台上可能在读到一半被信号打断，拿到一个撕裂的值。

这里补一个容易忽略的点：volatile只能保证这个变量本身的访问，它管不了被它“保护”的其他数据。上面g_buf的例子，中断写g_buf、主循环读g_buf，如果g_buf不是 volatile，主循环读到的内容仍可能被缓存或者重排。要么给g_buf也加 volatile，要么用内存屏障把两侧隔开。实际工程里更稳的做法是用一个环形缓冲区加读写索引，索引做原子操作，数据区靠屏障保证可见性。

4.3 内存屏障缺位时，volatile 顶不上

这一节专门说清楚一个高频误区：volatile 在 CPU 层面不建立任何顺序保证。

现代处理器为了性能会重排访存指令。以常见的弱内存序架构为例，一个写操作后面跟一个读操作，硬件完全可能让读先完成。在这种机器上，下面这段“生产者—消费者”的代码靠 volatile 是不够的：

volatile int ready = 0; int data = 0; void producer(void) { data = 42; ready = 1; // 可能先于 data 的写被其他核看到 } void consumer(void) { while (!ready) { } use(data); // 可能读到旧值 }

要让这段代码在弱内存序平台上正确工作，需要在ready = 1之前插入释放屏障，在读到ready之后插入获取屏障。C++ 里对应的工具是std::atomic_thread_fence，或者干脆把ready换成std::atomic<int>并用memory_order_release/memory_order_acquire。C 里也有对应的atomic_store_explicit系列。

我在做跨平台代码时的经验是：只要这段逻辑涉及“先写 A 后写 B，读方看到 B 就认为 A 已完成”，就不该用 volatile 裸写，直接上原子加内存序。用 volatile 拼屏障的代码在 x86 上往往能跑通（因为 x86 的存储模型比较强），一换到别的架构就原形毕露，而且这种 bug 极难复现，往往在压力测试或者量产之后才暴露。

4.4 volatile 的代价：从寄存器分配到指令数

说完了用法，得说说成本，不然容易滥用。

第一层代价是寄存器分配。volatile 变量不能长期驻留寄存器，每次使用都要从内存加载。在一个热点循环里，如果循环计数器被误加了 volatile，每轮迭代多出两次访存，性能差距在嵌入式平台上可能达到数倍。

第二层代价是指令数。普通变量连续赋值会被合并，volatile 不会。写过寄存器的人都知道，配置一个外设往往要连续写十几个字段，如果这些字段分散在 volatile 结构体里，每条赋值都会生成一条存储指令，这在时序敏感的初始化序列里反而是必要的，但在纯软件逻辑里就是纯损耗。

第三层代价是优化空间被压缩。编译器没法对 volatile 变量做常量传播、死代码消除、循环不变量外提。它只能老老实实按你写的顺序生成代码。

所以我的判断标准是：只有当一个对象的修改来源在编译器视野之外时，才加 volatile。硬件寄存器、中断修改的标志、信号处理函数改的变量、setjmp/longjmp跨过的局部变量，这四类之外，绝大多数情况都不需要。多线程共享数据请用原子或锁，不要用 volatile 凑合。

5. 面试现场的五类问法与我的回答骨架

5.1 概念题：一句话说清它约束的是什么

最常见的开场是“说说 volatile 的作用”。这个问题的坑在于，答“防止编译器优化”太笼统，答三条规则又像背书。我习惯用一句话打底再展开：

volatile 告诉编译器，这个对象的值可能在程序控制之外发生变化，因此对它的每一次访问都必须真实发生，不能合并、不能删除、相对顺序不能改变。它约束的是访问方式，不涉及原子性和内存序。

这句话里包含了三个信息：约束对象是谁、约束内容是什么、边界在哪。后面如果对方追问，就按“不能省、不能合、不能挪”三条展开，每条配一个反例。如果对方不追问，这句话本身已经足够体现理解深度。

有个细节值得主动提：volatile 不是“关闭优化”的开关，它只作用于被修饰的对象。这个补充能立刻把你和背答案的人区分开。

5.2 判断题：能保证线程安全吗

标准答案是不能，而且要给理由。理由分两层：一层是复合操作非原子，++拆成三步；另一层是不建立跨线程的同步关系，无法保证一个线程的写在另一个线程可见的顺序。

如果对方继续追问“那什么情况下 volatile 在多线程里看起来是对的”，可以举单写多读的布尔标志：一个线程只写、其他线程只读，且不依赖其他数据的可见性。这种场景下 volatile 在多数平台上能工作，但标准并不保证，正确写法仍然是std::atomic<bool>配memory_order_relaxed。能主动指出“看起来对但不是标准保证”，通常会让面试官高看一眼。

5.3 读代码题：这段循环为什么退不出来

经典题型如下：

bool g_flag = false; // 注意没有 volatile void thread_a() { while (!g_flag) { } do_something(); } void thread_b() { g_flag = true; }

问：为什么thread_a可能永远不退出。

分析路径是：g_flag不是 volatile 也不是原子类型，编译器在thread_a里看不到任何能修改它的代码，合法地把读操作提到循环外，变成“读一次，若为假则死循环”。这是编译器优化，不是 bug。修法有两条：改成std::atomic<bool>是标准答案；用volatile bool能让循环退出来，但仍然不解决内存序问题，属于“能跑但不正确”。

答这道题的关键不是说出“加 volatile”，而是说清楚“加 volatile 只是让读真实发生，真正正确的方式是原子类型”。能指出这一点，说明你理解了边界。

5.4 组合题：const volatile 与 volatile 成员函数

const volatile int这个组合经常被拿出来问。它表达的是：程序不能写（const），但外部可能改（volatile）。典型场景是只读的状态寄存器，硬件会更新它的值，软件只负责读。这种变量的每次读取都是 volatile 读，同时任何写操作在编译期就会被拒绝。

volatile修饰成员函数是另一个冷门点。void refresh() volatile;表示这个成员函数里的this是volatile T*，函数内访问的成员都按 volatile 处理。它的用途是把硬件访问封装进类里时，保证成员函数内部的每次成员访问都是真实访存。

还有一个常见混淆：volatile和mutable完全是两回事。mutable用于在 const 成员函数里修改成员，解决的是 const 正确性问题；volatile解决的是访问真实性问题。两者可以同时出现在一个成员上，语义各自独立。

5.5 扣分点清单：这些回答一出口就掉档

整理几条我实际听过、印象比较深的错误回答，供对照检查。

最后一条要特别说明：volatile不是建议性的，是强制的。编译器可以忽略register，但不能忽略volatile。把这两者混为一谈，是很典型的印象式记忆。

如果时间允许，我会在回答末尾补一句工程经验：真实项目里 volatile 用得越少越好，每加一个都应该能说清楚“这个值在编译器视野之外被谁改了”。说不清楚就别加，加了反而掩盖真正的并发问题。

最后分享一个我自己调 bug 的习惯。遇到“开优化就挂、关优化就好”的现象，第一反应是查 volatile，但第二反应一定要查有没有别的地方越界写。因为野指针踩到某个变量上，表现和缺 volatile 几乎一模一样，而后者改起来简单，前者才是真正的定时炸弹。这个习惯帮我避过至少两次误判，其中一次真实原因是数组越界把相邻的循环变量踩了，如果当时只加 volatile，问题会被暂时掩盖，等到上线再爆出来就麻烦了。