你的变量被编译器偷偷优化掉了——volatile这个关键字到底什么时候该加欢迎关注微信公众号“边缘AI嵌入式”带你了解更多嵌入式加边缘AI的前沿技术和应用示例今天写volatile时想到上学那会给企业做的一个项目用的是某国产MCUADCDMA采集8个通道的模拟量。DMA搬运完成后触发中断中断里设标志位主循环里检测到标志位就去DMA缓冲区读数据做计算。开发阶段一直用-O0编译一切正常。交付前切到-O2做性能优化结果ADC读出来的值死活不更新永远是上电时第一次读到的值。查了两天。最后发现DMA缓冲区没加volatile。编译器在-O2下把缓冲区里的旧值缓存到了寄存器里后面每次读其实都在读寄存器里的过时数据。加上volatile两秒钟解决。两天的时间换了一个单词。这大概就是嵌入式开发的浪漫。你有没有遇到类似的这种玄学事件代码逻辑查了八百遍没问题。硬件信号拿示波器看了也没问题。但程序就是不按预期跑。最诡异的是——你把编译器优化等级从-O2降到-O0bug就消失了。你开始怀疑人生怀疑编译器甚至怀疑这颗芯片是从义乌小商品市场批发来的。别慌。十有八九你漏了一个volatile。先看一个经典翻车现场uint8_tflag0;voidEXTI0_IRQHandler(void){flag1;}intmain(void){// ... 初始化 ...while(flag0){// 等待中断把flag置1}// flag变成1了往下执行do_something();}逻辑清清楚楚主循环里死等等中断把flag改成1就往下走。有什么问题-O0编译一切正常。中断来了flag变1循环退出皆大欢喜。-O2编译主循环死在那里了。中断触发了一万次flag的值在内存里确实是1了但程序就是不往下走。原因是编译器太聪明了。编译器的小心思编译器的优化器在分析while(flag 0)这段代码的时候它看到的世界是这样的“flag在进入循环之前是0循环体里没有任何代码会修改flag所以flag永远是0。既然永远是0那这个循环永远不会退出。既然永远不退出我就不用每次都去内存里读flag了直接当成0就行。”然后编译器把你的代码优化成了等价于while(1){// 永远在这儿转}编译器没有错。从C语言的标准来看它的分析完全正确。因为编译器不知道有个叫中断的东西会在背后偷偷改变flag的值。在编译器的认知里如果当前的执行流没有修改一个变量那这个变量就不会变。这就是问题所在编译器不知道存在你的代码之外的力量。中断服务函数是硬件触发的不在编译器分析的正常执行流范围内。DMA控制器也是外设寄存器也是——它们都可以在你的代码背后偷偷改变内存中的值。volatile的作用告诉编译器别自作聪明volatile这个关键字翻译过来是易变的。它的作用就一句话告诉编译器这个变量可能在你看不见的地方被修改所以每次访问它都必须老老实实去内存里读别给我缓存到寄存器里偷懒。修复方案极其简单volatileuint8_tflag0;// 就加这么一个词加了volatile之后编译器在生成while(flag 0)的汇编代码时每次循环都会从flag对应的内存地址重新读取值而不是用寄存器里缓存的旧值。一个单词解决一个通宵。到底哪些场景必须加volatile记住这个口诀凡是会被你的代码之外的力量修改的变量都需要volatile。场景一中断和主循环之间共享的变量这是最常见的场景上面已经演示过了。中断里改的变量主循环里读加volatile。反过来也一样主循环里改的变量如果中断里要读也加。volatileuint32_tsystick_count0;// SysTick中断里累加voidSysTick_Handler(void){systick_count;}uint32_tget_tick(void){returnsystick_count;// 主循环里读}场景二硬件外设寄存器这个其实你已经在用了只是可能没注意到。STM32的CMSIS头文件里所有外设寄存器的定义都带着volatiletypedefstruct{__IOuint32_tCR1;// __IO就是volatile__IOuint32_tCR2;__IOuint32_tSR;// 状态寄存器硬件会自己修改它__IOuint32_tDR;// 数据寄存器收到数据硬件自动填进去// ...}USART_TypeDef;状态寄存器的值是硬件自己改的你的代码没动它但它就是变了。如果不加volatile编译器可能会把第一次读到的状态值缓存起来之后都用这个旧值那你永远也等不到发送完成的标志位。场景三RTOS中多个任务共享的变量如果你用了FreeRTOS之类的实时操作系统两个任务之间通过全局变量通信虽然正规做法应该用信号量或消息队列那这个变量也需要volatile。因为任务切换是由调度器控制的对编译器来说另一个任务的代码也属于看不见的力量。场景四DMA操作的目标缓冲区DMA直接内存访问可以在不经过CPU的情况下直接往内存里写数据。你的代码没动那块内存但DMA把串口收到的数据搬进去了。如果缓冲区没加volatile编译器可能认为那块内存里的内容没变过。volatileuint8_tdma_rx_buf[256];// DMA往这里搬数据volatile不能做的事讲完了该加的场景再讲讲volatile经常被过度神化的地方。误区一volatile能保证原子性不能。volatileuint32_tcounter0;// 中断里voidTIM_IRQHandler(void){counter;}// 主循环里voidmain_loop(void){uint32_tvalcounter;// 读出来的值可靠吗}在32位MCU上读写一个32位变量通常是原子的一条指令搞定所以上面这个例子碰巧没问题。但如果是一个64位变量或者是一个结构体counter这个操作就不是原子的了——它是读-改-写三步。中断可能在读和写之间插进来造成数据竞争。volatile只保证每次都去内存读不保证读写过程中不被打断。需要原子性的话你得关中断或者用硬件提供的原子操作指令。误区二volatile能当内存屏障用不完全能。在简单的Cortex-M单核MCU上volatile的效果通常足够了。但如果你在写多核系统或者和Cache打交道的高端SoC比如Cortex-A系列光靠volatile是不够的你还需要DMB/DSB之类的内存屏障指令来保证数据在各级缓存和内存之间的一致性。不过话说回来如果你在看这篇文章大概率还在跟Cortex-M打交道内存屏障的事暂时不用焦虑。误区三volatile会拖慢程序会但没你想的那么严重。加了volatile后编译器不能把这个变量优化到寄存器里每次都要访问内存确实会慢一点。但在嵌入式里需要加volatile的变量通常是标志位、计数器这种低频访问的东西。你的性能瓶颈绝不会出在这几个变量上。反过来说不该加的地方别乱加。如果你给一个纯粹的局部计算变量加了volatile编译器就没法做寄存器优化、循环展开这些加速手段那才是真的浪费性能。一个进阶技巧volatile的指针和指向volatile的指针这个是面试常考题也是日常开发中容易搞混的。volatileuint32_t*p1;// p1指向一个volatile的变量常用uint32_t*volatilep2;// p2本身是volatile的但指向的内容不是volatileuint32_t*volatilep3;// 全都是volatile的偶尔需要最常用的是第一种指针指向的那个内存地址里的值是可能被外部修改的。比如你定义一个指针指向外设寄存器的地址volatileuint32_t*uart_dr(volatileuint32_t*)0x40011004;每次通过*uart_dr读值编译器都会老老实实从0x40011004这个地址读不会缓存。这正是你想要的。第二种用得很少除非指针本身会在中断里被修改比如中断里切换了缓冲区的指针。第三种更少见除非指针和它指向的内容都可能被外部修改。那我怎么判断一个变量到底要不要加volatile问自己三个问题这个变量会不会在中断/DMA/其他任务里被修改——会就加。这个变量是不是映射到硬件寄存器的——是就加。这个变量只在当前函数或当前执行流里使用——那就别加让编译器好好优化。如果你实在拿不准还有一招开-O2编译跑一遍。再开-O0编译跑一遍。如果行为不一样大概率就是少了volatile。当然这招只能当救火工具不能当设计方法论。最好还是在写代码的时候就想清楚每个变量的生命周期和谁会动它。最后当你盯着屏幕上死活不变的变量值想砸键盘的时候先冷静看看是不是少了个volatile。它可能就是你和准时下班之间唯一的距离。*