• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴(yán)以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            File Mapping析疑

            轉(zhuǎn)載自:http://blog.sina.com.cn/s/blog_5e83fce60100pz2p.html

            最初接觸File Mapping是為了能夠方便地處理一個(gè)幾百兆的大文件,當(dāng)時(shí)查了些資料大概了解了一下就匆匆動(dòng)手了,因?yàn)橹淙欢恢渌匀?,在使用過(guò)程中遇到了不少問(wèn)題,今天在這里就是想把這些歷史遺留問(wèn)題解決掉。

                問(wèn)題一、Mapping有“映射”之意,那么在該語(yǔ)境中形成映射關(guān)系的雙方是誰(shuí),也就是從哪里映射到哪里呢?
                要回答這個(gè)問(wèn)題,我們必須要對(duì)虛擬內(nèi)存有所了解。現(xiàn)在操作系統(tǒng)中,大多都使用虛擬內(nèi)存技術(shù)來(lái)對(duì)內(nèi)存進(jìn)行管理。通過(guò)虛擬內(nèi)存,操作系統(tǒng)給予了每個(gè)進(jìn)程一個(gè)統(tǒng)一的地址空間。在32位操作系統(tǒng)中,該地址空間的大小達(dá)到 2^32個(gè),也就是4G了。從一個(gè)進(jìn)程的角度看來(lái),這4G的地址空間是自己獨(dú)享的,也就是說(shuō),如果操作系統(tǒng)允許的話,我可以訪問(wèn)這4G地址空間中的任何一個(gè)。當(dāng)然,操作系統(tǒng)是不可能讓一個(gè)進(jìn)程隨心所欲地使用這些地址的。下面,我們來(lái)看看這些地址具體是怎樣分配的:



            上面這個(gè)圖大家應(yīng)該都很熟悉,它是Linux中進(jìn)程的內(nèi)存映象。我們可以看到,在4G的地址空間中,我們先從下往上看, 0~0x08047ffff(大概128M左右)是系統(tǒng)保留的,不能使用。read-only segment和read/write segment用以存放系統(tǒng)加載器從可執(zhí)行文件中載入的代碼段以及數(shù)據(jù)段等內(nèi)容。運(yùn)行時(shí)堆大家應(yīng)該都比較清楚,是動(dòng)態(tài)分配內(nèi)存的地方,我們通過(guò)malloc和free等函數(shù)動(dòng)態(tài)在堆中分配和釋放內(nèi)存,堆的大小是往上增長(zhǎng)的,最大可達(dá)到0x3FFFFFFF處。好,到這里我們?cè)趶纳贤驴矗?xc0000000以上是核心虛擬內(nèi)存,專門為操作系統(tǒng)核心的數(shù)據(jù)結(jié)構(gòu)以及代碼預(yù)留的,一般用戶進(jìn)程無(wú)權(quán)使用。然后就到了棧區(qū)了,這里是系統(tǒng)保存跟函數(shù)操作有關(guān)的數(shù)據(jù),如局部變量,函數(shù)參數(shù)等內(nèi)容。與堆不一樣,棧是從上往下增長(zhǎng)的,其棧頂通過(guò)寄存器esp指出。那么被堆和棧夾著的區(qū)域是干什么的呢?原來(lái),那是用來(lái)放動(dòng)態(tài)共享庫(kù)的。在C/C++庫(kù)文件簡(jiǎn)介中我們談到了共享庫(kù),動(dòng)態(tài)共享庫(kù)是在程序被載入時(shí)或者運(yùn)行過(guò)程中載入到進(jìn)程內(nèi)存空間中的,它存放的地方就是我們稱作內(nèi)存映射區(qū)的這個(gè)地方。
                這樣一看,原來(lái)進(jìn)程開始運(yùn)行時(shí),4G的地址已經(jīng)被用掉了不少,其中,光是操作系統(tǒng)所占用的核心虛擬內(nèi)存就達(dá)到1G,加上程序的代碼和數(shù)據(jù)以及動(dòng)態(tài)共享庫(kù)等等,我們大概就剩下2G左右的地址空間可以使用了。那么,這2G空間我們是如何使用的呢?第一,我們使用malloc函數(shù),在堆中分配空間,使堆往上增長(zhǎng);第二,我們?cè)诤瘮?shù)中使用局部的數(shù)據(jù),以及函數(shù)調(diào)用時(shí)現(xiàn)場(chǎng)的保留,使棧空間往下增長(zhǎng);第三,我們使用File Mapping,使內(nèi)存映射區(qū)往上增長(zhǎng)。
                好了,終于出現(xiàn)File Mapping 了?,F(xiàn)在,我們也可以知道題目中“映射”的其中一方了:內(nèi)存。原來(lái)它就是在內(nèi)存映射區(qū)中的一段地址空間。那么,“映射”的另一方又是什么呢?那自然是文件了。我們可以將任何類型任何大?。ㄖ灰僮飨到y(tǒng)支持,現(xiàn)在win32支持最大的文件為16EB,就是2^64)的文件映射到內(nèi)存映射區(qū)中。當(dāng)然,太大的文件我們不可能一次性把它全部映射到虛擬內(nèi)存中去,畢竟我們大概只有2G的地址空間,兩者間是不可能構(gòu)成一一對(duì)應(yīng)的關(guān)系的。此時(shí),我們可以將文件分段進(jìn)行映射,每次將文件的一部分映射到內(nèi)存空間中。映射完以后,我們就可以像訪問(wèn)內(nèi)存那樣直接訪問(wèn)文件了。

                問(wèn)題二、數(shù)據(jù)在哪呢?數(shù)據(jù)文件?物理內(nèi)存?頁(yè)面文件?
                這里,我們暫且將被映射的文件稱為數(shù)據(jù)文件。當(dāng)我們映射好一個(gè)數(shù)據(jù)文件以后,操作系統(tǒng)并不會(huì)馬上將文件中的內(nèi)容提交到物理內(nèi)存中去,數(shù)據(jù)還是原封不動(dòng)地放在數(shù)據(jù)文件中。但是,當(dāng)程序首次對(duì)文件中某個(gè)數(shù)據(jù)進(jìn)行訪問(wèn)時(shí)(read /write),操作系統(tǒng)就會(huì)將該數(shù)據(jù)從數(shù)據(jù)文件中調(diào)入物理內(nèi)存中,供CPU使用。操作完畢后,當(dāng)我們解除映射時(shí),操作系統(tǒng)將根據(jù)映射的屬性(write/write-on-copy)決定是將更改后的數(shù)據(jù)寫回到數(shù)據(jù)文件中還是將更改直接丟棄。Readonly 不存在這個(gè)問(wèn)題,因?yàn)椴豢赡鼙桓模虼藆nmap時(shí)只需將內(nèi)存中的數(shù)據(jù)丟棄就可以了。
                 這中間還有一個(gè)問(wèn)題,那就是在映射以后和解除映射之前這個(gè)時(shí)間段內(nèi),物理內(nèi)存中的數(shù)據(jù)是有可能被換出的(swap out),那么,換出時(shí)這些數(shù)據(jù)是被存放在數(shù)據(jù)文件中還是像一般數(shù)據(jù)那樣存放在系統(tǒng)的頁(yè)面文件中呢?同樣,這也是跟映射的屬性緊密相關(guān)的:
                如果映射為readonly,那么換出時(shí)只需修改相應(yīng)的頁(yè)表(page table)內(nèi)容,標(biāo)注其已被換出即可。
                如果映射為write-on-copy,那么換出將存放在頁(yè)面文件中,
                如果映射為write,那么換出時(shí)將寫會(huì)到數(shù)據(jù)文件中。
                  
                問(wèn)題三、使用File Mapping為什么可以提高訪問(wèn)文件的速度呢?
                 這是因?yàn)椴僮飨到y(tǒng)在處理一般讀寫跟處理內(nèi)存映射使用的方法不一樣。在處理一般的讀寫操作時(shí),操作系統(tǒng)一般使用中斷的方式,先將內(nèi)容拷貝到核心虛擬內(nèi)存緩沖,然后再拷貝到進(jìn)程空間中;但是,處理內(nèi)存映射文件時(shí),一般使用虛擬內(nèi)存管理器,無(wú)需進(jìn)行中間的拷貝過(guò)程,因此速度加快。此外,像Windows這樣使用頁(yè)式管理虛擬內(nèi)存的操作系統(tǒng)中,數(shù)據(jù)的換入換出都是以頁(yè)為單位的(通常是4k或者8k),因?yàn)槌绦蛞话愣季哂袝r(shí)間和空間的局部性(locality),因此,相當(dāng)于進(jìn)行了大量的緩沖操作,有利于提高性能。

                問(wèn)題四、什么情況適合使用 File Mapping呢?看看人家的建議:
            File mapping is effective in the following situations:

            • You have a large file whose contents you want to access randomly one or more times.

            • You have a small file whose contents you want to read into memory all at once and access frequently. This technique is best for files that are no more than a few virtual memory pages in size.

            • You want to cache specific portions of a file in memory. File mapping eliminates the need to cache the data at all, which leaves more room in the system disk caches for other data.

            You should not use file mapping in the following situations:

            • You want to read a file sequentially from start to finish only once.

            • The file is several hundred megabytes or more in size. (Mapping large files fills virtual memory space quickly. In addition, your program may not have the available space if it has been running for a while or its memory space is fragmented.)


                問(wèn)題五、為什么在操作大文件時(shí)速度變得很慢呢?
                遇到這個(gè)問(wèn)題,你可以首先打開Windows的任務(wù)管理器,看看你進(jìn)程究竟使用了多少的內(nèi)存。呵呵,通常都是個(gè)天文數(shù)字。占用了那么多的內(nèi)存,系統(tǒng)肯定就很慢了。遇到這樣的問(wèn)題,我們通常都是使用內(nèi)存映射文件對(duì)數(shù)據(jù)文件進(jìn)行遍歷操作,譬如像將A文件拷貝為B文件。上面我們提到,操作系統(tǒng)是在真正用到數(shù)據(jù)的時(shí)候才會(huì)把它從數(shù)據(jù)文件中提交到物理內(nèi)存里面的,因此,剛做好映射不進(jìn)行操作的話,進(jìn)程并不會(huì)消耗多少內(nèi)存。但是,一旦你開始進(jìn)行遍歷,那么,操作系統(tǒng)就馬上將它們調(diào)入物理內(nèi)存中(你可以看看頁(yè)面錯(cuò)誤的數(shù)量,肯定是飛速增長(zhǎng)的),于是,內(nèi)存就一路飛漲了。
                怎么辦呢?不要一次性把整個(gè)文件進(jìn)行映射,而是分開進(jìn)行,操作完一部分后,將它unmap掉,這樣,操作系統(tǒng)就會(huì)把它們“趕回家去”了,內(nèi)存就不會(huì)占用太高了。

            posted on 2014-02-25 00:35 楊粼波 閱讀(662) 評(píng)論(0)  編輯 收藏 引用


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問(wèn)   Chat2DB   管理


            婷婷综合久久中文字幕蜜桃三电影| 亚洲午夜无码AV毛片久久| 色欲综合久久中文字幕网| 亚洲欧美日韩久久精品第一区| 久久久久亚洲AV无码永不| 99久久婷婷国产一区二区| 亚洲国产成人精品久久久国产成人一区二区三区综| 久久青青草原精品国产软件| 天堂久久天堂AV色综合| 丁香久久婷婷国产午夜视频| 欧美成人免费观看久久| a级成人毛片久久| 亚洲欧美一级久久精品| 久久精品国产亚洲AV无码娇色| 国产精品免费久久久久久久久| 婷婷久久五月天| 青青草国产精品久久久久| 97精品依人久久久大香线蕉97| 色综合久久88色综合天天| 一本久久a久久精品亚洲| 久久久久久亚洲精品不卡| 国产精品久久久久久一区二区三区| 手机看片久久高清国产日韩| 国产精品久久永久免费| 日韩人妻无码一区二区三区久久| 久久综合九色欧美综合狠狠 | 91久久婷婷国产综合精品青草| 亚洲精品美女久久久久99小说| 国产一级持黄大片99久久| 狠狠色婷婷久久综合频道日韩| 国产精品美女久久久免费| 国产精品一区二区久久国产| 伊人久久综合成人网| 国产精品久久久久a影院| 中文成人久久久久影院免费观看| 99久久精品费精品国产| 伊人久久精品线影院| 久久福利青草精品资源站免费| 国产精品久久国产精麻豆99网站| 影音先锋女人AV鲁色资源网久久 | 国产成人精品免费久久久久|