為了高效、準確測試出該系統下，單個進程能夠申請到的最大虛存空間，所以編寫了一個Linux的測試程序。因為 64 位真的是個很可怕的數字，所以程序在申請內存空間時，先申請較大的內存塊（100G），直到沒有這么大的內存塊，然后申請上次能申請到的內存塊的一半。重復以上步驟，直到內存塊變得足夠小（小于 100Byte）。然后結束申請內存。代碼如下：

#include
#define SZ_100G (50*2147483648)  //100GB 的字節數

int main()
{
	int *p[1000000];//存放申請內存塊的指針以備釋放
	int *ptem;
	long long int block_sz,total_sz=0;
	int i,j;
	char c='c';

	printf("pid=%d\n",getpid());
	getchar();

	block_sz=SZ_100G;
	for(i=0;;i++)
	{
		printf("i=%d\n",i);
		p[i]=(int *)malloc(block_sz*sizeof(char));
		if(NULL==p[i])//當所申請的內存塊不成功時，把內存塊大小減半重新申請
		{
			block_sz=block_sz/2;
			p[i]=(int *)malloc(block_sz*sizeof(char));
		}
		total_sz=total_sz+block_sz;//累加所申請到的內存塊

		if(block_sz<100)//當內存塊小于 100 個字節時結束內存申請
			break;
	}
	getchar();

	ptem=p[0];
	for(j=0;;j++)
	{
		if(0==j%1000)
			c=getchar();
		if('e'==c)
			break;

		*(ptem+=(2*1024*1024))=c;
	}

	for(;i>=0;i--)//釋放所有內存塊
		free(p[i]);

	printf("total_sz=%ldByte\n",total_sz);
	

	return 0;
}

在終端 1 編譯運行上面代碼。
運行后，先在另一個終端（終端 2）執行：

cat /proc/6674/status

查看該進程的 status 文件如下圖圖一所示：

終端 1 終端 2

圖一

對于 status 文件，本文只會關注以下幾個參數：

VmPeak（進程所占用的虛存空間最大值）

VmRSS（進程正在占用物理內存大小）

VmSwap（進程占用交換區大小）

然后回車開始申請內存，當終端停止輸出數字時，再次在終端 2 執行：

cat /proc/6674/status

得到下圖圖二輸出：

終端 1 終端 2

圖二

對比圖一和圖二中的 VmPeak：

137438953320K – 12044K = 140737475866624 Byte

= 111 1111 1111 1111 1111 1111 0100 0001 0111 0000 0000 0000（B） Byte

是的，如果你沒有眼花，你數到上面得到的是一個 47 位!!!!二進制數。

47 位什么概念？大概是 128TB = 128*1024GB !!! (試問現在誰的個人電腦有這么大的硬盤？？更不要說內存)

一個進程能夠申請到這么恐怖的內存空間？這不但超過了物理內存、超過了物理內存+交換區、還超過了硬盤大小啊。這不科學啊。

但是從 status 讀出來的數據錯不了的。

首先，虛擬內存，顧名思義，虛擬的、并不是事實上存在，在一個進程的虛存空間里，只存在進程自己和系統內核，而不存在其他進程。這是為了方便編程和提高物理內存利用率而創造出來的一種機制（在過去內存是很貴的）。虛擬內存中對應著的是邏輯地址，邏輯地址通過操作系統和硬件的配合映射到物理內存上。（這里就不在多說虛擬內存的定義。如果把段頁式內存管理機制理解后，虛擬內存也就理解了。關于段頁式內存管理介紹可參考：深入理解操作系統之——分頁式存儲管理，深入理解操作系統之——段頁式存儲器管理。）

其二，交換區，實際上就是物理內存不夠用時，虛存空間的數據就必須映射到交換區上。

那么單個進程所能申請的最大虛存空間理應不會超過物理內存和交換區的和。然而實際卻是超過那么多。

然后，網上查閱相關資料，msdn 上看到了相關解釋。

傳送門：https://docs.microsoft.com/zh-cn/windows-hardware/drivers/gettingstarted/virtual-address-spaces

該文章介紹到，Windows 32 系統下，虛擬內存中，用戶空間占用了低地址 2G 的空間，系統內核占用了高地址 2G 空間。總共虛存空間就是 2^32Byte。

圖三

那么 64 位系統中，就系統而言，總共的虛存空間應當是 2^64Byte？

在該文章下面還有 Windows 64 位系統的虛存空間介紹，如下圖圖四所示。從圖中看到用戶虛存空間 8TB+系統空間 248TB=256TB=2^48 Byte ，這個數字似乎和上面所測得的單個進程能夠申請到的最大虛存空間的數字有點接近了。

圖四

注意看圖四，還可以發現 64 位系統中還有很大很大的虛存空間保留沒有被使用的。從這個出發繼續查閱資料，然后找到了關于目前 64 位 CPU 的相關說明。由于目前還遠遠用不到 64 位那么大的空間，所以 AMD 64 位 CPU 目前只用了 48 位的尋址。而 Intel 的 64 位 CPU 是和 AMD 交叉授權，所以 Intel 64CPU 也同樣只采用 48 位尋址。所以圖三的保留空間就得到了解釋。

再回到原先的問題，現在知道了就 64 位系統而言，虛擬內存空間是可以達到 2^48Byte 那么大的，參考 Windows 64 位系統虛存空間結構，可以猜測Linux 64 位系統下，用戶虛存空間和系統內核虛存空間分布和 Windows 是相似的，只是兩者大小比例有所差別。（因為找了很久，沒有找到Linux的官方文檔說明，只找到很舊的、32 位。所以不能提供準確的參考，如果有讀者找到，希望可以告訴作者一下補上）。

不過，到現在，還有問題沒有解決，為什么所申請的虛存空間會比物理內存與交換區的和大？

現在回到一開始沒有運行完的程序，在終端 1 回車繼續運行程序，程序接著會對所申請到的第一個 100G 內存塊每隔 2M 空間進行寫操作，每回車一次，會寫 1000 次。回車幾次后，在終端 2 再執行：

cat /proc/6674/status

得到下圖圖五：

圖五

由圖五可以看到正在使用的物理內存 VmRSS 變小了，正在使用的交換區空間 VmSwap 迅速增大。但是兩者之和是在一直增加的，這就說明，申請到的虛擬內存在未被使用之前，它只是一個數字，并沒有實際的物理內存和交換區與之相對應。當對虛存進行寫操作時，系統就會逐步分配物理內存，而物理內存的數據又會可能被系統調到交換區。現在問題逐漸明了了。

如果我不停地對虛存空間進行寫操作會怎樣，為了解決疑惑，在終端 1 不停回車，偶爾在終端 2 中查看 status 文件中的狀態，寫到一定程度后，終端 1 出現了

[1]    7893 killed     a.out

如圖六所示：

圖六

在進程結束之前查看到的 status 文件顯示 VmRSS+VmSwap 約等 1.8G，加上系統占用和其他進程占用，那么說此時物理內存和交換區已經接近極限了。再繼續運行寫的時候，操作系統為了系統的正常運行選擇把這個進程殺死了。那么所有的疑問也解決了。

系統所允許的申請的虛存空間是可以超過物理內存與交換區的和的。但是當進程所占用的物理內存加上交換區影響到了系統的正常運行就會被系統殺死。
編輯：hfy