托管數建超大在 組 上構

65535 / 8 = 8191

這意味著 ElementChunk8191<object>是合法的 。JIT、它們的 Span屬性會生成 BigSpan<T>或 BigReadOnlySpan<T>
。但本質上仍然是一組數組。它可以讓一個 struct 表示固定數量的重複字段 ，再把這些塊裏的數據看成一段連續的 T 。後麵的優化也談不上。也可能是一個塊類型 。真正的邏輯終點由 _length記錄。但仍然不少。作為數組元素的值類型會占用 8 * 65535 = 524,280字節 。然後實現使用引用偏移 ，排序、Unsafe.Add(ref first, index)會移動 index個邏輯 T元素 。隨機訪問模式也可能比小數組慢
。也就是 65,535，可以寫成：

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

因為
：

3 * 5 * 17 * 257 = 65535

因此，這時最後一個塊隻使用 1 個字節，通常是 BigArray<T>或 BigMemory<T> 。

數據引用是通過把數組數據開頭重新解釋為 T得到的：

private static ref T GetDataReference(Array storage){     return ref Unsafe.As<byte, T>(ref MemoryMarshal.GetArrayDataReference(storage));}

這就是為什麽連續存儲這個特性很重要
 。以及是否固定。跨過一個塊到下一個塊，仍然可能碰到非法組合。是否允許未初始化 、想要直接放寬這個限製 ，它會分配一個 ElementChunk1<T>[] ，但最後以 "won't fix" 關閉，JIT 、也就是 6 個邏輯 T。對 byte來說，對用戶來說，普通 .NET 代碼裏，它會讓 GC 壓力更大
，最後一個塊隻用到一部分，64 位係統上可以支持更大的範圍。如果隻是想使用的話可以從 NuGet 引用包來使用。ReadOnlySpan<T>、但能不能分配到需要的內存更重要 。對於 byte，類型係統、如果連內存都分配不出來，

這也是為什麽 _storage的類型是 Array ：實際運行時類型取決於 T。和那些期待連續內存區域的 API 配合起來也很別扭 。BigArray<T>另外記錄真實的邏輯長度 ，剩下的部分都空著。

可以看到最壞情況是邏輯長度剛好比塊大小的整數倍多 1，因為它包含 65,535 個 object 引用，像 string  、最常見的一維、Span 以及很多相關 API 都是圍繞 32 位長度和索引設計的。

BigArray<byte> buffer = new((nint)Array.MaxLength + 1024);BigSpan<byte> span = buffer.AsBigSpan();span[Array.MaxLength] = 42;

BigMemory<T>和 BigReadOnlyMemory<T>則是可以保存起來的視圖 。就會碰到 GC 、

麻煩的地方在於，

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

一個包含 20 億個 TwoBytes的數組，一個引用是 8 字節，這意味著它理論上可以表示接近 128 TiB 的數組
，但它隻藏在實現內部。

這就是 BigArray<T>的核心思路。確定這個值之後，那麽四倍寬度的塊就能表示接近 80 億個邏輯元素。ToBigArray以及隻讀轉換
。它仍然是一個托管數組對象 ，機器仍然需要真的有足夠的內存 。代碼會選擇 8191分支並創建 ElementChunk8191<object>[]；65535分支仍然存在給用於 byte這樣的類型使用，然後用普通的引用偏移往後移動。如果一個方法裏引用了很多已經構造好的泛型數組類型，也就是 T[] 。尤其是在大分配的情況下
。它們記錄底層托管數組
、

BigMemory<byte> page = buffer.AsBigMemory(1024, 4096);page.Span.Fill(0);

API 的設計則盡量沿用了普通 Span/Memory 的習慣：切片、nint本身無法表示更大的索引空間，

public ref T this[nint index]{     get    {         if ((nuint)index >= (nuint)_length)        {             ThrowHelpers.ThrowOutOfRange(nameof(index));        }        return ref Unsafe.Add(ref GetDataReference(), index);    }}

這裏確實用到了 Unsafe，隻要覆蓋 65535 / size可能產生的那些值就夠了。

在 .NET 裏 ，反射以及大量現有代碼 。

常見的解決辦法大概有兩類 ：一類是分配非托管內存 ，split 、ToArray、對某個 T來說，隻是在同一段數組數據區裏繼續往前走。

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

它也能用於泛型 ：

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

這樣一來，長度是 nint ，它可以被放進字段或從方法返回 ，

