共享單車、共享充電寶、共享雨傘，世間的共享有千萬種，而我獨愛共享內存。
早期的共享內存，著重於強調把同一片內存，map到多個進程的虛擬地址空間（在相應進程找到一個VMA區域），以便於CPU可以在各個進程訪問到這片內存。
現階段廣泛應用於多媒體、Graphics領域的共享內存方式，某種意義上不再強調映射到進程虛擬地址空間的概念（那無非是為了讓CPU訪問），而更強調以某種「句柄」的形式，讓大家知道某一片視頻、圖形圖像數據的存在並可以藉助此「句柄」來跨進程引用這片內存，讓視頻encoder、decoder、GPU等可以跨進程訪問內存。所以不同進程用的加速硬體其實是不同的，他們更在乎的是可以通過一個handle拿到這片內存，而不再特別在乎CPU訪問它的虛擬地址（當然仍然可以映射到進程的虛擬地址空間供CPU訪問）。
只要內存的拷貝(memcpy)仍然是一個佔據內存帶寬、CPU利用率的消耗大戶存在，共享內存作為Linux進程間通信、計算機系統裡各個不同硬體組件通信的最高效方法，都將持續繁榮。關於內存拷貝會大多程度地佔據CPU利用率，這個可以最簡單地嘗試拷貝1080P，幀率每秒60的電影畫面，我保證你的系統的CPU，蛋會疼地不行。
我早就想系統地寫一篇綜述Linux裡面各種共享內存方式的文章了，但是一直被帶娃這個事業牽絆，今日我決定頂著娃娃們的山呼海嘯，也要寫一篇文章不吐不快。
共享內存的方式有很多種，目前主流的方式仍然有：
1.基於傳統SYS V的共享內存；
2.基於POSIX mmap文件映射實現共享內存；
3.通過memfd_create()和fd跨進程共享實現共享內存；
4.多媒體、圖形領域廣泛使用的基於dma-buf的共享內存。
歷史悠久、年代久遠、API怪異，對應內核代碼linux/ipc/shm.c，當你編譯內核的時候不選擇CONFIG_SYSVIPC，則不再具備此能力。
你在Linux敲ipcs命令看到的share memory就是這種共享內存：
下面寫一個最簡單的程序來看共享內存的寫端sw.c：
以及共享內存的讀端sr.c：
編譯和準備運行：
在此之前我們看一下系統的free:
下面運行sw和sr：
我們發現sr列印出來的和sw寫進去的是一致的。這個時候我們再看下free：
可以看到used顯著增大了（711632 -> 715908）, shared顯著地增大了（2264 -> 6360），而cached這一列也顯著地增大326604->330716。
我們都知道cached這一列統計的是file-backed的文件的page cache的大小。理論上，共享內存屬於匿名頁，但是由於這裡面有個非常特殊的tmpfs（/dev/shm指向/run/shm,/run/shm則mount為tmpfs）：
所以可以看出tmpfs的東西其實真的是有點含混：我們可以理解它為file-backed的匿名頁（anonymous page），有點類似女聲中的周深。前面我們反覆強調，匿名頁是沒有文件背景的，這樣當進行內存交換的時候，是與swap分區交換。磁碟文件系統裡面的東西在內存的副本是file-backed的頁面，所以不存在與swap分區交換的問題。但是tmpfs裡面的東西，真的是在統計意義上統計到page cache了，但是它並沒有真實的磁碟背景，這又和你訪問磁碟文件系統裡面的文件產生的page cache有本質的區別。所以，它是真地有那麼一點misc的感覺，凡事都沒有絕對，唯有變化本身是不變的。
也可以通過ipcs找到新創建的SYS V共享內存：
我對POSIX shm_open()、mmap () API系列的共享內存的喜愛，遠遠超過SYS V 100倍。原諒我就是一個懶惰的人，我就是討厭ftok、shmget、shmat、shmdt這樣的API。
上面的程序如果用POSIX的寫法，可以簡化成寫端psw.c：
讀端：
編譯和執行：
這樣我們會在/dev/shm/、/run/shm下面看到一個文件：
坦白講，mmap、munmap這樣的API讓我找到了回家的感覺，剛入行做Linux的時候，寫好framebuffer驅動後，就是把/dev/fb0 mmap到用戶空間來操作，所以mmap這樣的 API，真的是特別親切，像親人一樣。
當然，如果你不喜歡shm_open()這個API，你也可以用常規的open來打開文件，然後進行mmap。關鍵的是mmap，wikipedia如是說：
In computing, mmap(2) is a POSIX-compliant Unix system call that maps files or devices into memory. It is a method of memory-mapped file I/O. It implements demand paging, because file contents are not read from disk directly and initially do not use physical RAM at all. The actual reads from disk are performed in a "lazy" manner, after a specific location is accessed. After the memory is no longer needed, it is important to munmap(2) the pointers to it. Protection information can be managed using mprotect(2), and special treatment can be enforced using madvise(2).
POSIX的共享內存，仍然符合我們前面說的tmpfs的特點，在運行了sw,sr後，再運行psw和psr，我們發現free命令再次戲劇性變化：
請將這個free命令的結果與前2次的free結果的各個欄位進行對照:
第3次比第2次的cached大了這麼多？是因為我編寫這篇文章邊在訪問磁碟裡面的文件，當然POSIX的這個共享內存本身也導致cached增大了。
如果說POSIX的mmap讓我找到回家的感覺，那麼memfd_create()則是萬般驚豔。見過這種API，才知道什麼叫天生尤物——而且是尤物中的尤物，它完全屬於那種讓碼農第一眼看到就會兩眼充血，恨不得眼珠子奪眶而出貼到它身上去的那種API；一般人見到它第一次，都會忽略了它的長相，因為它的身材實在太火辣太搶眼了。
先不要浮想聯翩，在所有的所有開始之前，我們要先提一下跨進程分享fd（文件描述符，對應我們很多時候說的「句柄」）這個重要的概念。
眾所周知，Linux的fd屬於一個進程級別的東西。進入每個進程的/proc/pid/fd可以看到它的fd的列表：
這個進程的0，1，2和那個進程的0，1，2不是一回事。
某年某月的某一天，人們發現，一個進程其實想訪問另外一個進程的fd。當然，這只是目的不是手段。比如進程A有2個fd指向2片內存，如果進程B可以拿到這2個fd，其實就可以透過這2個fd訪問到這2片內存。這個fd某種意義上充當了一個中間媒介的作用。有人說，那還不簡單嗎，如果進程A:
fd = open();
open()如果返回100，把這個100告訴進程B不就可以了嗎，進程B訪問這個100就可以了。這說明你還是沒搞明白fd是一個進程內部的東西，是不能跨進程的概念。你的100和我的100，不是一個東西。這些基本的東西你搞不明白，你搞別的都是白搭。
Linux提供一個特殊的方法，可以把一個進程的fd甩鍋、踢皮球給另外一個進程（其實「甩鍋」這個詞用在這裡不合適，因為「甩鍋」是一種推卸，而fd的傳遞是一種分享）。我特碼一直想把我的bug甩（分）鍋（享）出去，卻發現總是被人把bug甩鍋過來。
那麼如何甩（分）鍋（享）fd呢？
欲知後事如何，請聽下回分解~~~
Linux閱碼場原創精華文章匯總
更多精彩，盡在"Linux閱碼場"，掃描下方二維碼關注
你的隨手轉發或點個在看是對我們最大的支持！