1 問題描述
目前公司的很多程式需要在32位模式下執行，有些專案的相關系統容易遇到記憶體溢位的問題，系統在使用過程中不太穩定。通過分析得出，預設情況下，32程式的記憶體位址空間只有2g，這2g記憶體除了儲存程式資料外還需要儲存程式本身，根據經驗，程式一旦使用超過1g的記憶體就不太穩定。
將程式中耗記憶體的功能拆分成單獨的程序。此方法在目前的各個專案開發中正在使用。但有時候會出現功能無法拆分（如資料瀏覽），或拆分後還出現主程序較長時間使用還是出現記憶體溢位的問題。所以此方案還不能完全解決這個記憶體溢位的問題。
通過開啟/largeaddressaware 的方式突破單程序2個g的限制（理論最大4g 虛擬位址空間）。
具體操作方法：
方法1：在命令列依次執行以下幾行命令
cd c:\program files(x86)\microsoft visual studio 11.0\vc\bin
vcvars32.bat
editbin /largeaddressawrexx.exe
方法2：在vs （以vs2012為例）專案屬性->生成事件->後期生成事件命令列中設定如下命令列：
call"%vs110comntools%..\tools\vsvars32.bat"
editbin /largeaddressaware$(targetpath)
以下為測試程式的編寫示例：
測試程式：通過在exe中進行編寫以下大量分配記憶體的程式進行測試，將錯誤資訊輸出到日誌
static void main(string args)
tryint count = 100000000;
listlst = newlist(count);
for (int i = 0; i < count;i++)
lst.add(new int[1000000]);
catch (exception ex)
1)未突破2g限制的日誌資訊如下：
19:33:07:849
system.outofmemoryexception:引發型別為「system.outofmemoryexception」的異常。
19:33:07:855
當前專用內大小：1.69 gb
當前虛擬記憶體大小：1.94 gb
最大虛擬記憶體量：1.94 gb
物理記憶體總大小：4 gb
可用物理記憶體大小：4 gb
虛擬記憶體總大小：2 gb
可用虛擬記憶體大小：62.31 mb
交換空間總大小：4 gb
可用交換空間大小：4 gb
2)突破4g限制的日誌資訊如下：
19:33:45:371
system.outofmemoryexception:引發型別為「system.outofmemoryexception」的異常。
19:33:45:377
當前專用內大小：3.59 gb
當前虛擬記憶體大小：3.9 gb
最大虛擬記憶體量：3.91 gb
物理記憶體總大小：4 gb
可用物理記憶體大小：4 gb
虛擬記憶體總大小：4 gb
可用虛擬記憶體大小：105.38 mb
交換空間總大小：4 gb
可用交換空間大小：4 gb
綜上，通過方案一和方案二相結合，能比較完美地解決32位程式記憶體溢位的問題（當然，如果這個程式使用過程中占用的記憶體達到3g以上的時候還是容易出問題，那就需要從程式本身去優化了）。
win764位系統上讓32位程式能申請到4gb記憶體方法：
乙個程序所能分配的最大記憶體是多大？這是由什麼決定的？：
c#程式記憶體分配：
c# .net 下 x86使用大記憶體的處理：
c# .net 下 x86使用大記憶體的處理：
研究c#物件所佔記憶體的大小，以及count與capacity的區別：
解決sqlserver限制2G記憶體限制安裝
記錄一次不滿足linux安裝sqlserver最小記憶體限制情況下安裝sqlserver方法。1.如果之前安裝了sqlserver但並未成功，要先解除安裝 如果未安裝過，跳過 sudo yum remove mssql server sudo rm rf var opt mssql sudo rm ...
解決Win32程式記憶體超2G崩潰問題
長期以來，我們遊戲的pc版本一直飽受崩潰的困擾。其中最大的崩潰原因是在各伺服器一村的地方開啟大視距之後，就很容易崩潰。一度懷疑是記憶體問題，但在實際執行中發現應用占用的內存在1.7g左右就崩潰了。後續經過一系列排查，崩潰的堆疊也讓人匪夷所思。例如在乙個函式內部，前幾行各數值顯示還正常，後面指標指向的...
32位與4G記憶體限制
32位有4g記憶體限制，好像人所共知。但這個32位是指32位的cpu還是32位的作業系統？答案是，都是。記憶體限制，是作業系統和硬體 cpu，也許還有記憶體控制器 共同制約的。cpu對應的是定址實體地址，而作業系統對應的是定址邏輯位址。實際上使用者在使用計算機時，程序所訪問到的位址是邏輯位址，並不是...