volatile 关键字

1 前言

volatile 关键字是计算机编程中最易被误解的特性之一。虽然它的字面意思是“易变的”，但在不同的语境（C/C++、Java、C#、Rust、数据库）下，其语义范围从简单的“禁止优化”延伸到了复杂的“内存可见性”和“指令重排约束”。本报告旨在通过标准原文、汇编分析及测试代码，还原 volatile 在现代软件工程中的全貌。

2 C 标准引入 volatile的动机

2.1 Unix 中的问题

C 语言之所以引入 volatile 关键字，最初是为了解决类似早期 UNIX 源码中的问题：

#define KL 0177560  // 键盘状态寄存器的内存映射地址

struct { char lobyte, hibyte; };
struct { int ks, kb, ps, pb; };

getchar() {
    register rc;
    ...
    // 轮询等待：死循环检查键盘状态寄存器的最高位（符号位）是否变为 1
    while (KL->ks.lobyte >= 0); 
    
    // 按键按下后，读取数据寄存器并提取低 7 位的 ASCII 码
    rc = KL->kb & 0177;
    ...
    return rc;
}

上述 getchar() 函数中，程序需要进行硬件轮询（Polling）。它通过宏 KL 直接指向 PDP-11 机器上被内存映射的键盘状态寄存器（KBD_STAT）。当用户没有按键时，该寄存器的最高位（符号位）为 0，对应的标量值大于等于 0，程序保持阻塞；一旦用户按下按键，硬件会自动将该最高位置为 1，此时标量值变为负数，程序跳出循环，接着从数据寄存器中取走按键编码。

为了让这段代码正常工作，编译器在生成的汇编指令中，必须在每次循环迭代时都去该内存地址读一次数据。

但在常规的编译优化逻辑中，编译器会面临一个两难抉择：

普通内存的优化逻辑：如果这块内存只是普通的变量，为了追求极致性能，编译器在第一次读取后，发现后续代码没有对它进行修改，就会选择把数据缓存在 CPU 寄存器中，以后直接复用缓存。这样可以减少慢速的内存总线访问。
硬件寄存器的特殊需求：但在这个场景下，改变该内存数据的不是软件本身，而是外部硬件（键盘）。如果编译器把数据缓存在 CPU 寄存器里，那么无论用户怎么敲击键盘，CPU 寄存器里的值永远不会变，这个 while 轮询就会彻底沦为死循环。

在早期的 K&R C 时代，由于语法中缺乏一种标记手段，编译器根本无法分辨哪些内存是“普通变量”，哪些内存是“硬件寄存器”。

2.2 volatile 的引入

为了解决上面的问题，标准 C 引入了 volatile 关键字。

在《The C Programming Language, Second Edition（第二版）》中如下解释：

The purpose of volatile is to force an implementation to suppress optimization that could otherwise occur. For example, for a machine with memory-mapped input/output, a pointer to a device register might be declared as a pointer to volatile, in order to prevent the compiler from removing apparently redundant references through the pointer.

（volatile 的核心作用，就是强制编译器放弃对该变量进行任何形式的编译优化。例如，在支持内存映射 I/O（MMIO）的机器上，指向设备寄存器的指针应该被明确声明为指向 volatile 的指针。这样可以防止编译器将那些“表面上看起来重复、多余”的内存访问指令给优化掉。）

2.3 C/C++ 标准中的语义

在 C/C++ 中，volatile 的核心任务是约束编译器对“抽象机”（Abstract Machine）状态的优化，确保程序的可观察行为符合程序员意图。

2.3.1 抽象机和可观察行为

2.3.1.1 什么是“抽象机？

C/C++ 标准在定义语言语义时，并没有直接对应到具体的 ARM、x86 芯片或具体的操作系统，而是虚构了一个高高在上的、完美的“抽象机”。
在标准眼中，你的 C/C++ 源码是在这个抽象机上串行、严格、逐行执行的。抽象机拥有无限的内存，每一次变量读写都是一次真实发生的内存事件。
然而，物理世界的编译器（如 GCC、Clang）为了追求极致的性能，不可能真的傻傻地按照抽象机那种低效的方式去生成汇编代码。标准给予了编译器极大的自由度，即 As-if 规则：

只要最终生成的机器码在运行时的 “可观察行为” 与抽象机一致，编译器怎么优化、怎么魔改代码、怎么颠倒指令顺序都是合法的。

2.3.1.2 什么是“可观察行为”？

在标准（ISO C11 5.1.2.3）中，抽象机的外部世界能感知到的变化才叫可观察行为。这仅仅包括：

