聊進(jìn)程地址空間這件事我一般不喜歡從教科書上那張代碼段、數(shù)據(jù)段、堆、棧的示意圖講起因?yàn)槟菑垐D太干凈了,干凈到看不出真實(shí)系統(tǒng)里那些別扭的取舍。我更愿意先拋一個(gè)問題如果一個(gè)進(jìn)程拿到的地址就是物理內(nèi)存里的真實(shí)地址,它敢不敢隨便用答案顯然是不敢。它不僅不敢隨便用,連自己該用哪一塊都沒法事先知道——因?yàn)橥粫r(shí)刻可能有幾十上百個(gè)進(jìn)程在跑,誰先來誰后到、誰大誰小,全都不確定。進(jìn)程地址空間、虛擬地址、頁表、寫時(shí)拷貝這一整套機(jī)制,本質(zhì)上就是給這個(gè)混亂場面建立秩序的工具。搞嵌入式的同學(xué)可能覺得這些東西離自己很遠(yuǎn),但只要你的代碼跑在帶 MMU 的芯片上、只要你用過fork、只要你的程序莫名其妙漲過內(nèi)存,這套機(jī)制就在你腳下。這篇內(nèi)容我打算把地址空間為什么存在頁表怎么把映射做成硬件能查的表寫時(shí)拷貝到底省了什么、又偷偷付出了什么這幾件事掰開講,再配三個(gè)能直接跑的驗(yàn)證實(shí)驗(yàn),讓你不用只靠想象去理解它們。1. 先把地址這件事說透虛擬地址空間到底解決了什么問題1.1 從一段裸機(jī)代碼說起物理地址直編的四個(gè)坑在單片機(jī)上寫程序的時(shí)候,我們經(jīng)常是這么干的*(volatile uint32_t *)0x40001000 1;直接把某個(gè)外設(shè)寄存器地址寫進(jìn)代碼里。這種寫法在單任務(wù)、無 MMU 的環(huán)境下毫無問題,因?yàn)檎麄€(gè)系統(tǒng)只有一份地址空間,誰也不會(huì)跟你搶。但一旦把場景換成多任務(wù)操作系統(tǒng),這種物理地址直編的思路立刻會(huì)撞上四面墻。第一面墻是隔離。進(jìn)程 A 在地址 0x1000 處存了個(gè)關(guān)鍵結(jié)構(gòu)體,進(jìn)程 B 因?yàn)橹羔標(biāo)沐e(cuò)也往 0x1000 寫,結(jié)果 A 的數(shù)據(jù)被悄悄改掉,而且這種 bug 極難定位——A 崩潰的時(shí)候 B 早就跑完了。第二面墻是重定位。編譯器在編譯期根本不知道自己的代碼會(huì)被加載到物理內(nèi)存的哪個(gè)位置,如果按固定地址生成跳轉(zhuǎn)指令,加載位置一變?nèi)P皆輸。第三面墻是稀疏使用。一個(gè)進(jìn)程可能只用了 1MB 內(nèi)存,但它需要一段連續(xù)的大地址區(qū)間來放棧、放堆,如果按物理地址分配,就得真的預(yù)留那么多連續(xù)物理頁,浪費(fèi)得離譜。第四面墻是共享與回收。多個(gè)進(jìn)程跑同一個(gè)可執(zhí)行文件,按理說代碼段應(yīng)該只有一份,但物理地址直編的模型下沒法表達(dá)兩個(gè)進(jìn)程的某段地址指向同一塊物理內(nèi)存這個(gè)概念。虛擬地址空間就是把這幾面墻一次性推倒的方案。每個(gè)進(jìn)程都擁有一份獨(dú)立的、從 0 開始一直延伸到某個(gè)上限的地址空間,進(jìn)程里所有指針、所有跳轉(zhuǎn)、所有malloc返回的值,都是這個(gè)空間里的虛擬地址。真實(shí)物理內(nèi)存在哪里、有多少、是不是連續(xù)的,進(jìn)程完全不需要知道,也完全無法知道。1.2 虛擬地址空間的本質(zhì)一層可編程的映射我習(xí)慣把虛擬地址空間理解成一張可編程的對(duì)照表。表的左邊是虛擬頁號(hào),右邊是物理頁號(hào),中間還掛著幾個(gè)權(quán)限位。CPU 每次訪存,MMU 拿虛擬地址去查這張表,查到了就換成物理地址去訪問內(nèi)存,查不到或者權(quán)限不對(duì)就拋異常。這張表由操作系統(tǒng)維護(hù),進(jìn)程自己改不了,這就是隔離的物理基礎(chǔ)。這層抽象帶來的好處是連鎖反應(yīng)式的。因?yàn)橛成潢P(guān)系是可編程的,操作系統(tǒng)可以在進(jìn)程啟動(dòng)時(shí)把可執(zhí)行文件的代碼段映射到任意物理頁上,于是位置無關(guān)加載變成了默認(rèn)行為。因?yàn)橛成涫琼摿６鹊?一個(gè)進(jìn)程的地址空間里可以有大片沒有映射的空洞,訪問到就觸發(fā)缺頁異常,操作系統(tǒng)再?zèng)Q定是分配一頁、還是從磁盤讀回來、還是干脆殺掉進(jìn)程,于是按需分配成為可能。因?yàn)橛成浔砝锟梢杂涗涍@一頁是只讀的,多個(gè)進(jìn)程可以共享同一塊物理內(nèi)存,誰想寫就觸發(fā)異常,內(nèi)核再給誰單獨(dú)復(fù)制一份,于是共享庫和寫時(shí)拷貝順理成章。我特別想強(qiáng)調(diào)一點(diǎn)虛擬地址空間這套東西之所以能成立,是因?yàn)樗堰M(jìn)程看到的世界和真實(shí)的世界徹底解耦了。進(jìn)程以為自己獨(dú)占了一整塊連續(xù)的、從 0 開始的內(nèi)存;內(nèi)核知道這全是假的,物理頁散落在各處,隨時(shí)可以被換出、被遷移、被共享。這種謊言不是欺騙,而是一種極其成功的接口設(shè)計(jì)——它讓上層程序員可以用最簡單的心智模型寫代碼,把復(fù)雜性全部壓到內(nèi)核和硬件那一層。1.3 進(jìn)程地址空間布局一張圖背后藏著的信息在 64 位 Linux 上,一個(gè)典型進(jìn)程的虛擬地址空間大致長這樣區(qū)域內(nèi)容增長方向典型說明代碼段 text機(jī)器指令固定通常只讀、可執(zhí)行,多進(jìn)程共享數(shù)據(jù)段 data已初始化全局/靜態(tài)變量固定可讀寫,私有BSS未初始化全局/靜態(tài)變量固定不占文件空間,加載時(shí)清零堆 heapmalloc小對(duì)象向高地址由brk擴(kuò)展,連續(xù)映射區(qū) mmap大塊malloc、共享庫、文件映射向低地址從高地址往下長,靈活棧 stack局部變量、調(diào)用幀向低地址主線程默認(rèn) 8MBvdso/vvar內(nèi)核提供的高頻調(diào)用實(shí)現(xiàn)固定免去系統(tǒng)調(diào)用開銷這張表里有兩個(gè)細(xì)節(jié)是很多人忽略的。第一,堆和映射區(qū)是相向生長的。malloc小內(nèi)存走brk把堆頂往高推,大內(nèi)存(默認(rèn)閾值 128KB 左右,由M_MMAP_THRESHOLD控制)走mmap在高地址區(qū)找一塊空地,兩者中間留出巨大空隙,誰先撞上誰觸發(fā)擴(kuò)展或失敗。第二,代碼段和共享庫是真正共享物理頁的,不是各自復(fù)制一份。你在 /proc 的 smaps 里看到共享庫的Shared_Clean很大,而Private_Dirty很小,就是這個(gè)原因。還有一個(gè)容易誤解的點(diǎn)64 位下用戶態(tài)可用的虛擬地址并不是完整的 64 位,而是 48 位(4 級(jí)頁表)或者 57 位(5 級(jí)頁表,需要顯式開啟)。低半?yún)^(qū)屬于用戶進(jìn)程,高半?yún)^(qū)留給內(nèi)核,中間是一條不可跨越的鴻溝。所以你在 64 位程序里打印指針,看到的基本都是0x0000_7fxx_xxxx_xxxx這樣開頭的值,不會(huì)是0xffff_...。2. 頁表把映射做成硬件可查表2.1 為什么是頁而不是字節(jié)有人會(huì)問既然要做映射,為什么不做成字節(jié)粒度的映射表,一字節(jié)虛擬地址對(duì)應(yīng)一字節(jié)物理地址原因很直接——這張表會(huì)大到無法存儲(chǔ)。假設(shè)一個(gè)進(jìn)程有 4GB 虛擬空間,字節(jié)粒度映射表每項(xiàng)至少 8 字節(jié),那光映射表就要 32GB,比地址空間本身還大,荒謬。頁粒度是一個(gè)甜點(diǎn)。以 4KB 頁為例,4GB 地址空間需要 100 萬個(gè)表項(xiàng),每項(xiàng) 8 字節(jié),總共 8MB。勉強(qiáng)能接受,但還不夠好——因?yàn)榻^大多數(shù)進(jìn)程根本用不滿 4GB,為空洞付 8MB 代價(jià)太虧。這就逼出了下一層的優(yōu)化分級(jí)。而如果選更大的頁,比如 2MB,表項(xiàng)數(shù)量降到 2048 個(gè),表只有 16KB,但內(nèi)部碎片會(huì)變嚴(yán)重——一個(gè)進(jìn)程只用了 1 字節(jié)也得占 2MB。4KB 是歷史上軟硬件妥協(xié)出來的結(jié)果,和磁盤扇區(qū)、內(nèi)存顆粒的行緩沖都有關(guān)系,至今仍是絕大多數(shù)體系結(jié)構(gòu)的默認(rèn)頁大小。這里有個(gè)數(shù)值得記住4KB 2^12,所以虛擬地址的低 12 位是頁內(nèi)偏移,永遠(yuǎn)不會(huì)被翻譯,原樣透傳到物理地址的低 12 位。這個(gè)設(shè)計(jì)讓翻譯這件事變得極其簡單——MMU 只需要處理高位,低位直接抄過去。2.2 多級(jí)頁表用時(shí)間換空間的經(jīng)典取舍單級(jí)頁表的問題是,一張表必須連續(xù)存放,而它要覆蓋整個(gè)地址空間。48 位虛擬地址、4KB 頁,需要 2^36 個(gè)表項(xiàng),每項(xiàng) 8 字節(jié),單張表就是 512GB。這顯然不可能。解決辦法是把這張大表切碎、分層,變成一棵樹。x86-64 的 4 級(jí)頁表是這么切的把 48 位虛擬地址拆成 5 段,[47:39] [38:30] [29:21] [20:12] [11:0],前四段各 9 位,正好每段能索引 512 個(gè)表項(xiàng);最后 12 位是頁內(nèi)偏移。每張頁表頁正好 4KB,裝 512 個(gè) 8 字節(jié)表項(xiàng),大小嚴(yán)絲合縫。層級(jí)索引位單表容量單表覆蓋范圍表項(xiàng)指向PML447:39512 項(xiàng)512 × 512GB 256TBPDPT 頁P(yáng)DPT38:30512 項(xiàng)512 × 1GB 512GBPD 頁P(yáng)D29:21512 項(xiàng)512 × 2MB 1GBPT 頁P(yáng)T20:12512 項(xiàng)512 × 4KB 2MB物理頁這套設(shè)計(jì)的精妙之處在于不為空洞付錢。一個(gè)進(jìn)程如果只在某個(gè) 2MB 區(qū)間里用了幾頁,那么 PML4、PDPT、PD 各需要一張表(各 4KB),PT 也需要一張(4KB),總共 16KB 頁表就能支撐起這幾頁的映射;而地址空間里其他廣袤的空白區(qū)域,對(duì)應(yīng)的頁表頁根本不存在,頂級(jí)表項(xiàng)直接標(biāo)記為未映射。這就是分級(jí)頁表用空間效率換來的代價(jià)——查表要爬樹。爬樹的成本是可以量化的。一次 TLB 未命中,MMU 要依次讀 PML4、PDPT、PD、PT 四張表,每讀一張都是一次內(nèi)存訪問(這些表都在內(nèi)存里,只是被硬件緩存加速),最后才拿到物理頁號(hào),再去讀真正的數(shù)據(jù)。最壞情況是 5 次內(nèi)存訪問才能拿到一個(gè)字節(jié)。如果每次都這樣,程序會(huì)慢到?jīng)]法用。所以 CPU 里專門放了一個(gè) TLB(Translation Lookaside Buffer),緩存最近用過的虛擬頁號(hào)到物理頁號(hào)的對(duì)應(yīng)關(guān)系。TLB 命中的時(shí)候翻譯幾乎是零成本的,這也是為什么局部性好的程序跑得快——不只是緩存命中率高,頁表翻譯的緩存命中率也高。2.3 頁表項(xiàng)里到底存了什么一張頁表項(xiàng)是 8 字節(jié),但物理頁號(hào)只占其中一部分,剩下的位全是標(biāo)志位。理解這些位,才能理解內(nèi)核的很多行為。以 x86-64 的 4KB 頁表項(xiàng)為例位名稱含義實(shí)際影響0P存在位為 0 表示該頁不在內(nèi)存,訪問觸發(fā)缺頁1R/W讀寫位為 0 時(shí)寫操作觸發(fā)保護(hù)異常2U/S用戶/內(nèi)核位為 0 時(shí)用戶態(tài)訪問觸發(fā)異常3PWT寫通影響緩存策略,普通應(yīng)用很少關(guān)心4PCD禁止緩存用于映射設(shè)備內(nèi)存5A已訪問硬件置位,內(nèi)核據(jù)此判斷頁的活躍度6D已臟寫過的頁,換出時(shí)需要回寫7PS大頁標(biāo)志在 PD 層置位表示 2MB 大頁8G全局TLB 不隨 CR3 切換刷新12-51物理頁號(hào)高位地址指向?qū)嶋H物理頁63XD禁止執(zhí)行置位后該頁不可執(zhí)行,NX 保護(hù)的來源我經(jīng)常拿R/W位來講寫時(shí)拷貝,因?yàn)樗钦讬C(jī)制里最四兩撥千斤的一個(gè)位。內(nèi)核在fork之后把所有可寫的私有頁在父子兩個(gè)進(jìn)程的頁表里都標(biāo)成只讀,數(shù)據(jù)本身一個(gè)字節(jié)都沒動(dòng);等到某一方真的去寫,硬件發(fā)現(xiàn)R/W0,拋出保護(hù)異常,內(nèi)核在異常處理里再?zèng)Q定是復(fù)制一頁還是恢復(fù)可寫。整個(gè)復(fù)制動(dòng)作被推遲到了真正需要的那一刻,而且只復(fù)制真正被寫的那一頁。A位和D位也有講究。內(nèi)核的頁面回收算法需要知道哪些頁最近被訪問過,硬件每次訪問都會(huì)把A置 1,內(nèi)核掃描時(shí)讀一下、清一下,就能近似判斷出頁的熱度。這不是精確統(tǒng)計(jì),但足夠用,而且完全不占用軟件開銷。這種讓硬件順手干活的思路在體系結(jié)構(gòu)里到處都是。2.4 TLB 與頁表遍歷的真實(shí)開銷很多人學(xué)完頁表會(huì)有個(gè)模糊印象查表很慢,但 TLB 救了它。這個(gè)說法沒錯(cuò),但太籠統(tǒng)。我想給幾個(gè)更具體的數(shù),便于你判斷什么時(shí)候該關(guān)心它。TLB 通常分兩級(jí)L1 dTLB 只有幾十到一百多個(gè)條目,覆蓋幾 MB 到幾百 KB;L2 TLB 稍大,幾千條,覆蓋幾 MB 到幾十 MB。也就是說,如果一個(gè)程序的工作集(活躍頁數(shù))小于 L2 TLB 的覆蓋范圍,翻譯開銷基本可以忽略;一旦工作集超過這個(gè)范圍,TLB 開始頻繁未命中,每次未命中要爬 4 級(jí)頁表,性能會(huì)掉一個(gè)臺(tái)階。這就是大頁存在的理由。2MB 大頁只需要 PD 層一個(gè)表項(xiàng),不需要 PT 層,一次 TLB 表項(xiàng)就能覆蓋 2MB 而不是 4KB,覆蓋率提升 512 倍。數(shù)據(jù)庫、JVM 這類吃內(nèi)存大戶經(jīng)常開透明大頁,收益主要就在這里。代價(jià)是大頁內(nèi)部的碎片沒法回收,內(nèi)存緊張時(shí)反而會(huì)拖累系統(tǒng),所以很多場景又會(huì)關(guān)掉它。這是一個(gè)很典型的沒有銀彈案例。還有一個(gè)常被忽略的成本切換進(jìn)程要換頁表基址。x86 上頁表基址存在 CR3 寄存器里,進(jìn)程切換時(shí)內(nèi)核寫 CR3 指向新進(jìn)程的 PML4,這個(gè)動(dòng)作會(huì)讓 TLB 里大部分條目失效(除非用了 PCID 之類的機(jī)制給條目打標(biāo)簽)。所以高頻的進(jìn)程切換不僅浪費(fèi)在保存寄存器上,還浪費(fèi)在 TLB 冷啟動(dòng)上。這也是為什么線程切換比進(jìn)程切換便宜——同一地址空間,CR3 不用換。3. 寫時(shí)拷貝fork 性能的一次關(guān)鍵妥協(xié)3.1 fork 為什么要拷貝,又為什么不想拷貝fork的語義是創(chuàng)建一個(gè)和自己一模一樣的子進(jìn)程,最直白的實(shí)現(xiàn)就是把父進(jìn)程的所有內(nèi)存逐字節(jié)復(fù)制一份給子進(jìn)程。這在小進(jìn)程上沒問題,但一個(gè)占了幾個(gè) GB 的服務(wù)進(jìn)程 fork 一次,復(fù)制幾 GB 數(shù)據(jù),耗時(shí)可能到秒級(jí),期間父進(jìn)程還得停下來配合。這在早年的 Unix 上就是個(gè)大問題。寫時(shí)拷貝的思路是先別復(fù)制,讓父子共享同一份物理頁,把頁表里的寫權(quán)限全部收掉。如果父子倆從此只是讀,那就一直共享下去,零成本;如果某一方要寫,硬件拋出保護(hù)異常,內(nèi)核在異常里才真正復(fù)制那一頁,并且只復(fù)制被寫的那一頁。這樣,fork的實(shí)際開銷從復(fù)制全部數(shù)據(jù)降級(jí)成復(fù)制頁表項(xiàng),通常能快一到兩個(gè)數(shù)量級(jí)。但這里有個(gè)被嚴(yán)重低估的事實(shí)頁表本身還是要復(fù)制的。fork的時(shí)候內(nèi)核要遍歷父進(jìn)程的所有 VMA(虛擬內(nèi)存區(qū)域),為子進(jìn)程建立同樣的 VMA 結(jié)構(gòu),然后遍歷頁表,把每一級(jí)的表頁也復(fù)制一份出來——因?yàn)楦缸舆M(jìn)程的頁表必須各自獨(dú)立,否則一方改頁表項(xiàng)會(huì)影響到另一方。對(duì)一個(gè)映射了幾十 GB 內(nèi)存的進(jìn)程來說,光是復(fù)制頁表頁就可能要幾百 MB 的內(nèi)存和相當(dāng)可觀的時(shí)間。所以COW 讓 fork 變得免費(fèi)是個(gè)錯(cuò)誤認(rèn)知,更準(zhǔn)確的說法是COW 把 fork 的成本從數(shù)據(jù)量級(jí)降到了頁表量級(jí)。我給個(gè)量化的例子。假設(shè)一個(gè)進(jìn)程映射了 8GB 匿名內(nèi)存,頁大小 4KB,那么頁表項(xiàng)有 200 萬個(gè),PT 頁有 4000 個(gè),加上各級(jí)上層表,頁表總大小約 16MB 左右。fork時(shí)這 16MB 要被復(fù)制,200 萬個(gè) PTE 的R/W位要被清掉,這個(gè)遍歷本身就要幾十毫秒。相比之下 8GB 的數(shù)據(jù)復(fù)制要幾秒。差了將近兩個(gè)數(shù)量級(jí),但絕對(duì)不是零。3.2 COW 的完整觸發(fā)鏈路想真正吃透 COW,得把從fork到某一頁被復(fù)制的完整鏈路走一遍。我用 Linux 的實(shí)現(xiàn)做參照,其他系統(tǒng)的結(jié)構(gòu)大同小異。第一步,fork進(jìn)入內(nèi)核,走copy_process。這里會(huì)創(chuàng)建新的 task 結(jié)構(gòu)、新的 mm 結(jié)構(gòu)(地址空間描述符),然后調(diào)用copy_mm。第二步,copy_mm判斷是否共享地址空間。如果是clone帶CLONE_VM標(biāo)志(線程),直接共享 mm,什么都不復(fù)制;如果是fork,調(diào)用dup_mmap逐條復(fù)制 VMA。這一步會(huì)把父進(jìn)程的每個(gè) VMA 用vm_area_dup復(fù)制一份,掛到子進(jìn)程的 mm 上,同時(shí)把父子雙方的 VMA 都標(biāo)記為VM_MAYWRITE之類的共享狀態(tài),并建立反向映射結(jié)構(gòu)。第三步,copy_page_range遍歷頁表。對(duì)每一個(gè)有效的 PTE,內(nèi)核把對(duì)應(yīng)物理頁的引用計(jì)數(shù)加一,然后把父子雙方的 PTE 的R/W位清零,同時(shí)保留PTE_W在軟件位里的記錄(_PAGE_RW的軟件備份,不同內(nèi)核版本用不同方式記),以便將來恢復(fù)。注意,這里改的是父子兩份頁表,因?yàn)轫摫硪呀?jīng)各自獨(dú)立了。第四步,某一方執(zhí)行寫操作。CPU 發(fā)現(xiàn)目標(biāo)頁的 PTE 里R/W0,但頁是存在的,于是拋出 page fault,錯(cuò)誤碼里帶上寫和保護(hù)違規(guī)兩個(gè)標(biāo)志。第五步,內(nèi)核缺頁處理。do_page_fault拿到pt_regs和錯(cuò)誤碼,判斷出這是寫保護(hù)導(dǎo)致的可恢復(fù)異常,進(jìn)入handle_pte_fault分支,再走到do_wp_page。第六步,do_wp_page做決策。它先看這個(gè)物理頁當(dāng)前的引用情況如果只有當(dāng)前進(jìn)程在用(引用計(jì)數(shù)為 1),說明另一方早就復(fù)制走了或者根本沒共享,那就直接把 PTE 改回可寫,什么都不復(fù)制,這叫reuse 優(yōu)化;如果還有別人在用,就分配一個(gè)新頁,把舊頁內(nèi)容memcpy過去,新頁掛到當(dāng)前進(jìn)程的 PTE 上,舊頁引用計(jì)數(shù)減一。第七步,更新 TLB。頁表改了之后,要刷新對(duì)應(yīng)的 TLB 條目,否則 CPU 還會(huì)用舊的翻譯結(jié)果。這一步做漏了就會(huì)出現(xiàn)極難排查的數(shù)據(jù)不一致問題。這條鏈路里,do_wp_page的 reuse 判斷是關(guān)鍵的性能分水嶺。很多場景下父進(jìn)程 fork 完就exec,子進(jìn)程立刻換掉整個(gè)地址空間,父進(jìn)程這邊根本不會(huì)有寫沖突;或者 fork 之后只有一方活著,另一方早就退出,頁的引用計(jì)數(shù)掉回 1,后續(xù)的寫就能直接復(fù)用。真正需要復(fù)制的情況,往往比想象中少。3.3 引用計(jì)數(shù)與頁生命周期COW 能成立,前提是內(nèi)核精確知道這一頁現(xiàn)在被幾個(gè)地方引用著。Linux 用struct page里的_refcount(總引用數(shù),包括頁表引用、page cache 引用、內(nèi)核內(nèi)部引用)和_mapcount(被多少個(gè)用戶頁表映射)兩個(gè)字段共同管理。fork時(shí),每個(gè)被共享的可寫頁的_mapcount加一,_refcount加一。子進(jìn)程退出時(shí),它映射的每一頁都要減回去。觸發(fā) COW 復(fù)制時(shí),新頁的計(jì)數(shù)從零開始建立,舊頁的計(jì)數(shù)減一。如果減到_mapcount為 1,意味著只剩一個(gè)映射者,再寫就可以直接復(fù)用。這套計(jì)數(shù)機(jī)制出問題時(shí)的表現(xiàn)很有迷惑性。引用計(jì)數(shù)漏加會(huì)導(dǎo)致頁被提前釋放,表現(xiàn)為隨機(jī)的內(nèi)存損壞或者莫名的段錯(cuò)誤;引用計(jì)數(shù)多加會(huì)導(dǎo)致頁永遠(yuǎn)回收不掉,表現(xiàn)為內(nèi)存持續(xù)上漲但查不到泄漏點(diǎn)。我見過一個(gè)案例,某開發(fā)者在驅(qū)動(dòng)里手工改 PTE 實(shí)現(xiàn)共享內(nèi)存,忘了同步加_mapcount,結(jié)果系統(tǒng)跑幾小時(shí)后必然崩,查了兩天才定位到。還有一個(gè)容易忽略的點(diǎn)COW 和文件映射的交互。文件私有映射(MAP_PRIVATE)在被寫時(shí)也走 COW,但它多一層語義——寫完之后這頁就變成了匿名頁,不再和文件關(guān)聯(lián),后續(xù)的文件修改不會(huì)反映過來。這個(gè)行為很多人以為是 bug,其實(shí)是設(shè)計(jì)如此。3.4 COW 不是銀彈坑在哪寫時(shí)拷貝用得不當(dāng)會(huì)帶來幾個(gè)典型問題,我在實(shí)際項(xiàng)目里都踩過。第一個(gè)坑是大頁 COW。如果開了透明大頁,一個(gè) 2MB 的大頁被 COW,復(fù)制的是整整 2MB 而不是 4KB。一個(gè)進(jìn)程如果頻繁 fork 且每次都寫一點(diǎn)點(diǎn),開了大頁之后內(nèi)存占用和復(fù)制開銷都會(huì)暴漲。這種情況要么關(guān)掉大頁,要么用madvise(MADV_NOHUGEPAGE)在特定區(qū)域禁掉。第二個(gè)坑是內(nèi)存賬算不準(zhǔn)。父子進(jìn)程共享的頁,在各自的 smaps 里都會(huì)算進(jìn) RSS,于是把父子的 RSS 加起來會(huì)遠(yuǎn)大于實(shí)際物理占用。要準(zhǔn)確看共享情況,得看Pss(按共享比例分?jǐn)?而不是Rss。做容量規(guī)劃的時(shí)候如果只看 RSS,會(huì)嚴(yán)重高估。第三個(gè)坑是fork 之后立刻大改。有些程序 fork 出子進(jìn)程后馬上在子進(jìn)程里遍歷修改一個(gè)大數(shù)組,這時(shí)候每一頁都觸發(fā)一次 COW,等于把復(fù)制成本從 fork 時(shí)刻挪到了運(yùn)行時(shí)刻,總成本一點(diǎn)沒省,而且還多了幾百萬次缺頁異常的開銷。這種場景不如直接vfork加exec,或者用posix_spawn。第四個(gè)坑是和內(nèi)存回收打架。COW 產(chǎn)生的匿名頁在內(nèi)存緊張時(shí)會(huì)被換出,但父子共享期間頁被標(biāo)成只讀,回收路徑要特殊處理。極端情況下,內(nèi)存壓力大時(shí) COW 缺頁會(huì)因?yàn)橐然厥諆?nèi)存才能分配新頁,導(dǎo)致延遲抖動(dòng)明顯。這個(gè)在延遲敏感的服務(wù)里很致命。4. 動(dòng)手驗(yàn)證把抽象的東西量出來4.1 環(huán)境與工具準(zhǔn)備光看文字容易產(chǎn)生我懂了的錯(cuò)覺,所以我建議你親手跑一遍下面的實(shí)驗(yàn)。環(huán)境要求很簡單一臺(tái) 64 位 Linux,裝了 gcc,有 root 權(quán)限(讀 pagemap 需要),內(nèi)核版本 4.x 以上。核心工具就三個(gè)/proc/self/pagemap用來查虛擬頁對(duì)應(yīng)的物理頁號(hào);/proc/self/maps看虛擬地址區(qū)間;/proc/self/smaps看每個(gè)區(qū)間的詳細(xì)內(nèi)存賬。pagemap 的格式是一個(gè)大文件,每 8 字節(jié)對(duì)應(yīng)一個(gè)虛擬頁,文件偏移 虛擬頁號(hào) × 8。表項(xiàng)里 bit 63 是頁是否存在,bit 0-54 是物理頁號(hào)。注意從 4.x 某個(gè)版本開始,非特權(quán)用戶讀到的物理頁號(hào)字段會(huì)被清零,所以必須用 root 跑。4.2 實(shí)驗(yàn)一同一虛擬地址在不同進(jìn)程指向不同物理頁這個(gè)實(shí)驗(yàn)要驗(yàn)證的核心事實(shí)是fork 之后父子進(jìn)程打印出來的指針值完全一樣,但通過 COW 之后它們指向的物理頁不一樣了。#define _GNU_SOURCE #include stdio.h #include stdlib.h #include unistd.h #include fcntl.h #include sys/mman.h #include sys/wait.h static unsigned long long pfn_of(void *addr) { unsigned long long entry 0; int fd open(/proc/self/pagemap, O_RDONLY); if (fd 0) { perror(open pagemap); return 0; } off_t off (off_t)(((unsigned long)addr 12) * 8); if (pread(fd, entry, sizeof(entry), off) ! sizeof(entry)) { close(fd); return 0; } close(fd); if (!(entry (1ULL 63))) /* 頁不在內(nèi)存 */ return 0; return entry ((1ULL 55) - 1); } int main(void) { size_t page (size_t)sysconf(_SC_PAGESIZE); int *p mmap(NULL, page, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (p MAP_FAILED) { perror(mmap); return 1; } *p 0x1234; printf(parent pid%-6d va%p pfn%-8llu val0x%x\n, getpid(), (void *)p, pfn_of(p), *p); pid_t pid fork(); if (pid 0) { perror(fork); return 1; } if (pid 0) { printf(child pid%-6d va%p pfn%-8llu val0x%x\n, getpid(), (void *)p, pfn_of(p), *p); *p 0x5678; /* 觸發(fā) COW */ printf(child after-write va%p pfn%-8llu val0x%x\n, (void *)p, pfn_of(p), *p); _exit(0); } waitpid(pid, NULL, 0); printf(parent after-child va%p pfn%-8llu val0x%x\n, (void *)p, pfn_of(p), *p); return 0; }編譯和運(yùn)行g(shù)cc -O0 -g -o cow_demo cow_demo.c sudo ./cow_demo我用-O0是為了防止編譯器把*p的讀寫優(yōu)化掉。跑出來的結(jié)果應(yīng)該長這樣(具體頁號(hào)每次不同)parent pid12001 va0x7f3a2c000000 pfn284117 val0x1234 child pid12002 va0x7f3a2c000000 pfn284117 val0x1234 child after-write va0x7f3a2c000000 pfn631842 val0x5678 parent after-child va0x7f3a2c000000 pfn284117 val0x1234三個(gè)關(guān)鍵結(jié)論全在這幾行里。虛擬地址完全一致,父子倆都以為自己用的是0x7f3a2c000000。fork 剛完成時(shí)物理頁號(hào)也一致,說明數(shù)據(jù)確實(shí)沒被復(fù)制。子進(jìn)程寫完之后物理頁號(hào)變了,父進(jìn)程的沒變,而且父進(jìn)程讀到的值還是0x1234,說明 COW 只復(fù)制了被寫的那一頁,沒有影響另一方。這個(gè)結(jié)果和原理對(duì)得上,你才算真的理解了。這個(gè)實(shí)驗(yàn)我建議你多跑幾次,把pfn_of換成查多個(gè)頁,比如一次性 mmap 1MB(256 頁),子進(jìn)程只寫第 0 頁和第 100 頁,看看有多少頁的物理號(hào)變了。你會(huì)發(fā)現(xiàn)只有那兩頁變了,其余全部保持共享。這個(gè)惰性復(fù)制的直觀感受,比讀十遍文檔都管用。4.3 實(shí)驗(yàn)二用 smaps 觀察共享與私有內(nèi)存的變化pagemap 需要 root,在沒有 root 的環(huán)境里可以用 smaps 觀察同樣的現(xiàn)象。思路是fork 前記錄父進(jìn)程某段匿名映射的Rss和Pss,fork 后子進(jìn)程寫一遍,再回到父進(jìn)程看這些數(shù)值怎么變。# 在父進(jìn)程里執(zhí)行,先看初始狀態(tài) grep -A 25 /dev/zero (deleted)\|\[anon\] /proc/self/smaps | head -40更實(shí)用的是寫個(gè)小腳本,直接對(duì)某個(gè) PID 匯總pid$1 awk /^[0-9a-f]-[0-9a-f] / { name $0 } /^Rss:/ { rss $2 } /^Pss:/ { pss $2 } /^Shared_Clean:/ { sc $2 } /^Shared_Dirty:/ { sd $2 } /^Private_Clean:/{ pc $2 } /^Private_Dirty:/{ pd $2 } END { printf Rss%d kB Pss%d kB\n, rss, pss printf Shared_Clean%d Shared_Dirty%d\n, sc, sd printf Private_Clean%d Private_Dirty%d\n, pc, pd } /proc/$pid/smaps關(guān)鍵看點(diǎn)在于Pss和Rss的差異。Rss是這段區(qū)間有多少頁在內(nèi)存里,共享頁會(huì)被每個(gè)進(jìn)程各算一次;Pss是按共享比例分?jǐn)偤?這段區(qū)間實(shí)際上占了多少物理內(nèi)存,兩個(gè)進(jìn)程共享一頁,每個(gè)進(jìn)程只算半頁。所以如果一個(gè)進(jìn)程和另一個(gè)進(jìn)程大量共享內(nèi)存,Rss 會(huì)虛高,Pss 才是準(zhǔn)的。實(shí)測(cè)下來,一個(gè) fork 出來的子進(jìn)程如果只讀不寫,它在父進(jìn)程匿名區(qū)間上的Shared_Clean會(huì)上去,Private_Dirty保持很低一旦開始寫,Private_Dirty就一節(jié)一節(jié)往上爬,爬的速度取決于它實(shí)際寫了多少頁。這個(gè)增長曲線是階梯狀的,不是線性的,因?yàn)閺?fù)制是按頁觸發(fā)的。4.4 實(shí)驗(yàn)三把頁表層級(jí)也數(shù)一遍如果你想驗(yàn)證多級(jí)頁表不為空洞付錢這個(gè)說法,可以做一個(gè)簡單的對(duì)比一個(gè)進(jìn)程只mmap一頁并訪問,和mmap一大片并全部訪問,看看頁表占用的差異。從/proc/pid/status里的VmPTE字段能看到頁表本身消耗了多少內(nèi)存grep -E VmSize|VmRSS|VmPTE|VmPMD /proc/pid/statusVmPTE是頁表頁的總量(單位 kB),VmPMD是上層頁表頁的量。一個(gè)只映射幾頁的進(jìn)程,VmPTE通常是 4 的倍數(shù)(每張 PT 頁 4KB),VmPMD大概十幾到幾十 kB(因?yàn)檫M(jìn)程總有代碼段、棧、堆等若干區(qū)域,每個(gè)區(qū)域至少要掛一條通路)。當(dāng)你 mmap 幾百 MB 并逐頁訪問之后,VmPTE會(huì)明顯上漲,漲幅大約等于映射字節(jié)數(shù) ÷ 2MB × 4KB,也就是每覆蓋 2MB 就要多一張 PT 頁。這個(gè)比例你可以自己算一下驗(yàn)證,我算過幾次都對(duì)得上。5. 常見問題與排查技巧實(shí)錄5.1 進(jìn)程內(nèi)存持續(xù)上漲,是泄漏還是 COW這是我最常被問到的一類問題。表現(xiàn)是服務(wù)跑著跑著 RSS 漲上去,但代碼里查不到明顯的泄漏點(diǎn),重啟就恢復(fù)。這種情況下我會(huì)按下面這個(gè)順序排查。先看是匿名頁還是文件頁。直接讀 smaps,把Private_Dirty和Private_Clean分別匯總。Private_Dirty高說明是程序自己分配的內(nèi)存,大概率是真正的泄漏或者緩存無界增長;Private_Clean高說明是映射的文件頁,通常是代碼段或者 mmap 的文件,不算問題。再看是不是 COW 導(dǎo)致的雙份計(jì)賬。如果進(jìn)程是 fork 模型(比如 Perl、Python 的多進(jìn)程并發(fā)模型),父進(jìn)程占的內(nèi)存在 fork 后會(huì)被子進(jìn)程共享,fork 出來的子進(jìn)程如果寫了大量頁,每寫一頁就多出一份物理內(nèi)存。這種情況Rss會(huì)漲,但Pss長得沒那么快,而且父進(jìn)程和子進(jìn)程的Private_Dirty會(huì)同時(shí)增長。解決辦法通常是改用posix_spawn或者線程模型,或者限制子進(jìn)程生命周期。最后看是不是堆碎片。malloc的 RSS 漲但VmSize不漲,說明是已釋放的頁沒有歸還給操作系統(tǒng)。glibc 的malloc在很多情況下不會(huì)立刻munmap,尤其是堆頂以下的空閑塊?？梢杂胢alloc_trim(0)主動(dòng)歸還,或者配置M_MMAP_THRESHOLD讓大塊分配直接走mmap。5.2 地址對(duì)齊與段錯(cuò)誤的那些坑虛擬地址空間相關(guān)的段錯(cuò)誤,有一大半和對(duì)齊、權(quán)限標(biāo)志有關(guān),我把常見的幾種列在下面。mmap返回的地址一定是頁對(duì)齊的,但如果你自己算偏移,很容易算出非對(duì)齊地址。比如想映射文件偏移 5000 字節(jié)的位置,mmap的offset參數(shù)必須是 4096 的倍數(shù),因?yàn)閮?nèi)核是按頁映射的,不支持的偏移會(huì)直接返回MAP_FAILED并置EINVAL。正確做法是把偏移向下對(duì)齊到頁邊界,然后拿返回值加余數(shù)。另一個(gè)坑是PROT_WRITE和MAP_SHARED的組合。用MAP_SHARED映射一個(gè)只讀文件卻要求寫權(quán)限,mmap會(huì)失敗;但如果用MAP_PRIVATE,寫權(quán)限是允許的,只是寫了之后不會(huì)反映到文件。很多人在這里被卡住,以為是權(quán)限問題,其實(shí)是映射類型選錯(cuò)了。還有一個(gè)隱蔽的坑是棧溢出。主線程棧默認(rèn) 8MB,如果函數(shù)里開了個(gè)大數(shù)組,或者遞歸太深,會(huì)撞到棧底下面的保護(hù)頁,觸發(fā)段錯(cuò)誤。這種錯(cuò)誤的表現(xiàn)是地址接近0x7fff...的邊界,和堆、映射區(qū)的錯(cuò)誤很好區(qū)分。定位方法是看 core dump 里的rsp值和 maps 里棧區(qū)間的起止地址。5.3 常見問題速查我把這幾年處理過的相關(guān)問題整理成一張表,方便你出問題時(shí)先對(duì)號(hào)入座?，F(xiàn)象大概率原因排查手段處理方式同一地址在兩個(gè)進(jìn)程里值不一樣正常,虛擬地址獨(dú)立打 PFN 對(duì)比無需處理,理解機(jī)制即可fork 后 RSS 翻倍COW 后子進(jìn)程大量寫看 smaps 的 Private_Dirty改模型或減少子進(jìn)程寫fork 耗時(shí)隨內(nèi)存線性增長頁表復(fù)制開銷計(jì)時(shí) fork 前后的耗時(shí)用posix_spawn規(guī)避內(nèi)存漲了但 VmSize 沒變堆內(nèi)碎片看VmRSS與VmData差值malloc_trim或換分配器大頁開啟后內(nèi)存暴漲大頁 COW 復(fù)制 2MB看AnonHugePages字段MADV_NOHUGEPAGE局部禁用mmap 返回 MAP_FAILED偏移未頁對(duì)齊 / 權(quán)限沖突看 errno偏移向下對(duì)齊,檢查 flag段錯(cuò)誤地址在 0x7fff 附近棧溢出看 core 里的 rsp加大?；蛴枚言L問已 unmap 的地址懸垂指針用mmap加MAP_FIXED_NOREPLACE保護(hù)加內(nèi)存檢測(cè)工具提示讀/proc/self/pagemap拿到的物理頁號(hào)在新內(nèi)核上對(duì)非 root 用戶是清零的。這不是 bug,是有意為之。你要是發(fā)現(xiàn)查出來全是 0,先確認(rèn)是不是忘了sudo。注意/proc/pid/smaps的讀取開銷不小,尤其對(duì)大內(nèi)存進(jìn)程。線上環(huán)境頻繁讀會(huì)明顯增加內(nèi)核態(tài) CPU 占用,采樣間隔別低于十幾秒。5.4 幾個(gè)我踩過的坑第一個(gè)是關(guān)于pagemap的偏移計(jì)算。我一開始寫成(addr / 4096) * 8,結(jié)果因?yàn)閍ddr是void*,在 32 位編譯下沒問題,64 位下截?cái)喑鲞^怪問題。后來統(tǒng)一改成((unsigned long)addr 12) * 8,再轉(zhuǎn)off_t,才徹底穩(wěn)定。這種小地方不注意,查起來能耗掉半天。第二個(gè)是關(guān)于 COW 的測(cè)量時(shí)機(jī)。早期我做實(shí)驗(yàn)時(shí),在 fork 之后立刻讀子進(jìn)程的 PFN,發(fā)現(xiàn)和父進(jìn)程一樣,還以為 COW 沒生效。后來才想明白,fork 那一刻本來就不該復(fù)制,復(fù)制發(fā)生在寫的時(shí)候。所以我現(xiàn)在的實(shí)驗(yàn)?zāi)_本都是fork → 讀 → 寫 → 再讀,分三個(gè)時(shí)間點(diǎn)采樣,才看得到完整的變化過程。第三個(gè)是關(guān)于大頁的意外開啟。有次壓測(cè)一個(gè) fork 密集型服務(wù),發(fā)現(xiàn)內(nèi)存比預(yù)期多用了將近一倍,查了半天代碼沒找到問題,最后看AnonHugePages才發(fā)現(xiàn)系統(tǒng)默認(rèn)開了透明大頁,每次 COW 都復(fù)制 2MB。關(guān)掉之后內(nèi)存立刻回到預(yù)期水平。這件事之后我養(yǎng)成了習(xí)慣凡是 fork 密集的服務(wù),上線前必查一遍大頁配置。第四個(gè)是 TLB 刷新的問題。在做用戶態(tài)共享內(nèi)存的優(yōu)化時(shí),我嘗試手工改頁表來共享頁面,結(jié)果發(fā)現(xiàn)改了之后另一個(gè)進(jìn)程讀到的還是舊數(shù)據(jù)。原因就是 TLB 沒刷。后來改成走正規(guī)的mmap(MAP_SHARED)路徑,雖然多一層內(nèi)核調(diào)用,但省掉了所有這類心智負(fù)擔(dān)。這件事讓我徹底相信能在用戶態(tài)用標(biāo)準(zhǔn)接口解決的事,別去碰頁表。最后分享一個(gè)我平時(shí)做內(nèi)存問題定位的順序,不一定最優(yōu),但很省事先用VmSize和VmRSS的差值判斷是申請(qǐng)了沒用還是用了沒還;再用Private_Dirty判斷是匿名內(nèi)存還是文件頁;然后用Pss修正共享帶來的誤判;最后才上pagemap和 core dump 這種重武器。多數(shù)情況下前兩步就能把范圍縮到很小,真要讀到頁表一級(jí)的問題,其實(shí)一年也遇不上幾次。