偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

Mmap可以讓程序員解鎖哪些騷操作?

存儲 存儲設備
mmap在博主眼里是一種很獨特的機制,這種機制最大的誘惑在于可以像讀寫內(nèi)存樣方便的操作磁盤文件,這簡直就像魔法一樣,因此在一些場景下可以簡化代碼設計。

[[419462]]

大家好,我是小風哥!

今天這篇文章帶你講解下稍顯神秘的mmap到底是怎么一回事。

簡單的與麻煩的

用代碼讀寫內(nèi)存對程序員來說是非常方便非常自然的,但用代碼讀寫磁盤對程序員來說就不那么方便不那么自然了。

回想一下,你在代碼中讀寫內(nèi)存有多簡單:

定義一個數(shù)組:

  1. int a[100]; 
  2. a[0] = 2; 

看到了吧,這時你就在寫內(nèi)存,甚至你可能在寫這段代碼時下意識里都沒有去想讀內(nèi)存這件事。

再想想你是怎樣讀磁盤文件的?

  1. char buf[1024]; 
  2.  
  3. int fd = open("/filepath/abc.txt"); 
  4. read(fd, buf, 1024); 
  5. // 操作buf等等 

看到了吧,讀寫磁盤文件其實是一件很麻煩的事情,你需要open一個文件,意思是告訴操作系統(tǒng)“Hey,操作系統(tǒng),我要開始讀abc.txt這個文件了,把這個文件的所有信息準備好,然后給我一個代號”。這個代號就是所謂的文件描述符,拿到文件描述符后你才能繼續(xù)接下來的讀寫操作。

為什么麻煩

現(xiàn)在你應該看到了,操作磁盤文件要比操作內(nèi)存復雜很多,根本原因就在于尋址方式不同。

對內(nèi)存來說我們可以直接按照字節(jié)粒度去尋址,但對磁盤上保存的文件來說則不是這樣的,磁盤上保存的文件是按照塊(block)的粒度來尋址的,因此你必須先把磁盤中的文件讀取到內(nèi)存中,然后再按照字節(jié)粒度來操作文件內(nèi)容。

你可能會想既然直接操作內(nèi)存很簡單,那么我們有沒有辦法像讀寫內(nèi)存那樣去直接讀寫磁盤文件呢?

答案是肯定的。

要開腦洞了

對于像我們這樣在用戶態(tài)編程的程序員來說,內(nèi)存在我們眼里就是一段連續(xù)的空間。啊哈,巧了,磁盤上保存的文件在程序員眼里也存放在一段連續(xù)的空間中(有的同學可能會說文件其實是在磁盤上離散存放的,請注意,我們在這里只從文件使用者的角度來講)。

那么這兩段空間有沒有辦法關聯(lián)起來呢?

答案是肯定的,怎么關聯(lián)呢?

答案就是。。。。。。你猜對了嗎?答案是通過虛擬內(nèi)存。

關于虛擬內(nèi)存我們已經(jīng)講解過很多次了,虛擬內(nèi)存就是假的地址空間,是進程看到的幻象,其目的是讓每個進程都認為自己獨占內(nèi)存,關于虛擬內(nèi)存完整的詳細講解請參考博主的深入理解操作系統(tǒng),關注公眾號碼農(nóng)的荒島求生并回復操作系統(tǒng)即可。

既然進程看到地址空間是假的那么一切都好辦了。

既然是假的,那么就有做手腳的操作空間,怎么做手腳呢?

從普通程序員眼里看文件不是保存在一段連續(xù)的磁盤空間上嗎?我們可以直接把這段空間映射到進程的內(nèi)存中,就像這樣:

假設文件長度是100字節(jié),我們把該文件映射到了進程的內(nèi)存中,地址是從600 ~ 800,那么當你直接讀寫600 ~ 800這段內(nèi)存時,實際上就是在直接操作磁盤文件。

這一切是怎么做到呢?

魔術師操作系統(tǒng)

原來這一切背后的功勞是操作系統(tǒng)。

當我們首次讀取600~800這段地址空間時,操作系統(tǒng)會檢測的這一操作,因為此時這段內(nèi)存中什么內(nèi)容都還沒有,此時操作系統(tǒng)自己讀取磁盤文件填充到這段內(nèi)存空間中,此后程序就可以像讀內(nèi)存一樣直接讀取磁盤內(nèi)容了。

寫操作也很簡單,用戶程序依然可以直接修改這塊內(nèi)存,此后操作系統(tǒng)會在背后將修改內(nèi)容寫回磁盤。