对终端/文件的输入与输出（I/O 读写）。
写入文件的具体数据。
对声明为 volatile 对象的访问。

除了这三点之外，像普通变量的读写、中间控制流的计算等，都属于抽象机的“内部隐私”。编译器认为外界根本看不到这些隐私，因此可以肆无忌惮地优化它们。

2.3.1.3 为什么普通变量无法约束编译器？

假设有以下一段再普通不过的代码：

int a = 10;
int b = a + 5;
a = 20;

在抽象机的模型里，程序发生了三次内存操作：写 a \(\rightarrow\) 读 a \(\rightarrow\) 写 a。
但是，因为 a 和 b 只是普通变量，它们的读写不属于“可观察行为”。编译器在进行死代码消除和寄存器分配优化后，生成的汇编代码可能直接变成了：

// 编译器眼中等价的可观察行为
int b = 15;
int a = 20;

由于原本的“写 10”和“读 a”在优化后的硬件上从未真正发生过，如果此时 a 对应的不是普通内存，而是一个外部硬件会自动修改的寄存器，程序的逻辑就彻底崩溃了。

2.3.2 `volatile` 的法理任务：将内部隐私提升为“可观察行为”

当我们给对象加上 volatile 限定符时，根据 ISO C 11 (N 1570) 标准原文：

"Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine. [...] This is the observable behavior of the program."

这句话的法理重量在于：它剥夺了编译器利用 As-if 原则进行优化的特权。
一旦一个对象被标记为 volatile，对它的每一次读取和写入，就不再是抽象机可以随便抹去的“内部隐私”，而是被提升到了与“向屏幕打印 log”、“向文件写入数据”同等重要的“可观察行为”高度。
因此，编译器必须收起所有的聪明才智，严格、死板地按照抽象机的规则去评估它：

禁止缓存：每次在源码里看到读 volatile，汇编里必须生成一条去物理地址读取的指令，绝不允许复用 CPU 寄存器里的旧值。
禁止消除：如果连续两次向 volatile 变量写值，即使中间没有读取，编译器也绝不允许把第一次写入当作死代码消掉（因为这两次写入都属于可观察行为，可能对应着硬件的两个连续脉冲信号）。
约束重排：编译器不能把一个 volatile 读写操作，和一个属于可观察行为的 I/O 操作随意调换顺序。

2.3.3 为什么要假设“未知的方式与未知的副作用”？

ISO C11 6.7.3 节的这句规定，是为编译器的优化边界划定的一道红线：

"An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects."

在常规优化中，编译器会进行数据流分析（Data Flow Analysis）。如果编译器通读了全篇代码，发现没有任何一行代码去修改变量 X，编译器就会笃定地认为：X 的值是恒定不变的，从而把所有涉及 X 的条件判断直接固化。
但 volatile 打破了这种“闭环世界假说”。这句话强制要求编译器承认自己的“无知”：

未知的方式修改：即使你在当前的 C 源码里没看到有人改它，外部的硬件中断、DMA（直接内存存取）控制器、或者另一个并行的 CPU 核心，也可能在任何一个悄无声息的瞬间改变这个变量的值。
未知的副作用：对这个变量的每一次写入，都可能触发某些对环境的外部副作用（比如写这个地址会导致一个电机转动、或者触发一个硬件计数器清零）。
因为“无知”，所以编译器必须“敬畏”。由于无法预知行为和后果，编译器只能放弃一切主观推导，老老实实地保留源码中每一次对该内存的物理访问。

如今，volatile 的舞台早已不限于硬件 I/O 驱动，在现代软件（如 Linux 内核的并发原语、多线程状态同步等）中，它依然扮演着不可或缺的幕后英雄角色。

3 C 语言中 volatile 的应用场景

3.1 内存映射 I/O (MMIO)

这是 volatile 最经典的应用。嵌入式设备的硬件寄存器通常映射到特定的内存地址，这些寄存器的值会随物理硬件状态改变（如串口收到数据），而不是由 CPU 指令修改 ``。

示例：轮询状态寄存器

// 假设 0x40001000 是串口状态寄存器地址
#define UART_STAT_REG (*(volatile uint32_t *)0x40001000)

void wait_for_data() {
    // 如果不加 volatile，编译器可能只读一次地址值到寄存器，导致死循环
    while ((UART_STAT_REG & 0x01) == 0); 
    // 处理数据...
}

如果不使用 volatile，编译器可能会生成如下逻辑：加载地址值到 CPU 寄存器 -> 比较寄存器值 -> 跳转回比较。这意味着即使内存中的硬件状态更新了，CPU 寄存器里的旧值也不会改变 ``。

