你有過(guò)這種經(jīng)歷嗎一個(gè)設(shè)備放產(chǎn)線上一跑就是好幾天突然某天早上現(xiàn)場(chǎng)打電話過(guò)來(lái)說(shuō)設(shè)備掛了看門(mén)狗復(fù)位串口日志最后幾行全是亂碼。上去看了一眼CPU占用不高溫度也正常Flash也還有空間想了半天才發(fā)現(xiàn)是內(nèi)存的問(wèn)題——不是內(nèi)存條壞了而是代碼里的內(nèi)存被悄悄耗光、踩爛、碎片化了。這就是我寫(xiě)“一堂嵌入式內(nèi)存課”的原因。嵌入式開(kāi)發(fā)里內(nèi)存從來(lái)不是“配置項(xiàng)”而是你每天都在跟它博弈的對(duì)手。很多人學(xué)單片機(jī)、學(xué)Linux驅(qū)動(dòng)、學(xué)RTOS可以寫(xiě)出一堆功能正常的代碼但一到長(zhǎng)時(shí)間運(yùn)行、高并發(fā)中斷、多任務(wù)調(diào)度的場(chǎng)景就露餡。而內(nèi)存相關(guān)的知識(shí)點(diǎn)恰恰也是嵌入式面試?yán)锏母哳l八股結(jié)構(gòu)體對(duì)齊為什么浪費(fèi)空間malloc失敗是不是只有內(nèi)存不夠這一個(gè)原因棧和堆到底誰(shuí)快全局變量為什么最好別亂用這些問(wèn)題背答案容易真拿到代碼里說(shuō)清楚很多人會(huì)卡殼。這篇文章不打算給你上一節(jié)學(xué)院派的理論課我會(huì)從實(shí)際項(xiàng)目的角度出發(fā)把嵌入式內(nèi)存的整個(gè)框架拆開(kāi)內(nèi)存到底長(zhǎng)什么樣、哪些地方容易出問(wèn)題、出了問(wèn)題怎么定位、平時(shí)怎么從設(shè)計(jì)上省內(nèi)存。無(wú)論你是剛轉(zhuǎn)嵌入式的小白還是被線上問(wèn)題折磨的苦逼工程師或者正在準(zhǔn)備嵌入式崗位面試這篇內(nèi)容都值得你花十分鐘慢慢看完。1. 為什么嵌入式開(kāi)發(fā)者必須把內(nèi)存當(dāng)成第一等大事1.1 一個(gè)跑了幾天的設(shè)備為什么說(shuō)掛就掛先講一個(gè)我實(shí)際處理過(guò)的故障。一個(gè)遠(yuǎn)程升級(jí)后的終端設(shè)備用戶反饋平均每三天自動(dòng)重啟一次。排查方向一開(kāi)始完全跑偏了懷疑是網(wǎng)絡(luò)心跳超時(shí)導(dǎo)致看門(mén)狗復(fù)位又懷疑是Flash寫(xiě)入導(dǎo)致系統(tǒng)卡死查了兩周沒(méi)結(jié)果。后來(lái)我把日志里每次復(fù)位前的上下文全部打出來(lái)發(fā)現(xiàn)進(jìn)程是在調(diào)用一個(gè)網(wǎng)絡(luò)報(bào)文解析函數(shù)時(shí)掛掉的再往深挖是函數(shù)里有一段對(duì)緩沖區(qū)寫(xiě)入的操作長(zhǎng)度沒(méi)有做邊界檢查數(shù)據(jù)稍大就把棧給踩了。這種問(wèn)題在開(kāi)發(fā)環(huán)境里很難復(fù)現(xiàn)因?yàn)闇y(cè)試數(shù)據(jù)量小你不可能每次都發(fā)超長(zhǎng)報(bào)文可一旦上了產(chǎn)線各種極端情況都會(huì)冒出來(lái)。這個(gè)案例想說(shuō)明一個(gè)非常樸素的道理嵌入式環(huán)境里的大部分嚴(yán)重故障根源都在內(nèi)存。棧溢出、堆越界、野指針、內(nèi)存泄漏它們不會(huì)立刻讓你程序崩掉而是像一顆定時(shí)炸彈跑幾小時(shí)、幾天、甚至幾周后突然發(fā)作。更麻煩的是這類問(wèn)題通常在開(kāi)發(fā)機(jī)上無(wú)法穩(wěn)定復(fù)現(xiàn)等到現(xiàn)場(chǎng)才暴露排障成本極其高昂。所以這塊內(nèi)容值得你提前用心學(xué)而不是等炸彈炸了再補(bǔ)課。1.2 從面試題到架構(gòu)設(shè)計(jì)內(nèi)存是嵌入式崗位的分水嶺嵌入式崗位的面試題里和內(nèi)存相關(guān)的題目幾乎必考。我隨手列幾個(gè)高頻的sizeof一個(gè)結(jié)構(gòu)體為什么不是成員大小之和malloc返回NULL的概率有多大返回非NULL就一定能用嗎free之后指針為什么要置NULL局部數(shù)組開(kāi)多大才算合理遞歸在嵌入式里為什么危險(xiǎn)這些題目考的不是記憶力而是你有沒(méi)有真正理解程序運(yùn)行時(shí)的內(nèi)存模型。能背出答案的人很多但能把答案講透的人很少。比如結(jié)構(gòu)體對(duì)齊很多人知道CPU為了性能會(huì)填充字節(jié)但到了自己定義結(jié)構(gòu)體時(shí)依然把char、uint32_t、uint16_t隨便排列一個(gè)簡(jiǎn)單的配置文件結(jié)構(gòu)體白白多占幾十字節(jié)。再比如malloc失敗很多人以為系統(tǒng)只剩下一點(diǎn)點(diǎn)內(nèi)存才會(huì)失敗但實(shí)際情況里堆碎片化導(dǎo)致連續(xù)大塊內(nèi)存分配失敗比真正物理內(nèi)存不足要常見(jiàn)得多。這些問(wèn)題在工作中一旦遇到就非?？简?yàn)?zāi)銓?duì)內(nèi)存機(jī)制的理解深度。往上看一層嵌入式架構(gòu)師和普通開(kāi)發(fā)者的差異也往往體現(xiàn)在內(nèi)存設(shè)計(jì)上。普通開(kāi)發(fā)者考慮的是一段代碼怎么跑通架構(gòu)師考慮的是這個(gè)系統(tǒng)允許有多少個(gè)連接、每個(gè)連接占用多少緩沖、總量控制在多少、峰值情況怎么降級(jí)。內(nèi)存對(duì)于嵌入式系統(tǒng)來(lái)說(shuō)就是預(yù)算花錢(qián)要有規(guī)劃不能想怎么花就怎么花。1.3 嵌入式內(nèi)存觀把“夠用”變成“省著用”P(pán)C和服務(wù)器上的程序員可以不用太在意內(nèi)存反正物理內(nèi)存不夠還有虛擬內(nèi)存虛擬內(nèi)存不夠還能加條子。但嵌入式的內(nèi)存觀完全不同我總結(jié)了幾個(gè)關(guān)鍵差異。第一嵌入式設(shè)備通常沒(méi)有swap交換空間。也就是說(shuō)內(nèi)存告急就是真的告急操作系統(tǒng)沒(méi)法把一部分?jǐn)?shù)據(jù)挪到磁盤(pán)上緩解壓力系統(tǒng)只會(huì)直接分配失敗甚至觸發(fā)看門(mén)狗復(fù)位。第二嵌入式系統(tǒng)的堆空間往往是固定的比如你在鏈接腳本里給堆分配了64KB那就是64KB用完了就沒(méi)了。第三嵌入式系統(tǒng)里不僅有CPU訪問(wèn)的內(nèi)存還有DMA緩沖區(qū)、外設(shè)寄存器映射、共享內(nèi)存、DDR和SRAM等不同物理內(nèi)存域它們的訪問(wèn)方式、生命周期、對(duì)齊要求都不一樣比純應(yīng)用開(kāi)發(fā)復(fù)雜得多。所以做嵌入式開(kāi)發(fā)心態(tài)要調(diào)整成“省著用”。內(nèi)存不是拿來(lái)浪費(fèi)的而是要精確計(jì)算、合理分配的。這個(gè)意識(shí)會(huì)貫穿你整個(gè)職業(yè)生涯從第一行嵌入式代碼開(kāi)始到設(shè)計(jì)一個(gè)完整的嵌入式Linux項(xiàng)目你都在跟內(nèi)存打交道。懂得內(nèi)存你才敢說(shuō)自己入門(mén)了嵌入式。2. 先把內(nèi)存的全景摸清楚棧、堆、全局區(qū)與外設(shè)2.1 C程序的內(nèi)存布局背下來(lái)未必有用畫(huà)出來(lái)才有用嵌入式C程序的內(nèi)存布局其實(shí)非常固定但很多人從來(lái)沒(méi)有認(rèn)真畫(huà)過(guò)一遍。以典型的單片機(jī)或者嵌入式Linux用戶態(tài)程序?yàn)槔龔牡偷刂返礁叩刂反笾戮褪谴a段、只讀數(shù)據(jù)段、已初始化數(shù)據(jù)段、未初始化數(shù)據(jù)段、堆、棧棧頂以下是內(nèi)核映射區(qū)或保留區(qū)域。代碼段存放機(jī)器指令正常情況下只讀只讀數(shù)據(jù)段放字符串常量、const修飾的全局變量已初始化數(shù)據(jù)段也叫.data段放有初值的全局變量和靜態(tài)變量未初始化數(shù)據(jù)段也就是.bss段放沒(méi)顯式初始化的全局變量和靜態(tài)變量這一段不占用實(shí)際的Flash空間加載時(shí)被清零堆是向上生長(zhǎng)的那塊動(dòng)態(tài)內(nèi)存區(qū)域由malloc/new或者RTOS里專用的堆管理來(lái)分配棧是向下生長(zhǎng)的存函數(shù)調(diào)用幀、局部變量、函數(shù)返回地址等。畫(huà)過(guò)一遍你就會(huì)發(fā)現(xiàn)C語(yǔ)言的很多經(jīng)典問(wèn)題都可以在這個(gè)圖里找到答案。比如為什么函數(shù)里定義一個(gè)超大數(shù)組容易出事因?yàn)樗玫氖菞？臻g而?？臻g通常只有幾KB到幾十KB一個(gè)4KB的局部數(shù)組對(duì)某些MCU來(lái)說(shuō)已經(jīng)是災(zāi)難了。再比如為什么字符串常量不能修改因?yàn)樗≡谥蛔x數(shù)據(jù)段強(qiáng)行寫(xiě)進(jìn)去就是越權(quán)訪問(wèn)在MCU上會(huì)觸發(fā)硬件異常在嵌入式Linux上會(huì)拿到一個(gè)Segmentation fault。2.2 堆、棧、全局區(qū)/常量區(qū)分別該放什么不放什么我經(jīng)常被問(wèn)到寫(xiě)代碼時(shí)到底應(yīng)該把數(shù)據(jù)放在哪這里給出我個(gè)人的分法不一定適合所有場(chǎng)景但大部分嵌入式項(xiàng)目都可以參考。棧上放的應(yīng)該是生命周期很短的臨時(shí)數(shù)據(jù)比如函數(shù)里的解析緩沖區(qū)、循環(huán)變量、臨時(shí)結(jié)構(gòu)體。它的好處是自動(dòng)分配自動(dòng)釋放速度快基本沒(méi)有管理成本。缺點(diǎn)也很明顯空間有限函數(shù)退出就失效不能跨函數(shù)傳遞大塊數(shù)據(jù)。堆上放的是生命周期需要人工控制的數(shù)據(jù)比如動(dòng)態(tài)增長(zhǎng)的鏈表節(jié)點(diǎn)、接收緩存、協(xié)議幀隊(duì)列。它的靈活性最高但如果忘記釋放就會(huì)泄漏釋放之后繼續(xù)用就會(huì)出現(xiàn)踩內(nèi)存。全局區(qū)和靜態(tài)區(qū)適合放生命周期貫穿整個(gè)程序的數(shù)據(jù)比如協(xié)議棧的收發(fā)緩沖區(qū)、系統(tǒng)配置表、日志緩沖。它的訪問(wèn)效率高沒(méi)有堆分配的開(kāi)銷(xiāo)但要注意多個(gè)模塊同時(shí)訪問(wèn)時(shí)會(huì)產(chǎn)生耦合而且全局變量多了代碼很難維護(hù)。這里有一條關(guān)鍵建議能用靜態(tài)和棧解決的就不要上堆。在嵌入式環(huán)境里堆是風(fēng)險(xiǎn)最集中的區(qū)域碎片化、泄漏、越界全都在堆上爆發(fā)。如果你發(fā)現(xiàn)自己的代碼大量使用malloc/free每隔幾毫秒就來(lái)一次那么第一反應(yīng)不應(yīng)該是“我的程序很靈活”而應(yīng)該是“我的設(shè)計(jì)是不是有問(wèn)題”。2.3 寄存器、DMA、外設(shè)地址映射RAM之外的內(nèi)存嚴(yán)格來(lái)說(shuō)嵌入式工程師口里的“內(nèi)存”不只是RAM。你寫(xiě)的每一條訪問(wèn)外設(shè)寄存器的語(yǔ)句本質(zhì)上也是在操作“內(nèi)存”。在STM32這類單片機(jī)上GPIO、UART、DMA控制器的寄存器都被映射到固定的地址空間你直接對(duì)指針賦值就能控制外設(shè)在嵌入式Linux上驅(qū)動(dòng)工程師用ioremap把物理地址映射到內(nèi)核虛擬地址空間操作方式和操作內(nèi)存一模一樣。這里最需要注意的關(guān)鍵字是volatile。外設(shè)寄存器是隨時(shí)可能被硬件改變的如果你的代碼里用了一個(gè)普通指針去讀它編譯器很可能會(huì)做出錯(cuò)誤優(yōu)化把多次讀取合并成一次導(dǎo)致你讀到的永遠(yuǎn)是舊值。我見(jiàn)過(guò)不止一次串口接收標(biāo)志位明明已經(jīng)置1了但主循環(huán)一直讀不到就是這個(gè)原因。DMA緩沖區(qū)則是另一個(gè)容易出問(wèn)題的地方。DMA直接搬運(yùn)內(nèi)存不走CPU所以如果CPU和DMA同時(shí)訪問(wèn)一塊區(qū)域就存在數(shù)據(jù)一致性的風(fēng)險(xiǎn)。在帶Cache的嵌入式處理器上這個(gè)風(fēng)險(xiǎn)會(huì)被放大DMA寫(xiě)入的數(shù)據(jù)可能還在Cache里沒(méi)有回到物理內(nèi)存CPU去讀物理內(nèi)存時(shí)讀到的是舊數(shù)據(jù)反過(guò)來(lái)CPU寫(xiě)好的數(shù)據(jù)還躺在Cache里DMA去搬物理內(nèi)存時(shí)搬走的也是舊數(shù)據(jù)。正確的做法是在DMA操作前做Cache的clean或invalidate操作很多嵌入式Linux驅(qū)動(dòng)里都能看到dma_map_single、dma_alloc_coherent這類API就是在幫你處理這種一致性。2.4 三種分配方式的實(shí)際對(duì)比靜態(tài)、動(dòng)態(tài)、池化內(nèi)存從哪里來(lái)最直觀影響系統(tǒng)穩(wěn)定性的就是堆的管理方式。靜態(tài)分配、動(dòng)態(tài)分配、內(nèi)存池分配三種方式各有適用場(chǎng)景工程上我會(huì)這樣取舍。靜態(tài)分配是在編譯期確定大小最簡(jiǎn)單、最穩(wěn)定沒(méi)有任何運(yùn)行時(shí)開(kāi)銷(xiāo)也不會(huì)碎片化但靈活性差。如果某個(gè)緩沖區(qū)設(shè)計(jì)小了就只能改代碼重新編譯。動(dòng)態(tài)分配是malloc/free靈活度最高但碎片和泄漏的風(fēng)險(xiǎn)也最高。實(shí)時(shí)性要求高的系統(tǒng)還要警惕malloc內(nèi)部的鎖和復(fù)雜算法它可能在你需要毫秒級(jí)響應(yīng)的時(shí)候給你來(lái)一次幾十微秒的卡頓。內(nèi)存池分配是提前開(kāi)好一塊內(nèi)存然后切成固定大小的塊用鏈表維護(hù)空閑塊。分配釋放都只是從鏈表頭摘節(jié)點(diǎn)速度極快沒(méi)有碎片問(wèn)題代價(jià)是每個(gè)塊只能按最大規(guī)格使用會(huì)有內(nèi)部浪費(fèi)。我自己的實(shí)踐里網(wǎng)絡(luò)協(xié)議棧、消息隊(duì)列、RTOS的任務(wù)棧這一類高頻使用、大小基本固定的資源全部走內(nèi)存池偶爾一次性分配的大塊資源比如配置文件讀入、開(kāi)機(jī)時(shí)申請(qǐng)的臨時(shí)大緩沖才用malloc至于那些貫穿整個(gè)生命周期的協(xié)議幀緩沖直接靜態(tài)全局?jǐn)?shù)組。這套組合拳在長(zhǎng)時(shí)間運(yùn)行的設(shè)備上實(shí)測(cè)非常穩(wěn)內(nèi)存占用始終是一條平線不會(huì)有緩慢爬升的詭異曲線。3. 嵌入式內(nèi)存四大頑疾泄漏、踩踏、碎片與棧溢出3.1 內(nèi)存泄漏寫(xiě)入緩沖區(qū)的方式和“拆東墻補(bǔ)西墻”內(nèi)存泄漏是嵌入式現(xiàn)場(chǎng)最經(jīng)典的問(wèn)題。代碼邏輯本身沒(méi)有任何編譯錯(cuò)誤功能也正常但設(shè)備跑著跑著越來(lái)越卡最后內(nèi)存耗盡復(fù)位。我舉個(gè)最常見(jiàn)的錯(cuò)誤寫(xiě)法void on_rx_data(uint8_t *buf, uint16_t len) { char *tmp (char *)malloc(len); if (tmp NULL) { return; } memcpy(tmp, buf, len); // 處理數(shù)據(jù)... // 忘記 free(tmp) }這段代碼里每次收到一幀數(shù)據(jù)就malloc一塊內(nèi)存處理完卻沒(méi)有free。一次兩次看不出來(lái)但嵌入式設(shè)備的網(wǎng)絡(luò)連接往往會(huì)長(zhǎng)久保持每秒來(lái)幾幀數(shù)據(jù)幾個(gè)小時(shí)泄漏幾百KB幾天下來(lái)整個(gè)堆全被吃光。這種“寫(xiě)入緩沖區(qū)之后忘記釋放”的模式在協(xié)議解析、日志上報(bào)、消息轉(zhuǎn)發(fā)的代碼里特別常見(jiàn)寫(xiě)的時(shí)候很順手排查的時(shí)候特別煎熬。定位內(nèi)存泄漏常用的手段有幾招。Linux環(huán)境下可以用valgrind雖然慢但定位準(zhǔn)確也可以用AddressSanitizer編譯加-fsanitizeaddress就能在運(yùn)行時(shí)檢測(cè)泄漏。裸機(jī)和RTOS環(huán)境就比較原始了通常是在堆管理函數(shù)里加統(tǒng)計(jì)計(jì)數(shù)申請(qǐng)一次加一釋放一次減一定期把當(dāng)前剩余堆大小打印出來(lái)。如果一個(gè)模塊的剩余堆大小隨時(shí)間單調(diào)下降那基本就是它泄漏了。我自己的習(xí)慣是每個(gè)動(dòng)態(tài)內(nèi)存申請(qǐng)點(diǎn)都記得在注釋里寫(xiě)清釋放配對(duì)的位置雖然聽(tīng)起來(lái)很傻但真的很管用。3.2 緩沖區(qū)溢出與踩內(nèi)存valgrind 與 ASan 雙殺緩沖區(qū)溢出和踩內(nèi)存是最讓人頭疼的問(wèn)題因?yàn)楸ìF(xiàn)場(chǎng)和肇事現(xiàn)場(chǎng)往往不是同一個(gè)地方。你可能在A模塊往緩沖區(qū)里寫(xiě)多了幾個(gè)字節(jié)B模塊的全局變量就被改掉設(shè)備在某一個(gè)完全無(wú)關(guān)的功能上表現(xiàn)異常?？催@段典型的越界代碼void process_packet(uint8_t *data, uint16_t len) { uint8_t local_buf[64]; if (len 64) { // 缺陷沒(méi)有做長(zhǎng)度檢查直接越界拷貝 } memcpy(local_buf, data, len); }當(dāng)len超過(guò)64時(shí)memcpy就會(huì)越過(guò)local_buf的邊界把后面的棧內(nèi)容——包括函數(shù)返回地址——全部覆蓋掉。程序跑完這個(gè)函數(shù)后返回地址已經(jīng)變成一個(gè)隨機(jī)值CPU跳飛硬件異?？撮T(mén)狗復(fù)位只是時(shí)間問(wèn)題。更陰險(xiǎn)的情況是越界量比較小比如只多寫(xiě)了2字節(jié)剛好覆蓋了相鄰變量程序還能繼續(xù)跑但某個(gè)變量值開(kāi)始無(wú)規(guī)律變化這種問(wèn)題排查起來(lái)需要極致的耐心。我的排障習(xí)慣是優(yōu)先用工具。嵌入式Linux下直接開(kāi)ASan編一版出來(lái)跑測(cè)試它能精確報(bào)告是哪個(gè)文件哪一行越界了沒(méi)有ASan條件的話就用valgrind的memcheck工具把越界寫(xiě)和非法讀都揪出來(lái)。裸機(jī)環(huán)境下通常沒(méi)有現(xiàn)成工具我會(huì)在可疑數(shù)組前后放特殊填充字節(jié)比如0xAA、0x55定期檢查填充字節(jié)有沒(méi)有被改寫(xiě)。如果被改了說(shuō)明附近有人越界。這個(gè)土辦法雖然原始但關(guān)鍵時(shí)候比什么高級(jí)工具都靠譜。3.3 堆碎片化bin/arena/分配器以及長(zhǎng)時(shí)間運(yùn)行的隱形殺手內(nèi)存碎片化這個(gè)主題很多做上位機(jī)開(kāi)發(fā)的程序員根本沒(méi)概念。PC上有swap機(jī)制虛擬內(nèi)存把碎片問(wèn)題掩蓋掉了。但在嵌入式設(shè)備里堆碎片化是讓系統(tǒng)崩潰的隱形殺手。碎片化的原理不難理解你不停地malloc和free各種大小的內(nèi)存塊內(nèi)存空間被切成了很多小窟窿。每一塊單個(gè)看都不小但它們?cè)谖锢砩喜贿B續(xù)。當(dāng)你需要申請(qǐng)一塊較大的連續(xù)內(nèi)存時(shí)雖然空閑內(nèi)存總額是夠的但沒(méi)有一塊連續(xù)空間能滿足需求malloc就會(huì)返回NULL。典型的例子是設(shè)備運(yùn)行三天后調(diào)用鏈穩(wěn)定的malloc突然開(kāi)始失敗但你看free內(nèi)存還有好幾KB。glibc的malloc實(shí)現(xiàn)里fastbin和smallbin會(huì)在一定程度上減少碎片但長(zhǎng)期交錯(cuò)分配大小時(shí)仍然無(wú)力回天。內(nèi)核側(cè)的伙伴系統(tǒng)和slab分配器本質(zhì)上也是在做碎片控制伙伴系統(tǒng)按2的冪次劃分頁(yè)塊slab則緩存同類型對(duì)象。這些思想在應(yīng)用層完全可以借鑒最直接的方案就是我前面提到的內(nèi)存池。固定大小的池沒(méi)有碎片問(wèn)題因?yàn)獒尫呕厝サ膲K和申請(qǐng)的塊規(guī)格一樣如果有不同大小的需求就開(kāi)兩個(gè)池子分別管理。這個(gè)設(shè)計(jì)在我的項(xiàng)目里能把堆分配次數(shù)降到接近零系統(tǒng)的長(zhǎng)期運(yùn)行穩(wěn)定性提升非常明顯。3.4 棧溢出局部數(shù)組、遞歸和任務(wù)棧配置棧溢出在嵌入式系統(tǒng)里非常隱蔽因?yàn)楹芏鄷r(shí)候它不報(bào)錯(cuò)只是悄悄破壞數(shù)據(jù)。我在1.1里講的那個(gè)設(shè)備三天重啟一次的案例根源就是棧被越界拷貝踩了。常見(jiàn)引發(fā)棧溢出的行為包括局部數(shù)組開(kāi)得太大比如在函數(shù)里定義uint8_t big_buffer[8192]而整個(gè)任務(wù)棧才8192字節(jié)遞歸調(diào)用沒(méi)有深度限制每個(gè)遞歸層級(jí)都消耗棧幀深層函數(shù)調(diào)用鏈加上大的局部變量在多層調(diào)用疊加后瞬間擊穿棧底。RTOS環(huán)境里每個(gè)任務(wù)都有自己的棧棧大小由你在創(chuàng)建任務(wù)時(shí)指定。很多人不重視這個(gè)參數(shù)隨手填個(gè)128或者512字節(jié)省空間結(jié)果運(yùn)行一段時(shí)間后任務(wù)棧溢出系統(tǒng)隨機(jī)死機(jī)。我建議的做法是在任務(wù)棧的底部放幾個(gè)特殊魔數(shù)定期去檢查魔數(shù)有沒(méi)有被改寫(xiě)。如果被改了就說(shuō)明棧溢出了然后逐步加大棧大小直到魔數(shù)保持穩(wěn)定。另外還可以用工具鏈提供的棧使用統(tǒng)計(jì)比如GCC的-fstack-usage選項(xiàng)編譯后能生成每個(gè)函數(shù)的棧占用報(bào)告匯總一下就能算出任務(wù)棧的理論上限非常實(shí)用。4. 實(shí)操一個(gè)嵌入式Linux項(xiàng)目的內(nèi)存優(yōu)化實(shí)戰(zhàn)4.1 對(duì)著 /proc 和 top 看內(nèi)存別只看 free嵌入式Linux項(xiàng)目里排查內(nèi)存很多人上來(lái)就敲free -m看到MemFree剩幾十MB就覺(jué)得沒(méi)問(wèn)題。這個(gè)判斷方式會(huì)誤導(dǎo)你。Linux內(nèi)核會(huì)盡量把空閑內(nèi)存拿去做page cache所以MemFree低不代表內(nèi)存真不夠用MemAvailable才是系統(tǒng)當(dāng)前實(shí)際可以分配出去的內(nèi)存估算值。我習(xí)慣是這樣的先看/proc/meminfo里的關(guān)鍵項(xiàng)其次是具體進(jìn)程的內(nèi)存占用。給大家?guī)讉€(gè)最常用的命令組合# 系統(tǒng)級(jí)內(nèi)存總覽 cat /proc/meminfo | head -n 5 # 某個(gè)進(jìn)程的虛擬內(nèi)存和物理內(nèi)存峰值 cat /proc/pid/status | grep -E VmPeak|VmSize|VmRSS|RssAnon|RssFile # 按物理內(nèi)存占用排序進(jìn)程 ps -eo pid,comm,rss --sort-rss | head -n 20VmRSS代表進(jìn)程當(dāng)前實(shí)際占用的物理內(nèi)存這是最值得關(guān)注的指標(biāo)。如果一個(gè)長(zhǎng)期運(yùn)行的進(jìn)程VmRSS持續(xù)增長(zhǎng)那就要懷疑泄漏如果VmRSS保持平穩(wěn)但malloc偶爾失敗那要懷疑是不是虛擬內(nèi)存映射過(guò)多或者碎片化了。數(shù)據(jù)要看趨勢(shì)不要只看孤立的某一個(gè)瞬間。4.2 抓大放小按 VmRSS 找大頭再按調(diào)用鏈治本定位內(nèi)存大頭不能靠猜我有一套固定的實(shí)操流程。第一步用ps命令按RSS排序找到占內(nèi)存最多的幾個(gè)進(jìn)程第二步對(duì)嫌疑進(jìn)程查看/proc/PID/maps看清楚它映射了哪些庫(kù)、哪些大塊內(nèi)存第三步如果是自己的程序可以臨時(shí)打開(kāi)glibc的malloc統(tǒng)計(jì)代碼里調(diào)用mallinfo()拿到uordblks等字段看堆里真正使用的字節(jié)數(shù)第四步結(jié)合代碼的調(diào)用鏈找出內(nèi)存增長(zhǎng)的真實(shí)來(lái)源。有一個(gè)真實(shí)案例我印象很深。一臺(tái)嵌入式網(wǎng)關(guān)設(shè)備內(nèi)存總占用隨運(yùn)行時(shí)間穩(wěn)定爬升數(shù)值很規(guī)律每小時(shí)漲幾十KB。一開(kāi)始懷疑是某個(gè)網(wǎng)絡(luò)會(huì)話泄漏排查了很久沒(méi)結(jié)果。后來(lái)無(wú)意中發(fā)現(xiàn)是日志模塊的問(wèn)題日志字符串用的是追加寫(xiě)入的方式每次寫(xiě)日志都realloc擴(kuò)大緩沖區(qū)但日志滿了之后只做了截?cái)鄾](méi)有把malloc的冗余容量realloc回來(lái)導(dǎo)致緩沖區(qū)容量越漲越大變成了幾十MB。這類問(wèn)題本質(zhì)上是“偽泄漏”malloc的總量并沒(méi)有一直漲但緩沖區(qū)冗余越來(lái)越大反映在RSS上就是一條持續(xù)上升的曲線。定位到原因后我在日志模塊里加了一個(gè)容量收縮策略每次flush完就把緩沖區(qū)縮小到實(shí)際內(nèi)容大小內(nèi)存曲線立刻恢復(fù)正常。所以在做內(nèi)存優(yōu)化時(shí)第一原則是抓大放小。不要一開(kāi)始就糾結(jié)那幾字節(jié)的結(jié)構(gòu)體對(duì)齊先用工具把內(nèi)存大頭找出來(lái)再?zèng)Q定值不值得優(yōu)化。真正的優(yōu)化永遠(yuǎn)是有數(shù)據(jù)支撐的優(yōu)化。4.3 結(jié)構(gòu)體重排、位域、環(huán)形緩沖……我常用的幾個(gè)省錢(qián)技巧在內(nèi)存大頭解決之后再來(lái)?yè)讣?xì)節(jié)才有意義。我最常用的幾個(gè)“省錢(qián)”技巧全部在工程里實(shí)測(cè)有效。第一個(gè)是結(jié)構(gòu)體成員重排。因?yàn)榫幾g器會(huì)對(duì)齊訪問(wèn)結(jié)構(gòu)體成員順序直接決定最終大小?？聪旅孢@個(gè)例子// 不推薦按隨意順序聲明浪費(fèi)空間 struct cfg_a { char type; // 1字節(jié) uint32_t value; // 4字節(jié) uint16_t id; // 2字節(jié) }; // sizeof 12 // 推薦按對(duì)齊字節(jié)數(shù)從大到小排列 struct cfg_b { uint32_t value; // 4字節(jié) uint16_t id; // 2字節(jié) char type; // 1字節(jié) }; // sizeof 8兩個(gè)結(jié)構(gòu)體字段完全一樣只是順序不同cfg_a占了12字節(jié)cfg_b只占8字節(jié)。如果一個(gè)數(shù)組有1000個(gè)元素差距就是4KB。規(guī)則很簡(jiǎn)單從最大的類型開(kāi)始放小的往后排最后統(tǒng)一補(bǔ)padding。至于#pragma pack強(qiáng)行壓縮對(duì)齊我建議慎用雖然能省空間但可能導(dǎo)致非對(duì)齊訪問(wèn)在ARM平臺(tái)上輕則性能下降重則觸發(fā)硬件異常。第二個(gè)是位域。對(duì)于大量bool型的配置項(xiàng)與其每個(gè)都占一個(gè)字節(jié)不如按位打包。比如8個(gè)開(kāi)關(guān)狀態(tài)用一個(gè)uint8_t就裝下了比8個(gè)uint8_t省7個(gè)字節(jié)。代價(jià)是代碼可讀性下降存取都要做位運(yùn)算所以只建議在配置結(jié)構(gòu)體這類對(duì)空間敏感的場(chǎng)景使用。第三個(gè)是環(huán)形緩沖區(qū)。協(xié)議解析、串口收發(fā)、日志輸出這類場(chǎng)景最理想的結(jié)構(gòu)就是ring buffer。固定大小、無(wú)動(dòng)態(tài)分配、天然FIFO我用得非常多。一個(gè)常用的優(yōu)化技巧是把ring buffer的size設(shè)置為2的冪然后用位與運(yùn)算代替取模運(yùn)算性能會(huì)有明顯提升#define RING_SIZE 4096 static uint8_t ring_buf[RING_SIZE]; static uint16_t head, tail; int ring_push(uint8_t byte) { // 判斷是否滿保留一個(gè)空位區(qū)分空和滿 if (((head 1) (RING_SIZE - 1)) tail) { return -1; // 滿 } ring_buf[head] byte; head (head 1) (RING_SIZE - 1); return 0; }在嵌入式Linux同樣適用mmap加MAP_SHARED之后配合信號(hào)量或者自旋鎖做互斥。這里面有個(gè)隱藏的坑共享內(nèi)存里的結(jié)構(gòu)體涉及多端編譯時(shí)一定要顯式控制內(nèi)存布局否則一個(gè)平臺(tái)認(rèn)4字節(jié)對(duì)齊另一個(gè)平臺(tái)認(rèn)8字節(jié)對(duì)齊共享數(shù)據(jù)就全亂了。標(biāo)準(zhǔn)做法是定義明確寬度的整數(shù)類型加上packed屬性或者精心設(shè)計(jì)的對(duì)齊必要時(shí)還要固定大小端。這塊我后面講。4.4 多任務(wù)系統(tǒng)里的共享內(nèi)存與堆外內(nèi)存怎么玩嵌入式系統(tǒng)很少只有一個(gè)任務(wù)。RTOS環(huán)境里多個(gè)任務(wù)并發(fā)訪問(wèn)同一塊內(nèi)存嵌入式Linux環(huán)境里多進(jìn)程通過(guò)mmap共享內(nèi)存這些都是普通應(yīng)用不常遇到的高級(jí)場(chǎng)景。RTOS里的任務(wù)間通信我首推消息隊(duì)列而不是裸的全局變量共享。消息隊(duì)列的本質(zhì)是內(nèi)核幫你管理一塊緩沖區(qū)發(fā)送方寫(xiě)入接收方讀取不涉及直接競(jìng)爭(zhēng)也就繞開(kāi)了大部分并發(fā)訪問(wèn)問(wèn)題。但有些場(chǎng)景必須共享大塊內(nèi)存比如音頻數(shù)據(jù)、圖像幀這時(shí)候就要用到互斥鎖。要注意RTOS的互斥鎖有優(yōu)先級(jí)繼承機(jī)制普通信號(hào)量沒(méi)有用錯(cuò)了在實(shí)時(shí)系統(tǒng)中會(huì)造成優(yōu)先級(jí)翻轉(zhuǎn)這個(gè)細(xì)節(jié)在面試?yán)镆步?jīng)常被問(wèn)。嵌入式Linux下最常用的共享內(nèi)存方式就是mmap。一個(gè)典型的做法是MAP_SHARED加寫(xiě)回文件兩個(gè)進(jìn)程都能讀寫(xiě)同一段物理內(nèi)存。這個(gè)過(guò)程里有兩個(gè)關(guān)鍵細(xì)節(jié)第一共享內(nèi)存區(qū)需要專門(mén)的初始化流程通常先由主進(jìn)程創(chuàng)建并清零再?gòu)脑O(shè)備節(jié)點(diǎn)或共享文件系統(tǒng)里映射第二跨進(jìn)程的共享內(nèi)存訪問(wèn)必須配套同步機(jī)制否則兩個(gè)進(jìn)程同時(shí)寫(xiě)就會(huì)出現(xiàn)數(shù)據(jù)錯(cuò)亂。至于“堆外內(nèi)存”這個(gè)概念在嵌入式的語(yǔ)境下通常指不經(jīng)過(guò)AC標(biāo)準(zhǔn)庫(kù)malloc管理的內(nèi)存。比如你直接用一個(gè)固定的物理地址做DMA緩沖區(qū)或者用mmap映射一塊設(shè)備內(nèi)存這些都算堆外內(nèi)存。它的好處是繞過(guò)堆管理器的碎片和開(kāi)銷(xiāo)問(wèn)題壞處是你要自己負(fù)責(zé)生命周期和對(duì)齊。嵌入式Linux里分配DMA連續(xù)內(nèi)存一般要靠CMA機(jī)制makedma_contiguous或設(shè)備樹(shù)里配置reserved-memory普通malloc拿不到連續(xù)的物理頁(yè)這是“大內(nèi)存架構(gòu)”設(shè)計(jì)里繞不開(kāi)的一部分。5. 嵌入式內(nèi)存面試八股與排障速查5.1 嵌入式八股文哪些內(nèi)存問(wèn)題會(huì)被反復(fù)問(wèn)接下來(lái)說(shuō)說(shuō)面試。八股文這個(gè)詞在嵌入式圈子里很有爭(zhēng)議有人說(shuō)面試造火箭、工作擰螺絲但內(nèi)存相關(guān)的八股我建議你還是好好背因?yàn)樗鼈兪乔度胧介_(kāi)發(fā)的地基。下面是我整理的幾道高頻題和要點(diǎn)方便你快速過(guò)一遍。第一題sizeof結(jié)構(gòu)體為什么不是成員大小之和因?yàn)榫幾g器會(huì)做對(duì)齊填充具體和CPU架構(gòu)、編譯器選項(xiàng)、成員順序有關(guān)。第二題malloc失敗就代表內(nèi)存不足嗎不代表。可能是堆碎片化導(dǎo)致沒(méi)有足夠大的連續(xù)空間也可能是當(dāng)前進(jìn)程的虛擬內(nèi)存映射受限。第三題malloc返回非NULL就安全嗎不安全。Linux默認(rèn)開(kāi)啟了內(nèi)存overcommitmalloc可能返回非NULL但真正訪問(wèn)時(shí)系統(tǒng)已經(jīng)沒(méi)有物理內(nèi)存觸發(fā)OOM killer。第四題棧和堆哪個(gè)快?？?。棧分配只移動(dòng)棧指針堆分配需要查找空閑塊、可能觸發(fā)系統(tǒng)調(diào)用、還要處理并發(fā)鎖。所以高頻的小塊臨時(shí)數(shù)據(jù)首選棧。第五題free之后指針要置NULL嗎要看場(chǎng)景。free之后指針本身還持有原地址這是懸空指針再次free或訪問(wèn)就會(huì)踩內(nèi)存。在模塊內(nèi)置NULL是安全習(xí)慣但要清楚這只對(duì)當(dāng)前指針有效如果多個(gè)指針指向同一塊內(nèi)存只置其中一個(gè)意義有限。第六題結(jié)構(gòu)體里的柔性數(shù)組用來(lái)干什么柔性數(shù)組是C99的特性在結(jié)構(gòu)體尾部聲明一個(gè)不完整數(shù)組可以在不額外分配內(nèi)存的情況下攜帶變長(zhǎng)數(shù)據(jù)很多協(xié)議棧的幀結(jié)構(gòu)喜歡這么設(shè)計(jì)既省空間又避免多次malloc。5.2 一份可以直接抄的排查流程每次遇到內(nèi)存問(wèn)題我都按固定流程走很多團(tuán)隊(duì)里我也這么帶新人。整理成一套六步法你可以直接抄作業(yè)。第一步先歸類現(xiàn)象。是系統(tǒng)復(fù)位、是功能錯(cuò)亂、還是性能劣化不同類型的線索指向不同方向。復(fù)位優(yōu)先查棧溢出和返回地址被踩功能錯(cuò)亂優(yōu)先查野指針和緩沖區(qū)越界性能劣化優(yōu)先查泄漏和碎片。第二步保護(hù)現(xiàn)場(chǎng)。按1.1里說(shuō)的把復(fù)位前最后一段日志打全把用到的全局狀態(tài)dump出來(lái)。沒(méi)有現(xiàn)場(chǎng)數(shù)據(jù)后面全是在猜。第三步盡量復(fù)現(xiàn)。嵌入式問(wèn)題難復(fù)現(xiàn)但可以構(gòu)造條件比如把緩沖區(qū)長(zhǎng)度調(diào)到極端值、把任務(wù)?？s小一半、加大網(wǎng)絡(luò)報(bào)文頻率。第四步上工具。Linux下按優(yōu)先級(jí)排序是AddressSanitizer、valgrind、gdb、/proc統(tǒng)計(jì)MCU下按優(yōu)先級(jí)排序是棧哨兵、malloc計(jì)數(shù)、手工填充檢查。第五步追蹤趨勢(shì)。不要只拍一個(gè)瞬間的快照要連續(xù)采集內(nèi)存數(shù)據(jù)形成曲線看是線性增長(zhǎng)、階梯增長(zhǎng)還是偶發(fā)跳變不同曲線對(duì)應(yīng)不同根因。第六步驗(yàn)證修復(fù)。改完代碼不代表結(jié)束要跑足夠長(zhǎng)時(shí)間的壓力測(cè)試確認(rèn)內(nèi)存曲線回歸平穩(wěn)然后保留監(jiān)控手段等數(shù)據(jù)說(shuō)話。5.3 嵌入式內(nèi)存相關(guān)常見(jiàn)問(wèn)題速查表最后送一張排障速查表平時(shí)遇到問(wèn)題先對(duì)號(hào)入座能省不少時(shí)間。癥狀可能原因快速定位手段建議方案運(yùn)行幾天后malloc失敗堆碎片化/內(nèi)存泄漏malloc統(tǒng)計(jì)、mallinfo、valgrind內(nèi)存池化、定位泄漏點(diǎn)某個(gè)全局變量被莫名改寫(xiě)緩沖區(qū)越界變量附近放canary、ASan檢查memcpy和數(shù)組邊界函數(shù)返回后跳飛/PC亂跳棧被踩/返回地址損壞gdb bt、棧哨兵模式檢查局部數(shù)組大小和遞歸深度設(shè)備頻繁hardfault棧溢出/野指針/非對(duì)齊訪問(wèn)HardFault_Handler分析、RTT增大任務(wù)棧、查野指針內(nèi)存占用線性上升泄漏或緩沖區(qū)冗余監(jiān)控VmRSS趨勢(shì)、valgrind按調(diào)用鏈定位修復(fù)兩個(gè)進(jìn)程共享數(shù)據(jù)偶爾錯(cuò)亂缺少同步/結(jié)構(gòu)體布局不一致檢查互斥機(jī)制、比對(duì)各自sizeof加鎖、固定對(duì)齊和大小端DMA數(shù)據(jù)讀到舊值Cache一致性問(wèn)題增加flush/invalidate調(diào)試使用標(biāo)準(zhǔn)DMA映射API這張表覆蓋了我在實(shí)際工作中遇到的大部分內(nèi)存問(wèn)題場(chǎng)景。嵌入式內(nèi)存的排查沒(méi)有銀彈靠的就是對(duì)內(nèi)存布局的理解、對(duì)工具的熟練使用以及一步步逼近根因的耐心。我自己踩過(guò)很多坑最有感觸的一點(diǎn)是內(nèi)存問(wèn)題的修復(fù)往往只需要幾行代碼但定位的過(guò)程可能花費(fèi)好幾天。所以一定要在系統(tǒng)設(shè)計(jì)階段就把內(nèi)存策略想清楚不要等設(shè)備上了產(chǎn)線再追著問(wèn)題跑。說(shuō)到底嵌入式開(kāi)發(fā)拼的不是誰(shuí)功能寫(xiě)得花哨而是誰(shuí)的系統(tǒng)能一年365天穩(wěn)定運(yùn)行不出岔子。內(nèi)存這一關(guān)每個(gè)人都繞不開(kāi)。希望這堂“嵌入式內(nèi)存課”能幫你把這塊短板補(bǔ)上也歡迎你在評(píng)論區(qū)留下你自己踩過(guò)的內(nèi)存相關(guān)的坑一起交流一起進(jìn)步。