現(xiàn)在你應該看到了,其實采用mmap這種方法磁盤依然還是按照塊的粒度來尋址的,只不過在操作系統(tǒng)的一番騷操作下對于用戶態(tài)的程序來說“看起來”我們能像讀寫內(nèi)存那樣直接讀寫磁盤文件了,從按塊粒度尋址到按照字節(jié)粒度尋址,這中間的差異就是操作系統(tǒng)來填補的。

我想你現(xiàn)在應該大體明白mmap是什么意思了。

接下來你肯定要問的問題就是,mmap有什么好處呢?我為什么要使用mmap?

內(nèi)存copy與系統(tǒng)調(diào)用

我們常用的標準IO,也就是read/write其底層是涉及到系統(tǒng)調(diào)用的,同時當使用read/write讀寫文件內(nèi)容時,需要將數(shù)據(jù)從內(nèi)核態(tài)copy到用戶態(tài),修改完畢后再從用戶態(tài)copy到內(nèi)核態(tài),顯然,這些都是有開銷的。

而mmap則無此問題,基于mmap讀寫磁盤文件不會招致系統(tǒng)調(diào)用以及額外的內(nèi)存copy開銷,但mmap也不是完美的,mmap也有自己的缺點。

其中一方面在于為了創(chuàng)建并維持地址空間與文件的映射關系,內(nèi)核中需要有特定的數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)這一映射,這當然是有性能開銷的,除此之外另一點就是缺頁問題,page fault。

注意,缺頁中斷也是有開銷的,而且不同的內(nèi)核由于內(nèi)部的實現(xiàn)機制不同,其系統(tǒng)調(diào)用、數(shù)據(jù)copy以及缺頁處理的開銷也不同,因此就性能上來說我們不能肯定的說mmap就比標準IO好。這要看標準IO中的系統(tǒng)調(diào)用、內(nèi)存調(diào)用的開銷與mmap方法中的缺頁中斷處理的開銷哪個更小,開銷小的一方將展現(xiàn)出更優(yōu)異的性能。

還是那句話,談到性能,單純的理論分析就不是那么好用了,你需要基于真實的場景基于特定的操作系統(tǒng)以及硬件去測試才能有結(jié)論。

大文件處理

到目前為止我想大家對mmap最直觀的理解就是可以像直接讀寫內(nèi)存那樣來操作磁盤文件,這是其中一個優(yōu)點。

另一個優(yōu)點在于mmap其實是和操作系統(tǒng)中的虛擬內(nèi)存密切相關的,這就為mmap帶來了一個很有趣的優(yōu)勢。

這個優(yōu)勢在于處理大文件場景,這里的大文件指的是文件的大小超過你的物理內(nèi)存,在這種場景下如果你使用傳統(tǒng)的read/write,那么你必須一塊一塊的把文件搬到內(nèi)存,處理完文件的一小部分再處理下一部分。

這種需要在內(nèi)存中開辟一塊空間——也就是我們常說的buffer,的方案聽上去就麻煩有沒有,而且還需要操作系統(tǒng)把數(shù)據(jù)從內(nèi)核態(tài)copy到用戶態(tài)的buffer中。

但如果用mmap情況就不一樣了,只要你的進程地址空間足夠大,可以直接把這個大文件映射到你的進程地址空間中,即使該文件大小超過物理內(nèi)存也可以,這就是虛擬內(nèi)存的巧妙之處了,當物理內(nèi)存的空閑空間所剩無幾時虛擬內(nèi)存會把你進程地址空間中不常用的部分扔出去,這樣你就可以繼續(xù)在有限的物理內(nèi)存中處理超大文件了,這個過程對程序員是透明的,虛擬內(nèi)存都給你處理好了。關于虛擬內(nèi)存的透徹講解請參考博主的深入理解操作系統(tǒng),關注公眾號碼農(nóng)的荒島求生并回復操作系統(tǒng)即可。

注意,mmap與虛擬內(nèi)存的結(jié)合在處理大文件時可以簡化代碼設計,但在性能上是否優(yōu)于傳統(tǒng)的read/write方法就不一定了,還是那句話關于mmap與傳統(tǒng)IO在涉及到性能時你需要基于真實的應用場景測試。

使用mmap處理大文件要注意一點,如果你的系統(tǒng)是32位的話,進程的地址空間就只有4G,這其中還有一部分預留給操作系統(tǒng),因此在32位系統(tǒng)下可能不足以在你的進程地址空間中找到一塊連續(xù)的空間來映射該文件,在64位系統(tǒng)下則無需擔心地址空間不足的問題,這一點要注意。

節(jié)省內(nèi)存

這可能是mmap最大的優(yōu)勢,以及最好的應用場景了。

假設有一個文件,很多進程的運行都依賴于此文件,而且還是有一個假設,那就是這些進程是以只讀(read-only)的方式依賴于此文件。

你一定在想,這么神奇?很多進程以只讀的方式依賴此文件?有這樣的文件嗎?

