比爾·蓋茨在上世紀80年代說的“640K ought to be enough for anyone”

也就是“640K記憶體對哪個人來說都夠用了”

那個年代，微軟開發的還是DOS操作系統，程式員們還在絞盡腦汁，想要用好這極為有限的640K記憶體

而現在，我手頭的Mac Book Pro已經是16G記憶體了，上升了一萬倍還不止。

那比爾·蓋茨這句話在當時也是完全的無稽之談麽？有沒有哪怕一點點的道理呢？這一講里，我就和你一起來看一看。

1 程式裝載的挑戰

在運行這些可執行文件的時候，我們其實是通過一個裝載器，解析ELF或者PE格式的可執行文件

裝載器會把對應的指令和數據載入到記憶體裡面來，讓CPU去執行。

裝載到記憶體,裝載器需要滿足兩個要求

• 可執行程式載入後占用的記憶體空間應該是連續的
  執行指令的時候，程式計數器是順序地一條一條指令執行。這意味著，這一條條指令需要連續地存儲在一起
• 需要同時載入很多個程式，並且不能讓程式自己規定在記憶體中載入的位置
  雖然編譯出來的指令里已經有了對應的各種各樣的記憶體地址，但是實際載入的時候，我們其實沒有辦法確保，這個程式一定載入在哪一段記憶體地址上
  因為現在的電腦通常會同時運行很多個程式，可能你想要的記憶體地址已經被其他載入了的程式占用

要滿足這兩個基本的要求，我們很容易想到一個辦法。那就是我們可以在記憶體裡面，找到一段連續的記憶體空間，然後分配給裝載的程式，然後把這段連續的記憶體空間地址，和整個程式指令里指定的記憶體地址做一個映射。

指令里用到的記憶體地址叫作虛擬記憶體地址（Virtual Memory Address）

實際在記憶體硬體裡面的空間地址，我們叫物理記憶體地址（Physical Memory Address）

程式里有指令和各種記憶體地址，我們只需要關心虛擬記憶體地址就行了

對於任何一個程式來說，它看到的都是同樣的記憶體地址。我們維護一個虛擬記憶體到物理記憶體的映射表，這樣實際程式指令執行的時候，會通過虛擬記憶體地址，找到對應的物理記憶體地址，然後執行。因為是連續的記憶體地址空間，所以我們只需要維護映射關係的起始地址和對應的空間大小就可以了。

2 記憶體分段

這種找出一段連續的物理記憶體和虛擬記憶體地址進行映射的方法，我們叫分段（Segmentation）。

這裡的段，就是指系統分配出來的那個連續的記憶體空間。

分段的辦法很好，解決了程式本身不需要關心具體的物理記憶體地址的問題，但它也有一些不足之處，第一個就是記憶體碎片（Memory Fragmentation）

舉個例子

電腦有1GB的記憶體

先啟動一個圖形渲染程式，占用了512MB的記憶體

接著啟動一個Chrome瀏覽器，占用了128MB記憶體

再啟動一個PY程式，占用了256MB記憶體

這個時候，我們關掉Chrome，於是空閑記憶體還有1024 - 512 - 256 = 256MB

按理來說，我們有足夠的空間再去裝載一個200MB的程式。但是，這256MB的記憶體空間不是連續的，而是被分成了兩段128MB的記憶體

因此，實際情況是，我們的程式沒辦法載入進來。

當然了,有辦法解決 --- 記憶體交換（Memory Swapping）

我們可以把Python程式占用的256MB記憶體寫到硬碟，再從硬碟上讀回來到記憶體裡面

不過讀回來的時候，我們不再把它載入到原來的位置，而是緊緊跟在那已經被占用了的512MB記憶體後面

這樣，我們就有了連續的256MB記憶體空間，就可以去載入一個新的200MB的程式。如果你自己安裝過Linux操作系統，你應該遇到過分配一個swap硬碟分區的問題

這塊分出來的磁碟空間，其實就是專門給Linux操作系統進行記憶體交換用的。

虛擬記憶體、分段，再加上記憶體交換

看起來似乎已經解決了電腦同時裝載運行很多個程式的問題

不過三者的組合仍然會遇到一個性能瓶頸

• 硬碟的訪問速度要比記憶體慢很多
• 而每一次記憶體交換，我們都需要把一大段連續的記憶體數據寫到硬碟上

所以，如果記憶體交換的時候，交換的是一個很占記憶體空間的程式，這樣整個機器都會顯得卡頓。

3 記憶體分頁

既然問題出在記憶體碎片和記憶體交換的空間太大上，那麼解決問題的辦法就是，少出現一些記憶體碎片。