3.2 中断服务程序 (ISR) 与主程序的共享变量

当主程序在等待一个由中断修改的标志位时，该变量必须声明为 volatile。因为从编译器的角度看，主程序的循环逻辑中没有修改该变量的代码，它会倾向于缓存该值 ``。

示例：中断标志位

volatile int g_data_received = 0;

void Timer_IRQHandler(void) {
    g_data_received = 1; // 异步修改
}

int main(void) {
    while (!g_data_received) {
        // 等待中断发生
    }
    printf("Data received!\n");
}

3.3 信号处理器 (Signal Handlers) 中的异步通信

在类 Unix 系统中，信号可以随时打断程序。为了确保信号处理器修改的全局变量对主程序可见，标准规定应使用 volatile sig_atomic_t 类型 ``。sig_atomic_t 保证了操作的原子性，而 volatile 保证了可见性。

示例：处理 SIGINT 信号

#include <signal.h>

volatile sig_atomic_t g_keep_running = 1;

void handle_sigint(int sig) {
    g_keep_running = 0; // 安全地修改状态
}

int main() {
    signal(SIGINT, handle_sigint);
    while (g_keep_running) {
        // 执行任务...
    }
}

3.4 非局部跳转 (setjmp/longjmp) 中的局部变量

当使用 setjmp 保存环境并跳转回 longjmp 时，如果函数内的局部变量（自动变量）在 setjmp 和 longjmp 之间被修改过，其值在跳转后是未定义的，除非将其声明为 volatile ``。

示例：防止变量在跳转后被回滚

#include <setjmp.h>

jmp_buf env;

void test_jump() {
    volatile int count = 0; // 必须是 volatile
    int non_volatile_count = 0;

    if (setjmp(env) == 0) {
        count = 100;
        non_volatile_count = 100;
        longjmp(env, 1);
    } else {
        // 跳转回这里后：
        // count 保证为 100
        // non_volatile_count 的值是不确定的（可能变回 0）
        printf("count: %d, non_volatile: %d\n", count, non_volatile_count);
    }
}

这是因为编译器可能会将 non_volatile_count 缓存在寄存器中，而 longjmp 恢复的是 setjmp 时的寄存器快照，导致变量值“回滚”。volatile 强制变量存储在栈（内存）中，从而避开寄存器恢复的影响 ``。

3.5 防止安全擦除被优化

在处理密钥或密码时，开发者常使用 memset 清空缓冲区。但如果清空后不再读取该变量，编译器可能会认为这是“死存储”（Dead Store）并将其删除，导致敏感信息残留在内存中 ``。

void secret_process() {
    char password[1];
    get_password(password);
    //...处理...
    
    // 使用 volatile 指针强制执行写入，防止 memset 被优化掉
    volatile char *p = password;
    while(sizeof(password)--) *p++ = 0;
}

3.6 指针限定符的复合运用

指针与 volatile 结合时，限定符的位置决定了是“指针本身”易变，还是“指针指向的数据”易变。遵循“从右往左读”的原则可以准确区分：

指向易变数据的指针 (volatile int *p)：这是最常见的用法。表示 p 指向的地址内容（如硬件寄存器）可能被外部改变，编译器每次解引用 *p 时都必须重新从内存读取。
易变的指针 (int * volatile p)：表示指针变量 p 存储的地址值本身可能被改变（例如在中断服务程序中将 p 指向一个新的缓冲区）。编译器每次使用 p 之前都要重新获取它存储的地址。
双重易变指针 (volatile int * volatile p)：指针存储的地址和该地址指向的数据都可能在程序控制流之外发生变化。

3.7 `const volatile` 的组合语义

const 和 volatile 并非互斥，它们结合使用在嵌入式驱动中具有明确的物理意义：

语义：const 表示程序逻辑不应修改该变量（只读）；volatile 表示变量值可能被外部修改。
典型场景：系统时钟（RT Clock）或只读状态寄存器。例如 extern const volatile unsigned int rt_clock; 表示该变量由时钟中断更新（易变），但用户任务只能读取，不能尝试对其赋值。

3.8 `volatile` 与位域 (Bit-fields) 的陷阱

在 C 语言中，位域的访问行为是实现定义（Implementation-defined）的。当位域被声明为 volatile 时，会产生复杂的副作用：