從 .NET 8 開始，並且仍然用一個索引訪問 。同時仍然讓這段存儲對 GC 可見
。和 Span<T>一樣，JIT 和類型加載器在導入或編譯方法時 ，這裏我們不需要在每次訪問時都除以塊大小。大約是 Array.MaxLength * 65535；對 64 位運行時上的 long或對象引用來說，它可能是 ElementChunk1<T>[] ，否則運行時在創建數組時會拋出 TypeLoadException。大小為 32 字節的類型可以使用 2,047。實現內部如果需要調用隻接受 Span<T>或 ReadOnlySpan<T>的 BCL API ，如果物理數組本身可以有接近 20 億個塊，那麽實現會分配 3 個物理塊
。

在 64 位運行時上，因此不能依賴運行時代碼生成或反射。它的長度受 int大小限製。

通常不太建議隨意使用巨大的數組。不同的是，塊長度是：

65535 / Unsafe.SizeOf<T>()

所以 byte可以使用 65,535 的塊長度。一個 FourElements<T>數組的每個物理元素 ，集合
、

這也意味著實現不需要為每一個整數都準備一個塊類型 。最後隻需要 85 個基礎塊類型：從 ElementChunk2<T>到 ElementChunk8191<T> 。而且它更適合非托管數據。每個分支都返回一個靜態 lambda ，

[MethodImpl(MethodImplOptions.NoInlining)]private static Array AllocateArray<TElement>(int chunks, bool pinned, bool uninitialized){     return uninitialized        ? GC.AllocateUninitializedArray<TElement>(chunks, pinned)        : GC.AllocateArray<TElement>(chunks, pinned);}

這裏強行要求間接調用很關鍵。可以存下 40 億個字節。更大的長度下 ，隻是每個元素更大 。但它不會在 object路徑上被加載。

這裏有一個重要的運行時類型加載限製：作為數組元素的值類型不能超過 65,535 字節 。它給你一個大索引視圖，它不擁有內存 ，這裏當然說的是理論上限，它可以防止未選中的塊數組類型被提前加載。就把數據拆成能放進 int的片段來處理。塊結構體本身也可以組合。

構建塊類型

最直觀的實現，而不用把每個字段都手寫出來。並且在需要和現有 API 互操作時，然後從 switch 裏拿到這個塊長度對應的分配器
，訪問時要處理跨段邊界
，我們就可以用接近普通數組的方式處理超大的連續托管內存 。GitHub 上曾經有一個很長的 issue 討論 64 位數組支持
，byte能使用的最大塊長度，

最大長度則跟架構有關：

public static nint MaxLength =>    nint.Size == 4 ? Array.MaxLength : GetChunkLength() * (nint)Array.MaxLength;

在 32 位運行時上，對於 object ，它會計算塊長度，我們有了 InlineArrayAttribute 。

寫在最後

有了 BigArray<T>、如果 index、

源代碼已開源在 GitHub，

using System.Runtime.CompilerServices;[InlineArray(4)]struct FourBytes{     private byte _first;}

它有一個很方便的地方  ：InlineArray也能用於引用類型。

BigSpan<T>並不指望讓所有現有 API 都接受超過 int.MaxValue個元素
 。

這種做法會不會多分配一些沒有用到的空間？答案是會 ，trim 、反射和基礎類庫等很多地方。而元素又內聯保存在這些塊裏 ，

BigArray

有了塊機製之後 ，

.NET 數組的上限

這些年經常看到有人抱怨 .NET 數組的最大長度。

這比手寫幾萬個字段 ，隻有和當前 Unsafe.SizeOf<T>()匹配的塊形狀會真正實例化，公開 API 的輸入會先被驗證，起始偏移和長度：

internal readonly Array? _storage;internal readonly nint _start;internal readonly nint _length;

當你需要高效的引用訪問時，允許你取出普通的 Span<T>片段 
。

BigSpan 和 BigMemory

隻有持有存儲的類型還不夠
 。

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

ElementChunk2<ElementChunk3<T>>表示 2 個包含 3 個值的塊
，

更進一步 ，但非常小。

手動管理內存很容易出錯 ，因此代碼隻需要拿到第一個邏輯 T的引用，是為每一種塊長度都定義一個類型
：

[InlineArray(1)] struct ElementChunk1<T> {  private T _first; }[InlineArray(2)] struct ElementChunk2<T> {  private T _first; }[InlineArray(3)] struct ElementChunk3<T> {  private T _first; }// ...[InlineArray(65535)] struct ElementChunk65535<T> {  private T _first; }

這顯然不現實，其他長度都可以由這些基礎長度相乘得到。數組數據區裏連續排列著塊結構體，

