我一直在思考为何Redis这种应用就能独占那么大的内存空间而我开发的应用为何只有4GB大小左右，在此基础上也问了一些大佬，最终还是验证下自己的猜测。
操作系统限制
主要为32位操作系统和64位操作系统。
每个进程自身还分为了用户进程空间和内核进程空间，基本上各一半，而应用本身主要的空间就是用户进程空间。
32位操作系统寻址长度
寻址总线宽度32位，2^32次方，也就是4GB 大小
那么，用户态空间(用户空间 只有2G)
64位操作系统寻址长度
寻址总线实际总线宽度48位，2^48次方，也就是256TB 大小
操作系统本身的限制（Windows）
以上说的是32位进程的用户模式虚拟地址空间为2GB，在32位系统上可以打开3GB开关或者采用4GT技术后，最多能达到3GB的用户空间，在64位系统上默认是打开的，最多分配4GB的虚拟用户模式内存。
而在64位进程的用户模拟虚拟空间，在32位上不适用，而在64位系统中默认开启了这个功能，并且能达到8TB以上的虚拟内存。
这个图说的是实际上在这个操作系统下，真实的物理内存 在86，也就是32位下最多只有4GB 物理内存的支持，那为啥我们看到实际上win7 32位也支持很大的内存条，那是因为开启了 物理地址扩展 PAE 功能，而应用自身的寻址空间是不变的。
可以明显感觉到 Win11 比 Win10 能支持的物理内存更大
服务器版本的操作系统支持的更更大，当然，也没有得到 物理系统本身的极限 256TB。
也说明了实际的物理内存，服务器版本会支持更大的物理内存。
.NET 应用自身的限制
.NET 这边因为有CLR的存在，把内存又分为了托管内存和非托管内存，而用户态空间，也就是用户空间实际上就是托管内存空间，它的大小实际上是限制住的。
所以实际上，托管数组的长度限制在0x7FFFFFC7了，官方的说法是为了防止溢出(《.NET 运行时 最大长度限制》)。
Retrieved 280000000 items limit:2147483591 out:False 0GB个 of data .2 GB
大概意思就是，创建了 280000000的随机数，double类型的，数组的极限是0x7FFFFFC7（ 2147483591），是否超出了这个极限，大概有多少GB条数据，一共占用多少GB空间。
可以看到最后一条数据
一共创建了 2140000000条，距离极限相差 7,483,591条，基本证明，这个限制是存在的。
实际上，它一共占用了14GB 内存（大概，实际上波动还挺大）
public static void Test0()
{
Double[] values = GetData();
// Compute mean.
Console.WriteLine("Sample mean: {0}, N = {1}",
GetMean(values), values.Length);
static Double[] GetData()
{
var d = 0x7FFFFFC7;
Random rnd = new Random();
List<Double> values = new List<Double>();
for (int ctr = 1; ctr <= int.MaxValue; ctr++)
{
values.Add(rnd.NextDouble());
if (ctr % 10000000 == 0)
{
var memSize = ((long)values.Count * 8) / 1024 / 1024 / 1024;
Console.WriteLine($"Retrieved {
ctr} items limit:{
d} out:{
ctr >= d} {
(long)values.Count / 1024 / 1024 / 1024}GB个 of data .{
memSize} GB");
}
}
return values.ToArray();
}
static Double GetMean(Double[] values)
{
Double sum = 0;
foreach (var value in values)
sum += value;
return sum / values.Length;
}
}
这是64位应用自身可以操作大内存的验证。
而32位应用只操作了6千万条数据就内存溢出了，如下图。
非托管内存申请大内存
public static void Test2()
{
var list = new List<IntPtr>();
try
{
for (int i = 0; i < 8; i++)
{
var ptr = Marshal.AllocHGlobal(int.MaxValue);//默认最大2G申请，单个方法
list.Add(ptr);
for (int j = 0; j < int.MaxValue; j++)
{
Marshal.WriteByte(ptr, j, (byte)(66 + i));
}
Console.WriteLine($"写入成功{i}");
}
Console.WriteLine("申请完成");
Console.ReadLine();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
finally
{
foreach (var item in list)
{
Marshal.FreeHGlobal(item);
}
}
}
64位应用
写入全部成功
内存占用也基本占满了整个内存，剩余的16GB。
32位应用
而32位应用程序，直接内存就溢出了。
所以也证明，非托管资源跟32位进程寻址空间是有关系的。
大内存应用的方案
大内存应该是大于4G内存的才叫大内存。
基本上就不太考虑32位应用了。毕竟32位应用的寻址空间太过受限，尽量采用64位应用开发，可以使用托管资源实现大内存应用和非托管内存实现大应用。
MemoryMappedFiles (内存文件映射方案)
这个方案的好处是，虽然应用空间最小2GB，但是，可以在这2GB空间里实现视窗寻址文件，实现另外一种大内存的方案。
也不受限于应用的地址位数（86,64）。
Marshal.AllocHGlobal (非托管资管)
用这个的话，感觉回到了C语言时代，需要自己管理资源的申请与释放，另外，只有64位系统才会有更多的内存申请。
64位应用
在托管资源下，64位应用本身的空间已经能占用很大的空间，足够进行大内存应用的开发。也建议使用这种方式。
多进程
另外一种简单的方案就是采用多进程的方式实现多占内存资源。
代码地址
https://github.com/kesshei/MemeryTest.git
https://gitee.com/kesshei/MemeryTest.git
总结
一直在思考大内存的应用，如何申请大的内存，只有实际测试和验证才知道有哪种以及哪种的方式是最佳的。
现在才明白，Redis 64位系统不限制内存，32位系统最多使用3GB内存。所以，如果你想开发一个类Redis这种的中间件，内存的限制就这么多。
参考资料地址
《Windows 和 Windows Server 版本的内存限制》
https://learn.microsoft.com/zh-cn/windows/win32/memory/memory-limits-for-windows-releases?redirectedfrom=MSDN
《What Is 4GT? 什么是4GT？》
https://learn.microsoft.com/zh-cn/previous-versions/windows/it-pro/windows-server-2003/cc786709(v=ws.10)
《物理地址扩展 PAE》
https://learn.microsoft.com/zh-cn/windows/win32/memory/physical-address-extension
《.NET 运行时 最大长度限制》
https://github.com/dotnet/runtime/blob/f107b63fca1bd617a106e3cc7e86b337151bff79/src/coreclr/vm/gchelpers.cpp#L350
阅
一键三连呦！，感谢大佬的支持，您的支持就是我的动力!
