Mmap可以讓程序員解鎖哪些騷操作？
大家好，我是小風哥!
今天這篇文章帶你講解下稍顯神秘的mmap到底是怎么一回事。
簡單的與麻煩的
用代碼讀寫內存對程序員來說是非常方便非常自然的，但用代碼讀寫磁盤對程序員來說就不那么方便不那么自然了。
回想一下，你在代碼中讀寫內存有多簡單：
定義一個數組：
- int a[100];
- a[0] = 2;
看到了吧，這時你就在寫內存，甚至你可能在寫這段代碼時下意識里都沒有去想讀內存這件事。
再想想你是怎樣讀磁盤文件的?
- char buf[1024];
- int fd = open("/filepath/abc.txt");
- read(fd, buf, 1024);
- // 操作buf等等
看到了吧，讀寫磁盤文件其實是一件很麻煩的事情，你需要open一個文件，意思是告訴操作系統“Hey，操作系統，我要開始讀abc.txt這個文件了，把這個文件的所有信息準備好，然后給我一個代號”。這個代號就是所謂的文件描述符，拿到文件描述符后你才能繼續接下來的讀寫操作。
為什么麻煩
現在你應該看到了，操作磁盤文件要比操作內存復雜很多，根本原因就在于尋址方式不同。
對內存來說我們可以直接按照字節粒度去尋址，但對磁盤上保存的文件來說則不是這樣的，磁盤上保存的文件是按照塊(block)的粒度來尋址的，因此你必須先把磁盤中的文件讀取到內存中，然后再按照字節粒度來操作文件內容。
你可能會想既然直接操作內存很簡單，那么我們有沒有辦法像讀寫內存那樣去直接讀寫磁盤文件呢?
答案是肯定的。
要開腦洞了
對于像我們這樣在用戶態編程的程序員來說，內存在我們眼里就是一段連續的空間。啊哈，巧了，磁盤上保存的文件在程序員眼里也存放在一段連續的空間中(有的同學可能會說文件其實是在磁盤上離散存放的，請注意，我們在這里只從文件使用者的角度來講)。
那么這兩段空間有沒有辦法關聯起來呢?
答案是肯定的，怎么關聯呢?
答案就是。。。。。。你猜對了嗎?答案是通過虛擬內存。
關于虛擬內存我們已經講解過很多次了，虛擬內存就是假的地址空間，是進程看到的幻象，其目的是讓每個進程都認為自己獨占內存，關于虛擬內存完整的詳細講解請參考博主的深入理解操作系統，關注公眾號碼農的荒島求生并回復操作系統即可。
既然進程看到地址空間是假的那么一切都好辦了。
既然是假的，那么就有做手腳的操作空間，怎么做手腳呢?
從普通程序員眼里看文件不是保存在一段連續的磁盤空間上嗎?我們可以直接把這段空間映射到進程的內存中，就像這樣：
假設文件長度是100字節，我們把該文件映射到了進程的內存中，地址是從600 ~ 800，那么當你直接讀寫600 ~ 800這段內存時，實際上就是在直接操作磁盤文件。
這一切是怎么做到呢?
魔術師操作系統
原來這一切背后的功勞是操作系統。
當我們首次讀取600~800這段地址空間時，操作系統會檢測的這一操作，因為此時這段內存中什么內容都還沒有，此時操作系統自己讀取磁盤文件填充到這段內存空間中，此后程序就可以像讀內存一樣直接讀取磁盤內容了。
寫操作也很簡單，用戶程序依然可以直接修改這塊內存，此后操作系統會在背后將修改內容寫回磁盤。
現在你應該看到了，其實采用mmap這種方法磁盤依然還是按照塊的粒度來尋址的，只不過在操作系統的一番騷操作下對于用戶態的程序來說“看起來”我們能像讀寫內存那樣直接讀寫磁盤文件了，從按塊粒度尋址到按照字節粒度尋址，這中間的差異就是操作系統來填補的。
我想你現在應該大體明白mmap是什么意思了。
接下來你肯定要問的問題就是，mmap有什么好處呢?我為什么要使用mmap?
內存copy與系統調用
我們常用的標準IO，也就是read/write其底層是涉及到系統調用的，同時當使用read/write讀寫文件內容時，需要將數據從內核態copy到用戶態，修改完畢后再從用戶態copy到內核態，顯然，這些都是有開銷的。
而mmap則無此問題，基于mmap讀寫磁盤文件不會招致系統調用以及額外的內存copy開銷，但mmap也不是完美的，mmap也有自己的缺點。
其中一方面在于為了創建并維持地址空間與文件的映射關系，內核中需要有特定的數據結構來實現這一映射，這當然是有性能開銷的，除此之外另一點就是缺頁問題，page fault。
注意，缺頁中斷也是有開銷的，而且不同的內核由于內部的實現機制不同，其系統調用、數據copy以及缺頁處理的開銷也不同，因此就性能上來說我們不能肯定的說mmap就比標準IO好。這要看標準IO中的系統調用、內存調用的開銷與mmap方法中的缺頁中斷處理的開銷哪個更小，開銷小的一方將展現出更優異的性能。
還是那句話，談到性能，單純的理論分析就不是那么好用了，你需要基于真實的場景基于特定的操作系統以及硬件去測試才能有結論。
大文件處理
到目前為止我想大家對mmap最直觀的理解就是可以像直接讀寫內存那樣來操作磁盤文件，這是其中一個優點。
另一個優點在于mmap其實是和操作系統中的虛擬內存密切相關的，這就為mmap帶來了一個很有趣的優勢。
這個優勢在于處理大文件場景，這里的大文件指的是文件的大小超過你的物理內存，在這種場景下如果你使用傳統的read/write，那么你必須一塊一塊的把文件搬到內存，處理完文件的一小部分再處理下一部分。
這種需要在內存中開辟一塊空間——也就是我們常說的buffer，的方案聽上去就麻煩有沒有，而且還需要操作系統把數據從內核態copy到用戶態的buffer中。
但如果用mmap情況就不一樣了，只要你的進程地址空間足夠大，可以直接把這個大文件映射到你的進程地址空間中，即使該文件大小超過物理內存也可以，這就是虛擬內存的巧妙之處了，當物理內存的空閑空間所剩無幾時虛擬內存會把你進程地址空間中不常用的部分扔出去，這樣你就可以繼續在有限的物理內存中處理超大文件了，這個過程對程序員是透明的，虛擬內存都給你處理好了。關于虛擬內存的透徹講解請參考博主的深入理解操作系統，關注公眾號碼農的荒島求生并回復操作系統即可。
注意，mmap與虛擬內存的結合在處理大文件時可以簡化代碼設計，但在性能上是否優于傳統的read/write方法就不一定了，還是那句話關于mmap與傳統IO在涉及到性能時你需要基于真實的應用場景測試。
使用mmap處理大文件要注意一點，如果你的系統是32位的話，進程的地址空間就只有4G，這其中還有一部分預留給操作系統，因此在32位系統下可能不足以在你的進程地址空間中找到一塊連續的空間來映射該文件，在64位系統下則無需擔心地址空間不足的問題，這一點要注意。
節省內存
這可能是mmap最大的優勢，以及最好的應用場景了。
假設有一個文件，很多進程的運行都依賴于此文件，而且還是有一個假設，那就是這些進程是以只讀(read-only)的方式依賴于此文件。
你一定在想，這么神奇?很多進程以只讀的方式依賴此文件?有這樣的文件嗎?
答案是肯定的，這就是動態鏈接庫。
要想弄清楚動態鏈接庫，我們就不得不從靜態庫說起。
假設有三個程序A、B、C依賴一個靜態庫，那么鏈接器在生成可執行程序A、B、C時會把該靜態庫copy到A、B、C中，就像這樣：
假設你本身要寫的代碼只有2MB大小，但卻依賴了一個100MB的靜態庫，那么最終生成的可執行程序就是102MB，盡管你本身的代碼只有2MB。
而且從圖中我們可以看出，可執行程序A、B、C中都有一部分靜態庫的副本，這里面的內容是完全一樣的，那么很顯然，這些可執行程序放在磁盤上會浪費磁盤空間，加載到內存中運行時會浪費內存空間。
那么該怎么解決這個問題呢?
很簡單，可執行程序A、B、C中為什么都要各自保存一份完全一樣的數據呢?其實我們只需要在可執行程序A、B、C中保存一小點信息，這點信息里記錄了依賴了哪個庫，那么當可執行程序運行起來后再把相應的庫加載到內存中：
依然假設你本身要寫的代碼只有2MB大小，此時依賴了一個100MB的動態鏈接庫，那么最終生成的可執行程序就是2MB，盡管你依賴了一個100MB的庫。
而且從圖中可以看出，此時可執行程序ABC中已經沒有冗余信息了，這不但節省磁盤空間，而且節省內存空間，讓有限的內存可以同時運行更多的進程，是不是很酷。
現在我們已經知道了動態庫的妙用，但我們并沒有說明動態庫是怎么節省內存的，接下來mmap就該登場了。
你不是很多進程都依賴于同一個庫嘛，那么我就用mmap把該庫直接映射到各個進程的地址空間中，盡管每個進程都認為自己地址空間中加載了該庫，但實際上該庫在內存中只有一份。
mmap就這樣很神奇和動態鏈接庫聯動起來了，關于鏈接器以及靜態庫動態庫等更加詳細的講解你可以關注公眾號碼農的荒島求生并回復鏈接器即可。
想用好mmap沒那么容易
現在你應該大體了解mmap，想用好mmap你必須對虛擬內存有一個較為透徹的理解，并且能對你的應用場景有一個透徹的理解，在使用mmap之前問問自己是不是還有更好的辦法，因此，對于新手來說并不推薦使用該機制。
總結
mmap在博主眼里是一種很獨特的機制，這種機制最大的誘惑在于可以像讀寫內存樣方便的操作磁盤文件，這簡直就像魔法一樣，因此在一些場景下可以簡化代碼設計。
但談到mmap的與標準IO(read/write)的性能情況就比較復雜了，標準IO設計到系統調用以及用戶態內核態的copy問題，而mmap則涉及到維持內存與磁盤文件的映射關系以及缺頁處理的開銷，單純的從理論分析這二者半斤八兩，如果你的應用場景對性能要求較高，那么你需要基于真實場景進行測試。
我是小風哥，希望這篇文章對大家理解mmap有所幫助。