另外，當需要進行記憶體交換的時候，讓需要交換寫入或者從磁碟裝載的數據更少一點，這樣就可以解決這個問題。

這個辦法，在現在電腦的記憶體管理裡面，就叫作記憶體分頁（Paging）

**和分段這樣分配一整段連續的空間給到程式相比

分頁則是把整個物理記憶體空間切成一段段固定尺寸的大小**

而對應的程式所需要占用的虛擬記憶體空間，也會同樣切成一段段固定尺寸的大小。

這樣一個連續並且尺寸固定的記憶體空間，我們叫頁（Page）。

從虛擬記憶體到物理記憶體的映射，不再是拿整段連續的記憶體的物理地址，而是按照一個個頁來的。

頁的尺寸一般遠遠小於整個程式的大小。

在Linux下，我們通常只設置成4KB。你可以通過命令看看你手頭的Linux系統設置的頁的大小。

由於記憶體空間都是預先劃分好的，也就沒有不能使用的碎片，而只有被釋放出來的很多4KB的頁。

即使記憶體空間不夠，需要讓現有的、正在運行的其他程式

通過記憶體交換釋放出一些記憶體的頁出來，一次性寫入磁碟的也只有少數的一個頁或者幾個頁，不會花太多時間，讓整個機器被記憶體交換的過程給卡住。

分頁的方式使得載入程式的時候，不再需要一次性把程式載入到物理記憶體中

可以在進行虛擬記憶體和物理記憶體的頁之間的映射後，並不真的把頁載入到物理記憶體里，而是只在程式運行中，需要用到對應虛擬記憶體頁裡面的指令和數據時，再載入到物理記憶體裡面去。

實際上，我們的操作系統，的確是這麼做的

當要讀取特定的頁，卻發現數據並沒有載入到物理記憶體里的時候，就會觸發一個來自於CPU的缺頁錯誤（Page Fault）

操作系統會捕捉到這個錯誤，然後將對應的頁，從存放在硬碟上的虛擬記憶體里讀取出來，載入到物理記憶體里。這種方式，使得我們可以運行那些遠大於我們實際物理記憶體的程式。同時，這樣一來，任何程式都不需要一次性載入完所有指令和數據，只需要載入當前需要用到就行了。

通過虛擬記憶體、記憶體交換和記憶體分頁這三個技術的組合，我們最終得到了一個讓程式不需要考慮實際的物理記憶體地址、大小和當前分配空間的解決方案。

這些技術和方法，對於我們程式的編寫、編譯和鏈接過程都是透明的。這也是我們在電腦的軟硬體開發中常用的一種方法，就是加入一個間接層。

通過引入虛擬記憶體、頁映射和記憶體交換，我們的程式本身，就不再需要考慮對應的真實的記憶體地址、程式載入、記憶體管理等問題了。任何一個程式，都只需要把記憶體當成是一塊完整而連續的空間來直接使用。

4 總結

電腦只要640K記憶體就夠了嗎？很顯然，現在來看，比爾·蓋茨的這個判斷是不合理的，那為什麼他會這麼認為呢？因為他也是一個很優秀的程式員啊！

在虛擬記憶體、記憶體交換和記憶體分頁這三者結合之下，你會發現，其實要運行一個程式，“必需”的記憶體是很少的。CPU只需要執行當前的指令，極限情況下，記憶體也只需要載入一頁就好了。再大的程式，也可以分成一頁。每次，只在需要用到對應的數據和指令的時候，從硬碟上交換到記憶體裡面來就好了。以我們現在4K記憶體一頁的大小，640K記憶體也能放下足足160頁呢，也無怪乎在比爾·蓋茨會說出“640K ought to be enough for anyone”這樣的話。

不過呢，硬碟的訪問速度比記憶體慢很多，所以我們現在的電腦，沒有個幾G的記憶體都不好意思和人打招呼。

那麼，除了程式分頁裝載這種方式之外，我們還有其他優化記憶體使用的方式麽？下一講，我們就一起來看看“動態裝載”，學習一下讓兩個不同的應用程式，共用一個共用程式庫的辦法。

5 推薦閱讀

想要更深入地瞭解代碼裝載的詳細過程，推薦你閱讀《程式員的自我修養——鏈接、裝載和庫》的第1章和第6章。

6 思考

在Java這樣使用虛擬機的編程語言裡面，我們寫的程式是怎麼裝載到記憶體裡面來的呢？它也和我們講的一樣，是通過記憶體分頁和記憶體交換的方式載入到記憶體裡面來的麽？

jvm已經是上層應用，無需考慮物理分頁，一般更直接是考慮對象本身的空間大小，物理硬體管理統一由承載jvm的操縱系統去解決吧

參考

深入淺出電腦組成原理