這兩天果殼上有些人問到了關於在32位系統下使用4G或以上記憶體的問題。對於“32位作業系統能否使用4G或以上的記憶體”這個問題，在網路上爭論也是很多。下面，我就我自己對作業系統記憶體分配的理解，談談我的觀點。

         32位、64和“最大記憶體量”是怎麼回事

     首先需要明確一下，32位也好，64位也好，這個概念是同時存在於軟體、系統、主機板晶片組和CPU四個方面的。對於作業系統到底最多能支援多少記憶體這個問題，其實不是作業系統一方面說了算的。

     目前不少人可能對於CPU的定址概念有些模糊，認為CPU的定址範圍與其平常概念上的位寬直接聯絡，即所謂的32位CPU定址範圍為2^32，64位的則是2^64。其實這是一個錯誤的概念，對於CPU來說，這個的位寬一般是指是其資料匯流排位寬，和定址能力並無直接聯絡。至於一個CPU的定址位寬是多少則要看其具體的設計。

     而對於主機板晶片組這方面來說，目前的Intel x86平臺採取的是記憶體對映技術(Memory-Mapped I/O, MMIO)，也是PCI規範的一部分，也就是將I/O裝置放置在記憶體空間而非I/O空間，從處理器和作業系統看來，訪問一個硬體也就是訪問記憶體空間，因此主機板的晶片組也存在一個定址位寬的問題，當然也有可能成為記憶體總量的一個瓶頸。當然了，現在的新主機一般都不會有這個問題了。

     說完了硬體層面的概念，我們繼續看作業系統是如何與CPU進行“交流”的：

     Windows對於記憶體的管理，採取的是分頁機制，每個程序都佔有一定的虛擬地址空間，在這個機制下，這個空間一部分被對映到實體記憶體，一部分對映到虛擬記憶體（存在於硬碟上的一個或多個空間），還有一部分則可能什麼也沒有對映。同時，在CPU中，會設定一個“分頁標誌位”，如果CPU在執行指令時發現這個分頁標誌被設定，則會根據頁目錄和頁表中的對應關係，將指令中的虛擬地址轉換為實際的實體地址。

     目前的32位系統分頁大小為4K，定址位寬為32位，因此，第0個分頁的地址是0x00000000，第1個分頁地址從0x00001000開始，以此類推。所以，在目前的32位系統中，用到了32位中的高20位來標記物理頁，剩餘的12位用於新增一些標記資訊等。這樣，就可以支援到最大(2^20)*4096=4GB記憶體，除掉我們上面所說的為I/O保留的記憶體對映空間和作業系統本身保留的記憶體，剩下的就是我們在工作管理員裡能看到的可用空間。

上圖顯示的是我的電腦目前的記憶體分配情況

32位系統下的悲劇，這個圖是從網上搜羅來的

如何突破32位系統的4G限制

其實PAE並不是一個新鮮東西，也不是作業系統弄出來的特性

為了對PC伺服器提供大記憶體的支援，Intel採取了實體地址擴充套件(Physical Address Extension, PAE)的技術，將現有的IA32架構的處理器的地址匯流排從32位擴充套件到了36位，這樣從硬體層面來看，可以支援最多64G的記憶體。至於作業系統要如何實現對多出來的這幾位進行記憶體地址對映，簡要的說就是將原有的分頁表結構改成了三層結構。

     根據微軟官方的說法，下述系統支援開啟PAE功能：
          • Windows 7 (32 bit only)
          • Windows Server 2008 (32-bit only)
          • Windows Vista (32-bit only)
          • Windows Server 2003 (32-bit only)
          • Windows XP (32-bit only)
          • Windows 2000 Datacenter Server
          • Windows 2000 Advanced Server

     具體實現步驟可以見微軟官方文章：

http://msdn.microsoft.com/en-us/library/aa366796%28v=vs.85%29.aspx

     在這裡，推薦大家用一個叫Ready4GB的小程式，可以自動完成改造工作。

          開啟PAE的相容性問題和收益

     關於開啟PAE以後的相容性問題和是否有效可能是大家最為關心的問題了，根據微軟官方的說法，PAE開啟後，可能會造成部分驅動程式的相容性出現問題。事實上根據我自己的體驗，本人的NV 540M雙顯示卡就無法正確工作在PAE模式下，查證後發現所有的Nvidia的雙顯示卡都是不支援PAE的，網路上也有少數人反應開啟PAE後會造成藍屏等現象，是否有相關性尚無明確驗證。所以具體情況要嘗試後才能確定了。

     說到收益，網路上是眾說紛紜，很多人認為即便開啟了PAE，單個32位程式也無法分配到超過4G的空間，因此無效。

     先簡要了解一下應用程式執行時的記憶體使用情況是什麼樣的：因為不同使用者使用環境不會完全一樣，很顯然應用程式的開發人員不可能在設計階段去確定這個程式有多少記憶體空間可以使用。所以，正如前文所述，現在的應用程式執行時，都會分配到一個“虛擬”的記憶體空間，所有的記憶體請求都是在這個虛擬地址內完成的，然後再根據具體的記憶體對映關係，將這些虛擬地址轉換為具體的記憶體地址，或者是上的硬碟空間，在這些地方讀寫具體的資料。

     因此關於上述說法，前半句是對的，對於普通的32位程式來說，無論工作在何種環境下，其始終都只能分配到最多4G虛擬記憶體地址（0x00000000-0xFFFFFFFF），而這4G記憶體，其中有2G是作業系統保留的核心記憶體，另外2G才是程式的自由空間。這是32位程式的機制所決定的，即便我們將這些程式拿到現有的64位系統下執行，它們也只能分配到4G記憶體，2G可用記憶體。

應用程式記憶體分配示例

但是上述機制的存在絕不代表這PAE對於整個作業系統的效能沒有幫助，更多的記憶體有利於作業系統對多工進行記憶體分頁，可以提高系統在多工下的表現。總之，單個程式不能利用超過4G記憶體，不代表整個系統不能完全利用。

     另外，對於支援PAE的幾個系統來說，它們同時還支援另外一項技術：地址視窗擴充套件(Address Windowing Extensions, AWE)。這是一個程式設計時的介面，它可以使得32位程式訪問到超過4GB的記憶體，目前SQL Server是內建支援這項技術的。

     這幾個系統還有另外一個開關：/3GB，這個開關可以使得在給應用程式分配記憶體的時候，僅保留1G的核心記憶體，而將3G的記憶體保留為應用程式可用空間。但是由於這個開關縮減了核心記憶體空間，可能會造成系統的穩定性下降，因此建議還是用AWE功能進行替換。

     最後，我還在網上搜索相關文件的時候發現了一個很有意思的小東西4GB Patch(4GB補丁)，這個程式聲稱其能改造普通的32位程式，使之支援2G以上的可用記憶體：http://www.saqqdy.com/computer-skills/64-windows7-system-to-support-32-bit-process-virtual-memory-4g 。

     本人學識粗淺，對作業系統核心瞭解有限。以上內容如有謬誤，還望各位高人給與指點。