前不久組內又有一次我比較期待的分享:」Linux 的虛擬內存」。是某天晚上加班時,咱們討論虛擬內存的概念時,leader 發現幾位同事對虛擬內存認識不清後,特地給這位同窗挑選的主題(笑)。html
我以前瞭解一些操做系統的概念,主要是畢業後對本身大學四年的荒廢比較懊惱,以爲本身有些對不起計算機專業出身,因而在工做之餘抽出時間看了哈工大在網易雲課堂的操做系統公開課,本身也讀了一本講操做系統比較淺的書 《Linux內核設計與實現》,並且去年本身用 C 寫簡單的服務器時,也追根究底瞭解了更多的系統底層知識。多虧了這些知識,讓我對應用層的知識更有掌控感,也在上次排查問題時(從應用到內核查接口超時)助了我一臂之力。linux
前幾天另外一位同事來問另外一個虛擬內存相關的問題,我才發現對於虛擬內存,個人理解還不夠深入,一些概念還有些矛盾。因而翻一下資料從新整理一下這些知識,但願下次在用到它們時能更順暢。git
轉載隨意,文章會持續修訂,請註明來源地址:https://zhenbianshu.github.io 。github
毋庸置疑,虛擬內存絕對是操做系統中最重要的概念之一。我想主要是因爲內存的重要」戰略地位」。CPU太快,但容量小且功能單一,其餘 I/O 硬件支持各類花式功能,但是相對於 CPU,它們又太慢。因而它們之間就須要一種潤滑劑來做爲緩衝,這就是內存大顯身手的地方。api
而在現代操做系統中,多任務已經是標配。多任務並行,大大提高了 CPU 利用率,但卻引出了多個進程對內存操做的衝突問題,虛擬內存概念的提出就是爲了解決這個問題。緩存
上圖是虛擬內存最簡單也是最直觀的解釋。安全
操做系統有一塊物理內存(中間的部分),有兩個進程(實際會更多)P1 和 P2,操做系統偷偷地分別告訴 P1 和 P2,個人整個內存都是你的,隨便用,管夠。可事實上呢,操做系統只是給它們畫了個大餅,這些內存說是都給了 P1 和 P2,實際上只給了它們一個序號而已。只有當 P1 和 P2 真正開始使用這些內存時,系統纔開始使用展轉挪移,拼湊出各個塊給進程用,P2 覺得本身在用 A 內存,實際上已經被系統悄悄重定向到真正的 B 去了,甚至,當 P1 和 P2 共用了 C 內存,他們也不知道。服務器
操做系統的這種欺騙進程的手段,就是虛擬內存。對 P1 和 P2 等進程來講,它們都覺得本身佔用了整個內存,而本身使用的物理內存的哪段地址,它們並不知道也無需關心。多線程
虛擬內存是操做系統裏的概念,對操做系統來講,虛擬內存就是一張張的對照表,P1 獲取 A 內存裏的數據時應該去物理內存的 A 地址找,而找 B 內存裏的數據應該去物理內存的 C 地址。app
咱們知道系統裏的基本單位都是 Byte 字節,若是將每個虛擬內存的 Byte 都對應到物理內存的地址,每一個條目最少須要 8字節(32位虛擬地址->32位物理地址),在 4G 內存的狀況下,就須要 32GB 的空間來存放對照表,那麼這張表就大得真正的物理地址也放不下了,因而操做系統引入了 頁(Page)
的概念。
在系統啓動時,操做系統將整個物理內存以 4K 爲單位,劃分爲各個頁。以後進行內存分配時,都以頁爲單位,那麼虛擬內存頁對應物理內存頁的映射表就大大減少了,4G 內存,只須要 8M 的映射表便可,一些進程沒有使用到的虛擬內存,也並不須要保存映射關係,並且Linux 還爲大內存設計了多級頁表,能夠進一頁減小了內存消耗。操做系統虛擬內存到物理內存的映射表,就被稱爲頁表
。
咱們知道經過虛擬內存機制,每一個進程都覺得本身佔用了所有內存,進程訪問內存時,操做系統都會把進程提供的虛擬內存地址轉換爲物理地址,再去對應的物理地址上獲取數據。CPU 中有一種硬件,內存管理單元 MMU(Memory Management Unit)
專門用來將翻譯虛擬內存地址。CPU 還爲頁表尋址設置了緩存策略,因爲程序的局部性,其緩存命中率能達到 98%。
以上狀況是頁表內存在虛擬地址到物理地址的映射,而若是進程訪問的物理地址尚未被分配,系統則會產生一個缺頁中斷
,在中斷處理時,系統切到內核態爲進程虛擬地址分配物理地址。
虛擬內存不只經過內存地址轉換解決了多個進程訪問內存衝突的問題,還帶來更多的益處。
它有助於進程進行內存管理,主要體如今:
經過虛擬內存更容易實現內存和數據的共享。
在進程加載系統庫時,老是先分配一塊內存,將磁盤中的庫文件加載到這塊內存中,在直接使用物理內存時,因爲物理內存地址惟一,即便系統發現同一個庫在系統內加載了兩次,但每一個進程指定的加載內存不同,系統也無能爲力。
而在使用虛擬內存時,系統只須要將進程的虛擬內存地址指向庫文件所在的物理內存地址便可。如上文圖中所示,進程 P1 和 P2 的 B 地址都指向了物理地址 C。
而經過使用虛擬內存使用共享內存也很簡單,系統只須要將各個進程的虛擬內存地址指向系統分配的共享內存地址便可。
虛擬內存可讓幫進程」擴充」內存。
咱們前文提到了虛擬內存經過缺頁中斷爲進程分配物理內存,內存老是有限的,若是全部的物理內存都被佔用了怎麼辦呢?
Linux 提出 SWAP 的概念,Linux 中可使用 SWAP 分區,在分配物理內存,但可用內存不足時,將暫時不用的內存數據先放到磁盤上,讓有須要的進程先使用,等進程再須要使用這些數據時,再將這些數據加載到內存中,經過這種」交換」技術,Linux 可讓進程使用更多的內存。
在瞭解虛擬內存時,我也有過不少的問題。
最多見的就是 32位和64位的問題了。
CPU 經過物理總線訪問內存,那麼訪問地址的範圍就受限於機器總線的數量,在32位機器上,有32條總線,每條總線有高低兩種電位分別表明 bit 的 1 和 0,那麼可訪問的最大地址就是 2^32bit = 4GB,因此說 32 位機器上插入大於 4G 的內存是無效的,CPU 訪問不到多於 4G 的內存。
但 64位機器並無 64位總線,並且其最大內存還要受限於操做系統,Linux 目前支持最大 256G 內存。
根據虛擬內存的概念,在 32 位系統上運行 64 位軟件也並沒有不可,但因爲系統對虛擬內存地址的結構設計,64位的虛擬地址在32位系統內並不能使用。
操做系統使用了虛擬內存,咱們想要直接操做內存該怎麼辦呢?
Linux 會將各個設備都映射到 /dev/
目錄下的文件,咱們能夠經過這些設備文件直接操做硬件,內存也不例外。 在 Linux 中,內存設置被映射爲 /dev/mem
,root 用戶經過對這個文件讀寫,能夠直接操做內存。
使用 TOP 查看系統性能時,咱們會發如今 VIRT 這一列,Java 進程會佔用大量的虛擬內存。
致使這種問題的緣由是 Java 使用 Glibc 的 Arena 內存池分配了大量的虛擬內存並無使用。此外,Java 讀取的文件也會被映射爲虛擬內存,在虛擬機默認配置下 Java 每一個線程棧會佔用 1M 的虛擬內存。具體能夠查看 爲何linux下多線程程序如此消耗虛擬內存。
而真實佔用的物理內存要看 RES
(resident) 列,這一列的值纔是真正被映射到物理內存的大小。
咱們也能夠本身來管理 Linux 的虛擬內存。
查看系統內存狀況的方式有不少,free
、 vmstat
等命令均可輸出當前系統的內存狀態,須要注意的是可用內存並不僅是 free 這一列,因爲操做系統的 lazy 特性,大量的 buffer/cache 在進程再也不使用後,不會被當即清理,若是以前使用它們的進程再次運行還能夠繼續使用,它們在必要時也是能夠被利用的。
此外,經過 cat /proc/meminfo
能夠查看系統內存被使用的詳細狀況,包括髒頁狀態等。詳情可參見:/PROC/MEMINFO之謎。
若是想單獨查看某一進程的虛擬內存分佈狀況,可使用 pmap pid
命令,它會把虛擬內存各段的佔用狀況從低地址到高地址都列出來。
能夠添加 -XX
參數來輸出更詳細的信息。
咱們也能夠修改 Linux 的系統配置,使用 sysctl vm [-options] CONFIG
或 直接讀寫 /proc/sys/vm/
目錄下的文件來查看和修改配置。
虛擬內存的 SWAP 特性並不老是有益,聽任進程不停地將數據在內存與磁盤之間大量交換會極大地佔用 CPU,下降系統運行效率,因此有時候咱們並不但願使用 swap。
咱們能夠修改 vm.swappiness=0
來設置內存儘可能少使用 swap,或者乾脆使用 swapoff
命令禁用掉 SWAP。
虛擬內存的概念很是容易理解,可是它會衍生出來的一系列很是複雜的知識。本文只講了些基本原理,略過了不少細節,好比虛擬內存尋址中段寄存器的使用,操做系統使用虛擬內存加強緩存、緩衝區的應用等,有機會單獨拿出來講。
關於本文有什麼疑問能夠在下面留言交流,若是您以爲本文對您有幫助,歡迎關注個人 微博 或 GitHub 。您也能夠在個人 博客REPO 右上角點擊 Watch
並選擇 Releases only
項來 訂閱
個人博客,有新文章發佈會第一時間通知您。