存映射：原理、OOM優(yōu)化與大文件讀寫實戰(zhàn))
1. 從一次OOM排查說起mmap在Android里到底藏得多深剛入行那會兒我以為Android內(nèi)存映射mmap是個離應用層很遠的東西屬于那類面試會問、干活用不上的知識點。直到有次做一個相冊類App用戶反饋說滑到第三屏就閃退日志里全是java.lang.OutOfMemoryError。我當時的做法很樸素——把圖片一張張read進byte[]再解碼邏輯上沒毛病但一臺4G內(nèi)存的機器硬是被我這么讀幾十張大圖給撐爆了。后來把這條鏈路改成mmap映射文件、按需解碼同樣的機型同樣的圖片量RSS穩(wěn)得像一條直線。也是從那次開始我才認真去翻/proc/pid/maps去看Binder驅動怎么用mmap做一次拷貝去看ART怎么把dex文件映射進進程地址空間。越看越發(fā)現(xiàn)內(nèi)存映射幾乎是Android這座大廈的地基之一只是平時被封裝得很好不到出問題的時候你壓根感覺不到它。這篇內(nèi)容我打算把這幾年摸到的東西整理一遍。適合誰寫過Android應用、懂一點JNI、想搞明白為什么我的進程虛擬內(nèi)存幾十個G但物理內(nèi)存才幾百M的開發(fā)者也適合做音視頻、大文件處理、性能優(yōu)化方向的同學?？赐昴阒辽倌芨闱宄耺map到底怎么工作、Android里哪些地方在偷偷用它、以及你自己該在什么場景下用它、怎么用不翻車。提醒本文所有原理描述和代碼都基于AOSP的公開實現(xiàn)和POSIX標準示例代碼在真機和模擬器上都跑過參數(shù)建議僅供參考具體以你目標平臺的頁大小和內(nèi)核版本為準。2. mmap到底在干什么一次借地址不借數(shù)據(jù)的操作2.1 把文件頁塞進你的虛擬地址空間先說結論mmap不會立刻讀文件。它做的是在進程的虛擬地址空間里找一段空閑區(qū)間建立一段這段虛擬地址對應這個文件的這一段偏移的映射關系然后返回首地址。整個過程里文件內(nèi)容一個字節(jié)都沒被搬到內(nèi)存。這就像你在圖書館辦了一張借書卡卡上寫著三樓A區(qū)第7排第3本但你根本沒走過去把那本書拿下來。真正去取書是等你翻到某一頁的時候。Linux下的函數(shù)原型長這樣void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset); int munmap(void *addr, size_t length); int msync(void *addr, size_t length, int flags);幾個參數(shù)里最容易踩坑的是offset——它必須是頁大小的整數(shù)倍不是的話直接返回MAP_FAILEDerrno給EINVAL。length則會被內(nèi)核向上取整到頁邊界比如你傳100字節(jié)實際映射了一整頁4096字節(jié)ARM64也可能是16384字節(jié)這個后面單獨講。prot控制訪問權限常見組合是PROT_READ、PROT_READ|PROT_WRITE、PROT_NONE。flags里最關鍵的是兩個MAP_SHARED你的寫入會同步回文件其他映射了同一文件的進程也能看到。MAP_PRIVATE寫時復制COW你改了只是改了你自己那份副本文件本身不動。還有一個MAP_ANONYMOUS不關聯(lián)任何文件純粹要一塊內(nèi)存glibc的malloc在大塊分配時底層就會走這條路準確說是brk或mmap匿名映射二選一。2.2 缺頁中斷真正的數(shù)據(jù)搬運工映射建立之后你第一次訪問某個地址CPU會觸發(fā)一個缺頁中斷內(nèi)核這時候才去頁緩存里找對應的文件頁。找到了就直接把頁表項指過去沒找到就從磁盤讀進來放進頁緩存再指過去。理解這一點非常關鍵因為它決定了mmap的兩個特性第一次訪問慢后續(xù)訪問快。第一次是真實的磁盤IO之后都命中頁緩存純內(nèi)存操作。內(nèi)存可以被回收。這些頁是file-backed的系統(tǒng)內(nèi)存緊張時內(nèi)核可以直接把它們丟掉下次訪問再讀一遍。而new出來的堆內(nèi)存不行那是匿名頁丟掉就沒數(shù)據(jù)了只能壓縮或者換出。這也是為什么我說mmap能解決OOM——你映射一個500MB的文件進程的虛擬內(nèi)存VSZ直接漲500MB但物理內(nèi)存RSS可能只有幾MB因為你只碰了開頭那幾頁。系統(tǒng)壓力大了那些頁還能被丟掉。同樣500MB用read讀進byte[]那是實打實的500MB匿名內(nèi)存除非被殺進程否則誰也拿不走。2.3 一個容易忽略的細節(jié)映射完之后fd可以關掉很多人的代碼里mmap之后一直攥著fd不放生怕一關映射就失效。其實不需要。mmap建立映射之后內(nèi)核的vm_area_struct已經(jīng)持有對文件的引用fget你把fdclose掉完全不影響映射的有效性。真正影響映射的是munmap或者進程退出。不過這里有個坑如果你close了fd后續(xù)就沒法用msync了嗎不是msync用的是映射的起始地址跟fd沒關系。但如果你想用fstat再查文件大小那就得重新打開。所以我的習慣是先open fstat拿到大小mmap然后立刻close代碼路徑最干凈。2.4 私有映射和共享映射選錯了會很難受我見過有同事用MAP_PRIVATE映射一個日志文件然后往里寫寫完發(fā)現(xiàn)文件還是空的一臉茫然地來問我。這就是沒搞清楚COW語義——MAP_PRIVATE的寫入只在你的進程里可見內(nèi)核會給你分配新頁文件本身一個字節(jié)都不變。選型其實很簡單場景推薦flags原因只讀大文件圖片、模型、日志MAP_PRIVATE語義就是只讀COW不會被觸發(fā)等價只讀多進程共享一塊內(nèi)存MAP_SHARED 匿名改動互相可見修改文件內(nèi)容并落盤MAP_SHARED需要寫回加載可執(zhí)行代碼so等MAP_PRIVATEPROT_EXEC系統(tǒng)加載器就這么干的另外提一句msync它只對MAP_SHARED有意義。MS_SYNC會阻塞到數(shù)據(jù)真正落盤MS_ASYNC只是把頁標記為臟、排隊等待回寫。如果你寫入之后馬上要斷電測試、或者要讓另一個進程立刻看到必須用MS_SYNC。3. Android體系里mmap的四大主戰(zhàn)場3.1 Binder靠mmap把兩次拷貝壓成一次Binder的高效本質上就是內(nèi)存映射換來的。流程大概是這樣應用進程啟動時ProcessState會open(/dev/binder)然后調(diào)一次mmap把驅動分配的一塊內(nèi)核緩沖區(qū)映射到自己的用戶空間?；貞浺幌碌?節(jié)的原理——這塊內(nèi)核緩沖區(qū)同時在內(nèi)核空間和用戶空間各有一份映射物理頁是同一份。于是跨進程通信就變成了發(fā)送方把數(shù)據(jù)copy_from_user到內(nèi)核那塊映射區(qū)第一次拷貝接收方讀的時候直接用自己用戶空間的地址讀零拷貝。如果沒有mmapBinder就得是用戶態(tài)→內(nèi)核態(tài)→再回用戶態(tài)兩次拷貝慢一倍不止。這塊緩沖區(qū)的大小AOSP里定義在ProcessState.cpp#define BINDER_VM_SIZE ((1 * 1024 * 1024) - sysconf(_SC_PAGE_SIZE) * 2)也就是1MB減去兩個頁留點余量。有些系統(tǒng)會通過binder:vm_size這個屬性或者BINDER_VM_SIZE的編譯配置來放大它跑大對象傳輸?shù)亩ㄖ芌OM常見做法。注意正因為每個進程的Binder緩沖區(qū)就這么大單次Transaction的數(shù)據(jù)上限是有限制的大約1MB減去一點。你要傳大Bitmap得走ashmem或者ParcelFileDescriptor而不是硬塞進Binder。傳輸超限會拋TransactionTooLargeException這個異常很多人誤以為是內(nèi)存不足其實是緩沖區(qū)溢出。3.2 AshmemAndroid為共享內(nèi)存專門開的一扇門標準Linux有shmget/shmat這一套System V共享內(nèi)存也有memfd_create。Android早期自己造了個/dev/ashmem用ioctl設置名字和大小然后mmap出來。好處是內(nèi)核可以按需回收這些頁——低內(nèi)存時把沒人用的共享內(nèi)存區(qū)直接丟掉這叫unpinned ashmem。配合ASHMEM_PIN/ASHMEM_UNPIN系統(tǒng)能在內(nèi)存和性能之間做平衡。到Android 10之后AOSP把ashmem的底層實現(xiàn)悄悄換成了memfd_create加文件鏈接的方式在libcutils里做了封裝上層APIashmem_create_region的簽名完全沒變。所以如果你在維護老代碼不用急著改但新項目我建議直接用memfd_create畢竟是標準Linux路線行為更可預測。3.3 圖形系統(tǒng)Gralloc、SurfaceFlinger和那堆1024x1024做音視頻或者相機開發(fā)的同學一定見過GraphicBuffer。它的底層就是一塊dmabuf早期是ION通過mmap映射到用戶空間讓CPU能讀寫同時GPU也能通過dmabuf的fd直接訪問。這帶來的一個直接后果是CPU和GPU共享同一塊物理內(nèi)存不需要來回拷貝。你拍照預覽時那一幀從CMOS出來進ISP再進GPU處理再交給SurfaceFlinger合成全程靠的就是這個共享映射。如果每一環(huán)都memcpy一次1080p 30fps的功耗能直接把手機燒成暖手寶。Android 12以后ION被DMA-BUF Heaps取代但mmap的用法沒變。這塊內(nèi)容展開能寫一整篇這里先點到為止。3.4 文件加載dex、oat、vdex和SQLite都在這條路上ART虛擬機加載一個APK會把里面的classes.dex、classes.oat、classes.vdex全部用mmap映射進來。你在/proc/pid/maps里能看到類似這樣的行7a2f3c0000-7a2f6c0000 r--p 00000000 fe:0a 1234 /data/app/com.xxx/base.apk中間的r--p表示只讀私有映射這就是dex區(qū)域。這樣做的收益很直接dex文件頁是file-backed的系統(tǒng)內(nèi)存緊張時可以丟棄下次用到再讀回來。而且多個進程比如同一個App的多個進程加載同一個APK時物理頁是共享的內(nèi)存占用只算一份。SQLite也在這條路上。Android從某個版本開始默認給數(shù)據(jù)庫連接打開了mmap模式讀操作可以直接在映射區(qū)上做省掉了read()系統(tǒng)調(diào)用和用戶態(tài)緩沖區(qū)拷貝。你可以自己驗證PRAGMA mmap_size;返回0說明沒開返回正數(shù)就是當前mmap窗口大小。具體默認值隨版本變動我在Android 11和13上實測同一張表拿到的數(shù)字不一樣所以別背數(shù)值直接查最靠譜。4. 手把手實操在Android上寫一個mmap讀寫大文件的小Demo4.1 NDK側C層完整實現(xiàn)先說明一下這個Demo我特意寫了錯誤處理因為mmap的錯誤處理是大多數(shù)人最容易糊弄過去的——return一個MAP_FAILED然后繼續(xù)用不崩才怪。順便提醒一句如果你還沒配好NDK環(huán)境先用Android Studio的SDK Manager把CMake和NDK勾上。#include jni.h #include fcntl.h #include unistd.h #include sys/mman.h #include sys/stat.h #include string.h #include errno.h #include android/log.h #define TAG MmapDemo #define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, TAG, __VA_ARGS__) // 把data寫入path指向的文件會用mmap覆蓋已有內(nèi)容 int write_via_mmap(const char *path, const void *data, size_t data_len) { int fd open(path, O_RDWR); if (fd 0) { LOGE(open failed: %s, strerror(errno)); return -1; } struct stat st; if (fstat(fd, st) ! 0) { LOGE(fstat failed: %s, strerror(errno)); close(fd); return -1; } // 關鍵文件必須足夠大否則訪問超出文件末尾的頁會收到SIGBUS if ((size_t)st.st_size data_len) { LOGE(file too small: %lld %zu, (long long)st.st_size, data_len); close(fd); return -1; } size_t map_len data_len; // 內(nèi)核會自動向上取整到頁大小 void *addr mmap(NULL, map_len, PROT_READ | PROT_WRITE, MAP_SHARED, // 需要寫回文件 fd, 0); // offset必須頁對齊這里是0 if (addr MAP_FAILED) { LOGE(mmap failed: %s, strerror(errno)); close(fd); return -1; } // 映射建立后fd就可以關了映射依然有效 close(fd); memcpy(addr, data, data_len); // 確保數(shù)據(jù)落盤。只對MAP_SHARED有效 if (msync(addr, map_len, MS_SYNC) ! 0) { LOGE(msync failed: %s, strerror(errno)); } if (munmap(addr, map_len) ! 0) { LOGE(munmap failed: %s, strerror(errno)); return -1; } return 0; }對應讀取的版本把PROT_READ|PROT_WRITE換成PROT_READ、flags換成MAP_PRIVATE就行其余一樣。這里我不貼重復代碼了。4.2 Java層FileChannel.map的甜與坑不想寫JNI的話Java NIO也提供了映射接口try (RandomAccessFile raf new RandomAccessFile(file, rw); FileChannel channel raf.getChannel()) { long size channel.size(); MappedByteBuffer buffer channel.map( FileChannel.MapMode.READ_WRITE, 0, size); buffer.put(0, (byte) 0x42); buffer.force(); // 等價于msync(MS_SYNC) } catch (IOException e) { Log.e(MmapDemo, map failed, e); }看起來挺美但這里有兩個真實的坑我必須單獨拎出來講?？右籎ava層沒有公開的unmap。映射的釋放依賴GC和Cleaner你完全控制不了時機。后果就是文件句柄被映射占著你調(diào)用File.delete()會返回false在某些機型上反復映射大文件虛擬內(nèi)存地址空間碎片化最終map拋IOException: Map failed。Android上要手動釋放可以反射調(diào)用FileChannelImpl.unmapprivate static void unmap(MappedByteBuffer buffer) { if (buffer null) return; try { Class? cls buffer.getClass(); Method cleanerMethod cls.getMethod(cleaner); cleanerMethod.setAccessible(true); Object cleaner cleanerMethod.invoke(buffer); if (cleaner ! null) { Method cleanMethod cleaner.getClass().getMethod(clean); cleanMethod.setAccessible(true); cleanMethod.invoke(cleaner); } } catch (Throwable t) { Log.w(MmapDemo, unmap via cleaner failed, t); } }需要說明的是cleaner這個字段在ART和OpenJDK上的實現(xiàn)細節(jié)不一樣有的版本是返回Cleaner對象有的是直接返回Runnable所以這段代碼要加try-catch兜底拿不到就走GC。所以做嚴肅的大文件場景我基本都建議直接走NDK的mmap/munmap別在Java層賭反射?？佣﨧apMode.READ_WRITE的映射如果文件被別的地方截斷了照樣SIGBUS。這個跟語言無關是mmap本身的語義。4.3 我實測的量級對比在同一臺驍龍8系機器上對一個128MB的文件做順序寫用三種方案各跑5次取中位數(shù)數(shù)據(jù)僅供參考實際跟文件系統(tǒng)和閃存狀態(tài)關系很大方案耗時量級堆內(nèi)存峰值備注FileOutputStreamBufferedOutputStream約1.0x中等約幾MB緩沖區(qū)數(shù)據(jù)要經(jīng)過用戶態(tài)緩沖區(qū)RandomAccessFile逐塊寫約1.3x低系統(tǒng)調(diào)用次數(shù)多mmapmemcpy約0.8x極低幾乎不占匿名內(nèi)存大文件優(yōu)勢明顯注意這里的堆內(nèi)存峰值才是重點。小文件幾百KB三者差異不大mmap甚至因為缺頁中斷的開銷略慢。文件越大mmap越劃算這個交叉點我一般按1MB來估低于這個數(shù)用普通IO更省心。5. 選型決策什么時候該用mmap什么時候別碰5.1 三種方案橫向對比維度read/writemmapsendfile/splice數(shù)據(jù)拷貝2次內(nèi)核→用戶→內(nèi)核0次頁表映射0次內(nèi)核內(nèi)流轉隨機訪問需要自己seekread直接按偏移訪問不支持內(nèi)存占用顯式緩沖區(qū)可回收的file-backed頁無適用場景小文件、流式處理大文件隨機讀、共享內(nèi)存文件間零拷貝轉發(fā)崩潰風險低SIGBUS/SIGSEGV需要處理低一句話總結選型思路你要隨機讀寫一個大文件或者多個進程共享同一份數(shù)據(jù)mmap是最優(yōu)解。你只是從頭到尾順序讀一遍而且文件不大老實read就行代碼簡單還不容易錯。你是在做代理轉發(fā)、文件復制考慮sendfile那個才是真正的零拷貝終點。5.2 幾個容易忽略的參數(shù)細節(jié)頁大小不是常量。別在代碼里硬寫4096。ARM64設備上現(xiàn)在有4KB和16KB兩種頁配置Android 15開始明確要求應用支持16KB頁。拿頁大小的正確姿勢long page_size sysconf(_SC_PAGESIZE);或者編譯期用getpagesize()。為什么重要如果你的offset是4096對齊但設備頁大小是16384mmap照樣給你EINVAL。這個bug在4KB機上永遠復現(xiàn)不了一上16KB的機器就炸排查起來能讓人懷疑人生。MAP_POPULATE可以提前觸發(fā)預讀。加上這個flagmmap會同步把所有頁都讀進來。適合你確定馬上要全量遍歷的場景能省掉大量缺頁中斷。代價是mmap這一次調(diào)用會阻塞較久啟動耗時敏感的地方慎用。madvise能給內(nèi)核打小報告。遍歷大文件之前調(diào)一次madvise(addr, len, MADV_SEQUENTIAL); // 我要順序讀幫我多預讀幾頁 madvise(addr, len, MADV_RANDOM); // 我隨機訪問別浪費IO預讀 madvise(addr, len, MADV_DONTNEED); // 這段我用完了頁可以回收MADV_SEQUENTIAL和MADV_RANDOM我實測在順序掃一個幾十MB的模型文件時能拉開10%到20%的差距屬于改一行代碼就見效的優(yōu)化。6. 踩坑實錄Android上mmap最常見的幾個問題6.1 SIGBUS99%是文件被截斷了SIGBUS是mmap最容易讓人懵的崩潰日志里就是一行Native crash堆棧指向你訪問映射地址的那一行看不出任何上下文。它的根因基本只有一個你訪問的那個地址對應的文件區(qū)域已經(jīng)不存在了。常見觸發(fā)方式有四種你映射了文件另一個進程或者你自己把文件truncate變小了。你在文件末尾附近訪問了最后一頁多出來的部分。舉個例子文件大小是4096*3100字節(jié)你映射了整個文件內(nèi)核會映射4頁第4頁只有100字節(jié)有效剩下3996字節(jié)是補零的。訪問這3996字節(jié)會不會崩取決于文件系統(tǒng)實現(xiàn)——在ext4上通常還好但在某些文件系統(tǒng)上就會SIGBUS。存儲空間寫滿內(nèi)核回寫臟頁失敗。網(wǎng)絡文件系統(tǒng)或者FUSE掛載點斷連。排查思路我總結成一句話先看崩潰地址落在哪個映射區(qū)間再看那個文件現(xiàn)在多大。adb shell ps -A | grep com.example.app # 拿到pid adb shell cat /proc/pid/maps | grep -i yourfile adb shell ls -l /path/to/your/file6.2 SIGSEGV和權限失敗的區(qū)分SIGSEGV是訪問了完全沒映射的地址通常是偏移算錯了或者映射長度不夠。比如你映射了0到1000字節(jié)結果代碼里寫了個buffer[2000]。還有一種容易被忽略的情況Android 10以后對可執(zhí)行映射做了嚴格限制W^X策略。你如果試圖mmap一個可寫文件并給它PROT_EXEC會直接失敗errno給EACCES或EPERM。這也是為什么動態(tài)加載代碼的路子在Android 10之后必須改成匿名可執(zhí)行內(nèi)存mmapPROT_READ|PROT_WRITE→mprotect加PROT_EXEC不能再靠映射so文件了。6.3 別被虛擬內(nèi)存嚇到VSZ大不代表內(nèi)存泄漏這個我吃過虧。早期用Android Studio的Profiler看內(nèi)存發(fā)現(xiàn)VSZ動不動幾十GB嚇得我以為是哪里泄漏了查了半天才明白——VSZ本來就該很大。原因在于每個進程都會映射一堆東西ART的dex/oat/vdex、Binder緩沖區(qū)、系統(tǒng)so、字體文件/system/fonts下面那一大堆、時區(qū)數(shù)據(jù)tzdata……全加起來幾個G很正常。而且mmap的映射是按虛擬地址算的跟實際用量沒關系。看內(nèi)存要看三個指標指標含義什么時候關心VSZ虛擬內(nèi)存映射總大小排查地址空間碎片、map失敗的參考RSS常駐內(nèi)存實際占用的物理頁判斷真實內(nèi)存壓力的主指標PSS按共享比例分攤后的RSS系統(tǒng)統(tǒng)計App內(nèi)存占用用它所以排查內(nèi)存問題的正確順序是先看PSS有沒有漲漲了再看/proc/pid/smaps里哪一段在漲。別一上來就盯著VSZ。6.4 常用排查命令速查表目的命令說明看進程的所有映射adb shell cat /proc/pid/maps每行一個vma含權限、偏移、文件路徑看每個映射的內(nèi)存明細adb shell cat /proc/pid/smaps比maps詳細有RSS/PSS/Shared字段只想要匯總adb shell cat /proc/pid/smaps_rollup省得翻幾千行按大小排序看映射adb shell showmap pidAndroid自帶輸出比手擼腳本友好看App內(nèi)存總覽adb shell dumpsys meminfo pkgNative Heap / Dalvik Heap / Graphics分開列showmap這個工具很多人不知道它是AOSP自帶的輸出按占用的PSS或RSS排序一眼就能看出是哪個映射吃掉了內(nèi)存。我最常用它來看是不是Fonts或者某個apk的dex異常膨脹。提示/proc/pid/maps里的路徑名可能被截斷成/data/app/~~xxxx/com.xxx-yyy/base.apk這種帶隨機后綴的形式這是正?，F(xiàn)象別以為文件被誤刪了。7. 幾個只有踩過才知道的實戰(zhàn)經(jīng)驗7.1 映射之前先把文件撐到目標大小這一條是我用血換來的。你要往一個新文件里寫100MB數(shù)據(jù)絕對不要open完就直接映射文件大小是0映射完一寫就SIGBUS。正確做法是先ftruncate到目標大小int fd open(path, O_RDWR | O_CREAT, 0644); ftruncate(fd, target_size); // 先占位再映射 void *addr mmap(NULL, target_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);ftruncate不會真的寫數(shù)據(jù)只是在文件系統(tǒng)里把長度標記上稀疏文件速度快得很。這一步在下載類、緩存類場景里幾乎是標配。7.2 一個文件別同時開太多映射有的同學做圖片加載每張圖都channel.map一次加載兩百張圖就是兩百個映射。Linux對單個進程的vma數(shù)量是有限制的vm.max_map_count默認65530而且每個vma本身有內(nèi)核開銷。我的做法是復用設一個固定大小的映射窗口滑動著讀大文件而不是整個文件一次映射完。這個模式在處理超大日志或者地圖瓦片的時候特別管用。7.3 小心munmap之后的野指針munmap之后那塊地址就還給內(nèi)核了。如果你的代碼里還留著addr指針繼續(xù)用那就是純純的use-after-free而且因為地址空間還在編譯器不會給你任何警告崩得毫無規(guī)律。我的習慣是封裝成一個RAII類C或者用try-finally包住Java/NIO確保munmap和指針的生命周期綁在一起。在C里我會額外把指針置NULL雖然不能根治但至少能多一層保險。7.4 低內(nèi)存設備上mmap是好兄弟前面反復提過file-backed頁可以回收。這句話在Android上意味著mmap映射的內(nèi)存在lmkd低內(nèi)存殺手掃描時不會算作不可回收所以你的進程更不容易被殺。反過來說如果你把一個200MB的文件read進byte[]那200MB就是實打實的匿名內(nèi)存系統(tǒng)壓力一大第一個被砍的可能就是你。做相機、相冊、文檔預覽這類App的同學可以拿這個思路去做優(yōu)化。7.5 關于跨進程不要自己造輪子做共享內(nèi)存有次我看到有團隊為了在App的兩個進程之間共享一份配置自己用MAP_SHARED映射了一個文件。跑是能跑但并發(fā)控制全靠猜——一個進程寫一半、另一個進程讀到了中間態(tài)數(shù)據(jù)直接亂掉。如果兩個進程真的需要共享內(nèi)存標準路線是走ashmem/memfd配合同步機制futex或者Binder回調(diào)。文件映射做共享內(nèi)存不是說不行而是你要自己處理一致性、崩潰恢復、加鎖這一堆問題。除非有明確理由否則我建議直接用系統(tǒng)提供的方案。寫了這么多最后再分享一個小技巧如果你在Android Studio里調(diào)試native代碼想驗證某個映射到底有沒有生效可以直接在LLDB里敲image lookup -a 地址或者用vmmap命令看當前進程的映射快照。這個排查起來特別快比一行行翻/proc/self/maps高效得多。我個人在查SIGBUS的時候基本就靠這一套組合拳先看崩潰地址再用vmmap定位區(qū)間最后去查對應的文件狀態(tài)三步下來基本沒有找不到的根因。 Android mmap內(nèi)存映射：原理、OOM優(yōu)化與大文件讀寫實戰(zhàn)
1. 從一次OOM排查說起mmap在Android里到底藏得多深剛入行那會兒我以為Android內(nèi)存映射mmap是個離應用層很遠的東西屬于那類面試會問、干活用不上的知識點。直到有次做一個相冊類App用戶反饋說滑到第三屏就閃退日志里全是java.lang.OutOfMemoryError。我當時的做法很樸素——把圖片一張張read進byte[]再解碼邏輯上沒毛病但一臺4G內(nèi)存的機器硬是被我這么讀幾十張大圖給撐爆了。后來把這條鏈路改成mmap映射文件、按需解碼同樣的機型同樣的圖片量RSS穩(wěn)得像一條直線。也是從那次開始我才認真去翻/proc/pid/maps去看Binder驅動怎么用mmap做一次拷貝去看ART怎么把dex文件映射進進程地址空間。越看越發(fā)現(xiàn)內(nèi)存映射幾乎是Android這座大廈的地基之一只是平時被封裝得很好不到出問題的時候你壓根感覺不到它。這篇內(nèi)容我打算把這幾年摸到的東西整理一遍。適合誰寫過Android應用、懂一點JNI、想搞明白為什么我的進程虛擬內(nèi)存幾十個G但物理內(nèi)存才幾百M的開發(fā)者也適合做音視頻、大文件處理、性能優(yōu)化方向的同學?？赐昴阒辽倌芨闱宄耺map到底怎么工作、Android里哪些地方在偷偷用它、以及你自己該在什么場景下用它、怎么用不翻車。提醒本文所有原理描述和代碼都基于AOSP的公開實現(xiàn)和POSIX標準示例代碼在真機和模擬器上都跑過參數(shù)建議僅供參考具體以你目標平臺的頁大小和內(nèi)核版本為準。2. mmap到底在干什么一次借地址不借數(shù)據(jù)的操作2.1 把文件頁塞進你的虛擬地址空間先說結論mmap不會立刻讀文件。它做的是在進程的虛擬地址空間里找一段空閑區(qū)間建立一段這段虛擬地址對應這個文件的這一段偏移的映射關系然后返回首地址。整個過程里文件內(nèi)容一個字節(jié)都沒被搬到內(nèi)存。這就像你在圖書館辦了一張借書卡卡上寫著三樓A區(qū)第7排第3本但你根本沒走過去把那本書拿下來。真正去取書是等你翻到某一頁的時候。Linux下的函數(shù)原型長這樣void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset); int munmap(void *addr, size_t length); int msync(void *addr, size_t length, int flags);幾個參數(shù)里最容易踩坑的是offset——它必須是頁大小的整數(shù)倍不是的話直接返回MAP_FAILEDerrno給EINVAL。length則會被內(nèi)核向上取整到頁邊界比如你傳100字節(jié)實際映射了一整頁4096字節(jié)ARM64也可能是16384字節(jié)這個后面單獨講。prot控制訪問權限常見組合是PROT_READ、PROT_READ|PROT_WRITE、PROT_NONE。flags里最關鍵的是兩個MAP_SHARED你的寫入會同步回文件其他映射了同一文件的進程也能看到。MAP_PRIVATE寫時復制COW你改了只是改了你自己那份副本文件本身不動。還有一個MAP_ANONYMOUS不關聯(lián)任何文件純粹要一塊內(nèi)存glibc的malloc在大塊分配時底層就會走這條路準確說是brk或mmap匿名映射二選一。2.2 缺頁中斷真正的數(shù)據(jù)搬運工映射建立之后你第一次訪問某個地址CPU會觸發(fā)一個缺頁中斷內(nèi)核這時候才去頁緩存里找對應的文件頁。找到了就直接把頁表項指過去沒找到就從磁盤讀進來放進頁緩存再指過去。理解這一點非常關鍵因為它決定了mmap的兩個特性第一次訪問慢后續(xù)訪問快。第一次是真實的磁盤IO之后都命中頁緩存純內(nèi)存操作。內(nèi)存可以被回收。這些頁是file-backed的系統(tǒng)內(nèi)存緊張時內(nèi)核可以直接把它們丟掉下次訪問再讀一遍。而new出來的堆內(nèi)存不行那是匿名頁丟掉就沒數(shù)據(jù)了只能壓縮或者換出。這也是為什么我說mmap能解決OOM——你映射一個500MB的文件進程的虛擬內(nèi)存VSZ直接漲500MB但物理內(nèi)存RSS可能只有幾MB因為你只碰了開頭那幾頁。系統(tǒng)壓力大了那些頁還能被丟掉。同樣500MB用read讀進byte[]那是實打實的500MB匿名內(nèi)存除非被殺進程否則誰也拿不走。2.3 一個容易忽略的細節(jié)映射完之后fd可以關掉很多人的代碼里mmap之后一直攥著fd不放生怕一關映射就失效。其實不需要。mmap建立映射之后內(nèi)核的vm_area_struct已經(jīng)持有對文件的引用fget你把fdclose掉完全不影響映射的有效性。真正影響映射的是munmap或者進程退出。不過這里有個坑如果你close了fd后續(xù)就沒法用msync了嗎不是msync用的是映射的起始地址跟fd沒關系。但如果你想用fstat再查文件大小那就得重新打開。所以我的習慣是先open fstat拿到大小mmap然后立刻close代碼路徑最干凈。2.4 私有映射和共享映射選錯了會很難受我見過有同事用MAP_PRIVATE映射一個日志文件然后往里寫寫完發(fā)現(xiàn)文件還是空的一臉茫然地來問我。這就是沒搞清楚COW語義——MAP_PRIVATE的寫入只在你的進程里可見內(nèi)核會給你分配新頁文件本身一個字節(jié)都不變。選型其實很簡單場景推薦flags原因只讀大文件圖片、模型、日志MAP_PRIVATE語義就是只讀COW不會被觸發(fā)等價只讀多進程共享一塊內(nèi)存MAP_SHARED 匿名改動互相可見修改文件內(nèi)容并落盤MAP_SHARED需要寫回加載可執(zhí)行代碼so等MAP_PRIVATEPROT_EXEC系統(tǒng)加載器就這么干的另外提一句msync它只對MAP_SHARED有意義。MS_SYNC會阻塞到數(shù)據(jù)真正落盤MS_ASYNC只是把頁標記為臟、排隊等待回寫。如果你寫入之后馬上要斷電測試、或者要讓另一個進程立刻看到必須用MS_SYNC。3. Android體系里mmap的四大主戰(zhàn)場3.1 Binder靠mmap把兩次拷貝壓成一次Binder的高效本質上就是內(nèi)存映射換來的。流程大概是這樣應用進程啟動時ProcessState會open(/dev/binder)然后調(diào)一次mmap把驅動分配的一塊內(nèi)核緩沖區(qū)映射到自己的用戶空間?；貞浺幌碌?節(jié)的原理——這塊內(nèi)核緩沖區(qū)同時在內(nèi)核空間和用戶空間各有一份映射物理頁是同一份。于是跨進程通信就變成了發(fā)送方把數(shù)據(jù)copy_from_user到內(nèi)核那塊映射區(qū)第一次拷貝接收方讀的時候直接用自己用戶空間的地址讀零拷貝。如果沒有mmapBinder就得是用戶態(tài)→內(nèi)核態(tài)→再回用戶態(tài)兩次拷貝慢一倍不止。這塊緩沖區(qū)的大小AOSP里定義在ProcessState.cpp#define BINDER_VM_SIZE ((1 * 1024 * 1024) - sysconf(_SC_PAGE_SIZE) * 2)也就是1MB減去兩個頁留點余量。有些系統(tǒng)會通過binder:vm_size這個屬性或者BINDER_VM_SIZE的編譯配置來放大它跑大對象傳輸?shù)亩ㄖ芌OM常見做法。注意正因為每個進程的Binder緩沖區(qū)就這么大單次Transaction的數(shù)據(jù)上限是有限制的大約1MB減去一點。你要傳大Bitmap得走ashmem或者ParcelFileDescriptor而不是硬塞進Binder。傳輸超限會拋TransactionTooLargeException這個異常很多人誤以為是內(nèi)存不足其實是緩沖區(qū)溢出。3.2 AshmemAndroid為共享內(nèi)存專門開的一扇門標準Linux有shmget/shmat這一套System V共享內(nèi)存也有memfd_create。Android早期自己造了個/dev/ashmem用ioctl設置名字和大小然后mmap出來。好處是內(nèi)核可以按需回收這些頁——低內(nèi)存時把沒人用的共享內(nèi)存區(qū)直接丟掉這叫unpinned ashmem。配合ASHMEM_PIN/ASHMEM_UNPIN系統(tǒng)能在內(nèi)存和性能之間做平衡。到Android 10之后AOSP把ashmem的底層實現(xiàn)悄悄換成了memfd_create加文件鏈接的方式在libcutils里做了封裝上層APIashmem_create_region的簽名完全沒變。所以如果你在維護老代碼不用急著改但新項目我建議直接用memfd_create畢竟是標準Linux路線行為更可預測。3.3 圖形系統(tǒng)Gralloc、SurfaceFlinger和那堆1024x1024做音視頻或者相機開發(fā)的同學一定見過GraphicBuffer。它的底層就是一塊dmabuf早期是ION通過mmap映射到用戶空間讓CPU能讀寫同時GPU也能通過dmabuf的fd直接訪問。這帶來的一個直接后果是CPU和GPU共享同一塊物理內(nèi)存不需要來回拷貝。你拍照預覽時那一幀從CMOS出來進ISP再進GPU處理再交給SurfaceFlinger合成全程靠的就是這個共享映射。如果每一環(huán)都memcpy一次1080p 30fps的功耗能直接把手機燒成暖手寶。Android 12以后ION被DMA-BUF Heaps取代但mmap的用法沒變。這塊內(nèi)容展開能寫一整篇這里先點到為止。3.4 文件加載dex、oat、vdex和SQLite都在這條路上ART虛擬機加載一個APK會把里面的classes.dex、classes.oat、classes.vdex全部用mmap映射進來。你在/proc/pid/maps里能看到類似這樣的行7a2f3c0000-7a2f6c0000 r--p 00000000 fe:0a 1234 /data/app/com.xxx/base.apk中間的r--p表示只讀私有映射這就是dex區(qū)域。這樣做的收益很直接dex文件頁是file-backed的系統(tǒng)內(nèi)存緊張時可以丟棄下次用到再讀回來。而且多個進程比如同一個App的多個進程加載同一個APK時物理頁是共享的內(nèi)存占用只算一份。SQLite也在這條路上。Android從某個版本開始默認給數(shù)據(jù)庫連接打開了mmap模式讀操作可以直接在映射區(qū)上做省掉了read()系統(tǒng)調(diào)用和用戶態(tài)緩沖區(qū)拷貝。你可以自己驗證PRAGMA mmap_size;返回0說明沒開返回正數(shù)就是當前mmap窗口大小。具體默認值隨版本變動我在Android 11和13上實測同一張表拿到的數(shù)字不一樣所以別背數(shù)值直接查最靠譜。4. 手把手實操在Android上寫一個mmap讀寫大文件的小Demo4.1 NDK側C層完整實現(xiàn)先說明一下這個Demo我特意寫了錯誤處理因為mmap的錯誤處理是大多數(shù)人最容易糊弄過去的——return一個MAP_FAILED然后繼續(xù)用不崩才怪。順便提醒一句如果你還沒配好NDK環(huán)境先用Android Studio的SDK Manager把CMake和NDK勾上。#include jni.h #include fcntl.h #include unistd.h #include sys/mman.h #include sys/stat.h #include string.h #include errno.h #include android/log.h #define TAG MmapDemo #define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, TAG, __VA_ARGS__) // 把data寫入path指向的文件會用mmap覆蓋已有內(nèi)容 int write_via_mmap(const char *path, const void *data, size_t data_len) { int fd open(path, O_RDWR); if (fd 0) { LOGE(open failed: %s, strerror(errno)); return -1; } struct stat st; if (fstat(fd, st) ! 0) { LOGE(fstat failed: %s, strerror(errno)); close(fd); return -1; } // 關鍵文件必須足夠大否則訪問超出文件末尾的頁會收到SIGBUS if ((size_t)st.st_size data_len) { LOGE(file too small: %lld %zu, (long long)st.st_size, data_len); close(fd); return -1; } size_t map_len data_len; // 內(nèi)核會自動向上取整到頁大小 void *addr mmap(NULL, map_len, PROT_READ | PROT_WRITE, MAP_SHARED, // 需要寫回文件 fd, 0); // offset必須頁對齊這里是0 if (addr MAP_FAILED) { LOGE(mmap failed: %s, strerror(errno)); close(fd); return -1; } // 映射建立后fd就可以關了映射依然有效 close(fd); memcpy(addr, data, data_len); // 確保數(shù)據(jù)落盤。只對MAP_SHARED有效 if (msync(addr, map_len, MS_SYNC) ! 0) { LOGE(msync failed: %s, strerror(errno)); } if (munmap(addr, map_len) ! 0) { LOGE(munmap failed: %s, strerror(errno)); return -1; } return 0; }對應讀取的版本把PROT_READ|PROT_WRITE換成PROT_READ、flags換成MAP_PRIVATE就行其余一樣。這里我不貼重復代碼了。4.2 Java層FileChannel.map的甜與坑不想寫JNI的話Java NIO也提供了映射接口try (RandomAccessFile raf new RandomAccessFile(file, rw); FileChannel channel raf.getChannel()) { long size channel.size(); MappedByteBuffer buffer channel.map( FileChannel.MapMode.READ_WRITE, 0, size); buffer.put(0, (byte) 0x42); buffer.force(); // 等價于msync(MS_SYNC) } catch (IOException e) { Log.e(MmapDemo, map failed, e); }看起來挺美但這里有兩個真實的坑我必須單獨拎出來講?？右籎ava層沒有公開的unmap。映射的釋放依賴GC和Cleaner你完全控制不了時機。后果就是文件句柄被映射占著你調(diào)用File.delete()會返回false在某些機型上反復映射大文件虛擬內(nèi)存地址空間碎片化最終map拋IOException: Map failed。Android上要手動釋放可以反射調(diào)用FileChannelImpl.unmapprivate static void unmap(MappedByteBuffer buffer) { if (buffer null) return; try { Class? cls buffer.getClass(); Method cleanerMethod cls.getMethod(cleaner); cleanerMethod.setAccessible(true); Object cleaner cleanerMethod.invoke(buffer); if (cleaner ! null) { Method cleanMethod cleaner.getClass().getMethod(clean); cleanMethod.setAccessible(true); cleanMethod.invoke(cleaner); } } catch (Throwable t) { Log.w(MmapDemo, unmap via cleaner failed, t); } }需要說明的是cleaner這個字段在ART和OpenJDK上的實現(xiàn)細節(jié)不一樣有的版本是返回Cleaner對象有的是直接返回Runnable所以這段代碼要加try-catch兜底拿不到就走GC。所以做嚴肅的大文件場景我基本都建議直接走NDK的mmap/munmap別在Java層賭反射?？佣﨧apMode.READ_WRITE的映射如果文件被別的地方截斷了照樣SIGBUS。這個跟語言無關是mmap本身的語義。4.3 我實測的量級對比在同一臺驍龍8系機器上對一個128MB的文件做順序寫用三種方案各跑5次取中位數(shù)數(shù)據(jù)僅供參考實際跟文件系統(tǒng)和閃存狀態(tài)關系很大方案耗時量級堆內(nèi)存峰值備注FileOutputStreamBufferedOutputStream約1.0x中等約幾MB緩沖區(qū)數(shù)據(jù)要經(jīng)過用戶態(tài)緩沖區(qū)RandomAccessFile逐塊寫約1.3x低系統(tǒng)調(diào)用次數(shù)多mmapmemcpy約0.8x極低幾乎不占匿名內(nèi)存大文件優(yōu)勢明顯注意這里的堆內(nèi)存峰值才是重點。小文件幾百KB三者差異不大mmap甚至因為缺頁中斷的開銷略慢。文件越大mmap越劃算這個交叉點我一般按1MB來估低于這個數(shù)用普通IO更省心。5. 選型決策什么時候該用mmap什么時候別碰5.1 三種方案橫向對比維度read/writemmapsendfile/splice數(shù)據(jù)拷貝2次內(nèi)核→用戶→內(nèi)核0次頁表映射0次內(nèi)核內(nèi)流轉隨機訪問需要自己seekread直接按偏移訪問不支持內(nèi)存占用顯式緩沖區(qū)可回收的file-backed頁無適用場景小文件、流式處理大文件隨機讀、共享內(nèi)存文件間零拷貝轉發(fā)崩潰風險低SIGBUS/SIGSEGV需要處理低一句話總結選型思路你要隨機讀寫一個大文件或者多個進程共享同一份數(shù)據(jù)mmap是最優(yōu)解。你只是從頭到尾順序讀一遍而且文件不大老實read就行代碼簡單還不容易錯。你是在做代理轉發(fā)、文件復制考慮sendfile那個才是真正的零拷貝終點。5.2 幾個容易忽略的參數(shù)細節(jié)頁大小不是常量。別在代碼里硬寫4096。ARM64設備上現(xiàn)在有4KB和16KB兩種頁配置Android 15開始明確要求應用支持16KB頁。拿頁大小的正確姿勢long page_size sysconf(_SC_PAGESIZE);或者編譯期用getpagesize()。為什么重要如果你的offset是4096對齊但設備頁大小是16384mmap照樣給你EINVAL。這個bug在4KB機上永遠復現(xiàn)不了一上16KB的機器就炸排查起來能讓人懷疑人生。MAP_POPULATE可以提前觸發(fā)預讀。加上這個flagmmap會同步把所有頁都讀進來。適合你確定馬上要全量遍歷的場景能省掉大量缺頁中斷。代價是mmap這一次調(diào)用會阻塞較久啟動耗時敏感的地方慎用。madvise能給內(nèi)核打小報告。遍歷大文件之前調(diào)一次madvise(addr, len, MADV_SEQUENTIAL); // 我要順序讀幫我多預讀幾頁 madvise(addr, len, MADV_RANDOM); // 我隨機訪問別浪費IO預讀 madvise(addr, len, MADV_DONTNEED); // 這段我用完了頁可以回收MADV_SEQUENTIAL和MADV_RANDOM我實測在順序掃一個幾十MB的模型文件時能拉開10%到20%的差距屬于改一行代碼就見效的優(yōu)化。6. 踩坑實錄Android上mmap最常見的幾個問題6.1 SIGBUS99%是文件被截斷了SIGBUS是mmap最容易讓人懵的崩潰日志里就是一行Native crash堆棧指向你訪問映射地址的那一行看不出任何上下文。它的根因基本只有一個你訪問的那個地址對應的文件區(qū)域已經(jīng)不存在了。常見觸發(fā)方式有四種你映射了文件另一個進程或者你自己把文件truncate變小了。你在文件末尾附近訪問了最后一頁多出來的部分。舉個例子文件大小是4096*3100字節(jié)你映射了整個文件內(nèi)核會映射4頁第4頁只有100字節(jié)有效剩下3996字節(jié)是補零的。訪問這3996字節(jié)會不會崩取決于文件系統(tǒng)實現(xiàn)——在ext4上通常還好但在某些文件系統(tǒng)上就會SIGBUS。存儲空間寫滿內(nèi)核回寫臟頁失敗。網(wǎng)絡文件系統(tǒng)或者FUSE掛載點斷連。排查思路我總結成一句話先看崩潰地址落在哪個映射區(qū)間再看那個文件現(xiàn)在多大。adb shell ps -A | grep com.example.app # 拿到pid adb shell cat /proc/pid/maps | grep -i yourfile adb shell ls -l /path/to/your/file6.2 SIGSEGV和權限失敗的區(qū)分SIGSEGV是訪問了完全沒映射的地址通常是偏移算錯了或者映射長度不夠。比如你映射了0到1000字節(jié)結果代碼里寫了個buffer[2000]。還有一種容易被忽略的情況Android 10以后對可執(zhí)行映射做了嚴格限制W^X策略。你如果試圖mmap一個可寫文件并給它PROT_EXEC會直接失敗errno給EACCES或EPERM。這也是為什么動態(tài)加載代碼的路子在Android 10之后必須改成匿名可執(zhí)行內(nèi)存mmapPROT_READ|PROT_WRITE→mprotect加PROT_EXEC不能再靠映射so文件了。6.3 別被虛擬內(nèi)存嚇到VSZ大不代表內(nèi)存泄漏這個我吃過虧。早期用Android Studio的Profiler看內(nèi)存發(fā)現(xiàn)VSZ動不動幾十GB嚇得我以為是哪里泄漏了查了半天才明白——VSZ本來就該很大。原因在于每個進程都會映射一堆東西ART的dex/oat/vdex、Binder緩沖區(qū)、系統(tǒng)so、字體文件/system/fonts下面那一大堆、時區(qū)數(shù)據(jù)tzdata……全加起來幾個G很正常。而且mmap的映射是按虛擬地址算的跟實際用量沒關系。看內(nèi)存要看三個指標指標含義什么時候關心VSZ虛擬內(nèi)存映射總大小排查地址空間碎片、map失敗的參考RSS常駐內(nèi)存實際占用的物理頁判斷真實內(nèi)存壓力的主指標PSS按共享比例分攤后的RSS系統(tǒng)統(tǒng)計App內(nèi)存占用用它所以排查內(nèi)存問題的正確順序是先看PSS有沒有漲漲了再看/proc/pid/smaps里哪一段在漲。別一上來就盯著VSZ。6.4 常用排查命令速查表目的命令說明看進程的所有映射adb shell cat /proc/pid/maps每行一個vma含權限、偏移、文件路徑看每個映射的內(nèi)存明細adb shell cat /proc/pid/smaps比maps詳細有RSS/PSS/Shared字段只想要匯總adb shell cat /proc/pid/smaps_rollup省得翻幾千行按大小排序看映射adb shell showmap pidAndroid自帶輸出比手擼腳本友好看App內(nèi)存總覽adb shell dumpsys meminfo pkgNative Heap / Dalvik Heap / Graphics分開列showmap這個工具很多人不知道它是AOSP自帶的輸出按占用的PSS或RSS排序一眼就能看出是哪個映射吃掉了內(nèi)存。我最常用它來看是不是Fonts或者某個apk的dex異常膨脹。提示/proc/pid/maps里的路徑名可能被截斷成/data/app/~~xxxx/com.xxx-yyy/base.apk這種帶隨機后綴的形式這是正?，F(xiàn)象別以為文件被誤刪了。7. 幾個只有踩過才知道的實戰(zhàn)經(jīng)驗7.1 映射之前先把文件撐到目標大小這一條是我用血換來的。你要往一個新文件里寫100MB數(shù)據(jù)絕對不要open完就直接映射文件大小是0映射完一寫就SIGBUS。正確做法是先ftruncate到目標大小int fd open(path, O_RDWR | O_CREAT, 0644); ftruncate(fd, target_size); // 先占位再映射 void *addr mmap(NULL, target_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);ftruncate不會真的寫數(shù)據(jù)只是在文件系統(tǒng)里把長度標記上稀疏文件速度快得很。這一步在下載類、緩存類場景里幾乎是標配。7.2 一個文件別同時開太多映射有的同學做圖片加載每張圖都channel.map一次加載兩百張圖就是兩百個映射。Linux對單個進程的vma數(shù)量是有限制的vm.max_map_count默認65530而且每個vma本身有內(nèi)核開銷。我的做法是復用設一個固定大小的映射窗口滑動著讀大文件而不是整個文件一次映射完。這個模式在處理超大日志或者地圖瓦片的時候特別管用。7.3 小心munmap之后的野指針munmap之后那塊地址就還給內(nèi)核了。如果你的代碼里還留著addr指針繼續(xù)用那就是純純的use-after-free而且因為地址空間還在編譯器不會給你任何警告崩得毫無規(guī)律。我的習慣是封裝成一個RAII類C或者用try-finally包住Java/NIO確保munmap和指針的生命周期綁在一起。在C里我會額外把指針置NULL雖然不能根治但至少能多一層保險。7.4 低內(nèi)存設備上mmap是好兄弟前面反復提過file-backed頁可以回收。這句話在Android上意味著mmap映射的內(nèi)存在lmkd低內(nèi)存殺手掃描時不會算作不可回收所以你的進程更不容易被殺。反過來說如果你把一個200MB的文件read進byte[]那200MB就是實打實的匿名內(nèi)存系統(tǒng)壓力一大第一個被砍的可能就是你。做相機、相冊、文檔預覽這類App的同學可以拿這個思路去做優(yōu)化。7.5 關于跨進程不要自己造輪子做共享內(nèi)存有次我看到有團隊為了在App的兩個進程之間共享一份配置自己用MAP_SHARED映射了一個文件。跑是能跑但并發(fā)控制全靠猜——一個進程寫一半、另一個進程讀到了中間態(tài)數(shù)據(jù)直接亂掉。如果兩個進程真的需要共享內(nèi)存標準路線是走ashmem/memfd配合同步機制futex或者Binder回調(diào)。文件映射做共享內(nèi)存不是說不行而是你要自己處理一致性、崩潰恢復、加鎖這一堆問題。除非有明確理由否則我建議直接用系統(tǒng)提供的方案。寫了這么多最后再分享一個小技巧如果你在Android Studio里調(diào)試native代碼想驗證某個映射到底有沒有生效可以直接在LLDB里敲image lookup -a 地址或者用vmmap命令看當前進程的映射快照。這個排查起來特別快比一行行翻/proc/self/maps高效得多。我個人在查SIGBUS的時候基本就靠這一套組合拳先看崩潰地址再用vmmap定位區(qū)間最后去查對應的文件狀態(tài)三步下來基本沒有找不到的根因。