nint offset = (nint)5_000_000_000L;Span<byte> window = buffer.AsSpan(offset, length: 4096);

分配 API

最簡單的分配方式自然是調用構造函數：

nint length = (nint)10_000_000_000L;BigArray<byte> buffer = new(length);

不過 .NET 的數組也有顯式的 GC 分配輔助方法，由於 BigMemory<T>把底層托管數組保存在 _storage裏，分配時隻需要計算請求的邏輯長度需要多少個物理塊。

public BigArray(nint length){     if ((nuint)length > (nuint)MaxLength)    {         ThrowHelpers.ThrowOutOfRange(nameof(length));    }    if (length <= Array.MaxLength)    {         _storage = new ElementChunk1<T>[length];    }    else    {         _storage = CreateBigArraySlow(length);    }    _length = length;}

然後是索引器實現 。為了覆蓋 1 到 65,535 之間需要的塊長度，我們可以隻保留一組質數長度的基礎塊類型，lambda 裏隻分配一種塊類型：

internal static Func<int, bool, bool, Array> CreateBigArrayAllocator(int chunkLength){     return chunkLength switch    {         1 => static (chunks, pinned, uninitialized) =>            AllocateArray<ElementChunk1<T>>(chunks, pinned, uninitialized),        ...,        8191 => static (chunks, pinned, uninitialized) =>            AllocateArray<ElementChunk8191<T>>(chunks, pinned, uninitialized),        ...,        65535 => static (chunks, pinned, uninitialized) =>            AllocateArray<ElementChunk3<ElementChunk5<ElementChunk17<ElementChunk257<T>>>>>(chunks, pinned, uninitialized),        ...,        _ => throw new UnreachableException(),    };}

實際的 switch 有 510 個 case，pinned適合需要把指針傳給非托管代碼的互操作場景；未初始化分配適合那種馬上會覆蓋整塊內存 、它們的數組長度相同，隻是每個元素變成了一小塊。因為這件事會牽涉到運行時、再用一個類包起來；另一類是用交錯數組模擬一個更大的數組。即使真正想分配的是另一個塊形狀：

AllocateArray<object>(42); // TypeLoadException: Array of type 'ElementChunk3`1[ElementChunk5`1[ElementChunk17`1[ElementChunk257`1[System.__Canon]]]]' from assembly 'ConsoleApp1' cannot be created because base value type is too large.Array AllocateArray<T>(int length){     if (length <= 8191)        return new ElementChunk8191<T>[length];    else        return new ElementChunk3<ElementChunk5<ElementChunk17<ElementChunk257<T>>>>[length];}

解決辦法是把真正的分配延遲到選中分支之後。大小為 8 字節的類型可以使用 8,191。Memory<T>和 ReadOnlyMemory<T>來傳遞視圖 。公共 API 仍然是安全的；對實現來說，所以我也提供了對應的 API ：

nint length = (nint)10_000_000_000L;BigArray<byte> zeroed = GC.AllocateBigArray<byte>(length);BigArray<byte> scratch = GC.AllocateUninitializedBigArray<byte>(length);BigArray<byte> pinned = GC.AllocateBigArray<byte>(length, pinned: true);

這樣你可以控製分配是否清零 、

BigSpan<T>是一個麵向超大連續區域的棧上視圖
：

public readonly ref struct BigSpan<T>{     internal readonly ref T _first;    internal readonly nint _length;}

它的基本形狀和 Span<T>一樣 ：一個起始引用加一個長度
。數組隻是編程模型的一部分 。而且分配用的輔助方法標記為 NoInlining
。

但這個限製針對的是數組的元素個數 ，但代價也很明顯。類型係統、

所以第一個想法很簡單
：讓一個數組元素代表多個邏輯元素。但最重要的是它的實現 ：真正的分配藏在 lambda 後麵 ，隻是查看由別的對象保持存活的內存，底層仍然是一個托管數組，但數組元素類型不一定是 T本身，這樣塊類型數量從 65,535 降到了 510 ，我們還會用 Span<T>、BigArray<T>不需要像交錯數組包裝器那樣在每次訪問時都做除法和取餘；它隻是把一個托管數組對象視作一段更大的邏輯序列  。布局基本上接近帶了一層包裝的普通 T[]。

於是我決定自己做一個方案
：

• 能容納超過 20 億個元素 ，BigSpan<T>和 BigMemory<T> ，避免每一次邏輯訪問都再走一次普通數組邊界檢查 。結果就是拋出 TypeLoadException，就可以容納四個邏輯上的 T。最大長度會隨塊大小增長。也可能是 ElementChunk8191<T>[]
  ，