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