存储单元访问：由于位域通常不能独立寻址，访问一个 volatile 位域成员可能会导致编译器读取或写入整个存储单元（Container），从而意外触发相邻位域的硬件行为。
编译器差异：不同编译器（如 GCC 和 Clang）对 volatile 结构体成员的优化抑制程度不同。在某些情况下，即使成员是 volatile 的，如果结构体变量本身没有声明为 volatile，GCC 可能会在高级优化下移除循环检查。
控制参数：GCC 提供如 -fstrict-volatile-bitfields 标志，专门用于强制编译器按位域类型的原始宽度（如 int 宽度）进行访问，以适配特定硬件要求。

3.9 Linux 内核的“临时强转”模式

Linux 内核开发者通常主张不直接将数据结构成员声明为 volatile，因为这会全局禁用优化，导致关键代码段性能下降。

内核实践：内核倾向于在真正需要抑制优化的访问点进行临时强转。
宏定义示例：例如 READ_ONCE(x) 宏，其核心实现即为 (*(volatile typeof(x) *)&(x))。这种做法允许变量在锁保护的临界区内享受编译器优化，仅在需要跨线程同步或处理硬件异步时，才通过强制转换触发 volatile 语义。

3.10 序列点 (Sequence Points) 与访问稳定性

ISO C 标准对 volatile 的最低要求是：在序列点处，所有之前的 volatile 对象访问必须已经稳定，且后续访问尚未发生。

重排限制：编译器可以在两个序列点之间对 volatile 访问进行有限的重排或合并，但不能跨越序列点。
不可作为内存屏障：由于 volatile 不保证非 volatile 变量的执行顺序，因此不能用它来构建多核间的内存屏障。例如，先给普通指针 ptr 赋值再给 volatile 标志位 vobj 赋值，编译器可能重排这两个操作，除非中间加入显式的 asm volatile ("" : : : "memory");。

3.11 C 11 `_Atomic` 与 `volatile` 的协同与替代

自 C 11 起，_Atomic 提供了 volatile 无法实现的特性：

原子性：volatile 不保证操作的原子性（如 i++），而 _Atomic 确保了操作在指令级别不可分割。
可见性与顺序：_Atomic 自带内存模型约束（如 memory_order_acquire），能够处理硬件级别的指令重排，这在多核多线程编程中是 volatile 的上位替代。
推荐原则：对于单纯的硬件地址访问，坚持使用 volatile；对于线程间同步，应优先使用 _Atomic。

4 volatile 在现代编程中的应用和演变

4.1 Linux 内核共享变量访问：READ_ONCE 与 WRITE_ONCE

Linux 内核开发者倾向于不使用 volatile 声明变量，因为它可能导致代码效率极低。取而代之的是显式的访问宏。

// 简化实现
#define READ_ONCE(x)  (*(volatile typeof(x) *)&(x))
#define WRITE_ONCE(x, val) (*(volatile typeof(x) *)&(x) = (val))

对于多线程的同步代码：

/* 线程 A */
while (shared_data->ready == 0) {
    /* 等待线程 B 将 ready 置 1 */
}

READ_ONCE 可以加上 volatile 类似的语义，强制每次都去内存中去读：

while (READ_ONCE(shared_data->ready) == 0) {
    /* 每次循环都必须去内存‘真读’，防止被编译器优化为死循环 */
}

4.2 Rust: 显式方法调用

Rust 语言中不存在 volatile 关键字，而是通过 std::ptr 提供的方法进行显式操作。

use std::ptr;

fn write_to_hardware(addr: *mut u32) {
    unsafe {
        // Rust 要求显式调用 read_volatile 或 write_volatile
        ptr::write_volatile(addr, 0x01); 
        let val = ptr::read_volatile(addr);
    }
}

设计理念：Rust 认为“易变性”是操作（Operation）的属性，而非数据（Data）的属性。

4.3 Java: Happens-Before 保证

与 C/C++ 不同，Java 和 C# 中的 volatile 不仅抑制编译器优化，还深度参与了内存模型（Memory Model），提供跨线程的可见性保证。
在 Java 中，volatile 保证了变量的读写都直接作用于主内存，且具有“Happens-Before”语义：对一个 volatile 变量的写操作先于后面对该变量的读操作发生。

示例：双重检查锁定 (DCL) 单例模式


public class Singleton {
    // 必须加 volatile，防止指令重排
    private static volatile Singleton instance; 

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    // 若无 volatile，instance 赋值可能在构造函数完成前对其他线程可见
                    instance = new Singleton(); 
                }
            }
        }
        return instance;
    }
}

原因：new Singleton() 包含分配空间、初始化对象、引用赋值三个步骤。JVM 可能重排顺序，导致其他线程在检查 instance!= null 时获得一个尚未初始化完成的对象。

4.4 C#: 获取/释放语义 (Acquire-Release)