答案是肯定的,這就是動態(tài)鏈接庫。

要想弄清楚動態(tài)鏈接庫,我們就不得不從靜態(tài)庫說起。

假設有三個程序A、B、C依賴一個靜態(tài)庫,那么鏈接器在生成可執(zhí)行程序A、B、C時會把該靜態(tài)庫copy到A、B、C中,就像這樣:

假設你本身要寫的代碼只有2MB大小,但卻依賴了一個100MB的靜態(tài)庫,那么最終生成的可執(zhí)行程序就是102MB,盡管你本身的代碼只有2MB。

而且從圖中我們可以看出,可執(zhí)行程序A、B、C中都有一部分靜態(tài)庫的副本,這里面的內(nèi)容是完全一樣的,那么很顯然,這些可執(zhí)行程序放在磁盤上會浪費磁盤空間,加載到內(nèi)存中運行時會浪費內(nèi)存空間。

那么該怎么解決這個問題呢?

很簡單,可執(zhí)行程序A、B、C中為什么都要各自保存一份完全一樣的數(shù)據(jù)呢?其實我們只需要在可執(zhí)行程序A、B、C中保存一小點信息,這點信息里記錄了依賴了哪個庫,那么當可執(zhí)行程序運行起來后再把相應的庫加載到內(nèi)存中:

依然假設你本身要寫的代碼只有2MB大小,此時依賴了一個100MB的動態(tài)鏈接庫,那么最終生成的可執(zhí)行程序就是2MB,盡管你依賴了一個100MB的庫。

而且從圖中可以看出,此時可執(zhí)行程序ABC中已經(jīng)沒有冗余信息了,這不但節(jié)省磁盤空間,而且節(jié)省內(nèi)存空間,讓有限的內(nèi)存可以同時運行更多的進程,是不是很酷。

現(xiàn)在我們已經(jīng)知道了動態(tài)庫的妙用,但我們并沒有說明動態(tài)庫是怎么節(jié)省內(nèi)存的,接下來mmap就該登場了。

你不是很多進程都依賴于同一個庫嘛,那么我就用mmap把該庫直接映射到各個進程的地址空間中,盡管每個進程都認為自己地址空間中加載了該庫,但實際上該庫在內(nèi)存中只有一份。

mmap就這樣很神奇和動態(tài)鏈接庫聯(lián)動起來了,關于鏈接器以及靜態(tài)庫動態(tài)庫等更加詳細的講解你可以關注公眾號碼農(nóng)的荒島求生并回復鏈接器即可。

想用好mmap沒那么容易

現(xiàn)在你應該大體了解mmap,想用好mmap你必須對虛擬內(nèi)存有一個較為透徹的理解,并且能對你的應用場景有一個透徹的理解,在使用mmap之前問問自己是不是還有更好的辦法,因此,對于新手來說并不推薦使用該機制。

總結(jié)

mmap在博主眼里是一種很獨特的機制,這種機制最大的誘惑在于可以像讀寫內(nèi)存樣方便的操作磁盤文件,這簡直就像魔法一樣,因此在一些場景下可以簡化代碼設計。

但談到mmap的與標準IO(read/write)的性能情況就比較復雜了,標準IO設計到系統(tǒng)調(diào)用以及用戶態(tài)內(nèi)核態(tài)的copy問題,而mmap則涉及到維持內(nèi)存與磁盤文件的映射關系以及缺頁處理的開銷,單純的從理論分析這二者半斤八兩,如果你的應用場景對性能要求較高,那么你需要基于真實場景進行測試。

我是小風哥,希望這篇文章對大家理解mmap有所幫助。

 

責任編輯:武曉燕 來源: 碼農(nóng)的荒島求生
相關推薦

2015-07-20 09:21:19

程序員非程序員技能

2019-11-26 10:00:47

程序員技能開發(fā)者

2011-09-06 09:02:06

程序員

2018-06-25 08:49:23

2019-09-25 11:39:07

程序員編程技術

2016-03-02 10:49:08

程序員快樂

2020-06-05 07:52:25

程序員離職編碼

2014-04-14 16:02:01

2010-07-20 11:03:10

程序員

2019-12-24 17:05:56

CIO正版化Office

2021-08-28 23:26:14

程序員編碼電腦

2015-06-16 13:00:43

程序員跳槽原因

2011-08-29 17:05:55

2020-09-25 20:48:15

程序員技能開發(fā)者

2013-08-20 09:33:59

程序員

2012-03-06 09:22:46

程序員

2015-07-20 09:04:38

程序員知乎神奇

2011-05-13 14:34:02

程序員

2010-01-12 14:30:41

C++程序

2020-11-16 11:50:21

Python代碼命令
點贊
收藏

51CTO技術棧公眾號