如何让.NET应用使用更大的内存

我一直在思考为何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