C# 的 volatile 读操作具有 Acquire 语义（后续指令不能重排到其之前），写操作具有 Release 语义（先前指令不能重排到其之后）。

特性	C# volatile	Interlocked
原子性	仅针对引用和部分 32 位类型。	强原子性（CompareExchange 等）。
性能	极高性能（轻量级栅栏）。	中等（涉及硬件锁总线）。
主要用途	标志位、状态指示。	计数器、复杂同步。

4.5 数据库语境：PostgreSQL 的函数易变性

在数据库（如 PostgreSQL）中，VOLATILE 是一个函数属性标签，用于告知优化器该函数的确定性。

类别	含义	示例
IMMUTABLE	相同输入永远返回相同输出。	`abs(x)`
STABLE	在单次表扫描中输出一致。	`current_timestamp`
VOLATILE	值可能随时间甚至在单次扫描中改变。	`random()`, `nextval()`

优化影响：如果函数被标记为 VOLATILE，优化器将无法在查询中进行预计算，必须对每一行记录重新评估该函数。

posted @ 2026-05-15 16:41 ixbwer 阅读(0) 评论(0) 收藏举报

刷新页面返回顶部

Live Long and fuck it

volatile 关键字

1 前言

2 C 标准引入 volatile的动机

2.1 Unix 中的问题

2.2 volatile 的引入

2.3 C/C++ 标准中的语义

2.3.1 抽象机和可观察行为

2.3.1.1 什么是“抽象机？

2.3.1.2 什么是“可观察行为”？

2.3.1.3 为什么普通变量无法约束编译器？

2.3.2 `volatile` 的法理任务：将内部隐私提升为“可观察行为”

2.3.3 为什么要假设“未知的方式与未知的副作用”？

3 C 语言中 volatile 的应用场景

3.1 内存映射 I/O (MMIO)

3.2 中断服务程序 (ISR) 与主程序的共享变量

3.3 信号处理器 (Signal Handlers) 中的异步通信

3.4 非局部跳转 (setjmp/longjmp) 中的局部变量

3.5 防止安全擦除被优化

3.6 指针限定符的复合运用

3.7 `const volatile` 的组合语义

3.8 `volatile` 与位域 (Bit-fields) 的陷阱

3.9 Linux 内核的“临时强转”模式

3.10 序列点 (Sequence Points) 与访问稳定性

3.11 C 11 `_Atomic` 与 `volatile` 的协同与替代

4 volatile 在现代编程中的应用和演变

4.1 Linux 内核共享变量访问：READ_ONCE 与 WRITE_ONCE

4.2 Rust: 显式方法调用

4.3 Java: Happens-Before 保证

4.4 C#: 获取/释放语义 (Acquire-Release)

4.5 数据库语境：PostgreSQL 的函数易变性

公告

Live Long and fuck it

volatile 关键字

1 前言

2 C 标准引入 volatile的动机

2.1 Unix 中的问题

2.2 volatile 的引入

2.3 C/C++ 标准中的语义

2.3.1 抽象机和可观察行为

2.3.1.1 什么是“抽象机？

2.3.1.2 什么是“可观察行为”？

2.3.1.3 为什么普通变量无法约束编译器？

2.3.2 volatile 的法理任务：将内部隐私提升为“可观察行为”

2.3.3 为什么要假设“未知的方式与未知的副作用”？

3 C 语言中 volatile 的应用场景

3.1 内存映射 I/O (MMIO)

3.2 中断服务程序 (ISR) 与主程序的共享变量

3.3 信号处理器 (Signal Handlers) 中的异步通信

3.4 非局部跳转 (setjmp/longjmp) 中的局部变量

3.5 防止安全擦除被优化

3.6 指针限定符的复合运用

3.7 const volatile 的组合语义

3.8 volatile 与位域 (Bit-fields) 的陷阱

3.9 Linux 内核的“临时强转”模式

3.10 序列点 (Sequence Points) 与访问稳定性

3.11 C 11 _Atomic 与 volatile 的协同与替代

4 volatile 在现代编程中的应用和演变

4.1 Linux 内核共享变量访问：READ_ONCE 与 WRITE_ONCE

4.2 Rust: 显式方法调用

4.3 Java: Happens-Before 保证

4.4 C#: 获取/释放语义 (Acquire-Release)

4.5 数据库语境：PostgreSQL 的函数易变性

公告

2.3.2 `volatile` 的法理任务：将内部隐私提升为“可观察行为”

3.7 `const volatile` 的组合语义

3.8 `volatile` 与位域 (Bit-fields) 的陷阱

3.11 C 11 `_Atomic` 与 `volatile` 的协同与替代