突破 .NET 数组 20 亿上限的托管大数组实现方案

问题的根源不在元素个数而在字节数

.NET 里数组、集合、Span 以及大量 BCL API 都建立在 32 位长度和索引之上。GitHub 上关于 64 位数组支持的讨论最终以 won’t fix 收场，原因很直接：改动会波及运行时、GC、JIT、类型系统、反射和现有代码库。

绕开这个限制的常见做法有两种。一是分配非托管内存再用类封装，二是用交错数组模拟。前者手动管理内存容易出错，且只适合非托管数据，string、object 这类引用类型根本走不通。后者虽然避开了非托管内存，但本质是一组数组的集合，需要管理每个内部数组的大小，访问时处理跨段边界，和期待连续内存的 API 配合起来非常别扭。

换个角度想：限制针对的是数组的元素个数，不是元素背后的字节数。byte[1024] 存 1024 字节，int[1024] 存 4096 字节，数组长度相同，只是每个元素更大。那么让一个数组元素代表多个逻辑元素，问题就转化了。

struct TwoBytes
{
 public byte A;
 public byte B;
}

一个包含 20 亿个 TwoBytes 的数组能存下 40 亿个字节，它仍然是一个托管数组对象。

用 InlineArray 构造块类型

.NET 8 开始提供的 InlineArrayAttribute 让 struct 可以表示固定数量的重复字段，不必手写每个字段。

using System.Runtime.CompilerServices;

[InlineArray(4)]
struct FourBytes
{
 private byte _first;
}

这个特性同样适用于引用类型和泛型：

[InlineArray(4)]
struct FourStrings
{
 private string _first;
}

[InlineArray(4)]
struct FourElements<T>
{
 private T _first;
}

一个 FourElements<T> 数组的每个物理元素容纳四个逻辑 T。物理数组接近 20 亿个块，四倍宽度的块就能表示接近 80 亿个逻辑元素。BigArray<T> 的核心思路就在这里：底层是托管数组，但数组元素类型不一定是 T 本身，也可能是块类型，真实逻辑长度单独记录。

块长度的组合策略

最直观的做法是为每种块长度定义一个类型，从 ElementChunk1<T> 到 ElementChunk65535<T>，显然不现实。而且运行时有一个硬性限制：作为数组元素的值类型不能超过 65,535 字节。对某个 T，块长度上限是 65535 / Unsafe.SizeOf<T>()。byte 可以用 65,535，8 字节类型可以用 8,191，32 字节类型可以用 2,047。

块结构体本身可以嵌套组合：

[InlineArray(2)]
struct ElementChunk2<T>
{
 private T _first;
}

[InlineArray(3)]
struct ElementChunk3<T>
{
 private T _first;
}

ElementChunk2<ElementChunk3<T>> 表示 2 个包含 3 个值的块，即 6 个逻辑 T。byte 能用的最大块长度 65,535 可以写成：

ElementChunk3<ElementChunk5<ElementChunk17<ElementChunk257<byte>>>>

因为 3 × 5 × 17 × 257 = 65535。只保留一组质数长度的基础块类型，通过嵌套组合出其他长度，覆盖 1 到 65,535 之间需要的块长度只需要 85 个基础块类型，从 ElementChunk2<T> 到 ElementChunk8191<T>。

分配时计算请求的逻辑长度需要多少个物理块：

var chunkSize = Unsafe.SizeOf<T>();
var chunks = length / chunkSize + (length % chunkSize == 0 ? 0 : 1);

Array array = chunkSize switch
{
 1 => new ElementChunk1<T>[chunks],
 2 => new ElementChunk2<T>[chunks],
 3 => new ElementChunk3<T>[chunks],
 4 => new ElementChunk2<ElementChunk2<T>>[chunks],
 5 => new ElementChunk5<T>[chunks],
 6 => new ElementChunk2<ElementChunk3<T>>[chunks],
 7 => new ElementChunk7<T>[chunks],
 8 => new ElementChunk2<ElementChunk2<ElementChunk2<T>>>[chunks],
 9 => new ElementChunk3<ElementChunk3<T>>[chunks],
 10 => new ElementChunk2<ElementChunk5<T>>[chunks],
 // ...
 65535 => new ElementChunk3<ElementChunk5<ElementChunk17<ElementChunk257<T>>>>[chunks],
};

chunks 是真实托管数组的长度，和 BigArray<T> 暴露的逻辑长度不同。逻辑长度 10,000、块大小 4,095 时，分配 3 个物理块，最后一个块只用到一部分，真正的逻辑终点由 _length 记录。多分配的空间很小，最坏情况是逻辑长度刚好比块大小的整数倍多 1 且块大小为 65,535，最后一个块只使用 1 个字节。